Re: [OAUTH-WG] Downgrade attacks on PKCE

John Bradley <ve7jtb@ve7jtb.com> Mon, 01 June 2020 20:19 UTC

Return-Path: <ve7jtb@ve7jtb.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 535213A1532 for <oauth@ietfa.amsl.com>; Mon, 1 Jun 2020 13:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=ve7jtb-com.20150623.gappssmtp.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 Sq5a4QH1rhrb for <oauth@ietfa.amsl.com>; Mon, 1 Jun 2020 13:19:19 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 C06A03A1530 for <oauth@ietf.org>; Mon, 1 Jun 2020 13:19:18 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id w1so10395284qkw.5 for <oauth@ietf.org>; Mon, 01 Jun 2020 13:19:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=mHyyYIPaulyLhbVegG3naTtoxIGGC3tqRSn/gOHqb5s=; b=p0v0HWwd+vDcggsu8vnY1keUTI1bgntRToba5kCofkohWbK4S1C+i73KGldIy+b/I/ GuSFfqEGWSSgnoAaSLVFwVZ8q1rV6sPGpjDLAiEbpySDmKoem3z66FkyJvdHIsDyz5v7 wgO3bzv7fSnEex/eDAaxzTO/eO9qRlvw3Z19m0Zzob38lwDlp+FgTloDB0h+XZYIzt3B 4O3kvaUDB81gG6WJQzcK83gnQAlDQ9US5A/J4nKn4MNUvGH9tPvsgz+mxp3sujg3sAnF ib7IzuW9GIBu+FUXCtEZjojMi4zROt8nYIo0aJwoM7nV77JaOfebw8kYvGsYe7GGcu3+ NtQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=mHyyYIPaulyLhbVegG3naTtoxIGGC3tqRSn/gOHqb5s=; b=IE/JE9h5oEGAg9P66v0nt2gfObUJX5+aFyikGrnI55ebpbknXcqBWrTZmF2/erb358 85Tvjcgl7ToedKPNx5dla0TqG6xNJilYygPv5SQBSQI6+rnKiR4yB6bXiuMrUfZcG2kZ WgYZNefMz4NvMl24fSQRysZ4wm20SylVupydX+wrRp+2Au3pgf7C2xUePAXv1rXkMSdd 0cft1c0C4s040LSMeJEAAucQHS0VGBxD/xVnRiJTEsu9Ao6sjfmSftfhfQZZ758ua8fv QwO1ZgDBHNauo9NGbzETPIHLJNVMFKBEzRnPWWwQdK+pOepE0Dt7oijyyqqV4DR6XfC2 jFAA==
X-Gm-Message-State: AOAM532PTCNEIwJ0F8i+m/ebYwArKBSu+HNo6th1SvLNdEUGHZF3GQTf XRcEFiOKIejD6JKF6CSd0zzxmKxUIBeA3PSN
X-Google-Smtp-Source: ABdhPJz5cDePG1ne4E3pnE1+4xHQCbkedDYsq+WuQWj4ZTjhGMpcjeWTFx+P6oyQY9aw+71v7VONCQ==
X-Received: by 2002:a37:784:: with SMTP id 126mr21040036qkh.200.1591042757000; Mon, 01 Jun 2020 13:19:17 -0700 (PDT)
Received: from [192.168.8.102] ([190.107.226.22]) by smtp.gmail.com with ESMTPSA id b189sm273087qkg.110.2020.06.01.13.19.14 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 13:19:16 -0700 (PDT)
To: oauth@ietf.org
References: <MN2PR00MB0688661C391F3234CBFB9812F58A0@MN2PR00MB0688.namprd00.prod.outlook.com>
From: John Bradley <ve7jtb@ve7jtb.com>
Autocrypt: addr=ve7jtb@ve7jtb.com; keydata= mQINBF1708MBEAC+aR8GCZVXEdrPOaYORjPzZCi5nvoWd2t5+xKHCalCgnz8ORFcREM38tZI yQNQ6cfB1METyr+9dVqKrBm8x00QWIlZ4hrcW87pOBek3hrsvvbmagoxzlOCLYHQ+7ESjfUe QVV5O9mESU2s3Zm+c0kLAUYtsuo7neeeiYaAkiCHo9WkpybA5o9tzeg9fK8e+bygPFYD1u8B X1Uy3GYbO9iCQIUXjgVya0117J7XgN/2QwGUbQtYKAFOIyDZfz/WXce2nthRP0nfFczLKozA 0KgSu70CEWZedRqotqzXorSbWIStjqf5WlD2g+Yf2+pbHt19xKQKplfy11qM0tJSd4UhcPu3 CWXfTVEzecQAee72A9U9yy4H3DimSxbkee/K8/f8ZkddzkUC5RxNEp3iYVThzVKbbScFU+6n JW7vwmihP1V3eBpbxpOGDF36h4CLssG1sTQFDHAstSJwQPFsUYzly6tEtLCVt1S8XIqzbTu9 /sHaBJBORmq8z1D7AWh7q9whjp0j+xcDITmIQq31Bkftxq3ru4Ow9b7cBb86bhotvDoXTQJL dEcfcB/YvobVSsy0W06GrKTf218N8+lHHL3z3GXxxoQUUU9yD45UxGSOe3rA7MQruoE+sa6O 1voGFcTDrGyYdjJ+KFsvK+GWHtMkLpHH/ArQsnTEhXXK+MfdAQARAQABtCNKb2huIFQuIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPokCVAQTAQgAPhYhBEiwG6+1WqDAVWlaHtAUSk/j /S+vBQJde9RyAhsDBQkDw6G9BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJENAUSk/j/S+v G6EQAIn7W2JGIaLRJhlHmA901QTwkEc/0Nj1qkJLDLKJuIB7P2/2go7/qEMngTZyZhoglM0w 9EuQie/9UXz7HtyORS+AsmDityDeUr5XkTunyTFLPiiv9E2SwJwAQVJYS6V0NbesJDnkqpTt 4UwUa+Asqw2NaCxT1THHvnFJkDYhPrCGvtOEXBFHpEzYwLoEjx2wfqU1byZsjoxYMCrNokaY J4SUw+bVZaFa+M5WNRwn7ySgEpCv1egSvUydXhFBJTbdwVmCZL7m4WJbECs/ofIYcBGtUJFV nIZ+g34iRqJUPnd4xI/F27u9ydvw+Ml8bldmMnIwhsFkkDnZb8ecBo2P4FQS3h0nB+uNYIl+ SFGLb9B17Kvhy8HtGWrn+KTUn2C96DTuJkwYwS/vUs43HhWUsCx6SLYmQpIUq1CoUOLCP5pJ VB0Q8e/zwrjkB4yMKLPdl3yFbj/bSXSvCG0LcjAAc4Thbngm+xoh5v+nZMxkL8AI9XDE3+Mi M869EDITGKQTmIIB6fKtuLJQYbhAG8uDZ0zOHAJoxArVE9ZwdYiHNGimFa04uBjtobDCz//n k1jaEd3dkjh6kVuQt3sSvf7icen27OXoBB4/HPlH/WNCaeIB13+YyfdYTcdiIB9s7W+R3Kan ANoCAT9pS/ogP5M8Tr8dvZkBPrflkXBspLBOLmc2uQINBF1708MBEADwwZM3OKVJQluPNTJf Jw0XjTJtt0dTMfXG4alx0pF1SHndJweFKtlkp0u5OJZ+YsaZtqspFe++LzBscL3sz2FPsWwP g2OS3Kg1il1QAjZSFoR7fDj5lmxQ9VQws9BSDAr1W1E5YAAnmJFDpJ2DQokYSx1B9MhgG6br UurLR0rZXGvNdNeMUCBMg6vMkvAmwR5yrwBZ8FFLTGk8zN8CUM8EFtGW7/m9r/iwsoUpdsq9 UghvVvIte1xTK+79g6IrNB14O7QUmAaV1FUA4lWqz3pHsPRLIoFS/C5F/d0fLLQ68En/nN2x Tk1totgEqO7gXJa0n48907ALvk5zubZ95lpCNb4gE8FK+hPXLLoYJ+aC2ILjsyD2sMCSEbVK 2QuGL+CmsLVRZCfy/NOhyeCC9IzUxES/Y/a9Zp1ZPdHpiZ7Bjm7O3QoaZ1Jm5vSJ9g7r4T3A fGt7hHGTk6E0jlCaKdt3aB8R4HiIZO/TgUc+tpqAaZBIWELzsqZXAdRhpNYKBAwSU80Oe7GZ zwly5454oKXZe9d7jyjEY19MEEHzWtYgbcygyLXbrUEMpwa+OlFRxuvfQyWYCY0aU7eh6qpP rSbxyj4TtJ3aetaEvNehjttSpNUSWEhsy3AGHqPMjgd5Otio0eP61quJNZdBgkqq2Xop1Lnq l48RAb5xUI1NE33CcwARAQABiQI8BBgBCAAmFiEESLAbr7VaoMBVaVoe0BRKT+P9L68FAl17 08MCGwwFCQPDob0ACgkQ0BRKT+P9L688mxAAj2d6uNsbnQ5937w5N3dWgUZNGaZOOY5XwjZy kbFzXEyOGTbWDevuE2fkkrDFZISvLwfJs5Q1fxF7hP72sSYjNFso+ngFGpF9o8QPkxn9c1vs d9W94HjZN0c4gdmLtdGWr4zZAbnWIjmuEhDxd8CFDLlhCT7L6Iii9UMbJ1trsCvp8d8vbIK+ 2pJhrCy6eIZy9ceoCH2XLaLDxoCtnMhWeSLrwA16qnXEpddtK5pXauvBkdv9bLy9z+SMvSn2 ZFSAI8nv0Ck3FfFBe3rHd16vOn//jmwwMzAb9mNDV8e7/KarWA/YmZJ4YiJ1KbuSu9mS89fG c4mug1igE9DYThB42OvD/8QGdUbkZFcr7E0QJflwrtaZ5j8wIoAUvf0IUsh/6Y6p23hYqxZy dUg43w5tEUtnBR3r/9jE4+RkQtVm8DplNTZUVkA3AVSRp23k4zsU7ioa8hzUasDf3jJMZfSd Xsiuo4Y1Eq6IddJL063Uh6jouXASjwynRW0W7CWlR1/D9z9v+I+0zK/px1vEgNRSQzqtKkMV wUDKMby9BNuIURIj6TBpKk5jBrp3kMP6Yt+Ke9Fs0pPoFX6e+LbOhBvNNGusWIadZfMpL8Ur ZWafyadOQJtqa+xpicVY+ui83oXmGajjOnbIieYlWoskl00HNzppfyBtqOMcxRa7yBIooQE=
Message-ID: <45997787-9218-569c-1b1f-3cb159557089@ve7jtb.com>
Date: Mon, 1 Jun 2020 16:19:12 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <MN2PR00MB0688661C391F3234CBFB9812F58A0@MN2PR00MB0688.namprd00.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------382AB4311FCE7C7B761940C6"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/c7MTIXA51EKas4J1cNVt88OCACo>
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 20:19:21 -0000

Definatly 2.

To my mind if you get a challange and dont get a verifyer that must fail. 

I guess the querstion is if there is a veriyer with no challange what to
do. 

We diden't specify that.   I would reject that as a config error or
indication of a MIM in the front channel.

I think that is the correct thing to do.

On 6/1/2020 3:11 PM, Mike Jones wrote:
>
> Like Filip and Neil and I believe Ryan, I prefer the dynamic option
> 2.  It keeps existing clients working when possible, which should be a
> goal of OAuth 2.1.
>
>  
>
>                                                        Thanks,
>
>                                                        -- Mike
>
>  
>
> *From:* Dick Hardt <dick.hardt@gmail.com>
> *Sent:* Monday, June 1, 2020 10:54 AM
> *To:* Neil Madden <neil.madden@forgerock.com>
> *Cc:* Daniel Fett <fett@danielfett.de>de>; oauth@ietf.org; Mike Jones
> <Michael.Jones@microsoft.com>
> *Subject:* Re: [OAUTH-WG] Downgrade attacks on PKCE
>
>  
>
> Mike: what are your thoughts on the options?
>
> ᐧ
>
>  
>
> On Sat, May 30, 2020 at 4:39 AM Neil Madden <neil.madden@forgerock.com
> <mailto: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
>         <mailto: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 <mailto:OAuth@ietf.org>
>         https://www.ietf.org/mailman/listinfo/oauth
>
>      
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth