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

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 2 Feb 2022 07:18:52 -0500

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

---

From: Neil Madden <[email-masked]>
Date: Thu, 3 Feb 2022 23:47:55 +0000

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]> wrote:
> 
> 
> All,
> 
> The JWK Thumbprint URI document is a simple and straightforward specification.
> 
> Please, provide your feedback on the mailing list by Feb 16th.
> 
> Regards,
>  Rifaat & Hannes
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 4 Feb 2022 09:00:25 +0200

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
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 4 Feb 2022 15:29:55 +0000

> 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 sche…

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?

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]> On Behalf Of Vladimir Dzhuvinov
Sent: Thursday, February 3, 2022 11:00 PM
To: [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.

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.

~Vladimir

Vladimir Dzhuvinov

— Neil

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

All,

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]>

---

From: David Chadwick <[email-masked]>
Date: Fri, 4 Feb 2022 17:55:28 +0000

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

All,

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

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:

the SIOP creates an asymmetric
key pair and encodes the public key as a JWK

the SIOP creates
the JWK Thumbprint as described in [RFC7638] and converts it to
a URI as described in [JONES],

the SIOP passes
both the JWK and JWK Thumbprint URI to the RP in the JWT,

the RP extracts
the JWK and JWK Thumbprint from the JWT

the RP re-computes
the JWK Thumbprint from the JWK

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

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

Regards,

Rifaat & Hannes

---

From: Warren Parad <[email-masked]>
Date: Fri, 4 Feb 2022 22:38:54 +0100

I also agree that there hasn't been sufficient review of this document to
warrant progressing it.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.

On Fri, Feb 4, 2022 at 6:56 PM David Chadwick <
[email-masked]> wrote:

> 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
> 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
>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Neil Madden <[email-masked]>
Date: Sat, 5 Feb 2022 09:00:04 +0000

Hi Mike,

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

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

---

From: Kristina Yasuda <[email-masked]>
Date: Tue, 15 Feb 2022 00:33:51 +0000

Hi All,

Thank you very much for the constructive feedback.
We have tried to address the WGLC comments received to date with the latest draft published at https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwk-thumbprint-uri-01.

Following are updates made to the document:
- Added security considerations about multiple public keys coresponding to the same private key.
- Added hash algorithm identifier after the JWK thumbprint URI prefix to make it explicit in a URI which hash algorithm is used.
- Added reference to a registry for hash algorithm identifiers.
- Added SHA-256 as a mandatory to implement hash algorithm to promote interoperability.

Kindest Regards,
Kristina

From: OAuth <[email-masked]> On Behalf Of Rifaat Shekh-Yusef
Sent: Wednesday, February 2, 2022 4:19 AM
To: oauth <[email-masked]>
Subject: [OAUTH-WG] WGLC for JWK Thumbprint URI document

All,

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%7C798aea1808b74133e90308d9e64643b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637794012195931100%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UDG%2F77OaaA%2BaTPiBiDzKYbyXUvJ2YY5m%2F7wO7OhW%2FNI%3D&reserved=0>

Regards,
 Rifaat & Hannes

---

From: Neil Madden <[email-masked]>
Date: Tue, 15 Feb 2022 13:36:46 +0000

Thanks, these changes address my comments. I am happy with the new draft text.

Cheers,

Neil

> On 15 Feb 2022, at 00:33, Kristina Yasuda <Kristina.Yasuda=[email-masked]> wrote:
> 
> Hi All,
>  
> We have tried to address the WGLC comments received to date with the latest draft published athttps://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwk-thumbprint-uri-01 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwk-thumbprint-uri-01>.
>  
> 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%7C798aea1808b74133e90308d9e64643b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637794012195931100%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UDG%2F77OaaA%2BaTPiBiDzKYbyXUvJ2YY5m%2F7wO7OhW%2FNI%3D&reserved=0>
>

---

From: Warren Parad <[email-masked]>
Date: Tue, 15 Feb 2022 15:02:47 +0100

This is a great improvement.

Warren Parad

Founder, CTO

On Tue, Feb 15, 2022 at 2:37 PM Neil Madden <[email-masked]>
wrote:

> On 15 Feb 2022, at 00:33, Kristina Yasuda <
> Kristina.Yasuda=[email-masked]> wrote:
>
> Hi All,
>
> We have tried to address the WGLC comments received to date with the
> latest draft published at
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwk-thumbprint-uri-01
> .
>
> - Added hash algorithm identifier after the JWK thumbprint URI prefix to
> make it explicit in a URI which hash algorithm is used.
> *From:* OAuth <[email-masked]> *On Behalf Of *Rifaat Shekh-Yusef
> *Sent:* Wednesday, February 2, 2022 4:19 AM
> *To:* oauth <[email-masked]>
> *Subject:* [OAUTH-WG] WGLC for JWK Thumbprint URI document
>
> All,
>
> <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%7C798aea1808b74133e90308d9e64643b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637794012195931100%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UDG%2F77OaaA%2BaTPiBiDzKYbyXUvJ2YY5m%2F7wO7OhW%2FNI%3D&reserved=0>
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 16 Feb 2022 02:48:39 +0000

My traditional blog post describing the updated draft is at https://self-issued.info/?p=2251.  I also tweeted about it at https://twitter.com/selfissued/status/1493778351919489037.

                                                       -- Mike

From: OAuth <[email-masked]> On Behalf Of Kristina Yasuda
Sent: Monday, February 14, 2022 4:34 PM
To: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

Hi All,

Kindest Regards,
Kristina

From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of Rifaat Shekh-Yusef
Sent: Wednesday, February 2, 2022 4:19 AM
To: oauth <[email-masked]<mailto:[email-masked]>>
Subject: [OAUTH-WG] WGLC for JWK Thumbprint URI document

All,

Regards,
 Rifaat & Hannes