Thanks James. > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Manger, James H > Sent: Thursday, February 03, 2011 9:23 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] MAC: more comments on draft-hammer-oauth-v2- > mac-token-02 > > Comments on draft-hammer-oauth-v2-mac-token-02 > <http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02> > > This draft is a good improvement. > > (continuing numbering from my previous comments) > > 11. The "access token" field would be better labelled "id". The MAC scheme > only needs this field to identify the MAC secret. The MAC scheme itself > doesn't need to care whether this id also represents a scope, duration, > assertion etc. > > Though it may slightly complicated the use of the MAC scheme with OAuth2, > I would seriously consider supporting two identifiers: > * An authentication id -- to identify the key used to verify the MAC; and > * An authorization id -- to identify the > scope/account/permissions/duration... > that the client want to act under. > The SASL framework has these two concepts > [RFC4422 Simple Authentication and Security Layer (SASL)]. > Any modern SASL authentication mechanism will be expected to support > both ids. > The authorization id is a good match for an OAuth2 token or other sort of > assertion. > The OAuth2-to-MAC binding could define a 'keyid' parameter to accompany > the 'secret'. > The 'keyid' value would map to the authentication id field in the MAC > scheme, and the 'access_token' would map to the authorization id field.
I don't see the value of this, but I do see how it complicates both the specification and its usage with OAuth. The token can be constructed using these two identifiers if needed, outside its use with OAuth, but my instinctive reaction is that if you need something that much more specific, you will be better off using something else. > 12. Which bytes does the body hash apply to? Is it the "message-body" or > "payload body" (in HTTPbis parlance)? I assume any Transfer-Encoding (eg > chunked) is removed before calculating the body hash, but any Content- > Encoding (eg gzip) is not removed. The spec should explicitly state this. > [c.f. > wording as for the "Content-MD5" header in draft-ietf-httpbis-p3-payload- > 12, section 6.8] I'll make this clear. > 13. The MAC algorithm should be explicitly indicated in the request, instead > of being implied by the access-token/id. I suggest including an "algorithm" > parameter in the "Authorization" request header. I also suggest including an > "algorithms" parameter in the "WWW-Authenticate" response header that is > a > (comma-separated?) list of MAC algorithms that the server supports. Why? The client does not get a choice which algorithm to use. There is no negotiation here. > 14. Explicitly state in section 3.3.2 (and 3.3.3) that SHA-1 (and SHA-256) are > used to calculate the body hash when using the hmac-sha-1 (and hmac-sha- > 256) algorithm. Why isn't 3.2 enough? That's where body hash is discussed. > 15. 3.3.2 (and 3.3.3) shouldn't mention the OAuth-specific "authorization > server" (when defining their "key" field). Ok. > 16. OAuth2 can provide a "secret" as a Unicode string. MAC algorithms such > as HMAC use a key that is a byte array. Section 2 of the MAC spec says > 'secret' > can only include printable ASCII chars (except " and /). This is not quite > right. > The MAC scheme should expect 'secret' to be a byte array (ie not limit its > chars). A 'secret' string from an OAuth2 response should be UTF-8 encoded > to produce the byte array the MAC scheme uses. What about when the secret is returned in the HTTP fragment? What is the value of making this use UTF-8. > 17. This MAC scheme should be compared to the SCRAM SASL mechanism > [RFC 5802]. > SCRAM is the latest-and-greatest authentication mechanism based on a > shared secret (without using the brilliant, but patent-troubled, zero- > knowledge proof techniques). > It has quite a few features that MAC is missing: two ids (auth & authz); > credentials at the server are not sufficient to impersonate the client (not a > "password-equivalent"); mutual authentication; channel binding (to an > underlying TLS secure tunnel). > I don't think MAC can achieve all these properties. The MAC scheme almost > certainly wants to avoid multiple exchanges at the HTTP layer. I expect the > wider IETF community to judge MAC by comparing it negatively to SCRAM > unless the document is quite clear about its constraints (eg sign an HTTP > request without any interactivity with the server; suitable for shared secret > keys, but not for shared passwords...). I'll make this comparison clear in the introduction. EHL > > -- > James Manger > > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Manger, James H > Sent: Tuesday, 11 January 2011 5:05 PM > To: OAuth WG > Subject: [OAUTH-WG] MAC: comments on draft-hammer-oauth-v2-mac- > token-00 > > Comments on draft-hammer-oauth-v2-mac-token-00 > <http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-00> > > 1. The connection of this MAC scheme to OAuth is secondary. The primary > function of the MAC scheme is to secure the authenticity of parts of an HTTP > request using a shared secret. Section 2 "Issuing MAC-Type Access Tokens" > would be better at the end, ideally as an Annex, along with most of the > OAuth talk from the introduction (and title). > > 2. Include a \n after the final query string parameter. > It makes the format simply lines of text, instead of making the last line > special > (and only special if there are query params). It is awkward to manually edit > sample files, debug files etc without a final newline character. > Adding a final \n would just make it more consistent. > > 3. The Authorization header example in 1.1 uses single quotes around values. > It should use double quotes. The ABNF in 3.1 for timestamp, for instance, > explicitly uses <">. > > 4. The quoted-string production only supports a subset of ASCII. Better add a > sentence stating that the 'token' is assumed to only use this subset so no > escaping is defined. May be worth adding that only double-quote and > backslash need escaping in quoted-string, but neither of those are allowed in > any of this specs parameters so no escaping in quoted-string values shall > occur. > > 5. Don't list the new line characters as separate numbered items in section > 3.2.1 "Normalized Request String". Better to say it is a line-based format. > Each line ends with a single new line character (U+000A). Then list the 7 > lines > (as points 1 to 7), followed by point 8 saying there is 1 extra line for each > query string parameter. > > 6. I18N. Is the Normalised Request String UTF-8, or does it happen to be just > ASCII? Host, path, and query strings can contain non-ASCII characters -- but I > guess that the ASCII-only escaping used to create an HTTP Host header and > URI are assumed to have occurred before this spec uses these values. Would > be worth an explicit statement, and definitely an example. > > 7. I suggest swapping steps 2 (sort) & 3 (combine escaped name and value) in > section 3.2.1.1. "Parameters Normalization". > The current 2-layer sort is not ideal (sort on %-escaped name, then on %- > escaped value if the names are equal). It needs a special comparator function > etc, instead of using a programming language's standard sort-a-list-of-strings > function. It is tempting to concatenate %-escaped name=value pairs and sort > those -- but it doesn't always give the same result. > Eg a1=X and a11=Y should sort in that order according to the spec, but "1" < > "=" in an ASCII string comparison of the pairs. > A programmer probably has a map/dictionary/assoc-array of unescaped > names to values. The normalisation rules require a separate map of escaped > names to escaped values plus a custom comparator that considers names > and values. > A nicer alternative would be to construct escaped name=value pairs then > sort that list (not map). > It would be worth adding another parameter to the example (eg a22=A) to > illustrate this (regardless of whether or not the steps are swapped). > > 8. HMAC operates on bytes, not strings. The 'text' and 'key' HMAC inputs (in > 3.2.2 and 3.2.3) should be specified as the UTF-8-encoding of the Normalized > Request String and access token shared secret respectively. Might be able to > say ASCII-encoding, but only if we are sure that an OAuth token response > (which might be a UTF-8 JSON blob) can never return non-ASCII chars in a > 'secret' field. > > 9. The 'secret' parameter is registered twice (7.1 & 7.2). I guess one of > these > should be registering the 'algorithm' parameter instead. > > 10. I would like a "WWW-Authenticate: MAC algorithm=..." response header > defined. It would provide a nice illustration of how a complete HTTP auth > scheme is mapped to OAuth2. That is, how the scheme name "MAC" and > parameters from the "WWW-Authenticate: MAC ..." response header can be > mapped to fields in an OAuth2 token response (where they are accompanied > by an actual secret key). > > -- > James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
