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 15:15, Neil Madden <[e-mail]> wrote:
> 
> On 30 Oct 2019, at 14:05, Torsten Lodderstedt <[e-mail]> wrote:
>>> 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.
> 
> Being able to impersonate A suggests that the attacker is already on the trusted side of the network and that you are employing zero additional network security controls between the RP and service A and B (e.g., TLS, firewalls, VLAN/switches, etc). Remember, this is intended to mitigate against accidental misconfiguration of the RP and header spoofing tricks coming from the external network. I'm not suggesting it as an alternative to basic network security on the trusted network.

Is there such a thing as a trusted network? I’m not sure what you mean but micro services call each other so network segregation would not help to prevent replay of a leaked security header. But (see below) different secret headers can be used to mitigate the threat I raised (at least limit the impact to an individual service).

> 
>> 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.  
> 
> Do you have an example?

I checked back and it seems I had misunderstood. It’s possible to use different secret header names, one per proxy-to-service connection. 

> The RPs and load balancers I'm familiar that support multiple backends all support sending different headers to each of them. Again though, security against attackers inside the trusted network is not part of what the solution is preventing.
> 
> Again, authenticating the *connection* from the RP to the backend services is good, but is completely orthogonal to authenticating the headers themselves.
> 
> -- Neil
> 
>