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

From: Mike Jones <[email-masked]>
Date: Thu, 13 Aug 2020 22:58:58 +0000

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 <[email-masked]> On Behalf Of Benjamin Kaduk
Sent: Thursday, August 13, 2020 2:59 PM
To: Brian Campbell <[email-masked]>
Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>; oauth <[email-masked]>
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 < 
> [email-masked]> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Filip Skokan <[email-masked]>
Date: Fri, 14 Aug 2020 12:58:53 +0200

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=
[email-masked]> 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
>
> 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
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 15 Aug 2020 12:08:12 +0300

+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:
>   * if the Request Object includes a sub claim with the value of the
>   * 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=[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     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
>     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
>
>     From: OAuth <[email-masked]
>     <mailto:[email-masked]>> On Behalf Of Benjamin Kaduk
>     To: Brian Campbell <[email-masked]
>     <mailto:[email-masked]>>
>     Cc: [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; The IESG <[email-masked]
>     <mailto:[email-masked]>>; oauth <[email-masked]
>     <mailto:[email-masked]>>
>     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
>
>     > [email-masked] <mailto:[email-masked]>> wrote:
>     >
>     > >
>     > >
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
Vladimir Dzhuvinov

---

From: Warren Parad <[email-masked]>
Date: Sat, 15 Aug 2020 18:27:19 +0200

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 <[email-masked]>
wrote:

> 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.
>
> 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
>> 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
>>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
> --
> Vladimir Dzhuvinov
>

---

From: Mike Jones <[email-masked]>
Date: Sat, 15 Aug 2020 16:41:29 +0000

Answering Filip and Vladirmir’s question about adding normative language around “typ” and “sub”:  Anytime you add a new required feature, you are breaking existing deployments.  Suppose we added the normative requirement “If a ‘typ’ header parameter is present, ASs MUST reject the Request object if its value is not ‘oauth.authz.req+jwt’”.  One could then write a certification test sending the AS a different “typ” value – which to pass, ASs would have to reject the JWT.  Every existing deployment would fail this test!  That’s exactly what we don’t want to have happen.

Brian asked for security considerations.  The IESG asked for security considerations.  I added them in the PR – working with Nat and John.  They point the way to the future without breaking existing deployments.  That’s as it should be.

                                                       -- Mike

From: OAuth <[email-masked]> On Behalf Of Warren Parad
Sent: Saturday, August 15, 2020 9:27 AM
To: Vladimir Dzhuvinov <[email-masked]>
Cc: oauth <[email-masked]>
Subject: [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

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

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?

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

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 <[email-masked]<mailto:[email-masked]>> 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

  *   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=[email-masked]<mailto:[email-masked]>> 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!

                                -- Mike

-----Original Message-----
From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of Benjamin Kaduk
Sent: Thursday, August 13, 2020 2:59 PM
To: Brian Campbell <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; The IESG <[email-masked]<mailto:[email-masked]>>; oauth <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

-Ben

On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote:
> [email-masked]<mailto:[email-masked]>> wrote:
>
> >

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

OAuth mailing list

[email-masked]<mailto:[email-masked]>

--

Vladimir Dzhuvinov
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Mon, 17 Aug 2020 09:36:11 -0600

> JWTs with "sub" present suffice?

Prohibiting the use of "sub" in request object JWTs would suffice, yes. I'd
suggested the more narrow/specific prohibition with the aim of a smaller
scoped change. But perhaps it'd be simpler to just say don't use "sub"? I
can't think of any non-erroneous reason sub would be in a request object.

-- 
_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._

---

From: Brian Campbell <[email-masked]>
Date: Mon, 17 Aug 2020 16:55:36 -0600

I might suggest that thinking about it in the context of interoperability
would be more meaningful than certification tests.

Saying that an AS MUST reject the Request object if it has a typ header and
the value of the header is not ‘oauth.authz.req+jwt’ [1] should allow for
interoperability with respect to JWT typing between all combinations of
existing and updated clients with existing and updated authorization
servers.

Saying that an AS MUST NOT include a sub with client id as the value would
break for an updated authorization server when receiving such a request
object JWT. But that's erroneous and potentially dangerous behaviour from
the client so I don't know that we need to try and maintain
interoperability there.

[1] Unfortunately "typ":"JWT" would probably also need to be allowed. As
best I understand it "typ":"JWT" basically says "this JWT is a JWT", which
isn't useful for explicit typing and I think makes it effectively
equivalent to an untyped JWT. I've honestly never understood why one would
use "typ":"JWT" but it shows up in a lot of places including examples and
explanations on sites like jwt.io so it seems very likely that it'd just
get copied over and show up in some amount of real world request object
JWTs.

On Sat, Aug 15, 2020 at 10:41 AM Mike Jones <Michael.Jones=
[email-masked]> wrote:

> Answering Filip and Vladirmir’s question about adding normative language
> around “typ” and “sub”:  Anytime you add a new required feature, you are
> breaking existing deployments.  Suppose we added the normative requirement
> “If a ‘typ’ header parameter is present, ASs MUST reject the Request object
> if its value is not ‘oauth.authz.req+jwt’”.  One could then write a
> certification test sending the AS a different “typ” value – which to pass,
> ASs would have to reject the JWT.  *Every existing deployment would fail
> this test!*  That’s exactly what we don’t want to have happen.
>
>
>
> Brian asked for security considerations.  The IESG asked for security
> considerations.  I added them in the PR – working with Nat and John.  They
> point the way to the future without breaking existing deployments.  That’s
> as it should be.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* OAuth <[email-masked]> *On Behalf Of * Warren Parad
> *Sent:* Saturday, August 15, 2020 9:27 AM
> *To:* Vladimir Dzhuvinov <[email-masked]>
> *Cc:* oauth <[email-masked]>
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's No Objection on
> 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
>
> On Sat, Aug 15, 2020 at 11:08 AM Vladimir Dzhuvinov <
> [email-masked]> wrote:
>

---

From: Joseph Heenan <[email-masked]>
Date: Wed, 19 Aug 2020 13:09:13 +0100

I agree with Brian here, I think “typ”:”JWT” should be permitted as well as no typ and “typ”: "oauth.authz.req+jwt".

There are other tests we could write for JAR that an OIDC server will fail (for example, one that tested the behaviour of passing a value only outside the request object - which an OIDC server would process, but one compliant with JAR [or FAPI-RW] would ignore the value outside). I don’t see having one more case of this as an issue - some servers will not be JAR compliant, and hence would fail tests that test JAR-specific behaviour.

I also agree with Brian about requiring AS to reject request objects that have a sub that’s a client_id, this doesn’t seem to cause significant interoperability concerns as it is hopefully unlikely that any client is doing so. I could possibly see an argument for weakening the requirement for an AS to reject a request object with sub=client_id to a ’should’ (rather than a must) given there is a small chance it could end up breaking an ecosystem, but I’m not entirely convinced.

Joseph

> On 17 Aug 2020, at 23:55, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> I might suggest that thinking about it in the context of interoperability would be more meaningful than certification tests. 
> 
> Saying that an AS MUST reject the Request object if it has a typ header and the value of the header is not ‘oauth.authz.req+jwt’ [1] should allow for interoperability with respect to JWT typing between all combinations of existing and updated clients with existing and updated authorization servers. 
> 
> Saying that an AS MUST NOT include a sub with client id as the value would break for an updated authorization server when receiving such a request object JWT. But that's erroneous and potentially dangerous behaviour from the client so I don't know that we need to try and maintain interoperability there. 
> 
> [1] Unfortunately "typ":"JWT" would probably also need to be allowed. As best I understand it "typ":"JWT" basically says "this JWT is a JWT", which isn't useful for explicit typing and I think makes it effectively equivalent to an untyped JWT. I've honestly never understood why one would use "typ":"JWT" but it shows up in a lot of places including examples and explanations on sites like jwt.io <http://jwt.io/> so it seems very likely that it'd just get copied over and show up in some amount of real world request object JWTs. 
> 
> 
> On Sat, Aug 15, 2020 at 10:41 AM Mike Jones <Michael..Jones=[email-masked] <mailto:[email-masked]>> wrote:
> From: OAuth <[email-masked] <mailto:[email-masked]>> On Behalf Of Warren Parad
> To: Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>>
> Cc: oauth <[email-masked] <mailto:[email-masked]>>
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> if the Request Object is explicitly typed (typ) its value MUST be ...
> On Fri, 14 Aug 2020 at 00:59, Mike Jones <Michael..Jones=[email-masked] <mailto:[email-masked]>> 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 athttps://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10 <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 <https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and-working-group-comments/diff#chg-draft-ietf-oauth-jwsreq.xml>.  Please review!
> 
> From: OAuth <[email-masked] <mailto:[email-masked]>> On Behalf Of Benjamin Kaduk
> To: Brian Campbell <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; The IESG <[email-masked] <mailto:[email-masked]>>; oauth <[email-masked] <mailto:[email-masked]>>
> > > https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0 <https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>  
> 
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> -- 
> Vladimir Dzhuvinov
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>_______________________________________________
> OAuth mailing list
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 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
> [email-masked]