Thanks for laying out the solutions so neatly. We would prefer #2 the "dynamic" solution because it wouldn't require us to do any changes. I've had the impression that the unexpected code_verifier case was somehow covered as an error in RFC 7636 but checked the spec now and apparently it isn't.
Vladimir On 30/05/2020 10:58, Daniel Fett wrote: > Hi all, > > Aaron, Dick, Torsten and I today discussed the downgrade attacks on > PKCE [1] and how to mitigate them in OAuth 2.1 and 2.0. We came to the > conclusion that we have two options: > > *1. "Static" Solution* > > For every client_id that is registered with an AS, the AS MUST either > always enforce the use of PKCE or always enforce the use of nonce. > Whether PKCE or nonce is enforced can be part of the client > registration or configured in other ways. > > In other words: A single client is not allowed to switch between using > PKCE and using nonce. > > Note that the client is allowed to use the respective other mechanism > on top of the enforced one. > > Properties: > > * Easy to understand mitigation. > * Implementation is mainly a new data field and a check in the > authorization request. > * Not compatible to deployments where clients sometimes use nonce > and sometimes use PKCE with the same client_id. * > *** > > ** > > *2. "Dynamic" Solution* > > Each AS that supports PKCE MUST check whether a code challenge is > contained in the authorization request. This information MUST be bound > to the code that is issued. > > When a code arrives at the token endpoint, the AS MUST do the > following check: > > 1. If there was a code_challenge in the authorization request for > which this code was issued, there must be a code_verifier in the > token request and it must be verified according to RFC7636. (This > is no change from the current behavior in RFC7636.) > 2. If there was no code_challenge in the authorization request, any > request to the token endpoint containing a code_verifier MUST be > rejected. > > Properties: > > * No change in behavior needed for properly implemented clients. > Backwards compatible for all existing deployments. > * Implementation is mainly some logic for the authorization > endpoint, token endpoint, and a new data field in the > authorization session maintained by the AS. > * Slightly more complex to implement for the AS, maybe. > > We would like to hear the feedback from the working group on these two > solutions before proceeding to propose wording for the affected documents. > > [1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ > > -Daniel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
