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 <wpa...@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 <aa...@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.kassel...@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-boun...@ietf.org> *On Behalf Of *Aaron Parecki >>> *Sent:* Wednesday 13 October 2021 18:40 >>> *To:* Warren Parad <wparad=40rhosys...@dmarc.ietf.org> >>> *Cc:* Mike Jones <Michael.Jones=40microsoft....@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...@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....@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
