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

[Daniel Fett <[e-mail]>]

I don't think that a MAY is appropriate here.

I wasn't in the call yesterday, so I hope I don't miss anything here, but...

Even with PKCE, the one-time use requirement of the code is still
important. First and foremost, if we allow unlimited re-use of the same
code, even just as an option, we change the semantics of this artifact.
I guess there are many examples where this causes issues, but one would
be DPoP. It assumes that there is only one (successful) token request
and in that request, the token is bound to a specific key. If there can
be more than one successful token request, all it takes is
code_challenge and the code sitting around somewhere in accessible
memory and an XSS attacker can exfiltrate them and use them on his own
device, binding the resulting token to an attacker-controlled key. This
is the attack outcome against which we introduced the nonce in DPoP.
(Probably we should add this thought as a security consideration to
DPoP, but that is a different topic.) I guess we can come up with many
other mechanisms and mitigations that depend on code being one-time use.

The attack described also shows nicely that code replay protection and
PKCE serve similar purposes, but are not the same thing.

The Security BCP introduces a second layer of defense at pretty much all
the critical places in the protocol, because practice shows that a
single defense can break too easily. For example, an attacker with
read-only access to the token request would be pretty bad without code
replay protections in place. Such attackers are considered in FAPI.
(Somebody capable of reading system logs at the client or server, proxy
logs at the client or server, browser logs, etc.)

Therefore, in my opinion, the code MUST be short-lived and at least
SHOULD, better MUST be one-time use.

And ideally, the code SHOULD also be invalidated if the PKCE verifier
does not match, not sure if that is in the current text or not.

-Daniel



Am 15.10.21 um 11:04 schrieb Pieter Kasselman:
>
> SHOULD is more likely to cause the right conversations to take place
> for implementors as they weigh the risks. Reducing it to MAY risks
> diluting it too much.
>
>  
>
> *From:*OAuth <[e-mail]> *On Behalf Of *Warren Parad
> *Sent:* Friday 15 October 2021 09:25
> *To:* Pieter Kasselman <pieter.kasselman=[e-mail]>
> *Cc:* IETF oauth WG <[e-mail]>
> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and
> OAuth 2.1
>
>  
>
> I wouldn't be against lowering it to MAY but only if we stipulate a
> SHOULD on an expected lifetime of an authorization code. I think
> sending the message that these should be one time use except in
> exceptional circumstances.
>
>
> 	
>
> *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%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154740432%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6rSI2UvnakrWNh3qtBEgIMbRO8L9oXu8zGj4Fd128B8%3D&reserved=0>.
>
>  
>
>  
>
> On Fri, Oct 15, 2021 at 10:17 AM Pieter Kasselman
> <pieter.kasselman=[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Any weakening of the requirement should include a clear outline of
>     the risks to help implementors make informed decisions.
>
>      
>
>     *From:*OAuth <[e-mail]
>     <mailto:[e-mail]>> *On Behalf Of *Ash Narayanan
>     *Sent:* Friday 15 October 2021 01:51
>     *To:* Aaron Parecki <[e-mail] <mailto:[e-mail]>>
>     *Cc:* IETF oauth WG <[e-mail] <mailto:[e-mail]>>
>     *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse
>     and OAuth 2.1
>
>      
>
>
>     	
>
>     You don't often get email from [e-mail]
>     <mailto:[e-mail]>. Learn why this is important
>     <http://aka.ms/LearnAboutSenderIdentification>
>
>     	
>
>         Yes, as I said before, authorization servers are free to
>         enforce one-time use of the authorization code even if there
>         isn't a requirement to. The proposal is just to remove the
>         *requirement* of authorization servers enforcing it.
>
>      
>
>     I agree, and therefore I think what it really ought to be is "MAY".
>
>      
>
>     Annabelle said:
>
>         There are legitimate use cases for a client to replay an
>         authorization code. Connection failures happen. Servers fall
>         over before completing requests. Users hit browser refresh
>         buttons. Permitting replay of authorization codes (assuming
>         valid PKCE, client creds, etc.) allows clients to handle these
>         failure modes simply and gracefully via retries.
>
>      
>
>     Couldn't agree more. Having experienced these exact use-cases, I
>     can honestly say that denying users a smooth experience just to be
>     compliant with the spec, which offers no additional security if
>     PKCE is also being used, makes no sense.
>
>     It is also more effort (from a repository layer perspective) to
>     implement one-time use than do PKCE verification.
>
>      
>
>         What is the practical reason for allowing "plain" PKCE in
>         OAuth 2.1? Are there really use cases out there where SHA-256
>         is a deal breaker?
>
>      
>
>     I'd be interested in these use-cases as well (I can't think of any). 
>
>      
>
>     On Thu, Oct 14, 2021 at 8:36 AM Aaron Parecki <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         Yes, as I said before, authorization servers are free to
>         enforce one-time use of the authorization code even if there
>         isn't a requirement to. The proposal is just to remove the
>         *requirement* of authorization servers enforcing it.
>
>          
>
>         I am okay with Mike's suggestion of changing the language to
>         "SHOULD" to continue to point out the possibility of enforcing
>         one-time authorization codes if desired.
>
>          
>
>          
>
>          
>
>         On Wed, Oct 13, 2021 at 2:15 PM Pieter Kasselman
>         <[e-mail]
>         <mailto:[e-mail]>> wrote:
>
>             Log files can exist in lots of place (clients, servers,
>             data lakes). The question is whether it is a valid
>             assumption that an attacker cannot obtain an Authorization
>             Code and a Code Verifier and present it a second time
>             round. Limiting the validity period is one layer of
>             defence, PKCE is another layer, one time use enforcement
>             is another. Assuming breach and designing from a defence
>             in depth perspective is a good practice, so why not give
>             implementors options (and guidance) to add additional
>             layers of defence to match their risk profiles?  
>
>              
>
>              
>
>             *From:*OAuth <[e-mail]
>             <mailto:[e-mail]>> *On Behalf Of *Sascha
>             Preibisch
>             *Sent:* Wednesday 13 October 2021 22:06
>             *To:* Aaron Parecki <[e-mail]
>             <mailto:[e-mail]>>
>             *Cc:* IETF oauth WG <[e-mail] <mailto:[e-mail]>>
>             *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization
>             code reuse and OAuth 2.1
>
>              
>
>             Ok, if the goal is to avoid unnecessary requirements I am
>             suggesting to point out why MUST was changed to SHOULD.
>             Otherwise developers will start to mix and match OAuth 2.0
>             and OAuth 2.1 requirements as they see them fit their needs.
>
>             In regards to encrypted values in PKCE, Aaron, I can also
>             not confirm that as the general implementation.
>
>              
>
>             On Wed, 13 Oct 2021 at 13:56, Aaron Parecki
>             <[e-mail] <mailto:[e-mail]>> wrote:
>
>                 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
>                 <[e-mail]
>                 <mailto:[e-mail]>> 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
>                     <[e-mail] <mailto:[e-mail]>> 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
>                         <[e-mail] <mailto:[e-mail]>>
>                         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?
>
>
>                             Image removed by sender.
>
>                             	
>
>                             *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%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154750385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y86Gy8RiRIbIAW3So8hr4PxYsta1VWX1X7l%2FHzVbcvI%3D&reserved=0>.
>
>                              
>
>                              
>
>                             On Wed, Oct 13, 2021 at 10:33 PM Aaron
>                             Parecki <[e-mail]
>                             <mailto:[e-mail]>> 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
>                                 <[e-mail]
>                                 <mailto:[e-mail]>>
>                                 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
>                                     <[e-mail]
>                                     <mailto:[e-mail]>>
>                                     *On Behalf Of *Aaron Parecki
>                                     *Sent:* Wednesday 13 October 2021
>                                     18:40
>                                     *To:* Warren Parad
>                                     <wparad=[e-mail]
>                                     <mailto:[e-mail]>>
>                                     *Cc:* Mike Jones
>                                     <Michael.Jones=[e-mail]
>                                     <mailto:[e-mail]>>;
>                                     [e-mail] <mailto:[e-mail]>
>                                     *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=[e-mail]
>                                     <mailto:[e-mail]>>
>                                     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"?
>
>                                          
>
>                                         Image removed by sender.
>
>                                         	
>
>                                         *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%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154760332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lbb9cJl0VUcfBD9IwzKF4BeB5nnggZxLB1TwlZYdNK4%3D&reserved=0>.
>
>                                          
>
>                                          
>
>                                         On Wed, Oct 13, 2021 at 7:17
>                                         PM Mike Jones
>                                         <Michael.Jones=[e-mail]
>                                         <mailto:[e-mail]>>
>                                         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
>                                             [e-mail]
>                                             <mailto:[e-mail]>
>                                             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%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154760332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=u3yNDEeIsFvqGwu3x8%2F22D25o3bVO9PkrBEA2IEKSzY%3D&reserved=0>
>
>                                         _______________________________________________
>                                         OAuth mailing list
>                                         [e-mail]
>                                         <mailto:[e-mail]>
>                                         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%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154770299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7JX5eYOgW7gjFIIySrFurb2%2B9dBhH4IAsXhIMkV%2FGps%3D&reserved=0>
>
>                         _______________________________________________
>                         OAuth mailing list
>                         [e-mail] <mailto:[e-mail]>
>                         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%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154770299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7JX5eYOgW7gjFIIySrFurb2%2B9dBhH4IAsXhIMkV%2FGps%3D&reserved=0>
>
>         _______________________________________________
>         OAuth mailing list
>         [e-mail] <mailto:[e-mail]>
>         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%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154780256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lJqE32wIC4OoFoYfUMYr8zd3pgEz2abBr2aga42rFsA%3D&reserved=0>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     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%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154780256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lJqE32wIC4OoFoYfUMYr8zd3pgEz2abBr2aga42rFsA%3D&reserved=0>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de