[Trimming the CC to just the OAuth WG.] On Wed, Jun 8, 2011 at 8:53 PM, Robert Sayre <say...@gmail.com> wrote: > 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.
Maybe I'm not completely clear how a mechanism with a server-supplied nonce would work. How do you avoid having to make a round-trip to the server for every request? > 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? I think we've handled most of the clock skew problems by using relative time rather than absolute time. I'd certainly consider a mechanism with a server-supplied nonce if you have one in mind. >> 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? I'd recommend using a MAC key of roughly the same length as the block size of the MAC. For example, for hmac-sha-1, I'd use 20 bytes. > Also, Adam wrote "this mechanism is for folks who cannot or will not > deploy TLS". How does that statement fit here? Often the issues surrounding deploying TLS revolve around third-party integrations, such as advertisements. This mechanism side-steps those issues, albeit providing less security than TLS. Adam _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
