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

Vladimir Dzhuvinov <vladimir@connect2id.com> Thu, 31 October 2019 16:45 UTC

Return-Path: <vladimir@connect2id.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 861EA120052 for <oauth@ietfa.amsl.com>; Thu, 31 Oct 2019 09:45:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 h7rB_apqXV2a for <oauth@ietfa.amsl.com>; Thu, 31 Oct 2019 09:45:27 -0700 (PDT)
Received: from p3plsmtpa09-02.prod.phx3.secureserver.net (p3plsmtpa09-02.prod.phx3.secureserver.net [173.201.193.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32E0312002F for <oauth@ietf.org>; Thu, 31 Oct 2019 09:45:27 -0700 (PDT)
Received: from [192.168.0.102] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id QDZbiH8wcyg8JQDZdiMnX7; Thu, 31 Oct 2019 09:45:26 -0700
References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <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> <E03CD445-39E8-4262-97BE-E0EE11231A63@forgerock.com> <2B2ACEE8-7B48-4E2D-94DA-AF3DA86DE809@mit.edu> <CA+k3eCRmmZJQjk-WGmpYZeyTvQR0SttRUZeh7FDT-=ikzOUwAA@mail.gmail.com> <d2dd4b24-a7d5-5080-4ddc-05e9a742d5d3@connect2id.com> <CA+iA6uiCu8KZM8xpxqxuF4cGR-n53c=w03-h9Ja1rpVsg0goQg@mail.gmail.com> <6535fb8b-89fd-9499-ebf6-e8c6e5542fcc@connect2id.com> <CA+iA6uhpFb-hn=iG-wR5oU4haRSkSTaawAAQK5TfmT0HkWv3Dg@mail.gmail.com> <AE622747-BB01-4275-A626-C19D2681D0E2@akamai.com>
To: "oauth@ietf.org" <oauth@ietf.org>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Openpgp: preference=signencrypt
Organization: Connect2id Ltd.
Message-ID: <5e8f7135-0b3a-fa06-a536-fa92f58aff4b@connect2id.com>
Date: Thu, 31 Oct 2019 18:45:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <AE622747-BB01-4275-A626-C19D2681D0E2@akamai.com>
Content-Type: multipart/alternative; boundary="------------3044A5F75AA64748C344A917"
Content-Language: en-US
X-CMAE-Envelope: MS4wfNWTCpBwxijzkTbyYl27T1t8JSBSW8qoI4JmCq7AijscpOVEg7fz33oRALUlTHcMzu5OmIzx9OLipLBrcuRkrqGyMbuMXqqxDlrsYuh6aqQxPOOOfTQT e5cxLJ9F82jSMDwSZ9yUxzhITq3VWFtt5Wn+0s6tGoJHhHi2jt/pVa5W
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/h0GYtQEJ4gzqp0c45Y_xFXXY6NM>
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: Thu, 31 Oct 2019 16:45:30 -0000

Thanks for this note. According to the abstract the advertising is
intended for "request headers for proactive content negotiation"
(Accept-*), which should exclude all other types of header. I looked at
the Security Considerations and wrote to the author with the suggestion
to note that implementations must be careful not to advertise any other
names, e.g. the names of headers intended to be set by the proxy for use
by a web server.

Vladimir

On 31/10/2019 15:13, Salz, Rich wrote:
>
> How about requiring reverse proxies to automatically scrub all inbound
> HTTP headers that start with "Sec-"?
>
> https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-07
>
>  
>
> Making a header value “secret” will not protect anything.
>