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:30 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 993E9120108 for <oauth@ietfa.amsl.com>; Wed, 30 Oct 2019 07:30:52 -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 7_pdtMA2eB7e for <oauth@ietfa.amsl.com>; Wed, 30 Oct 2019 07:30:48 -0700 (PDT)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 865091208EA for <oauth@ietf.org>; Wed, 30 Oct 2019 07:30:48 -0700 (PDT)
Received: by mail-wr1-x435.google.com with SMTP id v9so2554177wrq.5 for <oauth@ietf.org>; Wed, 30 Oct 2019 07:30:48 -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=tRHEaJ63MjMW0dy6pd/R7WikLOwqR0KpYT9maVd5aT8=; b=bbftEINNle9pMin+ErLszmvMa4yvLV1JzZqkFVi670lpqQBJuebFOl71dFt6lxbPws +dIkTzjl+Wgwv2V/ZV8uYjFvqJPjv930PRF49YIhx1L2EWoy2Bcj31nO5anjjSHgTWIK /bXC9D2NW4NOfyuOJYhxCGARjUVQ5zWPg97kY=
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=tRHEaJ63MjMW0dy6pd/R7WikLOwqR0KpYT9maVd5aT8=; b=ICtmll7sW9pBegvhZT1elVMKU00ddc8kWx6spVy5gYP7s9fDaVnbVcHIQWryl+CAVn UHE8d2v6Kuea/qjSMf87o1/NxoyumpqVz0HLBd6GGrAqyBhLQEAzx+mdd+HvoFbhs3+R DNADBS/YaHYN6qqaXm55YA4nqCmVtDUDCsRfr9vWKZ5U0thyyiYQ2eFVEUJES1OWMeMi hjTOfD69e3aFQ92E4LnlLXepOAAAjFzj4JkcPs51jgCWw4OsGtqUHUWuAyB0dJKh35ld 4sExnhwhE6zF0zO6xWqAixLAkfcNtfYCMFCwbgSQCKUqtYH1FzUBgA60wKscTIo2aYvw 6B+A==
X-Gm-Message-State: APjAAAW0VqhIB0ZgWLibXtlrY22/3wkKdds+A6ulYuIrpPAr2Xhg0byL hx1nb92Imab57PkmXzojwe/dqw==
X-Google-Smtp-Source: APXvYqxv7tBHaK1gNT9/xsP5fCs2v3FkFwihtPaK9rZBwEGkEU7Oqyd9+EbbMkMfT0xd4aBO+kqGFg==
X-Received: by 2002:a5d:674f:: with SMTP id l15mr181515wrw.80.1572445846916; Wed, 30 Oct 2019 07:30:46 -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 m3sm407378wrb.67.2019.10.30.07.30.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Oct 2019 07:30:46 -0700 (PDT)
From: Neil Madden <neil.madden@forgerock.com>
Message-Id: <1543ED50-D92F-4679-87F5-AE679E4184AB@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D8EA28FE-15F5-4D14-B97E-779C7074B10D"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 30 Oct 2019 14:30:45 +0000
In-Reply-To: <96892FC9-87E8-472F-B989-3D41DF43D2CC@akamai.com>
Cc: Justin Richer <jricher@mit.edu>, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
To: "Salz, Rich" <rsalz@akamai.com>
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> <96892FC9-87E8-472F-B989-3D41DF43D2CC@akamai.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/0tqTV7sJymNFLhbbiIWM5ES1q6Q>
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:30:52 -0000

Combining responses to related messages (429 error):

On 30 Oct 2019, at 14:07, Salz, Rich <rsalz@akamai.com>; wrote:
> 
>> But an unguessable header name is *simple* and effective and works right now with widely implemented functionality. 
> 
> You mean like admin/admin for administrator access?  There is no such thing as an unguessable name.

I'm thinking of a uniformly random 16 byte name right now. Have at it.

> You claim the name will never be exposed to untrusted parties.  How so?  You are now telling administrators to treat a *name* as securely as they treat a *key* (or password).  If it must be protected like key material, then use it like key material.

Again, this is a defense in depth measure. A config file is fine.

> The proxy-backend should be TLS, ideally authenticating the proxy.

I agree - but completely irrelevant to the current discussion, which is about how the backend distinguishes security-critical headers that the proxy set from security-critical headers that were sneaked past the proxy by a client (through misconfiguration or parsing bug).


> On 30 Oct 2019, at 14:18, Salz, Rich <rsalz@akamai.com>; wrote:
> 
> Again, authenticating the *connection* from the RP to the backend services is good, but is completely orthogonal to authenticating the headers themselves.
>  
> I strongly disagree.  Authenticating the sender allows the receiver to make a trust decision in the provenance and quality of the data it gets from the sender.  Do you disagree with that?

Yes, see:

 https://en.wikipedia.org/wiki/Confused_deputy_problem <https://en.wikipedia.org/wiki/Confused_deputy_problem>
https://en.wikipedia.org/wiki/Cross-site_request_forgery <https://en.wikipedia.org/wiki/Cross-site_request_forgery>
https://en.wikipedia.org/wiki/Server-side_request_forgery <https://en.wikipedia.org/wiki/Server-side_request_forgery>

and so on and so on. Authenticating the other side of a communication pipe is not sufficient to authenticate the origin of the data contained within those messages. The whole point of a proxy is that it forwards requests from clients. In the face of misconfigurations and parsing bugs the backend cannot distinguish headers that were set by the proxy from headers that were spoofed by the client. *This is the entire problem I have been discussing*. 

-- Neil