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
>