Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

From: Mike Jones <[email-masked]>
Date: Tue, 12 May 2020 00:21:40 +0000

That works for me.  Thanks all for the useful back-and-forth that got us to this point of clarity.  I suspect many of us learned things along the way; I know that I did!

                                                       Cheers,
                                                       -- Mike

From: Aaron Parecki <[email-masked]>
Sent: Monday, May 11, 2020 4:55 PM
To: OAuth WG <[email-masked]>
Cc: Neil Madden <[email-masked]>; Mike Jones <[email-masked]>
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

Thank you Neil.

To address Mike's concerns in the previous threads, I would like to also update section 9.7 with the following text:

Clients MUST prevent injection (replay) of authorization codes into the
authorization response by attackers. The use of the `code_challenge`
parameter is RECOMMENDED to this end. For confidential clients, the
OpenID Connect `nonce` parameter and ID Token Claim {{OpenID}} MAY be used
instead of or in addition to the `code_challenge` parameter for this
purpose. The `code_challenge` or OpenID Connect `nonce` value MUST be
transaction-specific and securely bound to the client and the user agent
in which the transaction was started.

This change better clarifies the specific circumstances under which the "nonce" parameter is sufficient to protect against authorization code injection.

Aaron Parecki

On Mon, May 11, 2020 at 11:55 AM Neil Madden <[email-masked]<mailto:[email-masked]>> wrote:
I am happy with this proposed wording. Thanks for updating it.

— Neil

On 11 May 2020, at 19:52, Aaron Parecki <[email-masked]<mailto:[email-masked]>> wrote:

Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!

We would like to propose the following text, which is a slight variation from the text Neil proposed. This would replace the paragraph in 4.1.2.1 (https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) that begins with "If the client does not send the "code_challenge" in the request..."

"An AS MUST reject requests without a code_challenge from public clients, and MUST reject such requests from other clients unless there is reasonable assurance that the client mitigates authorization code injection in other ways. See section 9.7 for details."

Section 9.7 is where the nuances of PKCE vs nonce are described.

As Neil described, we believe this will allow ASs to support both OAuth 2.0 and 2.1 clients simultaneously. The change from Neil's text is the clarification of which threats, and changing to MUST instead of SHOULD. The "MUST...unless" is more specific than "SHOULD", and since we are already describing the explicit exception to the rule, it's more clear as a MUST here.

Aaron Parecki

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 14 May 2020 08:56:43 +0200

Hi all,

I would also like to thank everybody for the substantial discussion.  

The proposed change for Section 4.1.2.1 works for me (as already stated). I’m not fully comfortable with the proposed change for Section 9.7 for the following reasons:

- The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE instead of requiring it (with a well-defined exception).
- Given the latest findings re nonce I don’t feel comfortable with recommending any mechanism that this WG is not responsible for and thus did not conduct the security threat analysis for. I think the better way for us as WG is to define the extension point for other mechanisms. The OpenID Foundation (or any other body) can then fill in and issue a statement that nonce (or another suitable mechanism) fulfils the requirements of the extension point. 

Based on this considerations, I propose the following text for Section 9.7:

Clients MUST prevent injection (replay) of authorization codes into
the authorization response by attackers. Public clients MUST use the 
"code_challenge” with a transaction-specific value that is
securely bound to the client and the user agent in which the
transaction was started. Confidential clients MUST use 
the “code_challenge” in the same way or other suitable mechanisms to 
mitigate authorization code injection. 

This text follows the logic in Section 4.1.2.1 and allows use of the nonce for confidential clients.

best regards,
Torsten. 

> On 12. May 2020, at 02:21, Mike Jones <Michael.Jones=[email-masked]> wrote:
> 
> On Mon, May 11, 2020 at 11:55 AM Neil Madden <[email-masked]> wrote:
> On 11 May 2020, at 19:52, Aaron Parecki <[email-masked]> wrote:
>  
> [email-masked]
> [email-masked]

---

From: Nov Matake <[email-masked]>
Date: Thu, 14 May 2020 16:37:49 +0900

Hi,

Why not allowing public clients use "other suitable mechanisms” then?
OAuth WG can allow both type of clients do so, then OIDF will define nonce as the alternative only for confidential clients.

> 2020/05/14 15:56、Torsten Lodderstedt <torsten=[email-masked]>のメール:
> 
> Hi all,
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 14 May 2020 11:32:14 +0200

Are you aware of any suitable mechanism? I’m asking since from my perspective this clause is mainly intended to allow existing OpenID Connect deployments to use nonce instead of PKCE in combination with OAuth 2.1. It’s a compromise. I think we should not encourage others to invent their own OAuth security mechanisms. 

> On 14. May 2020, at 09:37, Nov Matake <[email-masked]> wrote:
> 
> Hi,
>

---

From: Nov Matake <[email-masked]>
Date: Thu, 14 May 2020 19:18:27 +0900

There is no specific mechanism right now.
But future developers won’t be able to read the reason why the extension point is given only for confidential clients.

> On May 14, 2020, at 18:32, Torsten Lodderstedt <[email-masked]> wrote:
>

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 14 May 2020 16:35:49 -0700

> But future developers won’t be able to read the reason why the extension
> point is given only for confidential clients.

This is not a compelling argument.

The current situation is that we know of a handful of threats and attacks,
we know that PKCE solves them for both confidential and public clients, and
we also believe that OpenID Connect has solved one of the threats for
confidential clients a different way. The reason this conversation is
happening at all is because we want to make sure that OpenID Connect can
continue to solve that problem its own way outside of OAuth without
conflicting with OAuth.

It's not useful to anyone to leave extension points open for hypothetical
solutions later when we already know of a solution that works for public
clients. At that point that should just be a new spec.

Aaron Parecki

On Thu, May 14, 2020 at 3:18 AM Nov Matake <[email-masked]> wrote:

> But future developers won’t be able to read the reason why the extension
> point is given only for confidential clients.
>
> > Are you aware of any suitable mechanism? I’m asking since from my
> perspective this clause is mainly intended to allow existing OpenID Connect
> deployments to use nonce instead of PKCE in combination with OAuth 2.1.
> It’s a compromise. I think we should not encourage others to invent their
> own OAuth security mechanisms.
> >
>
>

---

From: Nov Matake <[email-masked]>
Date: Fri, 15 May 2020 09:12:20 +0900

Then the sentence should not open extension points even for confidential clients,
- by mention OIDC notice explicitly
- by allowing currently existing alternatives only (and prohibit new ones)
etc.

iPadから送信

> 2020/05/15 8:36、Aaron Parecki <[email-masked]>のメール:
> 
> 
> The current situation is that we know of a handful of threats and attacks, we know that PKCE solves them for both confidential and public clients, and we also believe that OpenID Connect has solved one of the threats for confidential clients a different way. The reason this conversation is happening at all is because we want to make sure that OpenID Connect can continue to solve that problem its own way outside of OAuth without conflicting with OAuth.
> 
> It's not useful to anyone to leave extension points open for hypothetical solutions later when we already know of a solution that works for public clients. At that point that should just be a new spec.
> 
> Aaron Parecki
> 
>