Subject: Re: [OAUTH-WG] Downgrade attacks on PKCE

From: Dick Hardt <[email-masked]>
Date: Mon, 1 Jun 2020 10:54:04 -0700

Mike: what are your thoughts on the options?
ᐧ

On Sat, May 30, 2020 at 4:39 AM Neil Madden <[email-masked]>
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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 2 Jun 2020 12:33:03 +0300

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
> 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.
>
> 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*
>
> 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:
>
>     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.)
>   * No change in behavior needed for properly implemented clients.
>   * 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.
>

---

From: Gavin Henry <[email-masked]>
Date: Tue, 2 Jun 2020 10:41:59 +0100

I note Ory Hydra forces PKCE for all types of clients already.