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

["Richard Backman, Annabelle" <[e-mail]>]

I think the HMAC/signature approach is actually easier for cloud vendors to implement. The threat model is much simpler to understand, and risk mitigation mostly boils down to well-understood cryptographic hygiene patterns. And again, it’s obvious what values are secrets and what values aren’t.

–
Annabelle Richard Backman
AWS Identity


From: OAuth <[e-mail]> on behalf of Vladimir Dzhuvinov <[e-mail]>
Organization: Connect2id Ltd.
Date: Thursday, October 31, 2019 at 1:50 PM
To: "[e-mail]" <[e-mail]>
Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)


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 <[e-mail]><mailto:[e-mail]> on behalf of Vladimir Dzhuvinov <[e-mail]><mailto:[e-mail]>
Organization: Connect2id Ltd.
Date: Thursday, October 31, 2019 at 4:27 AM
To: "[e-mail]"<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth


--
[e-mail]<mailto:[e-mail]>
ZmartZone IAM - www.zmartzone.eu<http://www.zmartzone.eu>

--

Vladimir Dzhuvinov



_______________________________________________

OAuth mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/oauth