Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Nov Matake <matake@gmail.com>
In-Reply-To: <2298156A-1CAE-478D-B036-DD32A6EEBEF0@lodderstedt.net>
Date: Thu, 14 May 2020 16:37:49 +0900
Cc: OAuth WG <oauth@ietf.org>,
 Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B5EBD2C-09EF-403A-9270-A53EEE691E40@gmail.com>
References: <MN2PR00MB068633B7B72E5416AA8984D1F5BE0@MN2PR00MB0686.namprd00.prod.outlook.com>
 <2298156A-1CAE-478D-B036-DD32A6EEBEF0@lodderstedt.net>
To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/f0tUKBHhip0QLZvVtLD9F651GuM>
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
Precedence: list

Hi,

Why not allowing public clients use "other suitable mechanisms=E2=80=9D =
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=E3=80=81Torsten Lodderstedt =
<torsten=3D40lodderstedt.net@dmarc.ietf.org>=E3=81=AE=E3=83=A1=E3=83=BC=E3=
=83=AB:
>=20
> Hi all,
>=20
> I would also like to thank everybody for the substantial discussion. =20=

>=20
> The proposed change for Section 4.1.2.1 works for me (as already =
stated). I=E2=80=99m not fully comfortable with the proposed change for =
Section 9.7 for the following reasons:
>=20
> - 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=E2=80=99t 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.=20
>=20
> Based on this considerations, I propose the following text for Section =
9.7:
>=20
> Clients MUST prevent injection (replay) of authorization codes into
> the authorization response by attackers. Public clients MUST use the=20=

> "code_challenge=E2=80=9D 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=20
> the =E2=80=9Ccode_challenge=E2=80=9D in the same way or other suitable =
mechanisms to=20
> mitigate authorization code injection.=20
>=20
> This text follows the logic in Section 4.1.2.1 and allows use of the =
nonce for confidential clients.
>=20
> best regards,
> Torsten.=20
>=20
>> On 12. May 2020, at 02:21, Mike Jones =
<Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
>>=20
>> 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!
>>=20
>>                                                       Cheers,
>>                                                       -- Mike
>>=20
>> From: Aaron Parecki <aaron@parecki.com>=20
>> Sent: Monday, May 11, 2020 4:55 PM
>> To: OAuth WG <oauth@ietf.org>
>> Cc: Neil Madden <neil.madden@forgerock.com>; Mike Jones =
<Michael.Jones@microsoft.com>
>> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>>=20
>> Thank you Neil.
>>=20
>> To address Mike's concerns in the previous threads, I would like to =
also update section 9.7 with the following text:
>>=20
>> Clients MUST prevent injection (replay) of authorization codes into =
the=20
>> authorization response by attackers. The use of the `code_challenge`
>> parameter is RECOMMENDED to this end. For confidential clients, the=20=

>> OpenID Connect `nonce` parameter and ID Token Claim {{OpenID}} MAY be =
used=20
>> instead of or in addition to the `code_challenge` parameter for this=20=

>> purpose. The `code_challenge` or OpenID Connect `nonce` value MUST be
>> transaction-specific and securely bound to the client and the user =
agent=20
>> in which the transaction was started.
>>=20
>> This change better clarifies the specific circumstances under which =
the "nonce" parameter is sufficient to protect against authorization =
code injection.
>>=20
>> Aaron Parecki
>>=20
>> On Mon, May 11, 2020 at 11:55 AM Neil Madden =
<neil.madden@forgerock.com> wrote:
>> I am happy with this proposed wording. Thanks for updating it.
>>=20
>> =E2=80=94 Neil
>>=20
>>=20
>> On 11 May 2020, at 19:52, Aaron Parecki <aaron@parecki.com> wrote:
>>=20
>> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!=20=

>>=20
>> 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..."
>>=20
>> "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."
>>=20
>> Section 9.7 is where the nuances of PKCE vs nonce are described.
>>=20
>> 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.
>>=20
>> Aaron Parecki
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth