In the case of > if the Request Object includes a sub claim with the value of the client_id > the AS MUST reject the request
What would the expectation be in terms of a client_credentials grant? >From experience, the *sub *is frequently populated with the client_id value and the client_id is not used. Which would mean breaking for that type of grant wouldn't it? Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress <https://bit.ly/37SSO1p>. On Sat, Aug 15, 2020 at 11:08 AM Vladimir Dzhuvinov <vladi...@connect2id.com> wrote: > +1 to make the "typ" check, as Filip suggested, normative, as existing > client and RP deployments with undefined "typ" will not be affected. New > deployments should be encouraged to type the JWT, and thus be made safer. > > > Regarding the "sub != client_id" check -- could a simple rejection of all > JWTs with "sub" present suffice? > > I find it difficult to imagine what else a client could end up setting the > "sub" claim to, if it does end up populating it for some reason. > > Rejecting JWTs with "sub=client_id" or "sub" present will break > deployments where a client for some reason sets the "typical" JWT claims, > and "sub" is a typical one, but if those deployments happen to accept > client_secret_jwt or private_key_jwt client authentication, they could well > be vulnerable to cross-JWT confusion attacks. > > > Vladimir > On 14/08/2020 13:58, Filip Skokan wrote: > > Hi Mike, Nat, > > I thought we would go as far as making these normative requirements > > - if the Request Object includes a sub claim with the value of the > client_id the AS MUST reject the request > - if the Request Object is explicitly typed (typ) its value MUST be ... > > First rejects client assertions to be passed as Request Objects. Second > rejects all future typed JWT profiles from being used as Request Objects > without worrying about the claims they may or may not contain. > > Or is that breaking? > > S pozdravem, > *Filip Skokan* > > > On Fri, 14 Aug 2020 at 00:59, Mike Jones <Michael.Jones= > 40microsoft....@dmarc.ietf.org> wrote: > >> At Nat's request, I've created a pull request addressing Cross-JWT >> Confusion security considerations. It addresses both Brian's comment and >> the IESG comments about explicit typing. See the full PR at >> https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10. See the source >> diffs at >> https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and-working-group-comments/diff#chg-draft-ietf-oauth-jwsreq.xml. >> Please review! >> >> This is only the first commit, albeit, one that addresses some of the >> must substantive issues. More commits will follow addressing additional >> IESG comments. >> >> -- Mike >> >> -----Original Message----- >> From: OAuth <oauth-boun...@ietf.org> On Behalf Of Benjamin Kaduk >> Sent: Thursday, August 13, 2020 2:59 PM >> To: Brian Campbell <bcampb...@pingidentity.com> >> Cc: draft-ietf-oauth-jws...@ietf.org; oauth-cha...@ietf.org; The IESG < >> i...@ietf.org>; oauth <oauth@ietf.org> >> Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on >> draft-ietf-oauth-jwsreq-26: (with COMMENT) >> >> Oops, that's my bad. Thanks for the correction -- I've linked to your >> message in the datatracker (but didn't bother to have the datatracker send >> a third copy of my updated-again ballot position). >> >> -Ben >> >> On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote: >> > While some discussion of why explicit typing was not used might be >> > useful to have, that thread started with a request for security >> > considerations prohibiting use of the "sub" with a client ID value. >> > Because such a request JWT could be repurposed for JWT client >> > authentication. And explicit typing wouldn't help in that situation. >> > >> > On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker < >> > nore...@ietf.org> wrote: >> > >> > > >> > > -------------------------------------------------------------------- >> > > -- >> > > COMMENT: >> > > -------------------------------------------------------------------- >> > > -- >> > > >> > > [updated to note that, per >> > > https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0 >> > > eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit >> > > typing is not used would be in order] >> > > >> > > >> > >> > -- >> > _CONFIDENTIALITY NOTICE: This email may contain confidential and >> > privileged material for the sole use of the intended recipient(s). Any >> > review, use, distribution or disclosure by others is strictly >> > prohibited. If you have received this communication in error, please >> > notify the sender immediately by e-mail and delete the message and any >> > file attachments from your computer. Thank you._ >> >> _______________________________________________ >> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > -- > Vladimir Dzhuvinov > > _______________________________________________ > 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
