- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Mon, 02 Jan 2012 21:17:59 +1300
- 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 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
Received on Monday, 2 January 2012 08:29:58 UTC