Responses to suggestions not adopted on draft 04 are inline below. Thanks for
your input.
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Torsten Lodderstedt
Sent: Wednesday, March 23, 2011 1:52 PM
To: Hannes Tschofenig
Cc: OAuth WG
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-bearer-03.txt
> section 2.4
>
> What is the meaning of the component "( token "=" ( token / quoted-string )
> )" in the definiton of the rule "param"?
Can any of the other working group members who participated in writing this
particular text answer this question? I agree that this should be defined in
the specification.
> "The "scope" attribute MUST NOT appear more than once."
> Is the scope optional?
Yes. Is there a particular change to the text that you believe is necessary?
> section 2.4.1
>
> I don't see the benefit of those error codes as they replicate the meaning of
> HTTP status codes 400, 401, and 403.
I disagree with this comment, as these error codes are more specific than the
corresponding HTTP status codes. Furthermore, before making any change to the
error codes, I would want to see a demonstration of working group consensus for
a specific change before making it.
> section 3.1
>
> "Token redirect" - does this also cover the threat of a counterfeit server
> phishing and abusing tokens
> (https://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.6.4)?
No, it does not, as I see it, but because the list of threats comes from
NIST800-63, I'm not prone to expand it here. I believe that this was text
originally authored by you. What specific change would you suggest?
> I would furthermore suggest to add the following paragraph to this section:
>
> Token abuse by counterfeit server: Clients SHOULD not make authenticated
> requests with an access
> token to unfamiliar resource servers, regardless of the presence
> of a secure channel. If the resource server address is well-known
> to the client, it MUST authenticate the resource servers by using HTTPS
> server authentication prior sending the request.
I believe that the suggested addition is largely redundant with this existing
text: "Presenting the token to an unauthenticated and unauthorized resource
server or failing to validate the certificate chain will allow adversaries to
steal the token and gain unauthorized access to protected resources". Is there
are specific change you'd like to propose that would consolidate both
statements of this security principle?
> section 3.3
>
> "Don't store bearer tokens in cookies As cookies are generally sent in the
> clear, implementations MUST NOT store bearer tokens within
> them."
>
> Every cookie can be declared to be send over encrypted channels only.
> Moreover, it is subject to a same origin policy. So what is the threat here?
> Is it about the storage in the clear?
The threat is about transmission in the clear. This point has already been
reworked in response to other comments. Your comments on the new text would be
welcome.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
