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, 01 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 >
- [OAUTH-WG] Downgrade attacks on PKCE Daniel Fett
- Re: [OAUTH-WG] Downgrade attacks on PKCE Neil Madden
- Re: [OAUTH-WG] Downgrade attacks on PKCE Ryan Kelly
- Re: [OAUTH-WG] Downgrade attacks on PKCE Filip Skokan
- Re: [OAUTH-WG] Downgrade attacks on PKCE Dick Hardt
- Re: [OAUTH-WG] Downgrade attacks on PKCE Mike Jones
- Re: [OAUTH-WG] Downgrade attacks on PKCE John Bradley
- Re: [OAUTH-WG] Downgrade attacks on PKCE Vladimir Dzhuvinov
- Re: [OAUTH-WG] Downgrade attacks on PKCE Gavin Henry
- Re: [OAUTH-WG] Downgrade attacks on PKCE Kazuki Tsuzuku