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

[Anders Rundgren <[e-mail]>]

On 2018-02-07 09:06, Neil Madden wrote:
> 
> On 7 Feb 2018, at 07:18, Anders Rundgren <[e-mail] <mailto:[e-mail]>> 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