eap Mailing List: Re: Proposed Resolution of Issue 215: Comments on Section 3

[Jari Arkko (jari.arkko]

Joseph Salowey wrote:

> [Joe] Basically I think this should be up to the method.  Methods should
> define a default key naming hashing scheme.  If a method wants to have the
> ability to negotiate other hash functions for naming then it can, but I
> don't really see this as necessary.   What we probably want to define is a
> name length that method should output, in general 128 bits seems sufficient.

Would you still require the method to use the input that
we defined earlier for the hash? So only the hash, not the
input would be method dependent? I think that may be required,
otherwise the key Ids will not be sufficiently different
among methods.

The other question I had is what if there's a collision
among the different hash functions? I assume that such
collisions would be rare for good quality hash functions,
so normally this would not be a problem. But lets say someone
deploys method X that uses SHA666, which is later discovered
to be weak. So weak in fact that you can calculate the inputs
that you need for a specific value.  Would this enable anyone
with an X account generate a key id that matches with someone
else's keyid from method Y? And if so, would it matter? Lets
think about this:

  1. If we mandate that client id is a part of the input, it
     becomes a bit harder for the attacker to choose the right
     input. But presumably it will still be possible to create
     a matching key id based on varying the rest of the input,
     such as the client nonce.

  2. This may be problematic if the bogus keyid now replaces
     state reserved for the real key associated with the same
     key id.

  3. The same would not be possible in the hash-less scheme,
     because we required the inputs, such as method type,
     to be present.

  4. However, this attack still requires (a) that there
     exists a bad method with a bad hash function, and
     (b) that someone's server is still accepting that
     bad method and bad hash function.

  5. Having a bad hash function may also mean other things
     for that server, such as ability to spoof authentication
     without keys.

Conclusion: I worried a bit about 2 and 3 above, but
4 and 5 seem to indicate that the only nodes affected
would be the clients of a server that still uses the
bad method for someone. So maybe its not a problem.

--Jari