Subject: Re: [OAUTH-WG] OAuth v2 Mac token spec

From: Peter Wolanin <[email-masked]>
Date: Wed, 4 May 2011 23:53:53 -0400

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 <[email-masked]> wrote:
>
>
>> -----Original Message-----
>> From: Peter Wolanin [mailto:[email-masked]]
>> 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.
[email-masked] : 978-296-5247

"Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 18 May 2011 09:38:39 -0700

> Sent: Wednesday, May 04, 2011 8:54 PM
> To: Eran Hammer-Lahav
> Cc: [email-masked]
> Subject: Re: OAuth v2 Mac token spec
> 

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
> >> 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?
> >
> >> 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.
> >

---

From: Peter Wolanin <[email-masked]>
Date: Wed, 18 May 2011 13:10:58 -0400

Dear Eran,

I was not suggesting an extra round-trip to the server.  Rather, that
whether or not the server requires the body hash be part of the credentials
supplied for that endpoint.

Thus, a client that could not calculate a body hash would simply not be able
to authenticate requests with a non-empty body, and should not attempt to do
so at all.

However, your use case of a file on disk does strengthen further in my mind
the argument for using body hash rather than calculating the hash over the
headers+body.  I should be able to calculate the hash of the file on disk
(e.g. using the PHP function hash_file('sha256', $filename) ), so I could
then construct all the headers and stream the file to the server.

-Peter

On Wed, May 18, 2011 at 12:38 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> parameter.
> 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
>