Re: [jose] preventing confusion of one kind of JWT for another in JWT BCP

Dick Hardt <dick.hardt@gmail.com> Thu, 27 July 2017 21:29 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1431321BB; Thu, 27 Jul 2017 14:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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 q-xh4Gj3Qq9n; Thu, 27 Jul 2017 14:29:34 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 0158D1321BD; Thu, 27 Jul 2017 14:29:33 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id p3so68181167qtg.2; Thu, 27 Jul 2017 14:29:33 -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=XSTLI0ZY66yudmGmJZcDkLZ735Q2jjVHp5LbBwYYvWo=; b=UpO8xZzuHo4vtbTfiN2K+TSoXSCin+2JqXkt++jbzaXsaXdWIE7R95wCj+/myOK4Uc nd0/8VH4+lFuWFBQlSvp7/ltcsHxVqJbDGffESRh5P4gVMk+U6mCwAqR5dbNvl27Irmw fHv4xh5VNifsi4TbRyvmh58NgeVqD2QWqE5Og7yjwQxQyXnX1BnZV03Rej/kHD7DKzWY YN6wWriizYFk+1vtObex5LLELxRUEr+WZH/uDcJIulQc+0Y+Vukbb9HmgJWXgheFrLK4 dApngr1FDMXOCh675WWeIn8cBfwhTeQGV1eXLnvmr8J+nBb6Zy23KFgTvqAdKLFy1MJE yOYw==
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=XSTLI0ZY66yudmGmJZcDkLZ735Q2jjVHp5LbBwYYvWo=; b=Y+oz7a7J3F8EYIJycLS8R5Kz9udUoULHJ4dMHPXP292E6PDzOscK3SBR+c6F3IQvxl MhLCbdxUG2FjGLa8mVE82dat69KMDEtExq4KzrphANn9O4v5HzpMlVHV6tvB1bwmu0SX Cdt2dpU5vCXT3YpAMONyGj82gVlMhc56tO4xWgm6EjDOwcw//14JYjPHJRuK8rYBzw0D xX61wSKDxNBH8CGAMmIm8KKgrHS/Zbcqd12B7R0U8MONTBLEZ09KWWZ7ZUMCvgQa2B7h zAh/yubROlGPOS+cs1pZAWzwTea05xBIhT4KdAnpe3WNScx7QRyYfhF3TVKiZirOkZkk ntYQ==
X-Gm-Message-State: AIVw112qzOLPcvgAfBNe4ubX3Pvzk1d4UU4Gq7jVWWClk14jOu4Kg1mq 3K/9d1gLUH73IxAbDPrSCPW+D1sGLQ==
X-Received: by 10.237.63.92 with SMTP id q28mr8355802qtf.49.1501190973101; Thu, 27 Jul 2017 14:29:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.104.131 with HTTP; Thu, 27 Jul 2017 14:29:09 -0700 (PDT)
In-Reply-To: <CA+k3eCRT_iuLHYrLxz+tf1MT9L9XG2jV0D0anC0h5w7A_ujEdQ@mail.gmail.com>
References: <CA+k3eCRT_iuLHYrLxz+tf1MT9L9XG2jV0D0anC0h5w7A_ujEdQ@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Thu, 27 Jul 2017 22:29:09 +0100
Message-ID: <CAD9ie-sM-FrVxZKrNLk91Nfr8kWzZgZ6_o=yLhyOYx=GLB34fw@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: oauth <oauth@ietf.org>, "jose@ietf.org" <jose@ietf.org>
Content-Type: multipart/alternative; boundary="001a1146e496b11e36055553428c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/E36OE9N1wjf4waPsJPN7HZm8L8o>
Subject: Re: [jose] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jul 2017 21:29:37 -0000

Brian: I did not think that 'crit' processing is required in JWT
https://tools.ietf.org/html/rfc7519

We have two goals:

Preventing new JWT profiles from being confused with older JWTs, which
'typ' solves (as does your proposal of 'crit' and 'p', but requires more
bytes)

Preventing existing JWT implementations from being confused with new JWT
profiles. 'crit' can solve that for JOSE JWTs, but not other JWTs.



On Thu, Jul 27, 2017 at 7:49 PM, Brian Campbell <bcampbell@pingidentity.com>
wrote:

> During the first WG meeting last week
> <https://datatracker.ietf.org/doc/minutes-99-oauth/> 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
> <https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01#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 <https://tools.ietf.org/html/rfc7519#section-5.1> strongly suggest
> that it's not currently being used for any validation.
>
> Alternatively using the JWS/JWE "crit" (Critical) Header Parameter
> <https://tools.ietf.org/html/rfc7515#section-4.1.11> 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
>
>


-- 
Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about
projects I am working on!