There is no attack that this prevents so your claim of improving security is unsubstantiated. I can’t see how we can ship a 2.1-compliant-by-default AS while this requirement remains so I don’t support it.
Neil > On 11 May 2020, at 01:35, Dick Hardt <dick.ha...@gmail.com> wrote: > > > It is a MUST to enforce consistency across all clients, and therefore to > improve security for all clients. > > An AS can decide to be OAuth 2.1 for all new clients, and encourage existing > clients to migrate to OAuth 2.1 (add support for PKCE). > > If the client wants OAuth 2.1, the AS will enforce it. > > I don't follow your logic below wrt. what an attacker will do. > > >> On Sun, May 10, 2020 at 1:46 PM Neil Madden <neil.mad...@forgerock.com> >> wrote: >> Let’s go back to basics. Why is this clause a MUST in the 2.1 spec? What >> does that accomplish? >> >> It doesn’t provide any security benefit - an attacker can just as easily >> send a code_challenge as a legitimate client, there’s no secret involved. So >> enforcing PKCE in this way doesn’t prevent any direct attacks. Presumably >> then making it a hard fail is designed to drive adoption of PKCE - turning >> the thumbscrews on clients that otherwise wouldn’t bother? >> >> But if we are saying that an AS can happily support legacy 2.0 clients >> without PKCE then the pressure of the MUST clause evaporates and they are >> free to ignore it again. What’s the incentive for an AS deployment to ever >> enforce 2.1 compliance if all it adds is a potential incompatibility with no >> security gain? (Given that servers and clients can already support PKCE if >> they wish). >> >> All I can see this doing is delaying adoption of 2.1 by ASes. >> >> — Neil >> >> >>> On 10 May 2020, at 21:35, Dick Hardt <dick.ha...@gmail.com> wrote: >>> >>> Sounds like your clients that have set PKCE to be mandatory will then be >>> OAuth 2.1 compliant with no extra work. >>> >>> A deployment can decide when they want to be compliant. That is not the >>> specifications decision. I'm unclear on what point you are wanting to make >>> below. >>> >>> >>>> On Sun, May 10, 2020 at 1:28 PM Neil Madden <neil.mad...@forgerock.com> >>>> wrote: >>>> This is the same as having 2.1 compliance turned off by default. We >>>> already have a per-client setting to make PKCE mandatory. >>>> >>>> If you can turn it off, what’s the point of making it a MUST in the spec? >>>> What does an optional MUST even mean for an AS to claim 2.1 compliance? >>>> >>>>> On 10 May 2020, at 21:19, Dick Hardt <dick.ha...@gmail.com> wrote: >>>>> >>>>> Is there a reason why a server can not support both OAuth 2.0 and OAuth >>>>> 2.1? The version supported could be dependent on the client id, ie older >>>>> clients could still be OAuth 2.0, and newer clients would be OAuth 2.1, >>>>> and PKCE would be enforced. >>>>> ᐧ >>>>> >>>>>> On Sun, May 10, 2020 at 1:05 PM Neil Madden <neil.mad...@forgerock.com> >>>>>> wrote: >>>>>> But if an AS upgrades to OAuth 2.1 then it MUST reject authorization >>>>>> requests that don’t include a code_challenge (section 4.1.2.1), so this >>>>>> will only be possible when all clients support PKCE. >>>>>> >>>>>> This makes it impossible for a 2.1-compliant AS to also support non-PKCE >>>>>> 2.0 clients (i.e., the vast majority of them). >>>>>> >>>>>> I think we can have a 2.1 spec that says clients and servers MUST >>>>>> support PKCE without this hard-fail clause. Otherwise I can’t see how >>>>>> we’d ever ship with 2.1-compliance enabled out-of-the-box. >>>>>> >>>>>> — Neil >>>>>> >>>>>>> On 10 May 2020, at 20:38, Dick Hardt <dick.ha...@gmail.com> wrote: >>>>>>> >>>>>>> Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just >>>>>>> as the other extensions. Similarly, OAuth 1.0 deployments upgrading to >>>>>>> OAuth 2.0 was voluntary. >>>>>>> >>>>>>> Would you clarify why you think upgrading to OAuth 2.1 would be >>>>>>> mandatory? >>>>>>> >>>>>>> >>>>>>>> On Sun, May 10, 2020 at 12:02 PM Mike Jones >>>>>>>> <Michael.Jones=40microsoft....@dmarc.ietf.org> wrote: >>>>>>>> I agree with actively maintaining and improving the OAuth 2.0 specs by >>>>>>>> adding enhancements that are voluntary to use. I’ve worked on many >>>>>>>> such improvements, including Dynamic Client Registration, >>>>>>>> Authorization Metadata, the Device Flow, Token Exchange, DPoP, and >>>>>>>> support PAR and RAR, etc.. The issue that’s the subject is the >>>>>>>> current discussion is whether to make use of another enhancement, >>>>>>>> PKCE, mandatory in cases where it’s actually not needed, rather than >>>>>>>> making its use voluntary like the other enhancements, which I >>>>>>>> certainly support. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Mike >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From: Torsten Lodderstedt <torsten=40lodderstedt....@dmarc.ietf.org> >>>>>>>> Sent: Sunday, May 10, 2020 3:15 AM >>>>>>>> To: Mike Jones <michael.jo...@microsoft.com> >>>>>>>> Cc: Daniel Fett <f...@danielfett.de>; oauth@ietf.org >>>>>>>> Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Mike, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Mike Jones <Michael.Jones=40microsoft....@dmarc.ietf.org> schrieb am >>>>>>>> Fr. 8. Mai 2020 um 18:55: >>>>>>>> >>>>>>>> OAuth 2.1 was supposed to not introduce breaking changes. >>>>>>>> >>>>>>>> I cannot remember the WG met that decision. Can you please refer to >>>>>>>> the respective thread? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Requiring exact redirect URI matching is already a breaking change. Do >>>>>>>> you oppose against this as well? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> If you want to do that, please do it in TxAuth instead. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Interesting statement. Does it mean you want to conserve OAuth 2.0 and >>>>>>>> force any enhancements/improvements to go into TXAuth? This would >>>>>>>> cause huge migration efforts for existing deployments wanting to >>>>>>>> benefit from those enhancements. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I think existing deployments are better served by actively maintaining >>>>>>>> and evolving the 2.x line. For example, PAR and RAR are attempts to >>>>>>>> improve OAuth 2.x and make it usable for new use cases. That’s better >>>>>>>> protection of existing investments than sending them of to TXAuth. >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> >>>>>>>> Torsten. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Mike >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From: OAuth <oauth-boun...@ietf.org> On Behalf Of Daniel Fett >>>>>>>> Sent: Thursday, May 7, 2020 11:50 PM >>>>>>>> To: oauth@ietf.org >>>>>>>> Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> +1 to all what Aaron said. Thanks for pointing this out! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> We need to address this in the security BCP and this will be a >>>>>>>> normative change that affects OpenID Connect Core (just as our current >>>>>>>> recommendation on the usage of nonce). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> We would then have: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - use PKCE, except if you use OIDC with a nonce, then you don't need >>>>>>>> PKCE, except if you are a public client, then you still need PKCE. >>>>>>>> >>>>>>>> - use state, except if you use PKCE, then you don't need state. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I think there are very good reasons to simplify this down to >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - use PKCE >>>>>>>> >>>>>>>> - you may or may not use state >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> First and foremost, not many people will understand why there are >>>>>>>> cases when the BCP/OAuth 2.1 mandate PKCE and some where they don't. >>>>>>>> However, understanding why you have to do something is key to >>>>>>>> compliance. The short version "PKCE protects the code; there is a >>>>>>>> specific case where it is not needed, but its better to use it all the >>>>>>>> time" is easy to understand. We will not see many implementations >>>>>>>> following the long version above correctly. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Second, we dramatically reduce technical complexity by reducing cases >>>>>>>> that need to be handled. We reduce correctness and compliance testing >>>>>>>> complexity in the same way. We reduce the cost of security analysis, >>>>>>>> which scales really badly to more cases. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> And finally, using nonce to protect against code injection is less >>>>>>>> robust than PKCE. AS have a better track record than clients when it >>>>>>>> comes to correctly implementing security mechanisms. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Yes, this will make a number of implementations non-spec-compliant, >>>>>>>> but I do not think that this is a huge problem. Software needs to >>>>>>>> adapt all the time and a software that has not been changed in a while >>>>>>>> is probably not one you would want to use anyway. We are setting a new >>>>>>>> goal for implementations to meet and eventually, maintained >>>>>>>> implementations will get there. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -Daniel >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Am 08.05.20 um 01:38 schrieb Aaron Parecki: >>>>>>>> >>>>>>>> Backing up a step or two, there's another point here that I think has >>>>>>>> been missed in these discussions. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> PKCE solves two problems: stolen authorization codes for public >>>>>>>> clients, and authorization code injection for all clients. We've only >>>>>>>> been talking about authorization code injection on the list so far. >>>>>>>> The quoted section of the security BCP (4.5.3) which says clients can >>>>>>>> do PKCE or use the nonce, is only talking about preventing >>>>>>>> authorization code injection. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The nonce parameter solves authorization code injection if the client >>>>>>>> requests an ID token. Public clients using the nonce parameter are >>>>>>>> still susceptible to stolen authorization codes so they still need to >>>>>>>> do PKCE as well. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The only case where OpenID Connect clients don't benefit from PKCE is >>>>>>>> if they are also confidential clients. Public client OIDC clients >>>>>>>> still need to do PKCE even if they check the nonce. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> OpenID Connect servers working with confidential clients still benefit >>>>>>>> from PKCE because they can then enforce the authorization code >>>>>>>> injection protection server-side rather than cross their fingers that >>>>>>>> clients implemented the nonce check properly. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I really don't think it's worth the amount of explanation this will >>>>>>>> take in the future to write an exception into OAuth 2.1 or the >>>>>>>> Security BCP for only some types of OpenID Connect clients when all >>>>>>>> clients would benefit from PKCE anyway. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Aaron >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, May 6, 2020 at 10:48 AM Dick Hardt <dick.ha...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is >>>>>>>> best practice for OAuth 2.0. It is not common in OpenID Connect >>>>>>>> servers as the nonce solves some of the issues that PKCE protects >>>>>>>> against. We think that most OpenID Connect implementations also >>>>>>>> support OAuth 2.0, and hence have support for PKCE if following best >>>>>>>> practices. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The advantages or requiring PKCE are: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - a simpler programming model across all OAuth applications and >>>>>>>> profiles as they all use PKCE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - reduced attack surface when using S256 as a fingerprint of the >>>>>>>> verifier is sent through the browser instead of the clear text value >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - enforcement by AS not client - makes it easier to handle for client >>>>>>>> developers and AS can ensure the check is conducted >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> What are disadvantages besides the potential impact to OpenID Connect >>>>>>>> deployments? How significant is that impact? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Dick, Aaron, and Torsten >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ᐧ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>> >>> >>> ᐧ >> > > ᐧ
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
