Proof Key for Code Exchange by OAuth Public Clients
RFC 7636

Note: This ballot was opened for revision 11 and is now closed.

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2015-06-09 for -12)
No email
send info
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) No Objection

Alissa Cooper No Objection

Comment (2015-06-10 for -12)
No email
send info
I support Barry's DISCUSS.

(Brian Haberman) No Objection

Comment (2015-06-10 for -12)
No email
send info
I agree with Barry's DISCUSS about "plain".  Using "plain" makes no sense to me.

(Joel Jaeggli) No Objection

Comment (2015-06-09 for -12)
No email
send info
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

Barry Leiba (was Discuss) No Objection

Comment (2015-07-06 for -14)
No email
send info
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

(Terry Manderson) No Objection

Alvaro Retana No Objection

(Martin Stiemerling) No Objection