Subject: [OAUTH-WG] FW: comments on oauth-v2-http-mac-00

From: Eran Hammer <[email-masked]>
Date: Thu, 8 Mar 2012 12:00:11 -0700

Sending to the full list.

-----Original Message-----
From: Roger Crew [mailto:[email-masked]] 
Sent: Saturday, December 31, 2011 12:47 AM
To: Eran Hammer-Lahav; Adam Barth; Ben Adida
Subject: comments on oauth-v2-http-mac-00

Hi,

I have some comments on the now-expired http_hmac draft (oauth-v2-http-mac-00), which I figured might be useful, on the assumption you're now working on a new draft...

<snip>

As for my role, I'm an implementer (... I need a server-side oauth2 framework, preferably in Perl, and the Perl community / CPAN doesn't really have anything here yet, so I'm trying to fill in the gaps...).

There are three issues I have with http-hmac draft 00 (and I'll also apologize in advance if any of these have already been beaten to death in prior WG discussion; I've only been able to look at the last six months of archives --- the joys of coming to the party late...).

In decreasing order of severity:
 - - - - -

I.  Section 3.3.1: 
   
    would be better if the request-URI portion (item #3) of 
    the normalized request string were ALWAYS just the 
    absolute_path+query_string

(i.e., 'abs_path' as defined in 2616, no scheme, no authority; what *normally* gets sent by browsers when proxies are not in use).

The problem is that "request-URI as defined by [RFC 2616 5.1.2]" means the full URI in the case where a proxy is being used, which then means that the http_hmac implementation has to be able to get at the browser config or otherwise have sufficient knowledge of the local network topology to know whether the request is indeed going to be sent via a proxy server (and hence whether to include the scheme+authority in the normalized request for the hash computation) -- among other things, this makes life rather difficult for javascript clients....

... never mind that the authority (host+port) is already taken care of by items #4 and #5, and the scheme may as well be fixed at "http"
(since if https is available there's mostly no reason to be using http_hmac in the first place).  As far as I can tell, there's just no reason to be including the full authority a second time in item #3 (and especially not if the proxy is going to be messing with it).

 - - - - -

II.  Section 5.1: 

     In token-issue messages, mac_key should be encoded.
     (E.g., have the mac_key parameter of OAuth2 token response 
     be the base64url-without-padding encoding of the key, 
     NOT the key itself)

Bottom line here is it needs to be possible for the key to be an arbitrary octet string.  This is a security issue since having the character set be restricted to 93 printable ASCII characters effectively reduces all key lengths by nearly 20%.  (It's probably best to think of this in terms of an attacker doing a brute force search and how big a space s/he needs to cover:

       93^n is roughly 256^(0.817n)

So for, say, HMAC-SHA1, where the key length is 20 bytes, a plainstring key will actually need to be at least 25 bytes to achieve the same level of protection.)

At the very least, this needs to be mentioned under Security Considerations, so that if you really *do* need keys to be plainstring for some reason, implementers will at least know to lengthen them accordingly.

But you're also assuming that the character set restriction for the key will not be exploitable in some way beyond the reduction of the search space (i.e., due to some yet-to-be-discovered weakness in the SHA family) -- I'll admit this seems unlikely, but I'm not sure I'd want to bet the farm on that, especially once SHA1 gets nearer the end of its useful life as the various weaknesses turn up...

Better to just have the extra (trivial) encoding/decoding steps be specified.  That way the key can be anything at all, and whatever weaknesses might exist in HMAC-SHA{1,256} will be the same as for everybody else that uses these algorithms (i.e., you won't be introducing potential new ones...)

 - - - - -

III.  Sections 3.3.2, 3.3.3 (and 5.1 if you agree with the previous point):

      Use base64url (rfc4648) without padding instead of straight 
      base64 (rfc2045) to encode arbitrary octet strings

Straight base64 was designed for use in email.  Base64url-no-padding is better in HTTP contexts for not using '+', '/', and '='.  

And I'll grant this doesn't necessarily matter for the Authorization header, but it *does* matter for the POST body and URI parameter lists, being able to pass http_hmac tokens as parameters is an obvious and useful extension (the bearer spec already does this), and it's less confusing if you have a uniform specification where you're using the same encoding everywhere.

Meanwhile, '='-padding is only necessary in cases where it otherwise might not be clear where the string ends -- again true in email contexts, but definitely NOT the case for HTTP quoted string syntax.

 - - - - -

I also had things to say about 'body_hash', but I now see that you're dropping that (to which my general reaction is basically, YAY, THANK YOU... 'ext' should be enough to play with).

and thanks for your time.

--
Roger Crew
[email-masked]