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

[Neil Madden <[e-mail]>]

Combining responses to related messages (429 error):

On 30 Oct 2019, at 14:07, Salz, Rich <[e-mail]> wrote:
> 
>> But an unguessable header name is *simple* and effective and works right now with widely implemented functionality. 
> 
> You mean like admin/admin for administrator access?  There is no such thing as an unguessable name.

I'm thinking of a uniformly random 16 byte name right now. Have at it.

> You claim the name will never be exposed to untrusted parties.  How so?  You are now telling administrators to treat a *name* as securely as they treat a *key* (or password).  If it must be protected like key material, then use it like key material.

Again, this is a defense in depth measure. A config file is fine.

> The proxy-backend should be TLS, ideally authenticating the proxy.

I agree - but completely irrelevant to the current discussion, which is about how the backend distinguishes security-critical headers that the proxy set from security-critical headers that were sneaked past the proxy by a client (through misconfiguration or parsing bug).


> On 30 Oct 2019, at 14:18, Salz, Rich <[e-mail]> wrote:
> 
> Again, authenticating the *connection* from the RP to the backend services is good, but is completely orthogonal to authenticating the headers themselves.
>  
> I strongly disagree.  Authenticating the sender allows the receiver to make a trust decision in the provenance and quality of the data it gets from the sender.  Do you disagree with that?

Yes, see:

 https://en.wikipedia.org/wiki/Confused_deputy_problem <https://en.wikipedia.org/wiki/Confused_deputy_problem>
https://en.wikipedia.org/wiki/Cross-site_request_forgery <https://en.wikipedia.org/wiki/Cross-site_request_forgery>
https://en.wikipedia.org/wiki/Server-side_request_forgery <https://en.wikipedia.org/wiki/Server-side_request_forgery>

and so on and so on. Authenticating the other side of a communication pipe is not sufficient to authenticate the origin of the data contained within those messages. The whole point of a proxy is that it forwards requests from clients. In the face of misconfigurations and parsing bugs the backend cannot distinguish headers that were set by the proxy from headers that were spoofed by the client. *This is the entire problem I have been discussing*. 

-- Neil