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

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