Re: [OAUTH-WG] Martin Duke's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)

Vittorio Bertocci <vittorio.bertocci@auth0.com> Wed, 14 April 2021 07:19 UTC

Return-Path: <vittorio.bertocci@auth0.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 9EC843A117B for <oauth@ietfa.amsl.com>; Wed, 14 Apr 2021 00:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.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 3Ol9v5na_6eJ for <oauth@ietfa.amsl.com>; Wed, 14 Apr 2021 00:19:01 -0700 (PDT)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 DAF6C3A112D for <oauth@ietf.org>; Wed, 14 Apr 2021 00:18:59 -0700 (PDT)
Received: by mail-pg1-x52c.google.com with SMTP id f29so13768194pgm.8 for <oauth@ietf.org>; Wed, 14 Apr 2021 00:18:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=ANNjAhCero6/eXOu5c3OKP1TscT0UFy/7v9SNgS32BE=; b=KTjQzofm54wnd+Lll3ciK57gjhTNR6gayog7Jo2wqo8+2B0ZuTnkQNLAmzGq9Nxgee GXMrIqYnepOe7AZMkJMND+gODC5dUZgiAv9s4yDV3u/bhVEKU9MN6HKohXcNWM/j7FG0 P5MJUQpcK9RdboUyLkAlhRa4ZwmQyUPdqWXiwAN9AsV0I9SCn37h3hOnOeLN3189Dh0u l/hPeTVJfkfgLjD9muv87I4Ovb+Ke5fRh+P4TxLiAGZrih+4UlbFpgRNOIKyKvZ1vb3N A/2CZNjW8Tgq3ZqFrQJ5OZ8PWS23u3iQCXYRBo6IbmF+A4Q488OSNkZ+quGWLvsdF8M5 4Oqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=ANNjAhCero6/eXOu5c3OKP1TscT0UFy/7v9SNgS32BE=; b=EvyoDEVWSZuXY+RFPzdp4pg1kRkIfDuhEHkb3q58dkMlcPPTaY76c+CKyJi/ndhvgT xamFsN+RWtZJZ2V5vBxn12C3TAdNLxNH2whAVQoPGtYS8rEjGAB/wvFk1O5YwfR9DJwT z6MtYuJZINjRgBea9lQIJj9QWAxo8DYebH/t4ulK6t6x562Z0WZ753PRMw/s3ztYqTOE knlS/TVDHYPsOe3D+KZnIoxHnKme9Kr4Un+rBeXKUqo/W+Wq2mv8tIZo0fp/tUukZ9Nr C/wQEQLEj1gpmP8zzAND3S25XdXMm7e5iD4pRfQ8NcTl9NVrb6dAku3dnfbob0XP75Yi mvXQ==
X-Gm-Message-State: AOAM531rFQM4Ib8ubq0oddNF+YujBeKSnuO5A6w6JKlh5zwOeenXxMrt 7ChWSqyGhqjsBo1p4Q1A0IjQuHvuW5nXNw==
X-Google-Smtp-Source: ABdhPJwfBbY11Wx+K7Kgidb3osqh49ckvQ8+2JnazUMzsF1PHndBur6amABghCd/BdKZUAyIZHn6Hw==
X-Received: by 2002:a63:3047:: with SMTP id w68mr16950728pgw.94.1618384738622; Wed, 14 Apr 2021 00:18:58 -0700 (PDT)
Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id a81sm13806730pfa.165.2021.04.14.00.18.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Apr 2021 00:18:58 -0700 (PDT)
From: Vittorio Bertocci <vittorio.bertocci@auth0.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Martin Duke <martin.h.duke@gmail.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-oauth-access-token-jwt@ietf.org" <draft-ietf-oauth-access-token-jwt@ietf.org>, "oauth-chairs@ietf.org" <oauth-chairs@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Martin Duke's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)
Thread-Index: ATExMzg3VOGotTUf2QrPIgQODNbq7TM3Mzk0ymXc04s=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Wed, 14 Apr 2021 07:18:57 +0000
Message-ID: <CO6PR18MB4052778DC903C25D3B38D230AE4E9@CO6PR18MB4052.namprd18.prod.outlook.com>
References: <161730912872.14258.15710315415917535021@ietfa.amsl.com> <20210408191223.GT79563@kduck.mit.edu>
In-Reply-To: <20210408191223.GT79563@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/JPS0gFfGIbZoAnMfTSJwbnNT8jo>
Subject: Re: [OAUTH-WG] Martin Duke's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 14 Apr 2021 07:19:09 -0000

Thanks Martin for the comments and Benjamin for addressing some of them!
Comments on the remaining ones:

    > (2.1) "...can use any signing algorithm." I presume there ought to be some
    > qualifiers on allowed algorithms?
The algorithms referred to here are the ones defined by the usual JWT/JWS, as in JWA (RFC7518). The reader should be able to get it from the context without ambiguity.

    > (4) I presume it's important that any resouree server rejection of the token
    > should be constant-time. Is this somewhere in the RFC tree, or do we need to
    > explicitly say it here and/or in Security Considerations?
I am thinking of analogous descriptions in other specs and I don’t recall mentions of that aspect, hence I assumed we didn’t have to specify it here either. In particular, I glanced thru RFC6750  section 3, which this spec specializes for the specific JWT AT scenario, and they don’t mention that either.

On 4/8/21, 12:12, "Benjamin Kaduk" <kaduk@mit.edu> wrote:

    On Thu, Apr 01, 2021 at 01:32:08PM -0700, Martin Duke via Datatracker wrote:
    > Martin Duke has entered the following ballot position for
    > draft-ietf-oauth-access-token-jwt-12: No Objection
    > 
    > When responding, please keep the subject line intact and reply to all
    > email addresses included in the To and CC lines. (Feel free to cut this
    > introductory paragraph, however.)
    > 
    > 
    > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    > for more information about IESG DISCUSS and COMMENT positions.
    > 
    > 
    > The document, along with other ballot positions, can be found here:
    > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/
    > 
    > 
    > 
    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------
    > 
    > (2.1) "...can use any signing algorithm." I presume there ought to be some
    > qualifiers on allowed algorithms?
    > 
    > (4) and (5) "This specification
    >    does not provide a mechanism for identifying a specific key as the
    >    one used to sign JWT access tokens."
    > 
    > I don't understand; there's a key ID right there in the token header?
    
    The concern here is about identifying keys authorized to sign JWS access
    tokens.  The server-provided metadata that lists such keys has a single
    bucket that covers keys used for signing different things, so you don't get
    any security benefit from key isolation, and a compromise of any of the
    (other) keys listed by the server would allow the attacker to sign JWT
    access tokens that are accepted as valid.
    
    So in a sense this is not about which key was actually used, but rather
    which key is supposed to be used.
    
    > (4) I presume it's important that any resouree server rejection of the token
    > should be constant-time. Is this somewhere in the RFC tree, or do we need to
    > explicitly say it here and/or in Security Considerations?
    
    (A good question, but I don't actually have the answer handy in memory.)
    
    -Ben