Re: [OAUTH-WG] Downgrade attacks on PKCE

Neil Madden <neil.madden@forgerock.com> Sat, 30 May 2020 11:38 UTC

Return-Path: <neil.madden@forgerock.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 756253A091A for <oauth@ietfa.amsl.com>; Sat, 30 May 2020 04:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 (1024-bit key) header.d=forgerock.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 Jv1JnRfi8Fgo for <oauth@ietfa.amsl.com>; Sat, 30 May 2020 04:38:48 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 0D90E3A0919 for <oauth@ietf.org>; Sat, 30 May 2020 04:38:47 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id x14so6796951wrp.2 for <oauth@ietf.org>; Sat, 30 May 2020 04:38:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0KtSMV91SIbCr/UUAsJv+UVdV2pGrx3eWSY8QYZGAw8=; b=Q2K+KgdZ3dQ597q25t9XZuH6Zmo7WPWzgWpdu/835Z5dWAa8V7jube/lV5P99RoEBP yS9r4YZgUpLjqIdkxP0VtJttsgKXaSrqCqgz+qt4an7QDD62mVomwS6Vry4yL494pgpy zRr5cgth73qTAp8UBaBp7vTZGhbVvkb8AzFMM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0KtSMV91SIbCr/UUAsJv+UVdV2pGrx3eWSY8QYZGAw8=; b=HlDxxGqonz5SSl7fhyKiYbssD2N/mYd+1GBqF3I9rUxWXTJpk3scVDWHpvpIS6938+ BbNEAwtpd8KLPr/RHc1b32e/JYotMdScMi26JCY/88m3LZHeSiQo5CdPbKHlXYl7BxYT lE2YvKdIM3W9U3RT6G86RiXrZX983+65zky5vnIzUEPuGlracxBJEOtZfdsNdpIasgnD RnseD08XREWGMsb18vG0zdvstZldh/h38ZZMGRQAJNJvg5dQYw1pN0MvN9idy19smK1f FnEV/K9a0qUp5HXmNJxUQCGV4L7teQJWbQjE1P3HvQMw0XhMc3vuiJi90+PplVXb+zqW jObA==
X-Gm-Message-State: AOAM531X3gL6Ff/tQLYjzDLR0BmNaZjb/AtAfLx6/azrJ/DurH8appTo M1unMhNx0L5bI9H7WYNznK0OKfTF96I=
X-Google-Smtp-Source: ABdhPJxsdGz4XYSyVDwsIHrVRyUs3ypM5ihZ/ymsTdZ03rHVJiQFHIKGrhKemfn7uD3zsTfA4TqDKw==
X-Received: by 2002:adf:df91:: with SMTP id z17mr12843396wrl.273.1590838726269; Sat, 30 May 2020 04:38:46 -0700 (PDT)
Received: from [10.0.0.2] (214.249.143.150.dyn.plus.net. [150.143.249.214]) by smtp.gmail.com with ESMTPSA id l5sm3055942wml.27.2020.05.30.04.38.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 May 2020 04:38:45 -0700 (PDT)
From: Neil Madden <neil.madden@forgerock.com>
Message-Id: <9EDABAF3-0445-4F5B-9DA5-4B3C1BFEE4B4@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_40117D3E-F962-4C2C-BE79-859DAAEF42B7"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sat, 30 May 2020 12:38:44 +0100
In-Reply-To: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de>
Cc: "oauth@ietf.org" <oauth@ietf.org>
To: Daniel Fett <fett@danielfett.de>
References: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/FO8OEQCy3CQqjXbaY47B2tJEpWg>
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: Sat, 30 May 2020 11:38:50 -0000

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:
> 
> 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.)
> 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/ <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