Return-Path: 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 ; 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 ; 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 ; Mon, 1 Jun 2020 13:19:18 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id w1so10395284qkw.5 for ; 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 (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: From: John Bradley 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: Content-Type: multipart/alternative; boundary="------------382AB4311FCE7C7B761940C6" Content-Language: en-GB Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 20:19:21 -0000 This is a multi-part message in MIME format. --------------382AB4311FCE7C7B761940C6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 > *Sent:* Monday, June 1, 2020 10:54 AM > *To:* Neil Madden > *Cc:* Daniel Fett ; oauth@ietf.org; Mike Jones > > *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 > 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 > 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 mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------382AB4311FCE7C7B761940C6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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>; 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> 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.

 

 

-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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------382AB4311FCE7C7B761940C6--