Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
Dick Hardt <dick.hardt@gmail.com> Thu, 27 July 2017 21:17 UTC
Return-Path: <dick.hardt@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE402131761; Thu, 27 Jul 2017 14:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H8r98A1ZnkI; Thu, 27 Jul 2017 14:17:49 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE3C131563; Thu, 27 Jul 2017 14:17:48 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id d136so113996717qkg.3; Thu, 27 Jul 2017 14:17:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tIaTRg+C0wRkbJieUt6+8XLmpSZ0zuWe1rm8LIj9dOg=; b=YUh0/Sbs/PO/kjA1eaoQm7tUnJLTN3No2dRiAIZv2RwbS3NfJNtzGPFOhqmPBBRNJH ujjHfZH6iBV87QVHM+HzPUKR0UVDomY+J1d3C7vPsRFLU/LYjgPB6Q/67RJANk5funrQ s2Mbd0VUAlix4RKefe5JcVSrqdARqLCzhcda9IDxD8jYLNDq3UL01o4VrXqVyZ+5tKKf DM4qsFOVm1mQ3ppwK9jzefT8/dwy8hUqJlVXL89cZCyzFaqTcPCzsbYHuuz5rCdYx51u rI6tLwekk6uI55r4Vc2EowOrv/qeeaBpRoh9j96T38wLqymzb9pJB6Ff4zcRS/0mWW0D T8wQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tIaTRg+C0wRkbJieUt6+8XLmpSZ0zuWe1rm8LIj9dOg=; b=Tc2RNUuXgpZ+ImtGqqMmyk+CFM+99pLOa4BXKr3NXmXQlAbL8hGIuthbn3k5+iibYH i3R5m6juv9eC+hSnofKGfLBJ5IFOygX7GPFwktwVSM/K9nKQSPkS05nBOWb+NogzGucu 96/wqTHyXZWsqHZCdT6BD3HE1dJQ1BqWnqbn6ram6QD52/Z14qAH47E008PNmdQM4L2L +mLYgaYTmiYhKGCS5hXsDjqsPb9p6UNCZ2CWhanV7IijvTL4i70bvqgshUcXM9/rsc/5 qPwYrYd3Jr9TMRqDzkfX/ul+YKpheS5+gWWNQ3r50oYqYg8kTaLQY0tibS4eEsJhW57t dwxQ==
X-Gm-Message-State: AIVw112AY77cZWoJboJFCrcmbFuFF4rOP4EAU73tM5Fe0RRj2SavCYoU uuOgx2sjUisUEZV3blXyOp4m1oRpCQ==
X-Received: by 10.55.124.67 with SMTP id x64mr7710969qkc.98.1501190267828; Thu, 27 Jul 2017 14:17:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.104.131 with HTTP; Thu, 27 Jul 2017 14:17:27 -0700 (PDT)
In-Reply-To: <CAOASepMaeS8WrCMb+WHV0FC2_w3f0KnY5XuDsuWJhAW2ayfryQ@mail.gmail.com>
References: <CA+k3eCRT_iuLHYrLxz+tf1MT9L9XG2jV0D0anC0h5w7A_ujEdQ@mail.gmail.com> <CAOASepOjYBYoKYEVvCLMzZgsdyGhr2LOB-dNqekxsKFm_gxixg@mail.gmail.com> <CA+k3eCS-Va2AvzRhWia_ETqSDYUMBOoi=sY3jg7TbJFhhuVnZA@mail.gmail.com> <CAOASepMaeS8WrCMb+WHV0FC2_w3f0KnY5XuDsuWJhAW2ayfryQ@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Thu, 27 Jul 2017 22:17:27 +0100
Message-ID: <CAD9ie-upQ8GYumi6NTGELQoc4s=7AWkZj3rk-iaeiPZOnpYBbQ@mail.gmail.com>
To: Nathaniel McCallum <npmccallum@redhat.com>
Cc: Brian Campbell <bcampbell@pingidentity.com>, oauth <oauth@ietf.org>, "jose@ietf.org" <jose@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c062748a7852e0555531832"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/PYS4y0KODqUPPSWaZefxoPP6gEI>
Subject: Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jul 2017 21:17:51 -0000
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!
- [OAUTH-WG] preventing confusion of one kind of JW… Brian Campbell
- Re: [OAUTH-WG] [jose] preventing confusion of one… Nathaniel McCallum
- Re: [OAUTH-WG] [jose] preventing confusion of one… Brian Campbell
- Re: [OAUTH-WG] [jose] preventing confusion of one… Nathaniel McCallum
- Re: [OAUTH-WG] [jose] preventing confusion of one… Dick Hardt
- Re: [OAUTH-WG] [jose] preventing confusion of one… Phil Hunt
- Re: [OAUTH-WG] [jose] preventing confusion of one… Dick Hardt
- Re: [OAUTH-WG] [jose] preventing confusion of one… John Bradley
- Re: [OAUTH-WG] [jose] preventing confusion of one… Nathaniel McCallum
- Re: [OAUTH-WG] [jose] preventing confusion of one… Brian Campbell
- Re: [OAUTH-WG] [jose] preventing confusion of one… Brian Campbell
- Re: [OAUTH-WG] [jose] preventing confusion of one… John Bradley
- Re: [OAUTH-WG] [jose] preventing confusion of one… Jim Schaad
- Re: [OAUTH-WG] [jose] preventing confusion of one… Brian Campbell