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 <e...@hueniverse.com>wrote:
>
>
> > -----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";
>
--
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
