Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
Nathaniel McCallum <npmccallum@redhat.com> Thu, 27 July 2017 19:31 UTC
Return-Path: <nmccallu@redhat.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 019D0131CD7 for <oauth@ietfa.amsl.com>; Thu, 27 Jul 2017 12:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.419
X-Spam-Level:
X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 hWfSc397JR95 for <oauth@ietfa.amsl.com>; Thu, 27 Jul 2017 12:30:58 -0700 (PDT)
Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) (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 E1A29131C31 for <oauth@ietf.org>; Thu, 27 Jul 2017 12:30:57 -0700 (PDT)
Received: by mail-it0-f45.google.com with SMTP id v205so71038282itf.1 for <oauth@ietf.org>; Thu, 27 Jul 2017 12:30:57 -0700 (PDT)
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=cxqnsmY86lDsmVHlQ4LcmGoFHKwPin2R2bfMlQxKjVE=; b=tG+R/AHasJf1rfCv4xoLk57KLtas2djKmubE9QBulimpnyvIxBlUHsg4lM2YehxgQp 4phD5pGfGoYuNYGW7yngVAmtAMbNnOzQevQOepC1gpuMslVRgjEjH5er1uIJPkBDMuIq rENCTpMdFMvm+eMwEEt1MrZBa5hZtj7iINwLahpPHy/rj7233UzVqdadsulG9X9wxXqW i0/hC2XrHkGb8vrhfLXRZ4EHaZA9TVruX+AN6NgGbJlyfGR01e2B0RnjFzFDlHl/Eg2I /vohoHnEicE9fFZFr1ucJqMYKHcabAiTP9+cPt4/jNBF+FIDxdVig81SOcE1lwEGMxkf 3SYg==
X-Gm-Message-State: AIVw112MVpN62FeGmZerPezuT6kLR1cqbwuw9oRNj+1VtXn7E/M3hqYk zsjGU5+tXANBKUOgNK6luLhI9q5ug/T93us=
X-Received: by 10.36.185.14 with SMTP id w14mr6557593ite.76.1501183857107; Thu, 27 Jul 2017 12:30:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.21.6 with HTTP; Thu, 27 Jul 2017 12:30:56 -0700 (PDT)
In-Reply-To: <CA+k3eCRT_iuLHYrLxz+tf1MT9L9XG2jV0D0anC0h5w7A_ujEdQ@mail.gmail.com>
References: <CA+k3eCRT_iuLHYrLxz+tf1MT9L9XG2jV0D0anC0h5w7A_ujEdQ@mail.gmail.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
Date: Thu, 27 Jul 2017 15:30:56 -0400
Message-ID: <CAOASepOjYBYoKYEVvCLMzZgsdyGhr2LOB-dNqekxsKFm_gxixg@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: oauth <oauth@ietf.org>, "jose@ietf.org" <jose@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/qVltsv5tubL0LjlHjneIhTYXZ8Q>
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 19:31:00 -0000
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 >
- [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