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

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