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

[Hans Zandbelt <[e-mail]>]

for me this thread is running a bit wild: if we don't believe that
implementers get incoming header removal right, why do we believe the same
implementers get randomizing and/or HMAC signing right
setting headers on a trusted leg between proxies and origin servers has
been a best practice for decades, regardless of implementation bugs (which
similarly exist in crypto implementations)
catering for non-trusted legs is fine, but don't let it stand in the way of
the obvious

Hans.

On Thu, Oct 31, 2019 at 10:35 PM Richard Backman, Annabelle <richanna=
[e-mail]> wrote:

> 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]> <[e-mail]> on behalf
> of Vladimir Dzhuvinov <[e-mail]> <[e-mail]>
> *Organization: *Connect2id Ltd.
> *Date: *Thursday, October 31, 2019 at 4:27 AM
> *To: *"[e-mail]" <[e-mail]> <[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)
>
>
>
> 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]> 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]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
>
> [e-mail]
>
> ZmartZone IAM - www.zmartzone.eu
>
> --
>
> Vladimir Dzhuvinov
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
[e-mail]
ZmartZone IAM - www.zmartzone.eu