Subject: [jose] JOSE dependence on "Key Guessing"

From: Anders Rundgren <[email-masked]>
Date: Wed, 7 Feb 2018 07:03:28 +0100

Dear list,

Believe or not but there is a new multi-party IETF effort in the workings for dealing with "clear text" versions of JWS and JWE.  Our BOF request was though turned down due to lack of published drafts and "customers" so issues will have to go through the mailing list only.

The goal is reusing as much as possible of the existing specifications, essentially limiting the work to repackaging.

However, it turned out that I wasn't fully up-to-date on the JOSE concept "Key Guessing":
https://tools.ietf.org/html/rfc7515#appendix-D

As far I can tell they only way you would ever need to do "Key Guessing" as described in appendix-D is if you have a scheme where the sender doesn't inform the receiver which key it actually used which sounds like a poor idea as well as highly unlikely to be used anywhere in practice.

Therefore I didn't bother too much with that until I had implemented support for JKU where the sender supplies a URL to a set of keys for the receiver to try out.  That is, "Key Guessing" is not only a possibility, it is an intrinsic part of the JOSE specifications.

So the question simply boils down to: Should derived standards-to-be, inherit obvious design flaws as well? IMO, they should not.  JKU could be redefined to point to a single JWK, removing the need for "Key Guessing" altogether.  Yes, there are "workarounds" like requiring additional key identification properties...

thanx,
Anders

---

From: Mike Jones <[email-masked]>
Date: Wed, 7 Feb 2018 06:22:35 +0000

Anders, you misunderstand the feature and its purpose.  The ability to reference a set of keys is essential to performing key roll-over - a critical security function.  The "kid" (key ID) value is typically used to indicate which member of the key set was employed.  There is no "key guessing".

For an example of how JWK sets are used for key roll-over in a production system, see http://openid.net/specs/openid-connect-core-1_0.html#Signing.

				-- Mike

-----Original Message-----
From: jose <[email-masked]> On Behalf Of Anders Rundgren
Sent: Tuesday, February 6, 2018 10:03 PM
To: [email-masked]
Subject: [jose] JOSE dependence on "Key Guessing"

Dear list,

thanx,
Anders

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 7 Feb 2018 08:18:50 +0100

> For an example of how JWK sets are used for key roll-over in a production system, see http://openid.net/specs/openid-connect-core-1_0.html#Signing.

    "If there are multiple keys in the referenced JWK Set document,
     a kid value MUST be provided in the JOSE Header"

This is what I was referring to. JKU as a standalone property is useless unless the set of keys is restricted to 1.

This is not mentioned in the JOSE specifications but fundamental for interoperabiity and testing.
The OpenID scheme does not only presume that there's an additional "kid" in the header, but that the referred key set also contains matching "kid"s.

Maybe the "right" solution is providing an interoperability section with a reference to JKU as well?

My (strong) wish is getting away from any kind of key guessing as a part of a test suite and reference implementation.  Yes, the are indeed JOSE implementations that support key guessing.

BTW, the spec you are referring to doesn't appear to actually use JKU:

    "ID Tokens SHOULD NOT use the JWS or JWE x5u, x5c, jku, or jwk Header Parameter fields.
     Instead, references to keys used are communicated in advance using
     Discovery and Registration parameters, per Section 10"

Anders

---

From: Neil Madden <[email-masked]>
Date: Wed, 7 Feb 2018 08:06:59 +0000

>> On 7 Feb 2018, at 07:18, Anders Rundgren <[email-masked]> wrote:
>> 

Can you clarify why? You can just try each applicable key. 

> My (strong) wish is getting away from any kind of key guessing as a part of a test suite and reference implementation.  Yes, the are indeed JOSE implementations that support key guessing.

Remember that the “kid” parameter is only integrity protected by the same signature that you are verifying so it should only be a hint. If an attacker can forge a signature for any key in the set then they can almost certainly also forge a kid value to go with it.

A bigger problem with “jku” would be the potential for SSRF (https://cwe.mitre.org/data/definitions/918.html) and similar attacks based on getting the server to access arbitrary URLs before it has validated the signature. 

— Neil

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 7 Feb 2018 10:44:11 +0100

On 2018-02-07 09:06, Neil Madden wrote:
> 
> On 7 Feb 2018, at 07:18, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
> 

This is what the posting referred to as "Key Guessing" which I consider an invalid concept.  That the OpenID folks do not utilize this either indirectly supports this stance.

> Remember that the “kid” parameter is only integrity protected by the same signature that you are verifying so it should only be a hint. If an attacker can forge a signature for any key in the set t…

If an attacker has access to the genuine user's private keys it is usually game over.

> A bigger problem with “jku” would be the potential for SSRF (https://cwe.mitre.org/data/definitions/918.html) and similar attacks based on getting the server to access arbitrary URLs before it has…

My reference implementation barfs at URLs that:
- Do not use the "https://" scheme
- Do not return HTTP 200
- Do not point to trusted servers
- Do not return properly formatted JWK key sets

thanx,
Anders

---

From: Neil Madden <[email-masked]>
Date: Wed, 7 Feb 2018 10:16:07 +0000

> On 7 Feb 2018, at 09:44, Anders Rundgren <[email-masked]> wrote:
> 

But why do you consider it invalid?

> If an attacker has access to the genuine user's private keys it is usually game over.

Indeed. My point is that adding a “kid” hint does nothing either way. There is no added security from trusting the sender to tell you which key they used before you can actually verify that the message really was from that sender.

> 
>> A bigger problem with “jku” would be the potential for SSRF (https://cwe.mitre.org/data/definitions/918.html <https://cwe.mitre.org/data/definitions/918.html>) and similar attacks based on getting the server to access arbitrary URLs before it has validated the signature.
> 

And now an attacker can probe your internal network by seeing what kind of error response they get to different jku URLs, and can potentially cause unwanted side-effects on trusted servers. Unless your trusted server list is strongly unguessable (and you compare against that list in constant time), then this is a huge risk.

— Neil

---

From: "Manger, James" <[email-masked]>
Date: Thu, 8 Feb 2018 06:20:15 +0000

A URI pointing to a JWK Set (jku) plus a key-id (kid) is sufficient to identify one specific key. But you should be able to point to a single key with a single URI. You can't with RFC7517 JWK, and that is a flaw. The sensible solution would be to define how to put a kid in the fragment portion of a URI that points to a JWK Set (application/jwk-set+json). For example, https://example.com/keys.jwks#2011-04-29 to identify the 2nd key from RFC7517 Appendix A.1.

I assume we can define the fragment format specific to application/jwk-set+json. Unless the +json suffix means it must use a generic JSON fragment format?

Then you can authorize a set of keys that will change over time with key roll-over by giving a URI to a JWK Set. And you can identify the specific key used in a specific transaction with a URI-with-fragment.

--
James Manger

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, 7 February 2018 5:23 PM
To: Anders Rundgren <[email-masked]>; [email-masked]
Subject: Re: [jose] JOSE dependence on "Key Guessing"

				-- Mike

-----Original Message-----
From: jose <[email-masked]> On Behalf Of Anders Rundgren
Sent: Tuesday, February 6, 2018 10:03 PM
To: [email-masked]
Subject: [jose] JOSE dependence on "Key Guessing"

Dear list,

thanx,
Anders