Mike: what are your thoughts on the options? ᐧ On Sat, May 30, 2020 at 4:39 AM Neil Madden <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> 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 > 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
