Thanks for your comments, Yaron. Responses to them, which reflect the content
of draft 09, follow inline.
-- Mike
From: [email protected] [mailto:[email protected]] On Behalf Of Mike
Jones
Sent: Wednesday, August 10, 2011 2:39 PM
To: [email protected]
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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
