*   I'm thinking of a uniformly random 16 byte name right now. Have at it.
Cute but missing the point.  I don’t have to guess it.  YOU have to securely 
deploy it across your proxy (however many staff), your backend (however many 
staff), your application developers (however many), and perhaps your diagnosing 
or debug teams if they are different.  And then you must make sure that if 
ANYONE ever takes a packet trace, or makes a slide out of a sample message, 
that they don’t disclose the header, such as by showing “here’s how we do 
OAUTH” at a user group meeting.

  *   Again, this is a defense in depth measure. A config file is fine.
No, it’s not.  It’s a multi-party shared secret that isn’t identified as a 
secret.  It’s not defense in depth, it’s a foundation of sand.

  *   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).
The backend must trust the proxy.  If you tell the proxy to “use FOOBAR123” as 
the header of the client certificate, how do you know that the proxy properly 
provided the client certificate?  Pretending that the backend only has to trust 
*part* of the proxy, because we use a sekrit header value is just that, 
pretending.

Your links to confused deputy and CSRF do not address the issues I raised.


  *   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*.
And you believe that configuring a proxy, of which you are skeptical, addresses 
that concern?

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to