Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

[Warren Parad <[e-mail]>]

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 <[e-mail]>
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=
> [e-mail]> 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 <[e-mail]> On Behalf Of Benjamin Kaduk
>> Sent: Thursday, August 13, 2020 2:59 PM
>> To: Brian Campbell <[e-mail]>
>> Cc: [e-mail]; [e-mail]; The IESG <
>> [e-mail]>; oauth <[e-mail]>
>> 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 <
>> > [e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
> --
> Vladimir Dzhuvinov
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>