Re: [OAUTH-WG] Downgrade attacks on PKCE

Vladimir Dzhuvinov <vladimir@connect2id.com> Tue, 02 June 2020 09:33 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 EF7633A003D for <oauth@ietfa.amsl.com>; Tue, 2 Jun 2020 02:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ranR5oE91MI8 for <oauth@ietfa.amsl.com>; Tue, 2 Jun 2020 02:33:08 -0700 (PDT)
Received: from p3plsmtpa07-01.prod.phx3.secureserver.net (p3plsmtpa07-01.prod.phx3.secureserver.net [173.201.192.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245013A003B for <oauth@ietf.org>; Tue, 2 Jun 2020 02:33:08 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id g3I8jubEDu8TBg3IAjn9Db; Tue, 02 Jun 2020 02:33:07 -0700
X-CMAE-Analysis: v=2.3 cv=Y6qGTSWN c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=zm8yXq-ZAAAA:8 a=npVdL-2ZxAp8NDnCRQwA:9 a=QEXdDO2ut3YA:10 a=axDs-AP9Xeh0hCMQ1f8A:9 a=2jFNRdZuiVSJzA0E:21 a=_W_S_7VecoQA:10 a=00HjG7_zKW9Ns9g_Kk0A:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=FiTvH8tk0901yUyQXKyt:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
Organization: Connect2id Ltd.
Message-ID: <5c4c8549-99f2-d10e-74db-66bd655d1c90@connect2id.com>
Date: Tue, 2 Jun 2020 12:33:03 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <3e18622b-5135-be90-0ce9-23676be4fc50@danielfett.de>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040506070804000004080506"
X-CMAE-Envelope: MS4wfJeWjtkMBIexodhqzxALokeo9d1LI3jhSqbG3yDgaiIJq/T5aIly4VVabUNQ0ORojeZKCWe53znCe6QtQSRBzANPGqdeebIWtR+p/rYH34c7x1KH8qv8 PAjzceBm24c6YCA313wriJzjHJl99L/BUEBzp4tWzYIKMXc9VAIxQhc8
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/3oh2ZfR9b36mUo8v8Jb2IfkRvDE>
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: Tue, 02 Jun 2020 09:33:10 -0000

Thanks for laying out the solutions so neatly.

We would prefer #2 the "dynamic" solution because it wouldn't require us
to do any changes. I've had the impression that the unexpected
code_verifier case was somehow covered as an error in RFC 7636 but
checked the spec now and apparently it isn't.

Vladimir

On 30/05/2020 10:58, Daniel Fett 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