Re: [OAUTH-WG] Downgrade attacks on PKCE

[John Bradley <[e-mail]>]

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 <[e-mail]>
> *Sent:* Monday, June 1, 2020 10:54 AM
> *To:* Neil Madden <[e-mail]>
> *Cc:* Daniel Fett <[e-mail]>; [e-mail]; Mike Jones
> <[e-mail]>
> *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 <[e-mail]
> <mailto:[e-mail]>> 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 <[e-mail]
>         <mailto:[e-mail]>> 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
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/oauth
>
>      
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth