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 <oauth-boun...@ietf.org> On Behalf Of Warren Parad
Sent: Saturday, August 15, 2020 9:27 AM
To: Vladimir Dzhuvinov <vladi...@connect2id.com>
Cc: oauth <oauth@ietf.org>
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
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?
[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
<vladi...@connect2id.com<mailto: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<mailto: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<mailto:oauth-boun...@ietf.org>> On Behalf
Of Benjamin Kaduk
Sent: Thursday, August 13, 2020 2:59 PM
To: Brian Campbell
<bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>>
Cc: draft-ietf-oauth-jws...@ietf.org<mailto:draft-ietf-oauth-jws...@ietf.org>;
oauth-cha...@ietf.org<mailto:oauth-cha...@ietf.org>; The IESG
<i...@ietf.org<mailto:i...@ietf.org>>; oauth
<oauth@ietf.org<mailto: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<mailto: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<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Vladimir Dzhuvinov
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
