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
