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

Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 14 May 2020 09:32 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7EE3A0854 for <oauth@ietfa.amsl.com>; Thu, 14 May 2020 02:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYMMv-iqBxDN for <oauth@ietfa.amsl.com>; Thu, 14 May 2020 02:32:17 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8487B3A0843 for <oauth@ietf.org>; Thu, 14 May 2020 02:32:17 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id z72so22027959wmc.2 for <oauth@ietf.org>; Thu, 14 May 2020 02:32:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gNY6TMq2t0G8Y5BwI5DSerFhT/VhwI3Ztk+kMUDoEUM=; b=0sjv12+s2f/joNcytT6POSrdrGIhyhOBiUxWxUF5EfchaGxX4x3FQN/CX75CzVM5gb LgM5NwlxLp5R9nKyJCk+WSHOOBHMyP5rarM0U2eqDFZk10HlyNLPLvjWHSNDG7RSkuj6 dlgAjlo3hmpC7To8C6K00e9itgBtl3kk27s5dHyyApeY2czjWWzZcOXcpO6s3cfIdtbx lt3wzfkLH93cWp0egxGpMW27cwJXl0CSjfm5bm9doUd/llI/AzA5oh/FFxqw9RTcbAKi sTKxYx7s/oOnHMxO/4WCvxVh49erYdu4Xloc0TcMlr6Xkls23iFw6enhBYBSAw8D29AH kk5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gNY6TMq2t0G8Y5BwI5DSerFhT/VhwI3Ztk+kMUDoEUM=; b=F85s7Z7GtTnlauJpq9RF/XpBBBa0Ad7lAx/Gph2J+rnd90B2DAbjft4RlfRdFeFSJB mkJi+J6PkQuB7U2LrlxGUCQjDZ8i0h4h/+2D6RcDeFDutF/TN3/edoZPWSARA0rsf+I9 piCA0tUEH0KV0D66514y0rHCpMwtpjZnc9O3Nd3JR2mOB5SzrG17Zg+JNYKPFLv9t9xN rkHkPjKBjJI0G+1x3Kp2kWV2+XPzgKoEf4THnHa4kfDGy+x3IDEXd6cH4fs7fwC8Mua2 gjYJYLIXxJIKGeeM8kUmBpFmIezRZPkUohTFiwQIxGvi2tSod7fMIcCs6zF6HTM/+sUB erRw==
X-Gm-Message-State: AGi0Pua+FMyjsNn9YEJ6VlwlCJ1s25xbfkl0QkQVQii2BQAHv+YoqFS4 dOPy/ciDHPCT2mJg1mfvLmV8K//FPGY=
X-Google-Smtp-Source: APiQypJODSw+uOYCIOvaPfncyiPkeeaXJaXtPfqAp7xFf10mAh+Md5zMVJJCdPCOz9ztu2WcaIDEBA==
X-Received: by 2002:a1c:541e:: with SMTP id i30mr16184802wmb.120.1589448735720; Thu, 14 May 2020 02:32:15 -0700 (PDT)
Received: from p200300eb8f301f8b1d4993d41b246345.dip0.t-ipconnect.de (p200300EB8F301F8B1D4993D41B246345.dip0.t-ipconnect.de. [2003:eb:8f30:1f8b:1d49:93d4:1b24:6345]) by smtp.gmail.com with ESMTPSA id w13sm2808827wrm.28.2020.05.14.02.32.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2020 02:32:15 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt <torsten@lodderstedt.net>
In-Reply-To: <9B5EBD2C-09EF-403A-9270-A53EEE691E40@gmail.com>
Date: Thu, 14 May 2020 11:32:14 +0200
Cc: OAuth WG <oauth@ietf.org>, Mike Jones <Michael.Jones@microsoft.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1887D983-7A43-41C3-AAAD-786AD749240A@lodderstedt.net>
References: <MN2PR00MB068633B7B72E5416AA8984D1F5BE0@MN2PR00MB0686.namprd00.prod.outlook.com> <2298156A-1CAE-478D-B036-DD32A6EEBEF0@lodderstedt.net> <9B5EBD2C-09EF-403A-9270-A53EEE691E40@gmail.com>
To: Nov Matake <matake@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/9G6hIqav50qXj0u8MIfICl_JWNY>
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2020 09:32:21 -0000

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 <matake@gmail.com> wrote:
> 
> 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=40lodderstedt.net@dmarc.ietf.org>のメールt;のメール:
>> 
>> 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=40microsoft.com@dmarc.ietf.org> wrote:
>>> 
>>> 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 <aaron@parecki.com> 
>>> Sent: Monday, May 11, 2020 4:55 PM
>>> To: OAuth WG <oauth@ietf.org>
>>> Cc: Neil Madden <neil.madden@forgerock.com>om>; Mike Jones <Michael.Jones@microsoft.com>
>>> 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 <neil.madden@forgerock.com> wrote:
>>> I am happy with this proposed wording. Thanks for updating it.
>>> 
>>> — Neil
>>> 
>>> 
>>> On 11 May 2020, at 19:52, Aaron Parecki <aaron@parecki.com> 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
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>