- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 03 Jan 2012 01:07:37 +1300
- To: Torsten Lodderstedt <torsten@lodderstedt.net>
- CC: igor.faynberg@alcatel-lucent.com, ietf-http-wg@w3.org, oauth@ietf.org
On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: > Hi, >>>> >>> 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. >> >> > > 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
Received on Monday, 2 January 2012 12:10:58 UTC