Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

"Richard Backman, Annabelle" <richanna@amazon.com> Tue, 14 January 2020 21:18 UTC

Return-Path: <prvs=275f11436=richanna@amazon.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 B27FD120110 for <oauth@ietfa.amsl.com>; Tue, 14 Jan 2020 13:18:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.498
X-Spam-Level:
X-Spam-Status: No, score=-14.498 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_FONT_LOW_CONTRAST=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD7ri8gx8ZsG for <oauth@ietfa.amsl.com>; Tue, 14 Jan 2020 13:17:59 -0800 (PST)
Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (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 D77F3120889 for <oauth@ietf.org>; Tue, 14 Jan 2020 13:17:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1579036680; x=1610572680; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KncKTotEdR1OK7MN/V/P537yJ5LBTGZQo2zPYX6OKfM=; b=NHoJdenDPf9woNargIONKbC3v3g340snJtpmlFfcUeBGd8s3p2tZf/pS rds03TpBHwrC50E6Oc3uYq0Cp1GLqj+b6vPWDycM8mnijcTkntX0qfRXC b0Zwrn7W6Ikkn5HF6bsucynDBXqBKdnj1fNGSh6O4/d46Wd4iXtD26SzN k=;
IronPort-SDR: E7tc9N3/xFZjzjG5JL2rBovSZLBCRwcxETCEvDDddjPy8BuQ2S1UVFrOV6TM8nkXaDJjClUav6 aWTr0kuDfG8w==
X-IronPort-AV: E=Sophos; i="5.70,320,1574121600"; d="scan'208,217"; a="10322954"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2c-6f38efd9.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 14 Jan 2020 21:17:49 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2c-6f38efd9.us-west-2.amazon.com (Postfix) with ESMTPS id 504BFA11D3; Tue, 14 Jan 2020 21:17:48 +0000 (UTC)
Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 14 Jan 2020 21:17:47 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 14 Jan 2020 21:17:47 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Tue, 14 Jan 2020 21:17:47 +0000
From: "Richard Backman, Annabelle" <richanna@amazon.com>
To: Aaron Parecki <aaron@parecki.com>, Justin Richer <jricher@mit.edu>
CC: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>, oauth <oauth@ietf.org>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
Thread-Topic: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
Thread-Index: AQHVyoPR7PL9YO5H+k2gS2IKzXqhA6fqJP+A
Date: Tue, 14 Jan 2020 21:17:47 +0000
Message-ID: <A5B3B188-89D8-45B7-8CEB-A68B907B931C@amazon.com>
References: <CAD9ie-vRsL9ey2LDNoaWkapRUewS_c1S0r3QCcqJLmJ5KqKsGw@mail.gmail.com> <5F7A3816-AC9B-4BA2-9D91-CF89109B6788@forgerock.com> <CAD9ie-uebUCw5vxELPXQvQSY3Z3T2dNJGOpzEQ8cMgZcCOu+tg@mail.gmail.com> <79DF80DA-6682-4F25-A02A-B4137053FD8A@mit.edu> <CAGBSGjq9QWLR1n5sjE_rSyGmK_fqzgiSgyRhHZO_DhriHhgKjg@mail.gmail.com>
In-Reply-To: <CAGBSGjq9QWLR1n5sjE_rSyGmK_fqzgiSgyRhHZO_DhriHhgKjg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.161.253]
Content-Type: multipart/alternative; boundary="_000_A5B3B18889D845B78CEBA68B907B931Camazoncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/n7NQLZjAcAPRO6vm9sbVyb0C3rA>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: 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: Tue, 14 Jan 2020 21:18:02 -0000

The kid used by a service will change when it rotates keys (this is the main value of JWK Sets IMHO), so kid cannot be used as part of static metadata. You’d need to introduce a new field so you can assign a “logical key” identifier that remains the same across key rotations/versions.

There are several issues with trying to address this by augmenting JWK though:

  *   Existing deployments will ignore the logical key identifier, so there is no way to keep those keys from being used to sign fraudulent ID Tokens (for example).
  *   The JWK set becomes a shared resource that spans trust boundaries.

A solution based on separate jwks_uri metadata parameters solves both of these problems, and requires very little effort for ASes that don’t have this concern.

–
Annabelle Richard Backman
AWS Identity


From: OAuth <oauth-bounces@ietf.org> on behalf of Aaron Parecki <aaron@parecki.com>
Date: Monday, January 13, 2020 at 6:39 PM
To: Justin Richer <jricher@mit.edu>
Cc: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>rg>, oauth <oauth@ietf.org>rg>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

Right now, Okta publishes two keys at the jwks_uri in order to be able to rotate keys periodically. During the token lifetime window during key rotation, the RSs can still find both the old and new key IDs in the set.

RSs are looking for a specific key ID when they do this, so it would be fine to include additional keys that are used for something other than access tokens since the RSs would just ignore them.

So an extension could say "use this key identified by kid" and that'd be a decent extension mechanism.



On Mon, Jan 13, 2020 at 6:26 PM Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>> wrote:
I would rather see extensions define a key ID than a new key set URI. Otherwise what’s the point of having more than one key in the set, with unique identifiers?

It would’ve been nice if JWK could’ve agreed on a URL-based addressing format for individual keys within the set, but that ship’s sailed.


 — Justin


On Jan 10, 2020, at 9:34 PM, Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:

I was not saying that there was anything special about keys, nor that we needed to change OAuth.

While using one key and controlling where it us used via access control works, it is not ideal.

OAuth could have had just one endpoint, and done access control for different roles -- but it did not. We enabled flexibility by separating the authorization endpoint and the token endpoint. The dynamic client registration extension defined a new endpoint, the registration endpoint.

I don't think we can change what has been deployed today -- but NEW extensions that use keys for new purposes SHOULD define their own URI.
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=40ee9f20-bfaf-4f2d-8905-6e0ad8b28481]ᐧ

On Fri, Jan 10, 2020 at 11:31 AM Neil Madden <neil.madden@forgerock.com<mailto:neil.madden@forgerock.com>> wrote:
Sure, but we know how to run resilient services. My point is that there’s nothing particularly special about cryptographic keys: if you want to control how they are used there is a whole range of normal access control methods you can apply to them without needing to change anything in OAuth.

Neil


On 10 Jan 2020, at 18:50, Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:
There are many other factors to resiliency than multiple instances.

On Fri, Jan 10, 2020 at 10:30 AM Neil Madden <neil.madden@forgerock.com<mailto:neil.madden@forgerock.com>> wrote:


> On 10 Jan 2020, at 17:22, Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:
[...]
>
> As to the suggestion of using a JWT-decryption-microservice, another goal would be increased resiliency of the components. If the JWT-decryption-microservice is unavailable, the whole system is unavailable. If there are separate keys, then a failure in one component does not fail the entire system.

Well you can run more than one instance - it’s a completely stateless service. You can also run a separate instance (or set of instances) per key if you like.

Neil

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
----
Aaron Parecki
aaronparecki.com<http://aaronparecki.com>
@aaronpk<http://twitter.com/aaronpk>