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

[Torsten Lodderstedt <[e-mail]>]

> On 30. Oct 2019, at 14:56, Neil Madden <[e-mail]> wrote:
> 
> On 30 Oct 2019, at 13:24, Justin Richer <[e-mail]> wrote:
>> 
>> All of these problems can be solved, and I think solved better, by securing the connection between the proxy and the back-end. That way the back end will be able look not only for a specific header, but verify that the header came from the proxy itself. An obscure header name is one way to do that, but it has a lot of issues with it, especially since it’s likely to be selected once during set-up and never changed throughout the lifetime of the deployment. I think there are likely much better solutions here, and they’d address this issue without things getting weird.
> 
> The issue has nothing to do with the security of the connection between the proxy and the backend. It is to do with data origin authentication of the headers themselves. All of the headers arrive at the backend over the same connection, but only some of them were created by the proxy. There are undoubtedly better alternatives - e.g. using a shared secret to compute a HMAC over security sensitive headers and include that as an additional header or field. But an unguessable header name is *simple* and effective and works right now with widely implemented functionality. 
> 
> There's no need for the header name to ever change - the secret is not exposed to untrusted parties

If the proxy sends certs via an header X to service A and B and someone impersonates A it will find out the secret and use it to inject certs in a connection towards B. We have learned that it is sometime hard to use different secret header names for the same purpose with different request targets. In those cases, a way to authenticate the proxy might by a good solution.  

> and is a defense-in-depth rather than a primary defense. I also don't know why you consider this a "weird" solution - it's a simple pragmatic solution to a fairly widespread class of security vulnerabilities. It also has the benefit that it forces the backend to "validate" the secret, because it won't find the header if it gets it wrong, whereas it is much easier to forget to validate a HMAC tag. I'll take simple and weird over missing and broken any day.
> 
>> 
>> And one of the best things about a standard is that you’re still free to completely ignore it if you want to, so people can and will keep following whatever proprietary patterns they want to. But at least a standard mechanism would give us a way to say to newcomers and veterans alike “No really, here’s a way that we all agree works and has these properties”. 
> 
> I'm not arguing against a standard, just against a standard that makes it harder to mitigate known security vulnerabilities.
> 
> -- Neil
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth