Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT)
Thanks Barry for the comment. My (personal) responses inline. John and Naveen, if you have anything to add, please chime in. -Original Message- From: Barry Leiba Sent: Tuesday, June 09, 2015 4:42 AM To: The IESG Cc: draft-ietf-oauth-s...@ietf.org ; oauth-cha...@ietf.org ; draft-ietf-oauth-spop.sheph...@ietf.org ; oauth@ietf.org ; draft-ietf-oauth-spop...@ietf.org Subject: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT) Barry Leiba has entered the following ballot position for draft-ietf-oauth-spop-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ -- DISCUSS: -- How does "plain" do anything at all to mitigate this attack? Wouldn't anyone who could snag the grant also be able to snag the code verifier as well? Why is "plain" even here? You have to understand that this spec deals with a scenario that the communication is conducted over two segments: (1)Unprotected: Within the machine through mechanisms like custom scheme. (2)Protected: Over the network, which is protected by TLS. The “snagging” happens over the segment (1). For example, an attacker can snag the grant over this segment. However, he cannot snag code verifier because it is sent over (2), which is TLS protected. -- COMMENT: -- General: I would think that this mechanism should never be a substitute for using TLS, and that this document should be explicit about that, and should say that the proper mitigation for situations where TLS can be used... is to use TLS. Is there a reason we should NOT say that? OAuth (RFC6749 and RFC6750) mandates the use of TLS over the network. PKCE inherits this property. We could mention it again here, but it is sort of already done by inheritance. Putting quotation marks around "code_verifier" and "code_challenge" in the formulas is confusing: it makes it look as if you're putting in those strings themselves, rather than the values of the variables. It's probably unlikely that anyone would make that mistake, but I nevertheless suggest removing the quotation marks when you mean to refer to the values. That’s the peculiarity of the current XML2TXT converter. In XML, it is to signify strings themselves rather than the values of the variables. It renders nicely on HTML format etc., but TXT seem to have this confusing property. Perhaps RFC Editor can deal with. -- Section 2 -- I don't understand the distinction between STRING and ASCII(STRING). Can you please explain it? It is a notation used by JSON Web Signature, etc. It is making sure not to conflate the sequence of characters with sequence of octets of characters. -- Section 4.3 -- If "plain" does stay, why on Earth is it the default? Even if just for form's sake, shouldn't S256 be the default? It is partly historical. The draft started off there, then kept adding other mechanisms. There are many implementations of PKCE now but the largest portion of it is using “plain”. For the sake of interoperability with them, it needs to stay as it is written. -- Section 4.4 -- The word "code" is used for too many things, and "Authorization Grant" is already the right name for what we're talking about here. I suggest that in both the section title and body you use that term, to make it clear what you mean by the "code". RFC 6749 defines two types of Authorization Grant: Authorization Code and Implicit. In PKCE, we are specifically dealing with Authorization Code so replacing them with Authorization Grant loosens it up and is not desirable. I agree that we have been a bit lax in the use of the term “code” as an abbreviation of “Authorization Code”. Also, looking at the TXT representation of the spec, largely due to the formatting peculiarity, it is making them even more confusing than compared to other format. Therefore, I suggest the following: - Replace all occurrence of “code” as an abbreviation of “Authorization Code” with “Authorization Code”. - Capitalize the defined term “code challenge” and “code verifier” so that there will become “Code Challenge” and “Code Verifier” throughout. Similarly, in Section 4.5 please say "code_verifier" rather than "secret". Good catch. Accept. -- Section 4.4.1 -- Please expand "PKCE", which is, at the moment, only expanded in the document tit
[OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-introspection-09: (with DISCUSS and COMMENT)
Alissa Cooper has entered the following ballot position for draft-ietf-oauth-introspection-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ -- DISCUSS: -- = Section 2.1 = "The endpoint MAY allow other parameters to provide further context to the query. For instance, an authorization service may need to know the IP address of the client accessing the protected resource in order to determine the appropriateness of the token being presented." How does the protected resource know whether it needs to include such additional parameters or not? What is meant by the "appropriateness" of the token? In general if we're talking about a piece of data that could be sensitive like client IP address, it would be better for there to be specific guidelines to direct protected resources as to when this information needs to be sent. I note that Section 5 basically says such considerations are out of scope, but if this specific example is to be provided here then they seem in scope to me. = Section 5 = "One way to limit disclosure is to require authorization to call the introspection endpoint and to limit calls to only registered and trusted protected resource servers." I thought Section 2.1 made authorization to call the introspection endpoint mandatory. This makes it sound like it's optional. Which is it? -- COMMENT: -- = Section 1.1 = There is no reference to RFC2119 here, which may be okay but most documents include it if they use normative language (I think). = Section 2 = "The definition of an active token is up to the authorization server, but this is commonly a token that has been issued by this authorization server, is not expired, has not been revoked, and is within the purview of the protected resource making the introspection call." Is "within the purview" a term of art for OAuth 2.0? Is there a more specific way to describe what is meant here? Also, I note that in the description of the "active" member in Section 2.2, this criterion is not listed. It seems like these should be aligned. = Section 2.2 = "Note that in order to avoid disclosing too much of the authorization server's state to a third party, the authorization server SHOULD NOT include any additional information about an inactive token, including why the token is inactive." Seems like this should be a MUST NOT unless there's some reason for providing anything other than active set to false. Same comment applies in Section 4. = Section 2.3 = It seems like there is another error condition and I'm wondering if its handling needs to be specified. Per my question in Section 2.1, if it's possible that the request is properly formed but is missing some additional information that the authorization server needs to evaluate it, should there be an error condition specified for that case? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-ietf-oauth-introspection-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ -- COMMENT: -- I concur with Alissa's discuss. Additional comments: -- There is no reference to RFC 2119, but there seems to be lots of capitalized 2119 keywords. If those are intended to have the 2119 meaning, please add the usual reference. (I assume that these are intended as 2119 keywords for the remainder of the review.) -- 2.1, first paragraph: If the server MAY support GET, how does a client know to use it? Would you expect them to try and fail? -- 3 Is there a reason not to use a more standard IANA procedure? (I.e. let people request registrations to IANA, and have them forward the requests to the DE?) --3.1, under "Name" The MUST seems unnecessary, as that's the whole point of a registry. -- 4: The security considerations have a lot of restated 2119 keywords. If you want to reinforce those here, it would be better to do so with descriptive language, rather than having multiple occurrences of the same normative language. Redundant normative language is error prone, especially for future updates. -- 4, bullet list: It seems odd to have 2119 keywords in a "For instance" section. --4, 6th paragraph from end The reference to [TLS.BCP] should probably be normative. -- 4, last two paragraphs: "An authorization server offering token introspection MUST be able to understand the token values being presented to it during this call." and "the authorization server MUST be able to decrypt and validate the token in order to access this information." These seem more like statements of fact than normative language. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-spop-12: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-ietf-oauth-spop-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ -- COMMENT: -- I share Barry's and Alexey's concerns about both allowing "plain" and defaulting to it. I have some other comments, which may overlap with the comments from others: Substantive: -- section 1, pre-condition 3: "All OAuth 2.0 native app client-instances use the same client_id. Secrets provisioned in client binary applications cannot be considered confidential." Is that part of the pre-condition per-se, or a general statement? If the former, wouldn't a potential mitigation for this attack be to ensure the precondition doesn't occur? -- section 1, paragraph after precondition list: "not applicable since they rely on a per-client instance secret or aper client instance redirect URI." I infer that these are not realistic? If so, it might be useful to say why. For instance, would one way to mitigate this attack be to make sure you have per-client secrets and redirect URIs? -- 4.4.1, last sentence: Does this advice change if people register new challenge methods? That is, what if the client supports "plain", and "foo" but not S256, where foo is more secure than plain. Can it still use "plain"? -- 6.2: Does the ability to register new challenge methods introduce bid-down attacks? (Assuming that any such method is more secure than "plain", and that the server might not support it.) Also, I share Barry's concern that the registration procedures require quite a bit of special treatment from IANA. -- 7.4: This seems to need a normative reference to 6819. -- 7.5: How does the guidance in section 10.8 of 6479 apply to the code_verifier? Also, I think the last sentence requires this draft (or some other) to update 6749. Editorial: -- 4.4, 2nd to last paragraph: "The server MUST NOT include the "code_challenge" value in client requests in a form that other entities can extract." should "client requests" be "responses to clients"? (I assume the server does not send client requests--or do I have the terminology wrong?) -- 4.4.1, first paragraph: Please expand PKCE on first mention. (It might help to declare PKCE in the introduction.) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Brian Haberman's No Objection on draft-ietf-oauth-spop-12: (with COMMENT)
Brian Haberman has entered the following ballot position for draft-ietf-oauth-spop-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ -- COMMENT: -- I agree with Barry's DISCUSS about "plain". Using "plain" makes no sense to me. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Brian Haberman's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT)
Brian Haberman has entered the following ballot position for draft-ietf-oauth-introspection-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ -- COMMENT: -- * In Section 2.1... is the authorization service and the introspection endpoint the same device? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Benoit Claise's No Record on draft-ietf-oauth-introspection-09: (with COMMENT)
Benoit Claise has entered the following ballot position for draft-ietf-oauth-introspection-09: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ -- COMMENT: -- Interested in the answer to Alissa's DISCUSS point 1 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
