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

Only if the audience is different.

On Thu, Jul 27, 2017 at 10:00 PM, Nathaniel McCallum <npmccallum@redhat.com>
wrote:

> 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
> <bcampbell@pingidentity.com> 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 <
> npmccallum@redhat.com>
> > 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
> >> <bcampbell@pingidentity.com> 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
> >> > jose@ietf.org
> >> > 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.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about
projects I am working on!