Re: [OAUTH-WG] Downgrade attacks on PKCE

Filip Skokan <panva.ip@gmail.com> Mon, 01 June 2020 06:27 UTC

Return-Path: <panva.ip@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 A8B4F3A0D52 for <oauth@ietfa.amsl.com>; Sun, 31 May 2020 23:27:58 -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_MESSAGE=0.001, MIME_QP_LONG_LINE=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 edWocnr8nb0H for <oauth@ietfa.amsl.com>; Sun, 31 May 2020 23:27:57 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 C4DBE3A0D51 for <oauth@ietf.org>; Sun, 31 May 2020 23:27:56 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id k19so6387761edv.9 for <oauth@ietf.org>; Sun, 31 May 2020 23:27:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=yPCI53mn7NBtx1UUKs5sSS4mEvlh8mQaR63FCnBIIes=; b=J3tUJ10Xdpg1KbE9uiXcYIjZyYAHtM7q+2v3vwqHf91sjHEnNwtrnJGP/1qmYCn/Qw Gl7M6XT68VwThcBI4GwoKRmUEKYTha0uuIdt5XjtW9248V3UQA/BfD0NxNaQHr3nP7tX /IhNlPcSOIOjKKUlkus7D0M/F6GMu5pLOl0s2q42nDxx4Zd/rukyeQO4i5YQoRqUzuEX T+2I6gzmv6KpDbgDKVQCmwlIenBwQiWB3drEg6F1dWrQToqOSGJOOHC3YjHuE7JG08RJ kG51MG4FrGUzkGiglF5Fd9UdZboR4396/hKrOn5hH9/Wf3b5xIUOaqsAQaczQ8NIUwVC /hLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=yPCI53mn7NBtx1UUKs5sSS4mEvlh8mQaR63FCnBIIes=; b=d4V3v6AC+XmM8KxroPOXMm+Opso6x6sn0ZfMtSSrGUKnKRxx0dCS/S7+vVjmL0kPkC D4cykPaCC7cFpxfEGzr/Rqxj0EmxLGHsptfj/R4BNNaR8uWBHu6qoTXUzBgvacBbLF1w VK4Egdl4+e4jiCMa0enM6zJUK4iimE4wnWFPI2K4do9TQKuJijh8GathAwBZyFDpcDO0 AP6mzoqLryPexWbSQwIsh0v4Uf2Bf/rNWppkgxy9p/U1GWsZtV/7WAkwTI9JzUotiwsj izLp8JHT9hoDJEmmos7GEalLqWPnhsr/TldWJ9jxaqvuRZH9oN7mUxlA8/qt+3lSvxev dCLg==
X-Gm-Message-State: AOAM533QiBbWlSdDkXCCQvNl/v92voAsTQgUktZcV2OILyZtGa84txPO wbgKG1zyZc05UkX8Tsb2/f7mDuAIkA==
X-Google-Smtp-Source: ABdhPJwP5AE4ITPbuYnKzDa0sfzf9zSgYAmf/UqR2pDFgpmHJYiT9WMgw76rC/Wfb+kvRKBx7qS7Ug==
X-Received: by 2002:a05:6402:959:: with SMTP id h25mr19711132edz.287.1590992869920; Sun, 31 May 2020 23:27:49 -0700 (PDT)
Received: from [192.168.68.100] (173.c3.airnet.cz. [94.74.199.173]) by smtp.gmail.com with ESMTPSA id g23sm15644206edh.59.2020.05.31.23.27.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 31 May 2020 23:27:49 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-3F2B864A-D9A0-4832-AF82-7A1C12493746
Content-Transfer-Encoding: 7bit
From: Filip Skokan <panva.ip@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 1 Jun 2020 08:27:48 +0200
Message-Id: <77B4ABEF-3233-4511-98D3-796121B67AC2@gmail.com>
References: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de>
Cc: "oauth@ietf.org" <oauth@ietf.org>
In-Reply-To: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de>
To: Daniel Fett <fett@danielfett.de>
X-Mailer: iPhone Mail (17F75)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/dZOTi3tKoGvOXEwOzdIxEnNd3Bs>
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 06:27:59 -0000

I also have #2 in place since ages like others have, or are about to. 

It just made sense to me to have it that way based on PKCE Section 4.4.  The challenge and method are bound to the code to be verified later. 

When the server issues the authorization code in the authorization
   response, it MUST associate the "code_challenge" and
   "code_challenge_method" values with the authorization code so it can
   be verified later.

“Empty”, “Undefined” and the like are values to be verified too. The trigger to verify PKCE in the token request is presence of pkce params in either the code bound data or the request. Which would be the case described in Daniel’s blog post. 

- Filip

Odesláno z iPhonu

> 30. 5. 2020 v 9:59, Daniel Fett <fett@danielfett.de>de>:
> 
> 
> 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/
> 
> -Daniel
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth