Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1
Sascha Preibisch <saschapreibisch@gmail.com> Wed, 13 October 2021 20:50 UTC
Return-Path: <saschapreibisch@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 6837C3A0A0D for <oauth@ietfa.amsl.com>; Wed, 13 Oct 2021 13:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level:
X-Spam-Status: No, score=-1.987 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, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 V6VlJYAP4_eq for <oauth@ietfa.amsl.com>; Wed, 13 Oct 2021 13:50:16 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 3C8CB3A0A0C for <oauth@ietf.org>; Wed, 13 Oct 2021 13:50:16 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id u21so14154196lff.8 for <oauth@ietf.org>; Wed, 13 Oct 2021 13:50:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qMbe+kGnBCbHOrl7ng70TZIqZaSgZMz1FHYRxem3Fb8=; b=TMzjnAJVIz8Eyg+2PoNBmDKt3hA7RARCVoY7lEzGcLC/QoeRrTz99t0WJ0DT4MfYyH G9UOuugeN/PiH2uWXGaaphEhTt9SfAHntSN9f65PY4HP2ZSJyUczphvLYaYdw8mEa7q7 /KFbFyw/39peX7KJUCY05vUh8YlZ0DQGGh0n1w6GbHU7sxGYgWc6wOHqf7wZA2DvV2nH syU6Up6jHa1FCvhYIACBhTW30TklHFhnIgo74QycyitoRdkXgmK7xpnIm2gn/azX4qTP Mr9f8b036qnwya2nWWy8FRG9k4YcLT4rzxNlu0PiDXM3YSkZEhlen3ARh6hcnWEtnaFq pr7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qMbe+kGnBCbHOrl7ng70TZIqZaSgZMz1FHYRxem3Fb8=; b=CJK+0R5JNmvfCY9eSOjqmW2W2qr9/EeAbawi8QQBD0z5hR5uHnKwWYbHwTECTBN4mk /fpxayuPK/+lwNF/pgjFYyHNTdfvUDizv6lc3pSB7T+6B4u4DBv0kaZl8zVmkxWaKfqv dNqg6L4qpZETh/z/DWVSyi1meYdbvhq9f4MTQcZtEotbhV2kt+2lrxpwXDCI6oe/Lypj aBr4zJsoAjnhZ2ksKLw+PUAjQEufXqMxDnPY37w20PgTXmXIVZMftX8EsmuCX4ZIEkxM o9p3L6nYjzD0AQRtmMFBdbBdbVcFSGYJZgHsz1yFK0k7VtdpKL8SHuaV5kpo9VDEGsEu aqgQ==
X-Gm-Message-State: AOAM533v4HWw94gjuHyiiFTTZ5Z+MfgLg2/tTE50iW3/f6s4UcHlABjQ 2OG2Gl5Ex/wpni1X4gG/oAnSr+apnZawCfqo5i/AVEkb
X-Google-Smtp-Source: ABdhPJzgUXdqFeIbXNTtWRWL06nbIb8LH9K7e3l2lqXATfmBka8txU2TAN1ECdCe87BV45uKFXT9tH96R+N1O8aKbbo=
X-Received: by 2002:a05:651c:885:: with SMTP id d5mr1742078ljq.82.1634158214011; Wed, 13 Oct 2021 13:50:14 -0700 (PDT)
MIME-Version: 1.0
References: <SA2PR00MB100244DAAD267EBD2FF51678F5B79@SA2PR00MB1002.namprd00.prod.outlook.com> <CAJot-L1HNvud7-ehODK7Bouv5-KotMy8EtEgLCyCzOXoSZCVCg@mail.gmail.com> <CAGBSGjpJrM4uUTdVvsEzh5sT0H9ZpEJ0D3yfo-p_1S9w_tdF8g@mail.gmail.com> <AM7PR83MB0452A256F01A7DE8BE65C98C91B79@AM7PR83MB0452.EURPRD83.prod.outlook.com> <CAGBSGjoNoHybJNZaxdFs2Z9D+rUi+zORzt9v_f0cdhYZaj=KcA@mail.gmail.com> <CAJot-L30=scUs0yon4fx_Ti6Sq8gW4xy758j2qGLR_Cg2R-82Q@mail.gmail.com> <CAGBSGjoGhoz203+sXOGtDLr14DJLsRhjEd1uA==7SNLNRZdzpQ@mail.gmail.com>
In-Reply-To: <CAGBSGjoGhoz203+sXOGtDLr14DJLsRhjEd1uA==7SNLNRZdzpQ@mail.gmail.com>
From: Sascha Preibisch <saschapreibisch@gmail.com>
Date: Wed, 13 Oct 2021 13:50:02 -0700
Message-ID: <CAP=vD9tOAxCAKumBcNkK077jMiWC+r7xBgu46oCFPgJPsu2EnQ@mail.gmail.com>
To: IETF oauth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000da5f6805ce421bc1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/qgDq9NcAyOBGyirEZjkdbUCtd2Y>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1
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: Wed, 13 Oct 2021 20:50:23 -0000
If the challenge is based on distributed authorization server configurations, how would they handle PKCE? I imagine that managing the state for PKCE is not less challenging than managing authorization codes on the server side, preventing reuse of them. With that in mind I am not sure if I follow the given argument. I would prefer to keep MUST as it is today. On Wed, 13 Oct 2021 at 13:37, Aaron Parecki <aaron@parecki.com> wrote: > HTTPS, because if that's broken then the rest of OAuth falls apart too. > > On Wed, Oct 13, 2021 at 1:36 PM Warren Parad <wparad@rhosys.ch> wrote: > >> I feel like I'm missing something, what stops just plain old network >> sniffing and replying the whole encrypted payload to the AS and getting >> back a valid token? >> >> Warren Parad >> >> Founder, CTO >> Secure your user data with IAM authorization as a service. Implement >> Authress <https://authress.io/>. >> >> >> On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki <aaron@parecki.com> wrote: >> >>> Aside from the "plain" method, the PKCE code verifier never leaves the >>> client until it's sent along with the authorization code in the POST >>> request to the token endpoint. The only place it can leak at that point is >>> if the authorization server itself leaks it. If you have things leaking >>> from the authorization server log, you likely have much bigger problems >>> than authorization code replays. >>> >>> Keep in mind that even with the proposed change to drop the requirement >>> of authorization codes being one time use, authorization servers are free >>> to enforce this still if they want. Authorization code lifetimes are still >>> expected to be short lived as well. >>> >>> Aaron >>> >>> >>> On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman < >>> pieter.kasselman@microsoft.com> wrote: >>> >>>> Aaron, I was curious what prevents an attacker from presenting an >>>> Authorization Code and a PKCE Code Verifier for a second time if the one >>>> time use requirement is removed. Is there another countermeasure in PKCE >>>> that would prevent it? For example, an attacker may obtain the >>>> Authorization Code and the Code Verifier from a log and replay it. >>>> >>>> >>>> >>>> Cheers >>>> >>>> >>>> >>>> Pieter >>>> >>>> >>>> >>>> *From:* OAuth <oauth-bounces@ietf.org> *On Behalf Of *Aaron Parecki >>>> *Sent:* Wednesday 13 October 2021 18:40 >>>> *To:* Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org> >>>> *Cc:* Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>; >>>> oauth@ietf.org >>>> *Subject:* [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and >>>> OAuth 2.1 >>>> >>>> >>>> >>>> Warren, I didn't see you on the interim call, so you might be missing >>>> some context. >>>> >>>> >>>> >>>> The issue that was discussed is that using PKCE already provides all >>>> the security benefit that is gained by enforcing single-use authorization >>>> codes. Therefore, requiring that they are single-use isn't necessary as it >>>> doesn't provide any additional benefit. >>>> >>>> >>>> >>>> If anyone can think of a possible attack by allowing authorization >>>> codes to be reused *even with a valid PKCE code verifier* then that would >>>> warrant keeping this requirement. >>>> >>>> >>>> >>>> --- >>>> >>>> Aaron Parecki >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Oct 13, 2021 at 10:27 AM Warren Parad <wparad= >>>> 40rhosys.ch@dmarc.ietf.org> wrote: >>>> >>>> Isn't it better for it to be worded as we want it to be, with the >>>> implication being that of course it might be difficult to do that, but that >>>> AS devs will think long and hard about sometimes not denying the request? >>>> Even with MUST, some AS will still allow reuse of auth codes. Isn't that >>>> better than flat out saying: *sure, there's a valid reason* >>>> >>>> >>>> >>>> In other words, how do we think about RFCs? Do they exist to be >>>> followed to the letter or not at all? Or do they exist to stipulate this is >>>> the way, but acknowledge that not everyone will build a solution that holds >>>> them as law. >>>> >>>> >>>> >>>> Let's look at *SHOULD* >>>> >>>> This word, or the adjective "RECOMMENDED", mean that there may exist >>>> valid reasons in particular circumstances to ignore a particular item, but >>>> the full implications must be understood and carefully weighed before >>>> choosing a different course. >>>> >>>> >>>> >>>> I think *recommended* here is not sufficient nor are there valid >>>> reasons. "It's too hard" isn't really a valid reason. Isn't it better in >>>> this case for an AS to not be compliant with the RFC, than it is to relax >>>> this to SHOULD and have lots of AS thinking reusing auth codes is a viable >>>> solution, "because they are a special snowflake where SHOULD should apply". >>>> >>>> >>>> >>>> Are we setting the standard or instead attempting to sustain a number >>>> of "AS that are in compliance with the RFC"? >>>> >>>> >>>> >>>> *Warren Parad* >>>> >>>> Founder, CTO >>>> >>>> Secure your user data with IAM authorization as a service. Implement >>>> Authress >>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C64289cdc8a4743659b3108d98e70a5d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697436788333255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lw%2BH1z1Ut9kr6S%2F4aVsPmcErAcZx0eK2WV78OlEl2dU%3D&reserved=0> >>>> . >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Oct 13, 2021 at 7:17 PM Mike Jones <Michael.Jones= >>>> 40microsoft.com@dmarc.ietf.org> wrote: >>>> >>>> During today’s call, it was asked whether we should drop the OAuth 2.0 >>>> language that: >>>> >>>> The client MUST NOT use the authorization code >>>> >>>> more than once. If an authorization code is used more than >>>> >>>> once, the authorization server MUST deny the request and SHOULD >>>> >>>> revoke (when possible) all tokens previously issued based on >>>> >>>> that authorization code.” >>>> >>>> >>>> >>>> The rationale given was that enforcing one-time use is impractical in >>>> distributed authorization server deployments. >>>> >>>> >>>> >>>> Thinking about this some more, at most, we should relax this to: >>>> >>>> The client MUST NOT use the authorization code >>>> >>>> more than once. If an authorization code is used more than >>>> >>>> once, the authorization server SHOULD deny the request and >>>> SHOULD >>>> >>>> revoke (when possible) all tokens previously issued based on >>>> >>>> that authorization code.” >>>> >>>> >>>> >>>> In short, it should remain illegal for the client to try to reuse the >>>> authorization code. We can relax the MUST to SHOULD in the server >>>> requirements in recognition of the difficulty of enforcing the MUST. >>>> >>>> >>>> >>>> Code reuse is part of some attack scenarios. We must not sanction it. >>>> >>>> >>>> >>>> -- Mike >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C64289cdc8a4743659b3108d98e70a5d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697436788343208%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ySJjihVbfLJJ85RtjNzEIMSPwe7kLZB8RKT8Ky3fYiA%3D&reserved=0> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C64289cdc8a4743659b3108d98e70a5d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697436788343208%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ySJjihVbfLJJ85RtjNzEIMSPwe7kLZB8RKT8Ky3fYiA%3D&reserved=0> >>>> >>>> _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
- [OAUTH-WG] Authorization code reuse and OAuth 2.1 Mike Jones
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Warren Parad
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Aaron Parecki
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Neil Madden
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Warren Parad
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Aaron Parecki
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Jeff Craig
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Warren Parad
- Re: [OAUTH-WG] Authorization code reuse and OAuth… David Waite
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Richard Backman, Annabelle
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Pieter Kasselman
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Aaron Parecki
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Warren Parad
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Aaron Parecki
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Sascha Preibisch
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Warren Parad
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Aaron Parecki
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Sascha Preibisch
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Richard Backman, Annabelle
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Pieter Kasselman
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Aaron Parecki
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Ash Narayanan
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Pieter Kasselman
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Warren Parad
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Pieter Kasselman
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Daniel Fett
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Mike Jones
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Richard Backman, Annabelle
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Vittorio Bertocci
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Mike Jones
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Ash Narayanan
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Vittorio Bertocci
- Re: [OAUTH-WG] Authorization code reuse and OAuth… David Waite
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Neil Madden
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Warren Parad
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Filip Skokan
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Takahiko Kawasaki
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Daniel Fett
- Re: [OAUTH-WG] Authorization code reuse and OAuth… Daniel Fett
- Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code … Warren Parad
- [OAUTH-WG] SUB and AUD configuration for web iden… Warren Parad
- Re: [OAUTH-WG] SUB and AUD configuration for web … Ash Narayanan