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 <saschapreibi...@gmail.com> 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 <aa...@parecki.com> 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 <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 >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
