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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
