On 2018-02-07 09:06, Neil Madden wrote:
On 7 Feb 2018, at 07:18, Anders Rundgren <[email protected]
<mailto:[email protected]>> wrote:
On 2018-02-07 07:22, Mike Jones wrote:
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.
"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.
Can you clarify why? You can just try each applicable key.
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.
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.
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.
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 validated the
signature.
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
— Neil
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
