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 13:57 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 5816D1200DE for <oauth@ietfa.amsl.com>; Wed, 30 Oct 2019 06:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 WEBQ_pYKhnkU for <oauth@ietfa.amsl.com>; Wed, 30 Oct 2019 06:56:58 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 461A0120112 for <oauth@ietf.org>; Wed, 30 Oct 2019 06:56:58 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id e6so581749wrw.1 for <oauth@ietf.org>; Wed, 30 Oct 2019 06:56:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=b5jJphLtmg2ct2t5Y7i47pSCbt8a7aysVosXPEk0B/I=; b=XrDq/00VAWvcHvosHzUuNfjs3Z5y/EjBtWkbr6nhJCG9IB1LYOfOvNdvBnYCqxRFAh moGbZbzM26pVC4aTHJpJNJzpTQPA3PSfyTdtF39rMs6Hzf6d4VjA1vc2k8oaOUZYeUXs 3vdNB+BsBDUA9sqvctAr6Jio7f5+4aUA+8inA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=b5jJphLtmg2ct2t5Y7i47pSCbt8a7aysVosXPEk0B/I=; b=BW/wC9B/cBrU5IVDWwpBCgmdZYvYPKZLsxN2Sa2AXTX5x/bCCsogZ3YRRRuBwLN6xT w+IImMQoZLjo24NhQkXNNNKNgqE73xxXyG0WhpPH33hjfND3hSA55JNd4xI17gw5/m74 TP6f9uGqAZACTUOialOGz/IaBnmdbscorhHEUKtHoJRqhvrY7k8k39oLXx7NP5Ql908t Gw0mRDBPYfdvdGkc9roA2QnE5sugrAzfhEZ18ECF3dKuWzXkWHeL5FEx/IHoDkUsMbst dOlHHdc06t9f7aFoGk0aLB81cvC3+zuhd1Gw9Xc/3Kwj8AzaWrnkB2jLP11u5jB26eIj mgOg==
X-Gm-Message-State: APjAAAU5XEBTb/EiNmNHz4MiOComuk6VzxjL7qPLyIJIZSCmzHfRIBW1 Y/sHFO5iUE7pqQVyug8GrvAQTQ==
X-Google-Smtp-Source: APXvYqzyU3ZBLt/Wm5iOYKnhJjm05pVFnQroiyVm8cM6Iq1qvdwLVNbbkRLeDxIajUS1rGmSu9tTDw==
X-Received: by 2002:adf:fbc4:: with SMTP id d4mr6941683wrs.265.1572443816587; Wed, 30 Oct 2019 06:56:56 -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 u10sm161808wmj.0.2019.10.30.06.56.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Oct 2019 06:56:55 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Neil Madden <neil.madden@forgerock.com>
In-Reply-To: <50867522-C1A5-4BE2-888A-910B352D1EC8@mit.edu>
Date: Wed, 30 Oct 2019 13:56:54 +0000
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4DFE9EE9-2A57-4F2F-B2E2-12217FE3CECE@forgerock.com>
References: <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <E58B4EB0-7E59-4A0C-B43F-263CEF0B955D@forgerock.com> <50867522-C1A5-4BE2-888A-910B352D1EC8@mit.edu>
To: Justin Richer <jricher@mit.edu>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/RoF2rxXG6aY25AOTiUBvKRdtX6s>
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 13:57:00 -0000

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 and is a defense-in-depth rather than a primary defense. I also don't know why you consider this a "weird" solution - it's a simple pragmatic solution to a fairly widespread class of security vulnerabilities. It also has the benefit that it forces the backend to "validate" the secret, because it won't find the header if it gets it wrong, whereas it is much easier to forget to validate a HMAC tag. I'll take simple and weird over missing and broken any day.

> 
> And one of the best things about a standard is that you’re still free to completely ignore it if you want to, so people can and will keep following whatever proprietary patterns they want to. But at least a standard mechanism would give us a way to say to newcomers and veterans alike “No really, here’s a way that we all agree works and has these properties”. 

I'm not arguing against a standard, just against a standard that makes it harder to mitigate known security vulnerabilities.

-- Neil