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 protected]>
Sent: Saturday, February 5, 2022 1:00 AM
To: Mike Jones <[email protected]>
Cc: [email protected]
Subject: Re: [OAUTH-WG] Re: WGLC for JWK Thumbprint URI document
Hi Mike,
On 4 Feb 2022, at 15:30, Mike Jones
<[email protected]<mailto:[email protected]>>
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 protected]<mailto:[email protected]>> On Behalf
Of Vladimir Dzhuvinov
Sent: Thursday, February 3, 2022 11:00 PM
To: [email protected]<mailto:[email protected]>
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 protected]><mailto:[email protected]> 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 protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
