Proof Key for Code Exchange by OAuth Public Clients
draft-ietf-oauth-spop-15
Yes
(Kathleen Moriarty)
No Objection
(Alia Atlas)
(Alvaro Retana)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Martin Stiemerling)
(Terry Manderson)
Note: This ballot was opened for revision 11 and is now closed.
Kathleen Moriarty Former IESG member
Yes
Yes
(for -11)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -12)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2015-06-10 for -12)
Unknown
I support Barry's DISCUSS.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -12)
Unknown
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2015-07-06 for -14)
Unknown
Version -14 resolves my DISCUSS (and also some of my non-blocking comments). Thanks very much for considering these and working with me on them! ========================================= My comment about the IANA Considerations remains. While it's non-blocking, I still hope you will accept the change I suggest: -- Section 6.2 -- I have the same comment here as in the other OAuth document: please shift the focus away from telling IANA how to handle tracking of the expert review, and make the mailing list something that the designated expert(s) keep track of. Also, please give more instructions to the DEs about what they should consider when they're evaluating a request (for example, should they approve all requests, or are there criteria they should apply?). For the first, here's a text change that I suggest we move toward for this sort of thing: OLD <most of Section 6.2> NEW Additional code_challenge_method types for use with the authorization endpoint are registered using the Specification Required policy [RFC5226], which includes review of the request by one or more Designated Experts. The DEs will ensure there is at least a two-week review of the request on the oauth-ext-review@ietf.org mailing list, and that any discussion on that list converges before they respond to the request. To allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that an acceptable specification will be published. Discussion on the oauth-ext-review@ietf.org mailing list should use an appropriate subject, such as "Request for PKCE code_challenge_method: example"). The Designated Expert(s) should consider the discussion on the mailing list, as well as <<these other things>> when evaluating registration requests. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. END ========================================= -- Section 7.2 -- I find the first first paragraph confusingly worded, and after discussion with the author I suggest this: NEW Clients MUST NOT downgrade to "plain" after trying the S256 method. Because servers are required to support S256, an error when S256 is presented can only mean that the server does not support PKCE at all. Otherwise, such an error could be indicative of a MITM attacker trying a downgrade attack. END ========================================= Finally, there is this comment, which is not a big deal and you should proceed as you think best: -- Section 2 -- There is no real distinction between STRING and ASCII(STRING), because STRING is already defined to be ASCII. Using "ASCII(xxx)" only adds clutter, and a suggest removing it. So, for example, that would result in changes such as this: OLD BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge NEW BASE64URL-ENCODE(SHA256(code_verifier)) == code_challenge END
Ben Campbell Former IESG member
No Objection
No Objection
(2015-06-09 for -12)
Unknown
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.)
Benoît Claise Former IESG member
No Objection
No Objection
(for -12)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(2015-06-10 for -12)
Unknown
I agree with Barry's DISCUSS about "plain". Using "plain" makes no sense to me.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -12)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -12)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2015-06-09 for -12)
Unknown
From Melinda Shore's OPSdir review: I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This document is ready, with very minor issues. It does not appear to introduce new management/manageability considerations. This document describes a challenge-response mechanism to protect against an OAuth authorization code being intercepted by an attacker, when that authorization code is sent in the clear. The authorization code is used to acquire an access token and must be protected. This attack (an attacker using an intercepted authz code to acquire an access token) has been observed in the wild. We are astonished to learn that OAuth is being run over an unencrypted channel. However, given that it is, this is a reasonable defense mechanism. Questions: Why is S256 RECOMMENDED and not a MUST? Nits: ASCII(STRING) does not appear to be used in the protocol grammar? Melinda
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -12)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -12)
Unknown