Thanks for the review. PKCE started out only supporting plain, and that is what most current deployments are using. That has the lowest implementation for client developers.
In the majority of situations (the ones currently exploited) on iOS the attacker only has access to the response coming back from the AS and not the request with the code_challenge. This is to do with the way custom scheme redirects work in the OS. Knowing that for not much more work we can protect the code_challenge as well. We made that Mandatory to implement on the server side, and SHOULD for clients. A client opting to do plain is still getting significant protection and the choice is based on there risk tolerance. The feedback was that there are some developers that would rather ignore the risk than so S256. If we didn’t have to deal with the pesky developers then I would agree with you that we should not allow plain. I fixed that issue in 7.1 and refactored the security considerations text based on feedback from Ben on Sunday. Let me know if Draft 11 fixes the issue for you. I will take care of the normative reference for SHA256 in the next update. Thanks for noticing. I am at The Cloud Identity Summit (CIS) all week so my responses may be spotty until next week. Regards John B. > On Jun 9, 2015, at 5:05 AM, Alexey Melnikov <[email protected]> wrote: > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > This review is in response to a request for early Gen-ART review. > > Document: draft-ietf-oauth-spop-11 > Reviewer: Alexey Melnikov > Review Date: 2015-06-09 > IETF LC End Date: 2015-06-01 > IESG Telechat date: 2015-06-11 > > Summary: Almost Ready > > > Major Concerns: > > What is the justification for having the "plain" verifier? If one is > intercepted by a malicious application, your extension becomes pointless. > > > Minor Concerns: > > Is code_challenge_method missing in 4.5? > > Sections 7.1 and 7.3 are talking about the same thing? Should they be merged > into one? If they are not talking about the same thing, should they be named > differently? > > > Nits: > > > 4.2. Client creates the code challenge > > The client then creates a code challenge, "code_challenge", derived > from the "code_verifier" by using one of the following > transformations on the "code_verifier": > > plain "code_challenge" = "code_verifier" > S256 "code_challenge" = BASE64URL- > > ENCODE(SHA256(ASCII("code_verifier"))) > It is RECOMMENDED to use the S256 transformation when possible. > ABNF for "code_challenge" is as follows. > > code-challenge = 43*128unreserved > unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" > ALPHA = %x41-5A / %x61-7A > DIGIT = %x30-39 > > SHA-256 requires a normative reference. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
