Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

From: Mike Jones <[email-masked]>
Date: Mon, 7 Feb 2022 21:17:59 +0000

Thanks for the useful information, Neil!  I learned things I didn't know from reading your remarks, which is always good. :-)

The good news is that in the application that motivated writing this specification (OpenID Connect Self-Issued OpenID Provider v2) the mitigation you described is already in place; the key is used to sign a JWT that includes both the key thumbprint and the key itself.  But it will be great to describe these attacks and how they relate to using key thumbprints as identifiers generally, so others are aware of them.

We also look forward to any additional Security Considerations text you may choose to supply.

                                                       Thanks again,
                                                       -- Mike

From: Neil Madden <[email-masked]>
Sent: Saturday, February 5, 2022 1:00 AM
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Re: WGLC for JWK Thumbprint URI document

Hi Mike,

On 4 Feb 2022, at 15:30, Mike Jones <Michael.Jones=[email-masked]<mailto:Michael.Jones=[email-masked]>> wrote:

Neil, thanks for your review.  First, you wrote:

> Using a (hash of a) public key as an identifier is an idea that has historically been subject to various attacks such as unknown key share attacks, as well as issues due to malleable signature schemes or key exchange schemes - where the same proof of identity is valid under many public keys. The security considerations should mention these issues, and potential suggest countermeasures (eg including the full public key JWK in the input to be signed etc).

I’m not all that familiar with the attacks you’re referencing.  Is there I write-up on them that you could refer me and the other working group members to so we can better understand them?  And ideally, could you write up a paragraph or two on them that you’d like us to include in the Security Considerations?

I’ll have a look and see if there is a concise write up somewhere. To give you an idea, here are some potential attacks:

Firstly, in ECDSA for example each signature is typically valid for at least two public keys, and these keys can be easily recovered from the signature itself [1]. So if Alice is using an ECDSA signature as proof of her identity, and her identity is a (hash of a) public key, then it is also a valid proof of identity for a different identity (different JWK thumbprint). This makes an authentication scheme based on this ambiguous, which is not usually a good thing.

A similar thing can happen with ECDH-based key exchanges or authenticated encryption schemes (like my own ECDH-1PU) with certain elliptic curves. In this case you can add “points of small order” to a public key to derive a new public key that will produce the same ECDH shared secrets (or even simpler change the PK point (x,y) to (x,-y)). The attacker in this case can’t decrypt or tamper with a message but they can claim that it came from their public key instead of the real originator. Again, this can make the same proof of identity valid for two or more identities if you use public keys as identities.

In both cases these “attacks” can be avoided by including the identities/public keys in the input to the signature (or KDF for ECDH). For example, EdDSA already does this, and this is a recommended best practice for ECDH (sadly missing from JWE). An alternative is to define a canonical public key for each given signature and reject non-canonical keys.

Whether these “attacks” actually lead to a vulnerability or not depends on exactly what you are doing. But it is a surprising property that can lead to subtle issues as the security considerations of RFC 7748 note [2]:

“ Designers using these curves should be aware that for each public

   key, there are several publicly computable public keys that are

   equivalent to it, i.e., they produce the same shared secrets.  Thus

   using a public key as an identifier and knowledge of a shared secret

   as proof of ownership (without including the public keys in the key

   derivation) might lead to subtle vulnerabilities.”

Adding wording along those lines (generalised to mention signatures too) would be good. I’ll come up with some wording.

Other security issues can arise when a public key hash is informally associated with some other kind of identifier without a strong binding between the two. For example, the unknown key share attacks described in RFC 8844 [3].

[1]: https://crypto.stackexchange.com/a/60219
[2]: https://datatracker.ietf.org/doc/html/rfc7748#section-7
[3]: https://www.rfc-editor.org/rfc/rfc8844.html

— Neil

Second, you asked that the hash algorithm be made explicit, as did Vladimir.  I’ll consult with Kristina on that today and respond to that suggestion in a subsequent message.

                                                       Thanks again,
                                                       -- Mike

From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of Vladimir Dzhuvinov
Sent: Thursday, February 3, 2022 11:00 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

The original JWK thumbprint RFC 7638 essentially describes the method for composing the hash input from a JWK and that the output is base64url encoded. SHA-256 is mentioned, but there is no default implied hash function. This leaves it to applications / other specs to determine.

https://www.rfc-editor.org/rfc/rfc7638.html#section-3.4

The URN gives us now a natural possibility to encode the hash function alongside the fact that it's a JWK thumbprint, so let's include it. This will make things more explicit and self-contained.

What do the authors think about this possibility?

~Vladimir

Vladimir Dzhuvinov
On 04/02/2022 01:47, Neil Madden wrote:
The draft doesn’t specify which hash function is being used. I assume it is SHA-256, but it should either say that is the only algorithm allowed or perhaps encode the hash algorithm into the URI. Otherwise the value is ambiguous.

Using a (hash of a) public key as an identifier is an idea that has historically been subject to various attacks such as unknown key share attacks, as well as issues due to malleable signature schemes or key exchange schemes - where the same proof of identity is valid under many public keys. The security considerations should mention these issues, and potential suggest countermeasures (eg including the full public key JWK in the input to be signed etc).

— Neil

On 2 Feb 2022, at 12:19, Rifaat Shekh-Yusef <[email-masked]><mailto:[email-masked]> wrote:

All,

The JWK Thumbprint URI document is a simple and straightforward specification.

This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by Feb 16th.

Regards,
 Rifaat & Hannes

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Fri, 18 Feb 2022 18:35:45 +0000

See my review comments in the thread “[OAUTH-WG] Comments on draft-chadwick-oauth-jwk-uri-00”.

                                                       -- Mike

From: David Chadwick <[email-masked]>
Sent: Friday, February 18, 2022 3:52 AM
To: Mike Jones <[email-masked]>; Kristina Yasuda <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

Hi Mike

The additional mechanism was published as an I-D last week.

draft-chadwick-oauth-jwk-uri-00.txt

I thought this list had been notified, but my-bad, I see it was not.  So I have just sent out the notification now.

So can we get some feedback from this group as well as the OIDC one, before progressing either?

Kind regards

David

On 17/02/2022 22:23, Mike Jones wrote:
Hi David,

Rifaat reminded me that yours is the only WGLC comment that has not been resolved by publication of -01.  As noted earlier, the substantive differences between this draft and the JWK URI draft that you’re proposing are being primarily discussed in the OpenID Connect working group, where the JWK Thumbprint URI mechanism is used.

In that discussion, you made this issue comment https://bitbucket.org/openid/connect/issues/1429/replace-jwk-thumbprint-uri-with-jwk-uri#comment-61838115:

“I agree that adding JWK URI should not exclude JWK Thumbprint URIs. Similarly JWK Thumbprint URIs should not exclude JWK URIs.”

That seems to me to indicate that you’re OK with this specification being published, while also wanting both working groups to consider your additional mechanism when a draft is submitted?  Am I hearing you correctly on that?

At least in my mind, the fact that you might publish another not-equivalent mechanism shouldn’t hold up publication of this mechanism.

                                                       Thanks again,
                                                       -- Mike

From: David Chadwick <[email-masked]><mailto:[email-masked]>
Sent: Monday, February 7, 2022 12:54 PM
To: Kristina Yasuda <[email-masked]><mailto:[email-masked]>; Mike Jones <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 07/02/2022 20:42, Kristina Yasuda wrote:
Hi David,

I think your comments below apply to the choices made in another specification (SIOP v2 in OIDF), rather than this IETF draft we are discussing.

Hi Kristina

Yes and no.

No, in that the registration of either of the I-Ds as an RFC is a matter for this list, and should answer this question, "what is the best way (or ways) of creating a URI from a public key."

Yes, in that the SIOPv2 specification requires at least one way of specifying a public key as a URI and therefore needs some other standard or standards to refer to.
I’ve seen you opened an issue in the OpenID Connect WG Bitbucket. Let’s discuss there whether SIOP v2 should use JWK Thumbprint URI.

Yes we can certainly discuss the latter issue in OIDF

Kind regards

David

Best,
Kristina

From: OAuth <[email-masked]><mailto:[email-masked]> On Behalf Of David Chadwick
Sent: Sunday, February 6, 2022 2:40 AM
To: Mike Jones <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 05/02/2022 17:46, Mike Jones wrote:
David, I believe your objections below are actually about the JWK Thumbprint [RFC 7638<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7638.html&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YsMfndDhygG7AkSPK9NeYrKhDwFkd5P%2FSAgZsrXH%2F6Q%3D&reserved=0>] computation used by this specification, and not the operation defined by this specification.  JWK Thumbprint became an RFC in 2015.

Hi Mike

no, my objection is to the JWK Thumbprint URI document. I accept that the JWK Thumbprint RFC already exists.

The aim of the SIOPv2 group is to transfer a public key as a URI, so it leverages the JWK Thumbprint RFC to do this. As I point out in my I-D, SIOPv2 transfers the public key and the public key thumbprint. My I-D suggests that we simply transfer the public key as a URI then no thumbprint computation is necessary by the SIOPv2. The recipient can compute its own thumbprint if it needs to by utilising the JWK Thumprint RFC and in this case no hashing algorithm needs to be jointly agreed upon.

Kind regards

David

This specification<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-jwk-thumbprint-uri-00.html&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8Vt%2BwrhXuAC3CjvGzaQtmYv4%2BIV3ElozbVGED4FLUvQ%3D&reserved=0> defines how to create a JWK Thumbprint URI by concatenating the URI prefix “urn:ietf:params:oauth:jwk-thumbprint” to an RFC 7638 JWK Thumbprint.  That’s all it does.  That’s why Rifaat’s statement “The JWK Thumbprint URI document is a simple and straightforward specification” is indeed correct.

                                                       Best wishes,
                                                       -- Mike

From: OAuth <[email-masked]><mailto:[email-masked]> On Behalf Of David Chadwick
Sent: Friday, February 4, 2022 9:55 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 02/02/2022 12:18, Rifaat Shekh-Yusef wrote:
All,

Actually this is a complex and inefficient specification compared to other possibilities.

I have written an Internet-Draft outlining an alternative scheme, the JWK URI, which provides OIDC SIOPv2 with all the requirements that it needs with much less effort than implementing JWK Thumbprint URIs. I am currently formatting this I-D correctly to submit to the IETF. The rationale for this new Internet Draft is as follows.

To produce or validate a JWK Thumbprint, both the sender and the receiver have to have the JWK available to them. Then they have to canonicalise the JWK as described in [RFC7638], and finally hash the octets of the UTF-8 representation of this JSON object with a pre-agreed algorithm in order to both obtain the same hash value. The way that the JWK Thumbprint URI is used in SIOPv2 [SIOPv2] is as follows:

  1.  the SIOP creates an asymmetric key pair and encodes the public key as a JWK
  2.  the SIOP creates the JWK Thumbprint as described in [RFC7638] and converts it to a URI as described in [JONES],
  3.  the SIOP passes both the JWK and JWK Thumbprint URI to the RP in the JWT,
  4.  the RP extracts the JWK and JWK Thumbprint from the JWT
  5.  the RP re-computes the JWK Thumbprint from the JWK
  6.  the RP compares the computed JWK Thumbprint with the received JWK Thumbprint to confirm that they are equal.

One can see that the use of JWK Thumbprint URIs is both inefficient (in all cases) and a significant disadvantage (in some cases). If the JWK URI is transferred instead of the JWK and JWK Thumbprint URI then:

a) The SIOP will never need to create the JWK Thumbprint URI. The RP may only need to create the JWK Thumbprint if it needs this, for example, as a unique subject identifier. Even in this case, there is still an advantage to the RP in receiving the JWK URI instead of the JWK Thumprint URI, in that the RP no longer needs to pre-agree a hashing algorithm with the SIOP. Thus the RP can independently determine which hashing algorithm to use when creating its own JWK Thumbprint. (Note. If the SIOP were able to canonicalise the same public key in a JWK in different ways and produce different thumbprints from the same public key, then the canonicalisation algorithm is broken, and the RP would never to able to deterministically produce the same thumbprints each time.)

b) In those cases where the SIOP uses ephemeral key pairs and a different public key each time it communicates with an RP, then neither party needs to produce the JWK Thumbprint as it will never be seen again. It is a significant disadvantage to have to use JWK Thumbprints in this case.

I therefore kindly request that the JWK Thumbprint URI document does not progress until the WG has had chance to compare and contrast the two methods.

Kind regards

David

This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-jwk-thumbprint-uri-00.html&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8Vt%2BwrhXuAC3CjvGzaQtmYv4%2BIV3ElozbVGED4FLUvQ%3D&reserved=0>

Regards,
 Rifaat & Hannes

OAuth mailing list

https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=L5UFnqyzv16VgMrickO8sVxQ77Om8PDtgM%2BMFjQbfhU%3D&reserved=0>