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

Dick Hardt <dick.hardt@gmail.com> Fri, 10 January 2020 01:26 UTC

Return-Path: <dick.hardt@gmail.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 53FA5120808 for <oauth@ietfa.amsl.com>; Thu, 9 Jan 2020 17:26:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 B2E98em-4zhZ for <oauth@ietfa.amsl.com>; Thu, 9 Jan 2020 17:26:01 -0800 (PST)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 9D585120288 for <oauth@ietf.org>; Thu, 9 Jan 2020 17:26:00 -0800 (PST)
Received: by mail-lj1-x233.google.com with SMTP id o13so376751ljg.4 for <oauth@ietf.org>; Thu, 09 Jan 2020 17:26:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=shmL5Vs7jTOCZWkX+nvbpyFUA+C+V1kdJnbxjezbrEs=; b=A30qpRwtRh3SYeN08YXzqymqSkqSwdILYWx/18LxK0Q7q7qkmLrp6qd3nlHx0+Jfh0 l4IiAVzSvMAeL841sOCxeOZ4IywTqy53oYAKg7Jj9YeNrengNTNn6kLQOSdpapaC+lR5 6b/mF4vQUpE5/5FrEYGksI3h7cBHmuczeARdWLa/+JXXYRqyl/UFjMyqpMz7Sotj860S smSCD0NBc9sM3Efm5hMNl7d3dVl/ctq+J6RNZlwdeDof+elJ4atlzfEXwlMjKA96hr06 vjks5h98sAazuFK6yY79KN/4ANjSfzSX6hSo0GinaJQ6DOha2uD8ZPZPTTUzF1odsJcy Vunw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=shmL5Vs7jTOCZWkX+nvbpyFUA+C+V1kdJnbxjezbrEs=; b=bDClXE/kdRVa4CZb638W9AstT69bSj+M2fpwJ7Qrg2vaML+u62e+JjuoUlACSeb+Bv 0S0bG8Aq50ZRDjOthj1KMM1xzVfLgWhMxtEM3O2mHiv1IGmSRs9CaXzFGz0QWNz2aQa1 fAhD+mPZOQnm3qngQOUI2Nat/ZHh/yjOdtF//7iFWzalgu/b6U8O0SXiI8hVojdOv63B wot0N0tp7fU1r/lq8ivMx+RaQSQb8R/oOMj25Twj4dEpsb0sVqnL0zQ48mVo+PpDdxya 8joD+6+s3+ALYvEzbYBQO/C0myJImGb/1iNI1+4APqJlWFK7rOOTMArj4DKXjy3v73jQ KHjA==
X-Gm-Message-State: APjAAAUW/Wqy/YF4gBm9u4fNYYwumQ3ksR61DWnkJ99bSEbrDnvadKAA lYtpKtenjYnv+Suks+fVBq/6SQP953F54kSvVGtZrO0M
X-Google-Smtp-Source: APXvYqx/H9dfw5kbBlTvLX81WUHktvPmg9crJy0dheyj5v1RjrnEsCci3hSxHtOGaUNPuKmeynrukTEP8H+dqZWd4yo=
X-Received: by 2002:a05:651c:204f:: with SMTP id t15mr637685ljo.240.1578619558724; Thu, 09 Jan 2020 17:25:58 -0800 (PST)
MIME-Version: 1.0
References: <CDAB3728-0FB0-49A5-9A6C-6F3794A6E1DB@amazon.com>
In-Reply-To: <CDAB3728-0FB0-49A5-9A6C-6F3794A6E1DB@amazon.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Thu, 09 Jan 2020 17:25:47 -0800
Message-ID: <CAD9ie-sVAc+D=k2TViSYs54jqtR4XboqirMG-d6B09o297Ge=A@mail.gmail.com>
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000088a0a059bbf02e2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/6qjzupOy3wsGKXMdPxewIu4ws2Y>
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: Fri, 10 Jan 2020 01:26:04 -0000

+1 to Annabelle's point

Different crypto operations should be able to use separate key pairs to
allow a separation of duties.
ᐧ

On Thu, Jan 9, 2020 at 4:25 PM Richard Backman, Annabelle <richanna=
40amazon.com@dmarc.ietf.org> wrote:

> The “typ” field helps prevent misrepresentation of a legitimately issued
> JWT, but it doesn’t address the issue I am trying to draw attention to,
> which is that the current model forces broader distribution and reuse of
> keys than is necessary, resulting in a greater blast radius for compromised
> keys or systems.
>
>
>
> For many cases, this is not a significant concern, as the AS is a
> monolithic system with no internal trust boundaries. However, in cases
> where the AS is composed of multiple microservices performing different
> tasks, the need to share keys between different microservices undermines
> efforts to create trust boundaries between them. I gave one example of this
> in my original email, where ID Token generation and access token generation
> are relegated to independent systems, each with separate private keys for
> signing tokens. Suppose a malicious party compromised the ID Token
> generator, or gained access to its private key, and issued fraudulent
> access tokens signed using that key. Since verifiers of both token types
> will look to the same metadata file and thus the same JWK set, they have no
> way to recognize that these access tokens are fraudulent.
>
>
>
> Note that while “typ” would help a verifier distinguish between an ID
> Token and an access token, it does not help in this case because the
> malicious party is generating well-formed access token JWTs, signed with a
> key that is legitimate for the AS but not for this purpose.
>
>
>
> The case for this being a concern on the encryption side is fuzzier,
> primarily because we simply don’t have many use cases where different kinds
> of content gets encrypted and sent to the AS in different contexts.
> However, I gave one example on the PAR thread
> <https://mailarchive.ietf.org/arch/msg/oauth/iVXk3EusmV4Bh9-r58bebgZ6888>,
> where a PAR endpoint that decrypts request object JWTs will also be able to
> decrypt id_token_hint JWTs.
>
>
>
> –
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
> *Date: *Thursday, January 9, 2020 at 11:34 AM
> *To: *"Richard Backman, Annabelle" <richanna@amazon.com>, oauth <
> oauth@ietf.org>
> *Subject: *[UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits
> of jwks_uri
>
>
>
> This a good thing to think about.  Thanks for bringing this up, Annabelle.
>
>
>
> One thing that partially mitigates this is that the “use” and/or “key_ops”
> attributes can be provided.  This can allow signing keys to be
> differentiated from encryption keys, for instance.
>
>
>
> I’m not as worried about encryption keys as signing keys.  If multiple
> kinds of applications encrypt content to a party using the same public
> per-party key, and the encryption is being used only to ensure
> confidentiality of the messages, the confidentiality is still achieved.
>
>
>
> One mitigation for signing keys is use of the “typ” field, as described in
> the JWT BCP.  Even if the same key was used and you receive an unexpected
> JWT type, you will still reject it.
>
>
>
> I believe there’s also cases where it’s fine to use the same signing key
> for related operations.  For instance, signing a Pushed Authorization
> Request and a Request Object with the same key seems both logical and safe
> to me.  (If others can think of an attack that this enables, however,
> please do point it out.)
>
>
>
> Which I believe leaves us with this case to worry about – shared signing
> keys by unrelated applications when “typ” is not used.  One way to mitigate
> this would be to use per-application key sets.  For instance, using values
> other than “jwks_uri” to reference key sets for particular applications.
>
>
>
> Anyway, for PAR, I believe that it’s fine to use the same keys as used for
> Request Objects, so no new fields are needed for it.
>
>
>
> I look forward to further discussion on the topic.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* OAuth <oauth-bounces@ietf.org> *On Behalf Of *Richard Backman,
> Annabelle
> *Sent:* Wednesday, January 8, 2020 3:47 PM
> *To:* oauth <oauth@ietf.org>
> *Subject:* [OAUTH-WG] Cryptographic hygiene and the limits of jwks_uri
>
>
>
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-jwt-bcp-07%23section-3.12&data=02%7C01%7CMichael.Jones%40microsoft.com%7C73d547c7681f4ea59a4808d7949529e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637141240697295445&sdata=AeQLxCao2ZT661ZK2fE4a6QKyh8IzO%2Bq%2Fqzbt7Vld0s%3D&reserved=0>
> says: “Use different keys for different kinds of JWTs.” Section 4 of the
> JWT Profile for OAuth 2.0 Access Tokens
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-access-token-jwt-03%23section-4&data=02%7C01%7CMichael.Jones%40microsoft.com%7C73d547c7681f4ea59a4808d7949529e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637141240697305402&sdata=ISszTxlHTbALInjK%2FKggH9seZdW8kGXTDHZEWCyfAzc%3D&reserved=0>
> 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
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>