Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

>
> Yes, as I said before, authorization servers are free to enforce one-time
> use of the authorization code even if there isn't a requirement to. The
> proposal is just to remove the *requirement* of authorization servers
> enforcing it.
>

I agree, and therefore I think what it really ought to be is "MAY".

Annabelle said:

> There are legitimate use cases for a client to replay an authorization
> code. Connection failures happen. Servers fall over before completing
> requests. Users hit browser refresh buttons. Permitting replay of
> authorization codes (assuming valid PKCE, client creds, etc.) allows
> clients to handle these failure modes simply and gracefully via retries.

Couldn't agree more. Having experienced these exact use-cases, I can
honestly say that denying users a smooth experience just to be compliant
with the spec, which offers no additional security if PKCE is also being
used, makes no sense.
It is also more effort (from a repository layer perspective) to implement
one-time use than do PKCE verification.

What is the practical reason for allowing "plain" PKCE in OAuth 2.1? Are
> there really use cases out there where SHA-256 is a deal breaker?
>

I'd be interested in these use-cases as well (I can't think of any).

On Thu, Oct 14, 2021 at 8:36 AM Aaron Parecki <aaron@parecki.com> wrote:

> Yes, as I said before, authorization servers are free to enforce one-time
> use of the authorization code even if there isn't a requirement to. The
> proposal is just to remove the *requirement* of authorization servers
> enforcing it.
>
> I am okay with Mike's suggestion of changing the language to "SHOULD" to
> continue to point out the possibility of enforcing one-time authorization
> codes if desired.
>
>
>
> On Wed, Oct 13, 2021 at 2:15 PM Pieter Kasselman <
> pieter.kasselman@microsoft.com> wrote:
>
>> Log files can exist in lots of place (clients, servers, data lakes). The
>> question is whether it is a valid assumption that an attacker cannot obtain
>> an Authorization Code and a Code Verifier and present it a second time
>> round. Limiting the validity period is one layer of defence, PKCE is
>> another layer, one time use enforcement is another. Assuming breach and
>> designing from a defence in depth perspective is a good practice, so why
>> not give implementors options (and guidance) to add additional layers of
>> defence to match their risk profiles?
>>
>>
>>
>>
>>
>> *From:* OAuth <oauth-bounces@ietf.org> *On Behalf Of *Sascha Preibisch
>> *Sent:* Wednesday 13 October 2021 22:06
>> *To:* Aaron Parecki <aaron@parecki.com>
>> *Cc:* IETF oauth WG <oauth@ietf.org>
>> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and
>> OAuth 2.1
>>
>>
>>
>> Ok, if the goal is to avoid unnecessary requirements I am suggesting to
>> point out why MUST was changed to SHOULD. Otherwise developers will start
>> to mix and match OAuth 2.0 and OAuth 2.1 requirements as they see them fit
>> their needs.
>>
>> In regards to encrypted values in PKCE, Aaron, I can also not confirm
>> that as the general implementation.
>>
>>
>>
>> On Wed, 13 Oct 2021 at 13:56, Aaron Parecki <aaron@parecki.com> wrote:
>>
>> The PKCE spec actually says "Typically, the "code_challenge" and
>> "code_challenge_method" values are stored in encrypted form in the "code"
>> itself" which I feel like might be a stretch to say that's typical, but
>> this scenario was clearly thought of ahead of time. Doing that would enable
>> an AS to avoid storing server-side state.
>>
>>
>>
>> On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch <
>> saschapreibisch@gmail.com> wrote:
>>
>> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293904430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vwcfj%2FVB8a84yDoAmqkXraWyqjOfWGrV08XdtZLWMXw%3D&reserved=0>
>> .
>>
>>
>>
>>
>>
>> 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%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293914390%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9LtSUyb7WjZQqY%2FBnFy47HxchMNGZG6Qx82hj%2Bd9X04%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%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293914390%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gWX04yAEt3IP7lWFDS0zBzyJN8nvNfEf6Eq7i6qU7fM%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%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293924344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yk%2FjfwfllrczSKVwzH4Bt7GTr9TV8fSda2oZhV0ejyA%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%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293924344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yk%2FjfwfllrczSKVwzH4Bt7GTr9TV8fSda2oZhV0ejyA%3D&reserved=0>
>>
>> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>