> On 11. May 2020, at 07:38, Neil Madden <neil.mad...@forgerock.com> wrote: > > 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.
Are you saying PKCE does not prevent any attack? > > 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
