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 <bcampb...@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 <npmccal...@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 >> <bcampb...@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 >> > j...@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
