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

From: Peter Wolanin <[email-masked]>
Date: Sun, 27 Feb 2011 09:59:07 -0500

Dear Mr. Hammer-Lahav

regarding http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02

I was quite happy to find this, since I had overlooked it before and
it define the sort of robust HMAC-based auth we have been using for
our APIs in various forms, but has the advantage of being a standard
that if implemented would make our future implementations much more
standardized.

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.

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.

-Peter

--
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: Peter Wolanin <[email-masked]>
Date: Sun, 27 Feb 2011 10:55:08 -0500

To clarify a bit in terms of of the flexibility I mention being gained
by keeping a body hash filed in the headers and for constructing the
signature - I'm imagining myself implementing 2 layers of servers for
handling the upload and processing of large files.

The public facing server (e.g. a load balancer and auth server where
SSL terminates) could hold all the secrets and verify the signature
based on just the headers including the body hash.  Then, a back-end
sever could take the request body and verify the body hash (returning
a 403 if it doesn't match) without needing to have access to the
client secrets.

I agree with your comments at
http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/
that the core spec should be based on HMAC signatures.  I was
previously very disappointed when looking at the main Oauth2 spec and
seeing only the bearer token approach or the approach of sending the
secret in the request.  Seems like barely an improvement over http
basic auth.  Perhaps a bearer token is suitable for use cases of just
reading public or semi-public data, but even then I'm astounded that
the operation of getting a refreshed token would not use an HMAC based
signature instead of sending the secret.

Best,

-Peter Wolanin