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
