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

[Igor Faynberg <[e-mail]>]

Very good to have a clear sequence! Many thanks for all the work 
explaining this to me.
Maybe my misunderstanding can be corrected by considering observations 
1) and 2) and answering question 3) in-line:

On 1/3/2012 8:30 PM, Amos Jeffries wrote:
> ... Here is a transaction sequence for that bank:
>
>
> client 1 to proxy:
>   GET /?oauth_token=FOO HTTP/1.1
>   Host: bank.example.com
1): If this transaction is done over TLS, then this specific proxy is 
the ONLY  entity in the chain that knows the token at the moment, and 
since it is in the same domain as the server, we must assume its fidelity..
>
> proxy to server:
>   GET /?oauth_token=FOO HTTP/1.1
>   Host: bank.example.com

2) Now the server knows it, too.
>
>  (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

Same as in 1)
>
> proxy to server:
>   GET /?oauth_token=FOO-2 HTTP/1.1
>   Host: bank.example.com

Sane as in 2)
>
>  (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...

3) How can attacker swipe it, if the token was passed *as part of an 
encrypted payload?*

>
> 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
>