Can you give an example of a setup where the hash cannot be calculated? 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. 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
