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

From: Amos Jeffries <[email-masked]>
Date: Mon, 02 Jan 2012 21:17:59 +1300

On 2/01/2012 7:25 p.m., Igor Faynberg wrote:
> On 12/30/2011 10:14 PM, Amos Jeffries wrote:
>> ....
>>>
>>> Reading section 2.3, it appears this method of transferring the 
>>> credentials is open to replay attacks when caching TLS middleware is 
>>> present. I believe this spec should mandate cache controls on 
>>> responses using that method. Otherwise a lot of HTTP compliant 
>>> middleware will feel free to store and supply the protected response 
>>> to later replay attacks.
>>>
>>
> Amos,
>
> I believe that the draft addresses the replay matters by  specifying 
> the validity time field. Do you see a problem with that?

I did not see any such validity time field in the HTTP mechanisms.  You 
mean the validity period of the token itself? that would be irrelevant 
as the case I am raising is for software which does not support Bearer 
specs.
  (1) assuming the client is malicious and cannot be trusted to follow 
the bearer token limits.
  (2) the proxy acting as server for the transaction does *not* support 
bearer and is thus not implementing any bearer token time limitations.

The HTTP definition of www-auth specifies an implicit "Cache-Control: 
private" unless explicit "public" is added. The cache supports the HTTP 
imiplicit definitinon and does not cache the reply. Replay requests will 
get nothing from the cache.

In the query string case proxies use the full abolute URL (including 
query string with token) as part of the storage key. The HTTP spec 
outlines that the absence of cache-control time limitations permits a 
proxy to store the reply as long as it wishes. Meaning that any time 
limits imposed by the Bearer spec around the token itself are not 
supported. Therefore  Therefore any client requesting the URL with the 
token can be presented with a cached reply *indefinitely*.

  At no point between malicious client and proxy is any bearer 
implementation involved.

>
> (I did not understand what "HTTP-compliant middleware" meant, but if 
> it is something at the proxies, I think this is further addressed by 
> making TLS a must--which will make the token simply invisible.)

By "HTTP compolliant middleware" I mean any software which obeys HTTP 
proxy guidelines but not necessarily OAuth or other specifications. 
There are alot of those.

>
> With best wishes for the New Year to you and all OAuthers,
>
> Igor
>
> Igor

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 03 Jan 2012 01:07:37 +1300

On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote:
> Hi,
>> I did not see any such validity time field in the HTTP mechanisms.  
>> You mean the validity period of the token itself? that would be 
>> irrelevant as the case I am raising is for software which does not 
>> support Bearer specs.
>>
>>
>
> Even if the software is not aware of the bearer spec, a token that 
> becomes invalid after a certain time span cannot sucessfully be 
> replayed any longer.

There is no time span limit mentioned in the section 2.3 when token is 
passed in the query string. That is my point.
Proxies which cache and obey HTTP but not Bearer *will* answer to replay 
attacks by providing the supposedly secure response body.

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

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 03 Jan 2012 13:36:48 +1300

On 1/2/2012 7:07 AM, Amos Jeffries 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

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 04 Jan 2012 14:30:01 +1300

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:
>>>>> general note: I do not understand why caching proxies should 
>>>>> impose a problem in case TLS is used (end2end). Could you please 
>>>>> explain?
>>>>
>>> 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:
>> "
>>
>> 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

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 04 Jan 2012 18:07:18 +1300

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

> 2) Now the server knows it, too.
>>
> Same as in 1)
> Sane as in 2)
>> 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