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

[Aaron Parecki <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>> 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 <
>>>> [e-mail]> 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 <[e-mail]> *On Behalf Of *Aaron Parecki
>>>>> *Sent:* Wednesday 13 October 2021 18:40
>>>>> *To:* Warren Parad <wparad=[e-mail]>
>>>>> *Cc:* Mike Jones <Michael.Jones=[e-mail]>;
>>>>> [e-mail]
>>>>> *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=
>>>>> [e-mail]> 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=
>>>>> [e-mail]> 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
>>>>> [e-mail]
>>>>> 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
>>>>> [e-mail]
>>>>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>