Definatly 2. To my mind if you get a challange and dont get a verifyer that must fail.
I guess the querstion is if there is a veriyer with no challange what to do. We diden't specify that. I would reject that as a config error or indication of a MIM in the front channel. I think that is the correct thing to do. On 6/1/2020 3:11 PM, Mike Jones wrote: > > Like Filip and Neil and I believe Ryan, I prefer the dynamic option > 2. It keeps existing clients working when possible, which should be a > goal of OAuth 2.1. > > > > Thanks, > > -- Mike > > > > *From:* Dick Hardt <dick.ha...@gmail.com> > *Sent:* Monday, June 1, 2020 10:54 AM > *To:* Neil Madden <neil.mad...@forgerock.com> > *Cc:* Daniel Fett <f...@danielfett.de>; oauth@ietf.org; Mike Jones > <michael.jo...@microsoft.com> > *Subject:* Re: [OAUTH-WG] Downgrade attacks on PKCE > > > > Mike: what are your thoughts on the options? > > ᐧ > > > > On Sat, May 30, 2020 at 4:39 AM Neil Madden <neil.mad...@forgerock.com > <mailto:neil.mad...@forgerock.com>> wrote: > > We (ForgeRock) already support solution 1 as a configuration > option, but I prefer solution 2 and have raised a ticket for us to > implement it. For us at least it’s a trivial fix and seems more > robust against configuration errors. > > > > — Neil > > > > On 30 May 2020, at 08:58, Daniel Fett <f...@danielfett.de > <mailto:f...@danielfett.de>> 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 > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
