W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

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

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 04 Jan 2012 18:07:18 +1300
Message-ID: <4F03DE86.5040701@treenet.co.nz>
To: igor.faynberg@alcatel-lucent.com
CC: Torsten Lodderstedt <torsten@lodderstedt.net>, ietf-http-wg@w3.org, oauth@ietf.org
On 4/01/2012 3:58 p.m., Igor Faynberg wrote:
> 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..

The client does too, surely.

Fidelity, well;
  * it is going to cache the reply for re-use, <=== this is what I worry 
about.
  * it is going to log the URL+token for a longish term,
  * it may pass the URL+token in unencrypted packets (via ICP,  HTCP, 
UDP syslog) to any peers it may have,

Given these risks are all internal to the security domain and so very 
slight, they are still weak points in the transactions long-term integrity.

Adding the cache-controls erases the risks related to caching. With 
correct CC headers URL replay would fail even if TLS were not present.

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

In the last year or so it has become safe to assume SSL/TLS is 
compromised by MITM. Or alternatively some secondary infection at one of 
the end points. Paranoia dictates that someone will figure it out 
somehow if the stakes are high enough. When they do, its a good idea to 
have the rest of the system firmly sealed.

The given sequence was for the reverse-proxy. The alternative scenario 
is an identical sequence with a SSL interception proxy. For example an 
installation of: http://wiki.squid-cache.org/Features/SslBump. In that 
alternative the proxy is outside the servers security domain and inside 
some third-party ISP domain at the user end.

AYJ
Received on Wednesday, 4 January 2012 05:11:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:52 GMT