Sending to the full list.
-----Original Message-----
From: Roger Crew [mailto:[email protected]]
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 protected]
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
