Only if the audience is different. On Thu, Jul 27, 2017 at 10:00 PM, Nathaniel McCallum <npmccal...@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 > <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 > -- Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
