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

[Joseph Salowey (jsalowey]

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko [at] piuha.net] 
> Sent: Sunday, July 25, 2004 10:15 PM
> To: Joseph Salowey
> Cc: 'Bernard Aboba'; eap [at] frascone.com
> Subject: Re: [eap] Proposed Resolution of Issue 215: Comments 
> on Section 3
> 
> 
> 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.
> 

[Joe] In general the nonces should provide enough uniqueness.  In any case
the text in the document can only be a guideline anyway.  Some methods may
not authenticate both client and server.  If they do the format of the
identity must be clearly defined and I think this can only be done by the
method itself.  


> 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.
>

[Joe] I think the attack you outline above may not be possible with many
methods since the server has a fair amount of control over what gets
exchanged and hashed.  If this is possible this would result in an
authentication failure for the entity whose key was replaced.   I think this
would be rare and I'm not too worried about it.  Perhaps if we make the
first byte indicate the type of hash function used that would help, or we
could add a few bytes and make it include the EAP method as well.  I'm not
sure it is worth it. 
 
> --Jari
>