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 21:00 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 0BBC11321B5 for <oauth@ietfa.amsl.com>; Thu, 27 Jul 2017 14:00:09 -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 liG__1bEx8ZI for <oauth@ietfa.amsl.com>; Thu, 27 Jul 2017 14:00:07 -0700 (PDT)
Received: from mail-it0-f48.google.com (mail-it0-f48.google.com [209.85.214.48]) (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 007F81321B1 for <oauth@ietf.org>; Thu, 27 Jul 2017 14:00:06 -0700 (PDT)
Received: by mail-it0-f48.google.com with SMTP id v205so3385958itf.1 for <oauth@ietf.org>; Thu, 27 Jul 2017 14:00:06 -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=XxgZ/BpiJRPSmPuIyBMEikiwlmKnTswyKvdgDeqRxmg=; b=fhTr/S8Wo/oW2tB6EExdfQ3cOjsy6LuabvDgnYprq1ufVjRUgf+1w6PzwwH2M6fT/W SmDn7D8G4mEWoFv3oskz+U6xMUlg+RtLgVu4OxwXV56CkGxue1D3gxNWR6fEb8HzExs0 /1ggGb1I28emWVyIVCCxyC4TstFoh7JBnVVyxyiDKfbKNzHkmS1rdlDR7eOLhX7TPGvg MWECw8rAc5TfeYRXLzasvK9E1XXJDvTv0ZCO6Es6vCgAOwFpKkJuZMAWiI666KkmDmG5 Brp49xw93vTbdT0K/IIG/AoK88cy/IMDvRLSvYL2PBlBme09xUQun3G+DpvHSRC8K+Kp WG2w==
X-Gm-Message-State: AIVw113Bxa8iNLCYc28HDZpSXV1ZWbKXILg2UNOjvISJJwC0ArPwA/1B U+oZvC/y4/erxQEtwku5TbokddByHPf5
X-Received: by 10.36.185.14 with SMTP id w14mr6837480ite.76.1501189206161; Thu, 27 Jul 2017 14:00:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.21.6 with HTTP; Thu, 27 Jul 2017 14:00:05 -0700 (PDT)
In-Reply-To: <CA+k3eCS-Va2AvzRhWia_ETqSDYUMBOoi=sY3jg7TbJFhhuVnZA@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>
From: Nathaniel McCallum <npmccallum@redhat.com>
Date: Thu, 27 Jul 2017 17:00:05 -0400
Message-ID: <CAOASepMaeS8WrCMb+WHV0FC2_w3f0KnY5XuDsuWJhAW2ayfryQ@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/wO8xGLHGO_CNsn3kcysa0HP8dFQ>
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:00:09 -0000

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.