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: Mon, 02 Jan 2012 21:17:59 +1300
Message-ID: <4F016837.3040904@treenet.co.nz>
To: igor.faynberg@alcatel-lucent.com
CC: ietf-http-wg@w3.org, oauth@ietf.org
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 
  (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
Received on Monday, 2 January 2012 08:29:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:00 UTC