Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)

Neil Madden <neil.madden@forgerock.com> Mon, 28 October 2019 16:32 UTC

Return-Path: <neil.madden@forgerock.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8725E1208C4 for <oauth@ietfa.amsl.com>; Mon, 28 Oct 2019 09:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHPMwgyQ4McU for <oauth@ietfa.amsl.com>; Mon, 28 Oct 2019 09:32:41 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CC31208AA for <oauth@ietf.org>; Mon, 28 Oct 2019 09:32:41 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id z11so10557518wro.11 for <oauth@ietf.org>; Mon, 28 Oct 2019 09:32:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AJI0el2iuMpvwMfg1CwFHUL2u9OyUOCiMJhtJSYwnro=; b=RhfdMn4QmcDyNlSCK+8+tpAUPvFTItJI0qR4aS080GmSju2x6U4knkJBFwJKZHIdfb pvxJrboDW7TeyKqkrW2bQ7m00T5/zjc1ZKjcZBIdQVPsr6/deAkAbsC+nBi8csF1auDw 4hH/XA3OIT7o1ilS8RBJr1QZOgJ1bbGrWHbDg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AJI0el2iuMpvwMfg1CwFHUL2u9OyUOCiMJhtJSYwnro=; b=belkbd8SxKKZw5CWEN4Hf1KmbNUfExjnwos451BUTnHtlqQKG1o/vIr3sMQTqEXg6z rUkp1KSooe6u3myRXCkNTbfLNTNCmsmuQrcfjvC36ghe6W8KfSOL/Spta6ASbk7nV62I bDCBFZxKZKUaOxnQOJil7Hphs8+YFgtnQXBs2vmbmnrMLBVTJq902OWYmXWzPIA0z9Kf 4uLX5247Jrl4Va+XJ7xuDHSyzjj1DEl4AvV9pMXY8RS+2Y39vJmnya90UXZe8lpf2OG4 U076uJipcWIZpreDPj7ZOT5DTKlbX6a+W1sdTuKC2mvvcCN9LVCSbmTatma/zUfaawOX PCdA==
X-Gm-Message-State: APjAAAXkqEEjMK6TUx0hPe0cDHGd+2F6E1vQxn3WGW3GGr6jl/UznIMb oLdVSxWZO7WPcXKuC9DnPyGzaw==
X-Google-Smtp-Source: APXvYqxi6oLgQDIQKkabqnGE2zhTgdFNeB2QfYQxqK2XAUuucSlj4vBcU1ZcbipXDMAPFVZ83yMDPQ==
X-Received: by 2002:a5d:678e:: with SMTP id v14mr15207924wru.393.1572280359661; Mon, 28 Oct 2019 09:32:39 -0700 (PDT)
Received: from [192.168.1.64] (227.249.143.150.dyn.plus.net. [150.143.249.227]) by smtp.gmail.com with ESMTPSA id r188sm100878wmr.17.2019.10.28.09.32.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Oct 2019 09:32:38 -0700 (PDT)
From: Neil Madden <neil.madden@forgerock.com>
Message-Id: <E03CD445-39E8-4262-97BE-E0EE11231A63@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EC53E624-EF68-497D-AB57-76068DD10846"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 28 Oct 2019 16:32:37 +0000
In-Reply-To: <CA+k3eCQbku0V6z2wCM084FW342dY6=_H7mEv6U3sHCDgefkxXA@mail.gmail.com>
Cc: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, oauth <oauth@ietf.org>
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <CAEKOcs2gkM3Henz5nS04_EuBQXWWbJU5K02ErP0rnVZXmjxXJQ@mail.gmail.com> <20191021020546.GZ43312@kduck.mit.edu> <CA+k3eCS7pf3wXBkpbXE0AXKUGogo0YcHd8oWfiBfkPB5axGQQw@mail.gmail.com> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <20191024170326.GO69013@kduck.mit.edu> <CAGL6epJZtTXKSGFj0BfhF3kd_Z-z2xzOWXOPEKXc5m18Z4L1uA@mail.gmail.com> <CA+k3eCS8VuCfy4XeqYmLuuLK=rLvHsonSZj4i9O11U-mcua9Pg@mail.gmail.com> <CAGL6epKTV5hXqm2-qgUyG-iA90eLu49GjOKeyLcfsn2naTSV5w@mail.gmail.com> <CA+k3eCQ87n4m--nBc+PX7qE727fqA6vM=meEJZxwfnbpJ2dOsw@mail.gmail.com> <CAGL6epJQbVDrAKB+zNAPuaG0+uLxF3HijEE6=vgYaeXxB_2PXQ@mail.gmail.com> <CA+k3eCQbku0V6z2wCM084FW342dY6=_H7mEv6U3sHCDgefkxXA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Noa77YXq7Fpvz-gN3YR3J0_yC6c>
Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Oct 2019 16:32:44 -0000

While there are some benefits to standardizing headers for this kind of communication, there are some significant downsides - particularly when using headers to communicate critical security information like certs. It is *very* easy to misconfigure a reverse proxy to not strip Forwarded (or whatever) headers from incoming requests, allowing a client to simply supply a certificate as a header without authenticating the TLS connection with the corresponding private key. One good practice to prevent this is to pick a random and unguessable header name (configurable per installation) to be used for communicating the certificate, rather than using something fixed and standard. That way even if you misconfigure the proxy an attacker still has to try and guess the correct header name.

I suppose the same thing could be accomplished by having an extension for including a shared secret (or HMAC tag) in the header to authenticate it.

-- Neil

> On 28 Oct 2019, at 15:32, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>; wrote:
> 
> I don't think there's anything beyond defining something to carry the client certificate information (including the format and encoding). And it could well be a new RFC7239 parameter. Or it might just be a new HTTP header on its own.  
> 
> On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com <mailto:rifaat.ietf@gmail.com>> wrote:
> Thanks Brian,
> 
> I guess my question is: given RFC7239 and the fact that it is straightforward to secure the channel between the terminating reverse proxy and the backend service in a cluster, is there anything, from a standard perspective, that we need to do beyond defining a new parameter to carry the client certificate information?
> You seem suggest that the answer is yes. If so, can you please elaborate on why is that?
> 
> Regards,
>  Rifaat
> 
> 
> 
> On Mon, Oct 28, 2019 at 8:42 AM Brian Campbell <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>> wrote:
> 
> 
> On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com <mailto:rifaat.ietf@gmail.com>> wrote:
> 
> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>> wrote:
> 
> I did look at RFC7239 when doing that and it could have been made to work but felt the fit wasn't quite right and would have been more cumbersome to use than not.  
> 
> 
> Can you elaborate on this?
> These days, with the zero trust model in mind, there are orchestration tools, e.g. Istio, that easily allows you to establish an MTLS channel between the reverse proxy/load balancer/API GW and the backend servers.
> Why is that not sufficient? 
> Which part is cumbersome?
> 
> What I meant was only that in the course of writing https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09 <https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09>;, which aims to define HTTP header fields that enable a TLS terminating reverse proxy to convey information to a backend server about the validated Token Binding Message received from a client, it seemed more straightforward and sufficient for the use-case to use new HTTP headers to carry the information rather than to use new fields in the Forwarded header framework from RFC7239.    
>  
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>