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 20:48 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 B75751200D5 for <oauth@ietfa.amsl.com>; Thu, 31 Oct 2019 13:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 bj63TT7ZejD5 for <oauth@ietfa.amsl.com>; Thu, 31 Oct 2019 13:48:37 -0700 (PDT)
Received: from p3plsmtpa09-01.prod.phx3.secureserver.net (p3plsmtpa09-01.prod.phx3.secureserver.net [173.201.193.230]) (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 3647E120826 for <oauth@ietf.org>; Thu, 31 Oct 2019 13:48:37 -0700 (PDT)
Received: from [192.168.0.102] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id QHMtiu4uUnaIyQHMwizPFA; Thu, 31 Oct 2019 13:48:35 -0700
To: oauth@ietf.org
References: <85D42AA1-FF57-4383-BACB-57C5AA32CFAC@lodderstedt.net> <8A8B8892-9D16-4210-BC13-47B5D7859976@mit.edu> <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> <E70795A4-5BC7-4450-A1B4-FFC3D332F1DC@amazon.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Openpgp: preference=signencrypt
Organization: Connect2id Ltd.
Message-ID: <1ec7ef38-51f9-ff93-774d-09300736be73@connect2id.com>
Date: Thu, 31 Oct 2019 22:48:31 +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: <E70795A4-5BC7-4450-A1B4-FFC3D332F1DC@amazon.com>
Content-Type: multipart/alternative; boundary="------------28BACAD22C56612523513F3C"
Content-Language: en-US
X-CMAE-Envelope: MS4wfNh0zfx9ULV9tqZjhoAe1IhsBIkUD7zHItaATL6M7zrM1RVrC/o+78GL5EjZmlNGkqSCN4JTrnh0FFb5QyCs1eEQvjmrQxXbVvZVXfQDAEjdLF4vm32p OFKzvQsQ04son6zTdYiljJkm232EydcjYgY/5bmN2veSo7AFBw4CDl3v
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/OpPEF49T7Y6t2F-vMq6Trab9mD8>
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 20:48:41 -0000

I agree wholeheartedly that an HMAC or even signature is preferable.
With HMAC vs signature having their relative pros / cons, in terms of
computation and key distribution. If a standard for that is created, and
I am a web application developer, I'll be able to handle the header
checks in the application layer code relatively easily. But I have much
less control over how / where the application is going to be deployed,
and if the reverse proxy has this header security implemented. Software
and cloud vendors can sometimes be significantly behind in such
developments. Even basic handling of self-signed client certificates has
been an issue for us in popular cloud environments.

With that in mind, the "secret" headers can be configured with most
currently available reverse proxy software. I see it as a useful
intermediate step, until a standard for authenticated headers gets
agreed on and eventually implemented in reverse proxies. Can you comment
on that from this perspective?

Over the years I have come to the conclusion that standards which can be
implemented in the application layer or as a simple config stand a
better chance. Standards which rely on other layers or on broad vendor
or developer support to become useful run the risk of not getting
adopted in practice. Token binding suffered from that.

Vladimir

On 31/10/2019 20:55, Richard Backman, Annabelle wrote:
>
> Relying on a fixed, random header name for security, even as a
> “defense in depth” measure, is dangerous. In order for this mechanism
> to be effective, the header name must be random (in the cryptographic
> sense) and must be kept secret. It needs to be withheld from request
> logs or error logs, either on the reverse proxy or on the service. It
> cannot be committed to code repositories. Including it as a signed
> header in request signing algorithms that require an explicit list of
> signed headers (such as AWS Signature Version 4
> <https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html>;,
> draft-cavage-http-signatures
> <https://tools.ietf.org/html/draft-cavage-http-signatures-12>;,
> draft-ietf-oauth-signed-http-request
> <https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request>)
> turns that signature metadata into a secret, meaning that /it/ cannot
> be logged, etc. If signatures are sent to a central authority for
> processing, that authority must also know not to log the list of
> signed headers. I could go on, but I hope this is enough to express
> that there are SO MANY ways that header names can and will be
> revealed, and they aren’t always obvious.
>
>  
>
> What we are talking about is a message authenticity problem. The best
> practices for providing message authenticity involve applied crypto,
> e.g., an HMAC or digital signature over the header contents. If an
> implementation does that, then the random header name is unnecessary.
> This approach is immune to the sort of misconfiguration scenarios that
> have been discussed in this thread, as they would result in the
> reverse proxy failing to provide a properly signed header to the service.
>
>  
>
> – 
>
> Annabelle Richard Backman
>
> AWS Identity
>
>  
>
>  
>
> *From: *OAuth <oauth-bounces@ietf.org>; on behalf of Vladimir Dzhuvinov
> <vladimir@connect2id.com>;
> *Organization: *Connect2id Ltd.
> *Date: *Thursday, October 31, 2019 at 4:27 AM
> *To: *"oauth@ietf.org"; <oauth@ietf.org>;
> *Subject: *Re: [OAUTH-WG] client certs and TLS Terminating Reverse
> Proxies (was Re: I-D Action:
> draft-ietf-oauth-jwt-introspection-response-08.txt)
>
>  
>
> This is a good story.
>
> How about requiring reverse proxies to automatically scrub all inbound
> HTTP headers that start with "Sec-"?
>
> If a sec header has the format "Sec-[NAME]-[random-chars]" we get:
>
> * The "Sec-" prefix will  cause new compliant reserve proxies to
> automatically scrub the inbound HTTP header.
>
> * The NAME part still makes the header easily identifiable (I think
> Rich Salz had this concern).
>
> * The random chars part, potentially optional, will provide a line of
> defence against config errors in old legacy reverse proxies.
>
> All concerns should then get covered.
>
> Vladimir
>
> On 31/10/2019 12:48, Hans Zandbelt wrote:
>
>     the way I see this is that stripping and setting the headers must
>     be part of the implementation of the protocol itself, it should
>     not be something left to a non-atomic piece of configuration by an
>     administrator; I implemented it like this in the Apache
>     implementation of Brian's TTRP spec [1] and have been doing this
>     for the OIDC and OAuth Apache modules that set headers for
>     backends to consume [2]; and yes, I have made mistakes [3], but
>     IMHO it should not be a problem to use a well known header and
>     make the implementer (not the admin) get it right by pointing this
>     out in the spec, as is done for many other pitfalls
>
>      
>
>     Hans.
>
>      
>
>     [1] https://github.com/zmartzone/mod_token_binding/blob/master/src/mod_token_binding.c#L481-L483
>
>     [2] https://github.com/zmartzone/mod_auth_openidc/blob/master/src/mod_auth_openidc.c#L164-L175
>
>     [3] https://www.cvedetails.com/cve/CVE-2017-6413/
>
>      
>
>     On Thu, Oct 31, 2019 at 11:37 AM Vladimir Dzhuvinov
>     <vladimir@connect2id.com <mailto:vladimir@connect2id.com>> wrote:
>
>             All in all, I am in favor of this being defined in one
>             standard way, in addition to secure communication between
>             proxies and backends being standardized — but this latter
>             bit really seems like a separate problem.
>
>              
>
>              — Justin
>
>         -1 for devising a well known header
>
>         +1 for a simple way to authenticate a reverse proxy with a web
>         server
>
>         With a well known name, in a attack this will get probed
>         first. The well known header name doesn't guarantee a correct
>         config. And if we have a new standard for sec headers that
>         must be stripped automatically from inbound HTTP requests, we
>         cannot expect that will get implemented in all reverse proxy
>         software overnight.
>
>         Because a correct config is not practical as the only line of
>         defense, when we implemented mTLS we decided to add a length
>         (>= 32 chars) and randomness check to the header config. I saw
>         some concerns that this may cause deployment issues. Nobody
>         has complained about that so far.
>
>         https://connect2id.com/products/server/docs/config/core#op-tls-clientX509CertHeader
>
>         Regarding mistyping, this can be an issue, but has little to
>         no effect if a long random header gets misstyped (from the
>         inbound strip directive). With a well known header this will
>         result in a immediate security hole, which can theoretically
>         go unnoticed.
>
>         Here is an example Apache httpd config, to illustrate my point:
>
>         RequestHeader set
>         Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing ""
>
>         RequestHeader set
>         Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing
>         "%{SSL_CLIENT_CERT}s"
>
>         (the first line strips the inbound headers)
>
>          
>
>         Vladimir
>
>         -- 
>
>         Vladimir Dzhuvinov
>
>         _______________________________________________
>         OAuth mailing list
>         OAuth@ietf.org <mailto:OAuth@ietf.org>
>         https://www.ietf.org/mailman/listinfo/oauth
>
>
>      
>
>     -- 
>
>     hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
>
>     ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu>
>
> -- 
> Vladimir Dzhuvinov
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth