Re: [OAUTH-WG] How to enforce PKCE in authorization servers with a mix OAuth 2.0 and 2.1 clients?

Vladimir Dzhuvinov <vladimir@connect2id.com> Sat, 08 October 2022 10:27 UTC

Return-Path: <vladimir@connect2id.com>
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 45FAFC152569 for <oauth@ietfa.amsl.com>; Sat, 8 Oct 2022 03:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=connect2id.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgBdckRxEsms for <oauth@ietfa.amsl.com>; Sat, 8 Oct 2022 03:27:47 -0700 (PDT)
Received: from mout-b-206.mailbox.org (mout-b-206.mailbox.org [195.10.208.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3EA7C152568 for <oauth@ietf.org>; Sat, 8 Oct 2022 03:27:46 -0700 (PDT)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-b-206.mailbox.org (Postfix) with ESMTPS id 4Ml1Zy4HY2z9syQ; Sat, 8 Oct 2022 12:27:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=connect2id.com; s=MBO0001; t=1665224858; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0q93p9MhzdDitjzGTb3a/nHl+/3f8mFwpeivpYiYc+Q=; b=zBQQZE+P/iXmEHyWftXyLDk9nU9KI8rL458FY1mocb/1tF2riNZM21yv75mH88a0odYBT8 jV3O+ShrtaJFvAp7/8r3qaTAemybyBScGwbp7V33epIcR8ksiZozvqqdwIN4o7v4NwsFf1 0JGapOaHcyzDU2r5iiE0gt30AKEqJzzUPVaLo3htIvIb/ur+HITw9f0PAVLT95rlUZUhUq fM5Q+l7+P+uqfa6wOBTpOIHu5SdeM9HZWrwXAHGxiEmLSFwtW7/k6kd0Qp/z0+aX02t9al 9iV6SFg+bqPMKvlSlS2wlhqsThzTmNjXihe2DBoziBei8z5YOf7hsotBPIEi1g==
Message-ID: <227a5b14-5017-2f55-737a-74b94165b1c0@connect2id.com>
Date: Sat, 08 Oct 2022 13:27:14 +0300
MIME-Version: 1.0
Content-Language: en-US
To: Dima Postnikov <dima@postnikov.net>
Cc: oauth@ietf.org
References: <ba1a5680-616c-bfe1-46b7-899acbb180bf@connect2id.com> <CAEMK1uZzsx6a-EHuBuPMomTLdDE798jcBaWNTABzERnLVuM6Qw@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Organization: Connect2id Ltd.
In-Reply-To: <CAEMK1uZzsx6a-EHuBuPMomTLdDE798jcBaWNTABzERnLVuM6Qw@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms000407080007070509050904"
X-Rspamd-Queue-Id: 4Ml1Zy4HY2z9syQ
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/-uQjryhsqhtCAMQ0uGPNF2GDn_I>
Subject: Re: [OAUTH-WG] How to enforce PKCE in authorization servers with a mix OAuth 2.0 and 2.1 clients?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 08 Oct 2022 10:27:52 -0000

Thanks for chiming in Dima.

Do you reckon it's a good idea to define a code_challenge_method client 
reg parameter in the OAuth 2.1 spec?

To enable 2.0 -> 2.1 transitions and also give people a concrete and 
standard compliant way to implement the "REQUIRED or RECOMMENDED" in the 
OAuth 2.1 spec for code_challenge.

Another spec that deals with PKCE is the OAuth BCP, but to me that's not 
a optimal place to define a new parameter.


Vladimir Dzhuvinov


On 08/10/2022 04:31, Dima Postnikov wrote:
> Hi Vladimir,
>
> Similar issue exists in CDR (Australian Open Banking). PAR and PKCE 
> was added as mandatory to FAPI 1 Advanced profile.
>
> There was a transition period when AS had to support both (potentially).
>
> Also if the same AS is used outside of CDR, this dual support would 
> continue for some implementations.
>
> I don't think this was solved, so your client registration parameter 
> makes sense.
>
>
>
> On Wed, Oct 5, 2022 at 5:43 PM Vladimir Dzhuvinov 
> <vladimir@connect2id.com> wrote:
>
>     Has anyone faced the issue how an AS can handle a mix of OAuth 2.0
>     and
>     2.1 clients regarding PKCE enforcement?
>
>     The new OAuth 2.1 spec makes PKCE required, which is a good security
>     measure and fine for an AS where all clients are ready to comply with
>     the upgrade. In practice however, it's common for AS deployments
>     to have
>     a mix of legacy 2.0 and 2.1 clients, and at present OAuth doesn't
>     have a
>     standard client registration parameter, e.g.
>     code_challenge_method, to
>     lock a client into using PKCE.
>
>     https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-02#section-4.1.1
>
>     RFC 8414 defined the code_challenge_methods_supported metadata for
>     servers. It would be useful if deployments had a corresponding
>     parameter
>     for the clients.
>
>     https://www.rfc-editor.org/rfc/rfc8414
>
>     ~ Vladimir
>
>     -- 
>     Vladimir Dzhuvinov
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org
>     https://www.ietf.org/mailman/listinfo/oauth
>