[OAUTH-WG] Cryptographic hygiene and the limits of jwks_uri

"Richard Backman, Annabelle" <richanna@amazon.com> Wed, 08 January 2020 23:47 UTC

Return-Path: <prvs=269947d74=richanna@amazon.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B2275120142 for <oauth@ietfa.amsl.com>; Wed, 8 Jan 2020 15:47:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zpqwifKEIT2n for <oauth@ietfa.amsl.com>; Wed, 8 Jan 2020 15:47:30 -0800 (PST)
Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3F3120124 for <oauth@ietf.org>; Wed, 8 Jan 2020 15:47:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1578527251; x=1610063251; h=from:to:subject:date:message-id:mime-version; bh=DfDM2NwdDTqWdJgKDkR70LsZWnIVzEyWLhdS1ZB9oSA=; b=PsXg/bWOa0CIaq8EMzTCRTA6ahO5HJJBIuOTTnFmBd1F2ksoB09tsHKj ZC9r1VYWlOU6GAZTv5eF16wi47b0A8Emdvkj3FwsMvNi5HJoEH1hv9PVX VZ1vWcRgvLAyZZTOiHzZv+51UX4LE04t3SXCMtKXx4hjCw8G6Z+ErxAvd Q=;
IronPort-SDR: 6FWFMMeNNFJdH09ReYvAQiY0hrXcgbEw0awB5iISLGJtbibsQT+StLoFKRatqHmyM2gx53KT9y Ud7zjK2oPE7Q==
X-IronPort-AV: E=Sophos; i="5.69,411,1571702400"; d="scan'208,217"; a="17581567"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2c-168cbb73.us-west-2.amazon.com) ([]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 08 Jan 2020 23:47:19 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com []) by email-inbound-relay-2c-168cbb73.us-west-2.amazon.com (Postfix) with ESMTPS id 85205A26BF for <oauth@ietf.org>; Wed, 8 Jan 2020 23:47:18 +0000 (UTC)
Received: from EX13D11UWC003.ant.amazon.com ( by EX13MTAUWC001.ant.amazon.com ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 8 Jan 2020 23:47:17 +0000
Received: from EX13D11UWC004.ant.amazon.com ( by EX13D11UWC003.ant.amazon.com ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 8 Jan 2020 23:47:17 +0000
Received: from EX13D11UWC004.ant.amazon.com ([]) by EX13D11UWC004.ant.amazon.com ([]) with mapi id 15.00.1367.000; Wed, 8 Jan 2020 23:47:17 +0000
From: "Richard Backman, Annabelle" <richanna@amazon.com>
To: oauth <oauth@ietf.org>
Thread-Topic: Cryptographic hygiene and the limits of jwks_uri
Thread-Index: AQHVxn32ZMKwQrnvkUO4GZSyw84VLg==
Date: Wed, 08 Jan 2020 23:47:17 +0000
Message-ID: <A936D8D0-D8D7-4B58-AFF0-AE16E4C7A660@amazon.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_A936D8D0D8D74B58AFF0AE16E4C7A660amazoncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/eCZ-wUU2iwTyfx-zuqr2K3bM8-8>
Subject: [OAUTH-WG] Cryptographic hygiene and the limits of jwks_uri
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, 08 Jan 2020 23:47:33 -0000

I originally brought up this issue in the context of the PAR draft, but since it broadly applies to the OAuth space I’m starting a new thread…

Section 3.12 of the JWT BCP<https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-07#section-3.12> says: “Use different keys for different kinds of JWTs.” Section 4 of the JWT Profile for OAuth 2.0 Access Tokens<https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-03#section-4> says: “An authorization server MAY elect to use different keys to sign id_tokens and JWT access tokens.” These statements are consistent with good cryptographic hygiene. And we’ve made it difficult to impossible for an AS to follow them.

The AS has a single metadata document containing a single URI referencing a single JWK Set. But the AS has no way of indicating to clients which keys to use for which purposes. For example, an AS cannot say that *only these* keys are to be used to encrypt id_token_hint JWTs, and *only these* keys are to be used to encrypt JAR request object JWTs. For encryption, the AS could enforce that logic internally, but there is no way for the client to discover this. And while the AS may be built to only use certain keys for signing ID Tokens and other keys for signing JWT access tokens, it has no way to indicate this to the client. So even if ID Token generation and access token generation are isolated in different microservices within the AS, each microservice is capable of forging the other’s tokens, because consumers can’t be told to distinguish between different keys for the AS.

This seems like a ticking time bomb to me, as it’s a non-obvious side effect of combining various OAuth 2.0 extensions, and it can undermine a lot of sophisticated effort to follow security best practices. I can see a couple of ways to address this (e.g., more sophisticated AS key metadata, tagging or similar use case indication on JWKs), but before trying to propose something I’d like to get people’s opinions on the problem. Is this already mitigated in other ways? Has the ship sailed on this for OAuth, and now we have to live with it? Should this be left to the deployments that care to solve with non-interoperable solutions? Are there other clever ways we could approach this? Are there other angles that we need to consider?

Annabelle Richard Backman
AWS Identity