> On 11. May 2020, at 10:59, Neil Madden <neil.mad...@forgerock.com> wrote: > > > >> On 11 May 2020, at 08:53, Torsten Lodderstedt <tors...@lodderstedt.net> >> wrote: >> >> >> >>> On 11. May 2020, at 09:34, Neil Madden <neil.mad...@forgerock.com> wrote: >>> >>> >>> >>>> On 11 May 2020, at 08:05, Torsten Lodderstedt <tors...@lodderstedt.net> >>>> wrote: >>>> >>>> >>>> >>>>>> On 11. May 2020, at 08:47, Neil Madden <neil.mad...@forgerock.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On 11 May 2020, at 07:41, Torsten Lodderstedt <tors...@lodderstedt.net> >>>>>>> wrote: >>>>>> >>>>>>> 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? >>>>> >>>>> No, but servers and clients are already free to support PKCE. I’m saying >>>>> that rejecting requests from non-PKCE clients doesn’t prevent any attack. >>>>> It just denies service to legitimate clients. >>>> >>>> There are two aspects to this topic: >>>> >>>> 1) Do all ASs support PKCE? Requiring PKCE support fosters >>>> interoperability and security. Security since the client can be sure the >>>> AS supports PKCE. Today, if the AS does not support PKCE, the client will >>>> never learn since a compliant AS will just ignore additional request >>>> parameters. >>> >>> But just saying that a 2.1 AS MUST support PKCE is enough for this. >>> Rejecting requests just to support feature discovery is a sledgehammer to >>> crack a nut. >>> >>>> >>>> 2) Do ASs enforce PKCE? This fosters security since it forces clients to >>>> implement a means against code replay and CSRF. >>>> >>> >>> Again, just saying that 2.1 clients MUST support PKCE achieves this aim. >>> Rejecting non-PKCE requests doesn’t add anything to security. >>> >>> And as has been pointed out elsewhere in this thread there are clients that >>> don’t benefit from PKCE such as confidential OIDC clients. Indeed for most >>> confidential clients the gains of PKCE are relatively minor - code >>> injection attacks are already pretty hard to pull off in practice against >>> such clients. >> >> I agree, but I wouldn’t say they don’t benefit at all. >> >> 1) The nonce check happens after the OP had issued the ID Token. This means >> even if the transaction is being evaluated to be fraudulent afterwards, the >> OP releases PII to the RP. Depending on the way the OP obtained this data, >> this might have already caused unneglectable cost (e.g. for an external >> commercial claims provider). >> >> That’s not the case with PKCE. > > We’re talking about confidential clients. If the ID Token is not meant for > this client then client authentication will fail, or else the auth code was > meant for this client (but not this session) in which case the user already > consented to release of PII to that RP. > > If you are talking about a hybrid flow then PKCE doesn’t protect that either.
Sure. The OP won’t issue an ID Token if the PKCE check fails. > I’d like to see encrypted ID tokens become mandatory in hybrid flows, but > that’s not for this WG. > >> >> 2) The whole check relies on the client. I would rather rely on the OP/AS to >> enforce this security check since clients have a less promising track record >> of implementing security checks. >> >> 3) In mixed OAuth/OIDC scenarios, switching back and force between nonce and >> PKCE does not make developers live simpler. > > Maybe, but I don’t think either of these rise to the level of mandating that > ASes reject non-PKCE requests. > > In the interests of building consensus, maybe something along the lines of: > “An AS MUST reject requests without a code_challenge from public clients, and > SHOULD reject such requests from other clients unless there is reasonable > assurance that the client mitigates these threats in other ways”? Sounds reasonable. > > — Neil > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
