On Wed, Jun 8, 2011 at 10:32 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: >> -----Original Message----- >> From: Tim [mailto:tim-proje...@sentinelchicken.org] >> Sent: Wednesday, June 08, 2011 8:32 AM > >> At risk of repeating myself: Why not just adapt HTTP Digest for OAuth? >> That is not just rhetorical, it is a genuine question. What is HTTP Digest >> missing that you need?
Digest has a bunch of problems. See this document http://tools.ietf.org/html/draft-ietf-httpbis-security-properties-05#section-2.2.2 for a short tour of them. > The latest version of this draft: > > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00 > > Includes a Design Constraints section which tries to explain this: > > Unlike the HTTP Digest authentication scheme, this mechanism does not > require interacting with the server to prevent replay attacks. > Instead, the client provides both a nonce and a timestamp, which the > server can use to prevent replay attacks using a bounded amount of > storage. It's not obvious to me why the mechanism in the draft is better than a server-generated nonce and/or opaque string, as found in Digest. The mechanism in the draft can be bitten by clock skew problems, and having the server send a nonce doesn't necessarily require an unbounded amount of storage. I'm sorry if I've missed previous discussion on this issue, but could someone explain? > Also unlike Digest, this mechanism is not intended to > protect the user's password itself because the client and server both > have access to the key material in the clear. Instead, servers > should issue a short-lived derivative credential for this mechanism > during the initial TLS setup phase. That makes sense. I'm having trouble reconciling the Design Constraints section (1.1) with the section on Entropy of MAC Keys (7.5). How long are these keys supposed to be around in practice? Also, Adam wrote "this mechanism is for folks who cannot or will not deploy TLS". How does that statement fit here? - Rob _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
