Return-Path: 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 13CCE120132 for ; Fri, 10 Jan 2020 07:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.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 aPT2164fjgNO for ; Fri, 10 Jan 2020 07:51:09 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 4CBF1120900 for ; Fri, 10 Jan 2020 07:50:53 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id w15so2286695wru.4 for ; Fri, 10 Jan 2020 07:50:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CFNnyfzrJDgO6oYhw6+B9Mi1+8FPJ5+KJMjjGo4dA+A=; b=Jx9bUs1t3KSRAOqNu34hYKlmkJZOTwkc08Um+LSDL79j0BUaA5B3ix9lDH8me+gmqx sQM8dYa+DvyFGWF/2/5+uLWJxpuicKNXu0rlkMjAeGCKVhKTdu4a/siLKyEjSYFKX7cX XebxBrgBwQ0Gya9Vq83S2ZFWH8qLwhm9sXS+c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CFNnyfzrJDgO6oYhw6+B9Mi1+8FPJ5+KJMjjGo4dA+A=; b=EIiSOfwsPTnR1ANtHIPGEsGZmXSlAJTCago0Q1/0LPkf97uwoIiUPdp9K1S8SJ+KDA Y4AofD5HTHhJ9f+TgE5Zslb4ilaAQbykZiAtfeVllPfy59vQnQdfo/AZI6aGe903iz9c hWhgXL03pBTF+Gm6qQ5mTPvmaSxY5PJ1FiaJYIpzvrCzQem5w1VWtfV7L1RfeEYjynts c+SFDJ12UGg8sXF+klKuGFAJtel++XtcZogkLZTEhVZ0f9Qg+taPUSfaD67dFI0us9Ey WfEl6BlYih8hSBA2h9jLK3//U22GVsROc2Gfp48fvJXYXnp9UG9g8kgck3Y1JlPLcWnx HZxA== X-Gm-Message-State: APjAAAUokL7CAnrZXnSLABCzEfHMH2WCrWGc+kxONrLKeCgui9S8bh9d qL1lqVBHMu2cONxi5N7tsaIq/UvxC8k67g== X-Google-Smtp-Source: APXvYqyKI7P/f4z2q2QPBQTwzpPWMggQ0UPxtdfQzilBEaSxsXE//+izAelWLXiBH+2uDJ5ifIojKw== X-Received: by 2002:a05:6000:12ce:: with SMTP id l14mr4502888wrx.342.1578671451563; Fri, 10 Jan 2020 07:50:51 -0800 (PST) Received: from [192.168.1.64] (74.61.147.147.dyn.plus.net. [147.147.61.74]) by smtp.gmail.com with ESMTPSA id a5sm2633243wmb.37.2020.01.10.07.50.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jan 2020 07:50:50 -0800 (PST) From: Neil Madden Message-Id: <84329089-E065-421D-AD93-439C6D7E3F44@forgerock.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1895FB97-5573-463B-AC3D-C246089B3D01" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Fri, 10 Jan 2020 15:50:48 +0000 In-Reply-To: Cc: Mike Jones , oauth To: "Richard Backman, Annabelle" References: X-Mailer: Apple Mail (2.3601.0.10) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 15:51:14 -0000 --Apple-Mail=_1895FB97-5573-463B-AC3D-C246089B3D01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is an interesting point. I think OAuth has historically assumed that the AS is a monolithic = system, or at least can be treated like one by clients. I think we might = have to revisit quite a lot if we drop this assumption and adopt a = threat model in which the AS is itself composed of a collection of = mutually distrusting entities. Especially as different ASes might decide = to divide up the trust boundaries in different ways. At least partially this feels like an internal implementation detail of = the AS that can also be solved internally to that AS. For example, = rather than providing microservices direct access to private keys you = could implement a JWT-decryption-microservice that other microservices = call. It can then check if the calling microservice is allowed to = decrypt that type of JWT before returning the response (e.g., by = checking the "typ" header). The same can be done for signing JWTs. Of = course, that's not a perfect solution, but it illustrates that we don't = necessarily need to solve these problems in the WG. If we go down the path of separate keys, then it might be simpler to = introduce new metadata elements to list the kids of valid key ids for a = given purpose rather than having multiple JWK Set endpoints. e.g. = "id_token_hint_encryption_kids": ["rsa-key-1", "ec-key-2"]. That avoids = the client having to fetch multiple sets of keys. -- Neil > On 10 Jan 2020, at 00:25, Richard Backman, Annabelle = wrote: >=20 > The =E2=80=9Ctyp=E2=80=9D field helps prevent misrepresentation of a = legitimately issued JWT, but it doesn=E2=80=99t 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. > =20 > 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. > =20 > Note that while =E2=80=9Ctyp=E2=80=9D 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. > =20 > The case for this being a concern on the encryption side is fuzzier, = primarily because we simply don=E2=80=99t 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 = ,= where a PAR endpoint that decrypts request object JWTs will also be = able to decrypt id_token_hint JWTs. > =20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: Mike Jones > > Date: Thursday, January 9, 2020 at 11:34 AM > To: "Richard Backman, Annabelle" >, oauth > > Subject: [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits = of jwks_uri > =20 > This a good thing to think about. Thanks for bringing this up, = Annabelle. > =20 > One thing that partially mitigates this is that the =E2=80=9Cuse=E2=80=9D= and/or =E2=80=9Ckey_ops=E2=80=9D attributes can be provided. This can = allow signing keys to be differentiated from encryption keys, for = instance. > =20 > I=E2=80=99m 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. > =20 > One mitigation for signing keys is use of the =E2=80=9Ctyp=E2=80=9D = 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. > =20 > I believe there=E2=80=99s also cases where it=E2=80=99s 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.) > =20 > Which I believe leaves us with this case to worry about =E2=80=93 = shared signing keys by unrelated applications when =E2=80=9Ctyp=E2=80=9D = is not used. One way to mitigate this would be to use per-application = key sets. For instance, using values other than =E2=80=9Cjwks_uri=E2=80=9D= to reference key sets for particular applications. > =20 > Anyway, for PAR, I believe that it=E2=80=99s fine to use the same keys = as used for Request Objects, so no new fields are needed for it. > =20 > I look forward to further discussion on the topic. > =20 > -- Mike > =20 > From: OAuth > = On Behalf Of Richard Backman, Annabelle > Sent: Wednesday, January 8, 2020 3:47 PM > To: oauth > > Subject: [OAUTH-WG] Cryptographic hygiene and the limits of jwks_uri > =20 > I originally brought up this issue in the context of the PAR draft, = but since it broadly applies to the OAuth space I=E2=80=99m starting a = new thread=E2=80=A6 > =20 > Section 3.12 of the JWT BCP = says: =E2=80=9C= Use different keys for different kinds of JWTs.=E2=80=9D Section 4 of = the JWT Profile for OAuth 2.0 Access Tokens = says: =E2=80=9C= An authorization server MAY elect to use different keys to sign = id_tokens and JWT access tokens.=E2=80=9D These statements are = consistent with good cryptographic hygiene. And we=E2=80=99ve made it = difficult to impossible for an AS to follow them. > =20 > 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=E2=80=99s tokens, because consumers can=E2=80=99t be = told to distinguish between different keys for the AS. > =20 > This seems like a ticking time bomb to me, as it=E2=80=99s 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=E2=80=99d like to get = people=E2=80=99s 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? > =20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_1895FB97-5573-463B-AC3D-C246089B3D01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
This is an interesting point.

I think OAuth has historically assumed = that the AS is a monolithic system, or at least can be treated like one = by clients. I think we might have to revisit quite a lot if we drop this = assumption and adopt a threat model in which the AS is itself composed = of a collection of mutually distrusting entities. Especially as = different ASes might decide to divide up the trust boundaries in = different ways.

At least partially this feels like an internal implementation = detail of the AS that can also be solved internally to that AS. For = example, rather than providing microservices direct access to private = keys you could implement a JWT-decryption-microservice that other = microservices call. It can then check if the calling microservice is = allowed to decrypt that type of JWT before returning the response (e.g., = by checking the "typ" header). The same can be done for signing JWTs. Of = course, that's not a perfect solution, but it illustrates that we don't = necessarily need to solve these problems in the WG.

If we go down the path = of separate keys, then it might be simpler to introduce new metadata = elements to list the kids of valid key ids for a given purpose rather = than having multiple JWK Set endpoints. e.g. = "id_token_hint_encryption_kids": ["rsa-key-1", "ec-key-2"]. That avoids = the client having to fetch multiple sets of keys.
-- Neil

On 10 Jan 2020, at 00:25, Richard Backman, = Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> = wrote:

The =E2=80=9Ctyp=E2=80=9D field = helps prevent misrepresentation of a legitimately issued JWT, but it = doesn=E2=80=99t 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 = =E2=80=9Ctyp=E2=80=9D 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=E2=80=99t 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, where a PAR endpoint that = decrypts request object JWTs will also be able to decrypt id_token_hint = JWTs.
 
=E2=80=93 
Annabelle Richard Backman
AWS = Identity
 
 
From: Mike Jones <Michael.Jones=3D40microsoft.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 =E2=80=9Cuse=E2=80=9D and/or =E2=80=9Ckey_ops=E2=80=9D = attributes can be provided.  This can allow signing keys to be = differentiated from encryption keys, for instance.
 
I=E2=80=99m 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 =E2=80=9Ctyp=E2=80= =9D 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=E2=80=99s also cases where it=E2=80=99s 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 =E2=80=93= shared signing keys by unrelated applications when =E2=80=9Ctyp=E2=80=9D = is not used.  One way to mitigate this would be to use = per-application key sets.  For instance, using values other than = =E2=80=9Cjwks_uri=E2=80=9D to reference key sets for particular = applications.
 
Anyway, for PAR, I believe that it=E2=80=99s 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.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- 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=E2=80=99m starting a new = thread=E2=80=A6
 
Section= 3.12 of the JWT BCP says: =E2=80=9CUse = different keys for different kinds of JWTs.=E2=80=9D Section 4 of the JWT Profile for OAuth 2.0 Access = Tokenssays: =E2=80=9CAn authorization server MAY elect to use = different keys to sign id_tokens and JWT access tokens.=E2=80=9D These = statements are consistent with good cryptographic hygiene. And we=E2=80=99= 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=E2=80=99s tokens, because consumers can=E2=80=99t be = told to distinguish between different keys for the AS.
 
This seems like a ticking time = bomb to me, as it=E2=80=99s 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=E2=80=99d like to get people=E2=80=99s = 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?
 
=E2=80=93 
Annabelle Richard Backman
AWS = Identity
 
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_1895FB97-5573-463B-AC3D-C246089B3D01--