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

[Nathaniel McCallum <[e-mail]>]

Even after reading the whole section, I still don't understand the
problem. Yes, a class of attack could exist where an attacker
substitutes a valid JWT from one security context into another
context. But isn't this resolved by audience validation?

On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell
<[e-mail]> wrote:
> 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.