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 19:18 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 8B7F4120866 for <oauth@ietfa.amsl.com>; Wed, 30 Oct 2019 12:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZswbP5V3m5Un for <oauth@ietfa.amsl.com>; Wed, 30 Oct 2019 12:18:31 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 8A923120255 for <oauth@ietf.org>; Wed, 30 Oct 2019 12:18:31 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id q70so3310271wme.1 for <oauth@ietf.org>; Wed, 30 Oct 2019 12:18:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Pr6/9Rai4XnQmEkrUSlPN9I3I95MkU2RJxLYZnbX1oU=; b=CE+RUpP0BZ76bbw9PhCXbYznrjbNzHufCekRAtHHU8QI7uy8VRh2kFh8zRz8gdmfju Nof8qzk3C83gQ9IiO8QXpIEcceqFyLVs6D0yBvXsf14itFlvTREF3itgWd8n2H5gmngI axv2eH+kSRdFCeF8Z5d+c0zU8n8EakABMGiwM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Pr6/9Rai4XnQmEkrUSlPN9I3I95MkU2RJxLYZnbX1oU=; b=GpHXTboS12KlQzLkFe78OlQX2BfESCs6byxv/ZbKc2ZC+02WSGdIswY1HdsPU93WFY IrrdPDWY/ArAwmqQ0yBSHxV3RYKdiSvHgQdMHeh2nbrZTqmJs6+AvpyUR2ElV6uBsQpB dkM3C8LpAISchO7sWE+hHjI/90Yucwwxj4+AtukHGf0pkhViDvFA7DU9s1/zKQFl4FZR hzhKRS7txZv/ECAKXxFpJyZHPIgCOsumNpQfFKjFbXi7jLTj9Q80iLXyar3cZZ+r4sSD 5Cn+HJtqm92SHLiCzveQFXyi8LBRigQXU3RBF3Ak2BgHPAHFyuhgMrvbkhQfCV0WXslX ZVlg==
X-Gm-Message-State: APjAAAX1azjCf+kk1UbWnhsTjWEMBA87Gfde4+r5XE1Rbxum9f1+9ImP /8FerBWPvejbVi/YG7KMrM6ZIw==
X-Google-Smtp-Source: APXvYqxAFdFrEuelOna571ukE9K4cqKN5q6TYVvLOM+rFEm6hHStzIqEEyDKhyBhDHA39drQsmTxhw==
X-Received: by 2002:a1c:67d7:: with SMTP id b206mr1007901wmc.68.1572463109928; Wed, 30 Oct 2019 12:18:29 -0700 (PDT)
Received: from ?IPv6:2a01:4c8:9:46ab:edd0:36d9:9264:132d? ([2a01:4c8:9:46ab:edd0:36d9:9264:132d]) by smtp.gmail.com with ESMTPSA id v6sm1473394wru.72.2019.10.30.12.18.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Oct 2019 12:18:28 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-E6C615FD-1991-4CFA-8594-62B336B2042E
Content-Transfer-Encoding: 7bit
From: Neil Madden <neil.madden@forgerock.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 30 Oct 2019 19:18:27 +0000
Message-Id: <61CA8B4D-CD95-472D-94CC-DFCD68A23B45@forgerock.com>
References: <4D4F6A38-74ED-4243-A1BC-CE1823FC1ED9@akamai.com>
Cc: Justin Richer <jricher@mit.edu>, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
In-Reply-To: <4D4F6A38-74ED-4243-A1BC-CE1823FC1ED9@akamai.com>
To: "Salz, Rich" <rsalz@akamai.com>
X-Mailer: iPhone Mail (17A878)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/GmDgi3WAKLJYy7jlRR6DaKnnkYo>
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 19:18:34 -0000

If you can point out where I recommended disabling TLS or not bothering to strip headers from incoming requests, or anything else along those lines then please let me know. Otherwise, yes we’re done here. 

> On 30 Oct 2019, at 17:19, Salz, Rich <rsalz@akamai.com>; wrote:
> 
> 
> To quote your previous claim: "There is no such thing as an unguessable name."
> Right.  That doesn’t mean *I* have to guess it.
> 
> Even if your deployment team had such staggeringly bad operational security practices as to allow people to take packet captures from an internal network and show them on public slides without any kind of questions being asked, if this actually happens *YOU ARE NO WORSE OFF THAN IN THE SITUATION WHERE YOU USED A WELL-KNOWN HEADER NAME*!
> Yes you are worse off.  Because that now-exposed header value can be used for spoofing.  As opposed to protection by TLS, and then sending the plaintext message around.
>  
> I don't know how many different ways I can say that this is a defense in depth
> Because it is not.  It is taking an application-level piece of configuration data and requiring it to be treated as if it were crypto material. Which it cannot be, because multiple parties need to know it (as I said, the proxy, the backend, the app developers, the support team, etc).  It’s defense by “collapsing layers” rather than “in depth.”
>  
> As with all defense in depth, the aim is to be more than 1 configuration mistake away from total compromise.
> But that is exactly what you are proposing. Exposing the header *is* a total compromise and multiple entities will need to know that header value.
>  
> At any rate,  I think we’re done here.
>