Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP

[Brian Campbell <[e-mail]>]

The draft describes it in
https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01#section-2.7

On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum <[e-mail]>
wrote:

> What class of attacks is this trying to prevent? I frankly don't see a
> problem with confusing different types of JWT. But I may just be
> ignorant.
>
> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
> <[e-mail]> wrote:
> > During the first WG meeting last week I asked if use of the JOSE "crit"
> > (Critical) Header Parameter had been considered as a recommendation for
> > preventing confusion of one kind of JWT for another. Time was running
> short
> > in the meeting so there wasn't much discussion and it was requested that
> I
> > take the question to the list. And so here on the list is that.
> >
> > Section 3.9 of the JWT BCP draft now recommends explicit typing using the
> > "typ" JWS/JWE header parameter but does concede that 'the use of explicit
> > typing may not achieve disambiguation from existing kinds of JWTs, as the
> > validation rules for existing kinds JWTs often do not use the "typ"
> header
> > parameter value.'  And the recommendations for how to use the Type Header
> > Parameter in JWT strongly suggest that it's not currently being used for
> any
> > validation.
> >
> > Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to
> signal
> > the type/intent/profile/application of a JWT could achieve
> disambiguation
> > even in validation of existing kinds of JWTs. The critical header lists
> > other headers which must be understood and processed by the receiver and
> > that the JWS/JWE is invalid if those listed aren't understood. So a new
> > type/profile of JWT that uses the "crit" header would produce JWTs that
> > would be rejected even by existing applications of JWT validation (that
> > actually implement "crit" properly anyway).
> >
> > The JWT BCP could suggest the use of "crit" in conjunction with a
> > profile/application/type specific header. Or it could provide a bit more
> of
> > a framework like defining a registering a new JOSE header "p" (strawman
> of p
> > as a very short name for profile) and create a registry for its values. A
> > JWT header using that approach might look like the following where the
> value
> > 1 is registered as some cool new JWT profile/application. The consumer of
> > such a JWT would have to understand and process the "p" header, which
> would
> > mean checking that it had the value expected.
> >
> >      {
> >       "alg":"ES256",
> >       "crit":["p"],
> >       "p":1
> >      }
> >
> > A JOSE compliant JWT validator would reject such a JWT even for an OAuth
> > access token or OIDC id_token because the "p" header isn't known or
> > understood but is marked as critical.
> >
> > To me, that seems like an approach to preventing confusion that has more
> > teeth than the "typ" header. Which is why I asked about it last week and
> am
> > now bringing it to the list.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 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.
> > _______________________________________________
> > jose mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/jose
> >
>

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