Re: [OAUTH-WG] Downgrade attacks on PKCE

Dick Hardt <dick.hardt@gmail.com> Mon, 01 June 2020 17:54 UTC

Return-Path: <dick.hardt@gmail.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 8DEA63A13D0 for <oauth@ietfa.amsl.com>; Mon, 1 Jun 2020 10:54:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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=gmail.com
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 sK-9FUB-f56j for <oauth@ietfa.amsl.com>; Mon, 1 Jun 2020 10:54:34 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 3CEE83A13CD for <oauth@ietf.org>; Mon, 1 Jun 2020 10:54:34 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id e125so4462768lfd.1 for <oauth@ietf.org>; Mon, 01 Jun 2020 10:54:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HgrSWxLUCvUXazNpomsA/XnfOWVeOf3jqDkPjl5JSXY=; b=CrYY0dttB7SYgya3Ih0LyVySNBhvk1drL1NIRP1AJNAvbk3RMEYOyw+L6r+2U5pbmT YMvfr5SrC3dhCpl+xuLCNfr7q7K1ft6Ct/jAu2lUOqvJcDQUXFRMhunnMuWvcDBZKd3y i1CUxEmpbkIRQUfFoav3Uaakz5kRvsR7zTvSC93VcGkLfNrLzVECxx5pkreml3kX9Kx/ NBsR2D98gzoSAmPpMlKg6zRUFXlgeUniCxROggtuyqOW896SFAV8//JetSMTrs8yl/k2 lgrbIT8V3eB3OSxdqaJZb+y+mT6BRxL7Hb9MYXPcIo1F/70+NeYL9UTAA29tUpCLWWtN dlOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HgrSWxLUCvUXazNpomsA/XnfOWVeOf3jqDkPjl5JSXY=; b=jwYV0Sez+FR57HgtDAk9VwB8DuzjAWA3/TxtV5pD5jgLP/ueMAxwSfsMZSRDuDl0kr FnP9rWJMAoab9TAJ81A4xgTu4ucOOedBebIfu3i1XMOIT+/TgXLLyDJfSyKyixfx0UCH yDUzp2rocapEv+obPOAx2zSJsOzQvds30ONK0Z44CNftp9zskifEfRNssU2MYBBrcgrE XpxwYfrNTp6j2+JyYLrux4SlxEsyp2ruvnOk3hTl4JmF8CjXArgLdbVy/VxK1HFo+tC5 8ph7b/JO83Rqs/AtScXB0LP82fbvS9FW53Fa6FxYLf+dd1BAVlZ18N3rmrruRl4J7DoJ IGKQ==
X-Gm-Message-State: AOAM530IGCy+yxP+B+fXuNG0gW0QrCEeqbpt9MPF2xPdWLqp59Ib1Izo uC7AUcNYwVcXI+Edy4TJlaOR4VRcmq4naY1WcA8=
X-Google-Smtp-Source: ABdhPJyfTP7v5ofvw3rySnZKHgW4HFzbxumUmY4HU24lSGuZUIay9nuruJxVp4Og29dh6ddVUyX+4DCCGDSilUNhzwk=
X-Received: by 2002:a19:8453:: with SMTP id g80mr12026983lfd.167.1591034070414; Mon, 01 Jun 2020 10:54:30 -0700 (PDT)
MIME-Version: 1.0
References: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de> <9EDABAF3-0445-4F5B-9DA5-4B3C1BFEE4B4@forgerock.com>
In-Reply-To: <9EDABAF3-0445-4F5B-9DA5-4B3C1BFEE4B4@forgerock.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Mon, 1 Jun 2020 10:54:04 -0700
Message-ID: <CAD9ie-sQ421fkTh=tPQJwHn5Cm1dY7qdB_YbE0ObvbwVr_2utA@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: Daniel Fett <fett@danielfett.de>, "oauth@ietf.org" <oauth@ietf.org>, Mike Jones <michael.jones@microsoft.com>
Content-Type: multipart/alternative; boundary="00000000000097b9f005a7097c82"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/w5-v3B6FmYsJA3q9IFf1g3tlxDc>
Subject: Re: [OAUTH-WG] Downgrade attacks on PKCE
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: Mon, 01 Jun 2020 17:54:37 -0000

Mike: what are your thoughts on the options?
ᐧ

On Sat, May 30, 2020 at 4:39 AM Neil Madden <neil.madden@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 <fett@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
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>