Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?

[Amos Jeffries <[e-mail]>]

 On Tue, 03 Jan 2012 18:34:01 -0500, Igor Faynberg wrote:
> Well, this exchange made me read all I could find on reverse proxies.
> Now I understand--and agree with--the last statement of AYJ:  '"the
> server" is a proxy. '
>
> But my understanding is that the proxy (which DNS pointed me to when
> I tried to get to my bank) belongs in the domain "mybank," and this
> proxy had been issued a valid certificate--which I had ascertained in
> the process of authentication. So, the end result is that the proxy 
> is
> part of the bank.  If we expect it to be harmful to the bank--so we
> could the "server" itself as well as any bank's employee.  It would 
> be
> the bank replaying things to itself, right?

 I'm not sure we quite match ideas on this. The problem is between the 
 client and proxy. Not between the proxy and the server. Here is a 
 transaction sequence for that bank:


 client 1 to proxy:
   GET /?oauth_token=FOO HTTP/1.1
   Host: bank.example.com

 proxy to server:
   GET /?oauth_token=FOO HTTP/1.1
   Host: bank.example.com

  (server verifies the token "FOO" is valid for client 1 through the 
 proxy)

 bank server to proxy:
   HTTP/1.1 200 OK
   stuff

 proxy to client 1:
   HTTP/1.1 200 OK
   stuff

 .. some time passes. The token "FOO" expires, gets replaced by token 
 "FOO-2".


 client 1 to proxy:
   GET /?oauth_token=FOO-2 HTTP/1.1
   Host: bank.example.com

 proxy to server:
   GET /?oauth_token=FOO-2 HTTP/1.1
   Host: bank.example.com

  (server verifies the token "FOO-2" is valid for client 1 through the 
 proxy)

 bank server to proxy:
   HTTP/1.1 200 OK
   other-stuff

 proxy to client 1:
   HTTP/1.1 200 OK
   other-stuff


 Attacker processes some URL records they somehow swiped from the client 
 transactions...

 attacker to proxy:
   GET /?oauth_token=FOO HTTP/1.1
   Host: bank.example.com

 proxy to attacker:
   HTTP/1.1 200 OK
   stuff

 ... Oops.

 attacker to proxy:
   GET /?oauth_token=FOO-2 HTTP/1.1
   Host: bank.example.com

 proxy to attacker:
   HTTP/1.1 200 OK
   other-stuff

 ... Oops.


 I assume for clarity that the server and client 1 have both correctly 
 implemented Bearer and are performing proper validation and expiry on 
 the query-string tokens.

 The mitigation is for the server which implements Bearer to be sending 
 Cache-Control with one of the values: no-store, private, 
 proxy-revalidate and/or must-revalidate.

 AYJ


>
> Then it is the bank's problem, not OAuth's as far as I am 
> concerned...
>
> Igor
>
> On 1/2/2012 7:36 PM, Amos Jeffries wrote:
>> On 1/2/2012 7:07 AM, Amos Jeffries wrote:
>>>> On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote:
>>>> ...
>>>>>
>>>>> general note: I do not understand why caching proxies should 
>>>>> impose a problem in case TLS is used (end2end). Could you please 
>>>>> explain?
>>>>
>>>> Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP 
>>>> hops). Proxies which decrypt TLS and provide responses out of cache 
>>>> are already deployed in many places. Mostly in the form of 
>>>> reverse-proxies, but corporate decryption proxies are also on the 
>>>> increase.
>>>>
>>>> AYJ
>>
>> On 3/01/2012 11:17 a.m., Igor Faynberg wrote:
>>> I am at a loss here; granted, it is a gray area...  Does it mean 
>>> that RFC 2817 has not been implemented properly?
>>>
>>
>> From RFC 2817:
>> "
>>
>> 5. Upgrade across Proxies
>>
>>    As a hop-by-hop header, Upgrade is negotiated between each pair 
>> of
>>    HTTP counterparties.  If a User Agent sends a request with an 
>> Upgrade
>>    header to a proxy, it is requesting a change to the protocol 
>> between
>>    itself and the proxy, not an end-to-end change.
>> "
>>
>> The more common case is CONNECT method from RFC 2068, from a user 
>> agent to a reverse-proxy. Same behaviour.
>>
>>> To make it simple: At the client, I establish a session key with 
>>> the server, and then use it for confidentiality.  How is this key 
>>> known to any proxy?
>>
>>  "the server" is a proxy.
>>
>> AYJ