> On 7 Feb 2018, at 09:44, Anders Rundgren <[email protected]>
> wrote:
>
> 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.
But why do you consider it invalid?
>
>>> 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.
Indeed. My point is that adding a “kid” hint does nothing either way. There is
no added security from trusting the sender to tell you which key they used
before you can actually verify that the message really was from that sender.
>
>> A bigger problem with “jku” would be the potential for SSRF
>> (https://cwe.mitre.org/data/definitions/918.html
>> <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
And now an attacker can probe your internal network by seeing what kind of
error response they get to different jku URLs, and can potentially cause
unwanted side-effects on trusted servers. Unless your trusted server list is
strongly unguessable (and you compare against that list in constant time), then
this is a huge risk.
— Neil
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
