> -----Original Message----- > From: Peter Wolanin [mailto:peter.wola...@acquia.com] > Sent: Wednesday, May 04, 2011 8:54 PM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: OAuth v2 Mac token spec > > Can you give an example of a setup where the hash cannot be calculated?
Large file upload which is read from disk as it is being transmitted. > I think to be secure, the question of whether or not the body hash must be > included in the request should be specified in 2. Issuing MAC Credentials > > For example, as an added aspect of the algorithm, or a separate parameter. > Essentially something like bodyhash: required, versus > bodyhash: optional? Obviously it should be omitted if there is no body (e.g. > for a GET request). By including it in #2, it's certainly clear that some > clients > that cannot generate the body hash could not authenticate with any servers > that require it, but at least this would be known in advance. We can allow the server to indicate its requirements, but that adds more complexity and requires a round trip (pre-fetch or failed) to determine. I am not a fan of this approach. EHL > As a side note, we currently interact with or maintain several services which > use HMAC auth and in one case (a spam blocking service) the inclusion of the > message content in the HMAC (similar to using the body hash) is omitted in > favor of simply doing a HMAC over the URL nonce and time since the > consequence of a MITM attack is relatively unimportant. > > -Peter > On Mon, Apr 11, 2011 at 7:21 PM, Eran Hammer-Lahav > <e...@hueniverse.com> wrote: > > > > > >> -----Original Message----- > >> From: Peter Wolanin [mailto:peter.wola...@acquia.com] > >> Sent: Sunday, February 27, 2011 6:59 AM > > > >> I was a little unclear in the spec whether the client can choose not > >> to include the body hash in the signature. I'd hope that the spec > >> ends up clearly requiring the client to always send it even if a > >> given server may or may not validate the body hash. Our current > >> implementations include the body directly in the HMAC calculation, > >> but considering your current draft I appreciate the extra flexibility > >> provided by signing over the body hash rather than the body itself. > > > > Yes, we need to figure out when the client is required to include it. The > issue is that in some deployments, it is not possible for the client to > calculate > this value at the point where the header is set. > > > >> A downside to the MAC spec for OAuth2 is, as far as I can see, you > >> have to send your client secret in the request if you ever need to > >> refresh your OAuth token? I see in some recent messages liek > >> http://www.ietf.org/mail- archive/web/oauth/current/msg05214.html > >> some discussion that suggests I'm mistaken? > > > > Nope. Refresh does not require the access token or its secret. Just the > refresh code. > > > >> Also, as stated in section 7.3, there seems to be no provision for > >> ensuring response authenticity except relying on SSL. We have been > >> using protocols that include in the response an HMAC of the response > >> body calculated to include the client-supplied nonce. Obviously one > >> could add such a response header without breaking the protocol, but > >> I'd like to see an option in the MAC credentials an added field that > >> specifies whether the server is expected to provide such a response > >> HMAC and a standardized name and construction for such a response > header. > > > > I will add this later, once the current bits are stable. > > > > EHL > > > > > > -- > Peter M. Wolanin, Ph.D. : Momentum Specialist, Acquia. Inc. > peter.wola...@acquia.com : 978-296-5247 > > "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"; _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
