Re: [OAUTH-WG] Last call comments on bearer draft 08 from Yaron Goland

[Mike Jones <[e-mail]>]

Thanks for your comments, Yaron.  Responses to them, which reflect the content of draft 09, follow inline.

                                                                -- Mike

From: [e-mail] [mailto:[e-mail]] On Behalf Of Mike Jones
Sent: Wednesday, August 10, 2011 2:39 PM
To: [e-mail]
Subject: [OAUTH-WG] Last call comments on bearer draft 08 from Yaron Goland

1.  Introduction:  Adding the word "directly" after "rather than using the resource owner's credentials".

Done

1.3. Overview:  Comment on first sentence:  "OAuth also supports having a client directly provide its own credentials to get an access token. It would seem useful to refer to this as well less the reader think that OAuth is only for delegation. That was true with OAuth 1.0 but not 2.0."

Added the sentence:  "In some cases, a client can directly present its own credentials to an authorization server to obtain an access token without having to first obtain an access grant from a resource owner." and also qualified the phrase "Before a client can access a protect resource" by prefixing it with the words "In the general case,".

1.3. Overview, paragraph 3:  Commented on "The following steps are specified within this document": "Actually you also specify the token type returned in step D. I think this is worth explicitly calling out."

Added the sentence:  "Use of this specification also requires that the access token returned in step (D) must be a Bearer token."

2.  Authenticated Requests:  Commented "It would seem appropriate to begin with an example of step D showing that the returned access token is of type bearer."

Not done, in the interest of brevity.

2.3. URI Query Parameter:  Commented on second example: "Does order matter? In this case the access_token is last. Is that because it has to be or because order is irrelevant?"

Clarified the text and example to make it clear that order doesn't matter.

2.4. The WWW-Authenticate Response Header Field: Commented on word "invalid": "The term invalid is a tricky one. Invalid can mean 'not supported' or 'not recognized' but that is generally taken to be a 400 Bad Request and would not require a www-authenticate response header field. Or invalid can mean 'supported but not the right credentials' in which case the error is a 401 Unauthorized and a www-authenticate response is required.  I would urge you to consider simplifying this text by just stating (without preamble) that if a www-authenticate response header is returned (either from a 401 Unauthorized or other reasons) then support for the Bearer token type is specified as given below."

I've changed this language to "If the protected resource request does not include authentication credentials or does not contain an access token that enables access to the protected resource, the resource server MUST include ...".  I decided not to pare it down to the degree you suggested, as I believe that there is value to developers in explaining the conditions under which a WWW-Authenticate response would be used.

2.4. The WWW-Authenticate Response Header Field:  Commented on "param" definition: "As defined in http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-15#section-4.4, www-authenticate is not really an error response mechanism. It's an advertisement mechanism. It says "here is what I support by way of authentication."  So I really don't think it's appropriate to show horn in here error information that has nothing to do with advertising authorization capabilities. If we need to return things like error, error-desc, etc. that should either be stuck in the body or put in a separate header. We should leave the www-authenticate header to be as simple as possible."

As the bearer token spec has included these features since its inception, and since removing or changing these features would be a breaking change, I have not made this change.

3.1. Security Threats: Token redirect: Change "An attacker uses the token generated for consumption by resource server to obtain access to another resource server" to "An attacker uses the token generated for consumption by a particular resource server with a different resource server that mistakenly believes the token to be for it".

I've changed this to: "An attacker uses a token generated for consumption by a particular resource server to gain access to a different resource server that mistakenly believes the token to be for it."

3.1 Security Threads: Token replay:  Change "replay" to "capture" and change "An attacker attempts to use a token that has already been used with that resource server in the past" to "An attacker somehow obtains a token they were not authorized to possess and uses it to access protected resources".

Given that the replay attack is defined in NIST Special Publication 800-63, I am reluctant to change this attack description from "token replay" to "token capture".

3.2 Threat Mitigation:  Add at end of first paragraph:  "The mechanics of such an interaction are not defined by this specification."

Done

3.2. Threat Mitigation:  Delete "and replay" from paragraph 5.

Not done, as it is related to the change not made in 3.1.

3.2. Threat Mitigation:  Change "has to be" to "MUST".

Done

3.2. Threat Mitigation:  Comment on "leaked" in paragraph 5:  "Significantly? Really? In what way? Give me a token for a few hundred milliseconds and I can probably do all the damage I could do if you gave it to me for a few days.  I would suggest removing the term significantly."

Done

3.3. Summary of Recommendations: Validate SSL certificate chains: Change "must" to "MUST".

Done

3.3. Summary of Recommendations: Always use TLS (https):  Add "or equivalent transport security" after TLS reference.

Done

3.3. Summary of Recommendations: Don't store bearer tokens in cookies:  Add sentence at end: "Implementations that do store bearer tokens in cookies MUST take precautions against cross site request forgery."

Done

3.3. Summary of Recommendations:  Comment on "Don't pass bearer tokens in page URLs": "It seems like this should also be mentioned in section 3.2."

It's not clear where this would fit into the flow of 3.2, so I've let the description stand as-is in 3.3.

Appendix A.  Acknowledgements:  Change "Yaron Goland" to "Yaron Y. Goland".

Done