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> Wed, 30 October 2019 14:15 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 2259C120A36 for <oauth@ietfa.amsl.com>; Wed, 30 Oct 2019 07:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Yy0vCjWwAdNP for <oauth@ietfa.amsl.com>; Wed, 30 Oct 2019 07:15:42 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 AE86A120077 for <oauth@ietf.org>; Wed, 30 Oct 2019 07:15:41 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id p4so2484900wrm.8 for <oauth@ietf.org>; Wed, 30 Oct 2019 07:15: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=UHF7aR45aNy7YK+dechnPFv21wn6Gw/WR2znco84WYk=; b=cUQyV0U3g0EGUlBzF4HdqRZ5yvv2GMGxLmESJb7f4kfGSdjlgAJRugP6wDjMZkjKsy ELBHhpnaBTOoK/Ty88WfmclZzM2IMlz0z1sD5a8CWcql3SfJ/974wRpDFHlpZq66H1QW ta+d712QNn9lm5ezO2+IfQ719to2DDQuRMILc=
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=UHF7aR45aNy7YK+dechnPFv21wn6Gw/WR2znco84WYk=; b=lLEt2lNLyaGFrJhbTWfng+vYFoyh/8mgV7NSttwVNRHl4EEGght7zkqNtieFX1R561 mvD+F4WSoO19nG0Dm0iPaoE8VZv8RoUtyyEOSZj2+W+qBcDe82JYJd3DczohV66dSj5Q T5gxYTfG9tE90Sjha8s33oiIbP09/Vduef6e/+4cWJ9nB9j2XlSfP5cSKDkhh9t4ePu3 julu07c1GxKeYGyYbvNg2Yjiv34i27m0libA+/aD7FbA1eZBmfLLEj7hQs3urFdN0XDp oCeUxsnwm/BRE6M9GLwAfltGMRO0Ibt+qDPj8cB3gBy95x03G9kwylVwIg/PyiiKW+Qz kw7g==
X-Gm-Message-State: APjAAAW8a84WJfKzCp9O9S9d4sSYEQWTOPmjLbIaDmVNaNAVy93Jspfk 4qkkGNfOvhGoSyotcpQ8UfwpeQ==
X-Google-Smtp-Source: APXvYqxKXCgja1r/+sskhLP6NZq16OEkzmoBegZU2qL2Ao8OazoVjsv9NOsSt88kYzEvSquP8wUDeA==
X-Received: by 2002:adf:f685:: with SMTP id v5mr103503wrp.246.1572444940108; Wed, 30 Oct 2019 07:15:40 -0700 (PDT)
Received: from [192.168.2.134] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id u187sm193374wme.15.2019.10.30.07.15.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Oct 2019 07:15:39 -0700 (PDT)
From: Neil Madden <neil.madden@forgerock.com>
Message-Id: <4C4CFFA1-2AF9-4652-AF73-2EE45C5BA1EB@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AEDECF20-6DC6-41D1-87A9-64EA0957C592"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 30 Oct 2019 14:15:34 +0000
In-Reply-To: <4B61A342-6A73-45B9-9838-18038709D0D3@lodderstedt.net>
Cc: Justin Richer <jricher@mit.edu>, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
References: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <E58B4EB0-7E59-4A0C-B43F-263CEF0B955D@forgerock.com> <50867522-C1A5-4BE2-888A-910B352D1EC8@mit.edu> <4DFE9EE9-2A57-4F2F-B2E2-12217FE3CECE@forgerock.com> <4B61A342-6A73-45B9-9838-18038709D0D3@lodderstedt.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Bxi_Zo6iS8V3i-6IRR7ye6E5BOc>
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: Wed, 30 Oct 2019 14:15:44 -0000

On 30 Oct 2019, at 14:05, Torsten Lodderstedt <torsten@lodderstedt.net>; wrote:
>> On 30. Oct 2019, at 14:56, Neil Madden <neil.madden@forgerock.com>; wrote:
>> 
>> On 30 Oct 2019, at 13:24, Justin Richer <jricher@mit.edu>; wrote:
>>> 
>>> All of these problems can be solved, and I think solved better, by securing the connection between the proxy and the back-end. That way the back end will be able look not only for a specific header, but verify that the header came from the proxy itself. An obscure header name is one way to do that, but it has a lot of issues with it, especially since it’s likely to be selected once during set-up and never changed throughout the lifetime of the deployment. I think there are likely much better solutions here, and they’d address this issue without things getting weird.
>> 
>> The issue has nothing to do with the security of the connection between the proxy and the backend. It is to do with data origin authentication of the headers themselves. All of the headers arrive at the backend over the same connection, but only some of them were created by the proxy. There are undoubtedly better alternatives - e.g. using a shared secret to compute a HMAC over security sensitive headers and include that as an additional header or field. But an unguessable header name is *simple* and effective and works right now with widely implemented functionality. 
>> 
>> There's no need for the header name to ever change - the secret is not exposed to untrusted parties
> 
> If the proxy sends certs via an header X to service A and B and someone impersonates A it will find out the secret and use it to inject certs in a connection towards B.

Being able to impersonate A suggests that the attacker is already on the trusted side of the network and that you are employing zero additional network security controls between the RP and service A and B (e.g., TLS, firewalls, VLAN/switches, etc). Remember, this is intended to mitigate against accidental misconfiguration of the RP and header spoofing tricks coming from the external network. I'm not suggesting it as an alternative to basic network security on the trusted network.

> We have learned that it is sometime hard to use different secret header names for the same purpose with different request targets. In those cases, a way to authenticate the proxy might by a good solution.  

Do you have an example? The RPs and load balancers I'm familiar that support multiple backends all support sending different headers to each of them. Again though, security against attackers inside the trusted network is not part of what the solution is preventing.

Again, authenticating the *connection* from the RP to the backend services is good, but is completely orthogonal to authenticating the headers themselves.

-- Neil