eap Mailing List: Re: SHA-0 Broken

[Thomas Otto (t.otto]

Mohamad Badra wrote: 
> Add to that, if SHA-1 will be broken, this does not mean that HMAC_hash
> is automatically broken since TLS-PRF uses HMAC_hash instead of hash. 

A short look in the abstract of RFC 2104, HMAC, shows us the relation:
"The cryptographic strength of HMAC depends on the properties of the 
underlying hash function." 


Jari Arkko wrote:
> The slides you pointed us to say "the technique is not applicable to full 
> SHA-1". 

This is the state-of-the-art. What about tomorrow, next week or next month?
Along with the slashdot.org announcement, a statement of Edward Felten 
appeared - therein, he gives a general classification of this attack (excerpt 
of [3])

> The finding of a single collision in SHA-1 would not, by itself, cause much
> trouble, since one arbitrary collision won't do an attacker much good in
> practice. But history tells us that such discoveries are usually followed by
> a series of bigger discoveries that widen the breach, to the point that the
> broken primitive becomes unusable.

I'd like explicitly state that I'm aware of the fact, that this is the EAP 
mailing list and not a cryptography mailing list and that I immediately
stop talking about crypto topics. 
Nevertheless, most of us are certainly no designated experts in the
cryptography area and are reliant on research results of *real* cryptographers
like him. And why not take their advises into account? 

At this point, the question might arise: Why this discussion thread is 
initiated? This is because of the recent discussion about PSK methods. On 
August 6th, M.Badra posed the question

> Why we need (the goal) to define new pre shared key methods, that 
> are NOT based on TLS or IKEv2.

To tell the truth: Because of events like that at Crypto 04. Why not having
alternatives which does not rely on TLS, and much more, which makes use of
completely other cryptographic primitives than all proposals before? 

Have a look at EAP-PSK: This is an EAP method which is based on a pre-shared
key and takes as underlying crypto primitive AES. Nothing more, just AES.
More precisely, AES-128 is used for
* mutual authentication 
* session key derivation (via modified counter mode)
* encrypted communication through the secure tunnel 
   (aes in eax mode, hash is OMAC)

Let me enumerate some EAP methods which use a PRF function based on the 
hash functions currently came under fire: 
EAP-TLS and EAP-PAX on the one hand (TLS-PRF), 
on the other hand PEAPv2, EAP-FAST  (PRF of IKEv2)

Second, Joe Salowey mentioned that

> [...] methods based on existing key exchange frameworks such as TLS and
> IKEv2 are valuable because they build on widely implemented (at least in the
> case of TLS) and reviewed standards. TLS is probably the most widely
> deployed one and it has been extended to support multiple mechanisms 
> including certificates, kerberos and pre-shared key.  I would prefer to
> focus on the standard frameworks first. 

I agree. But why concentrating on one protocol? What if this protocol becomes 
vulnerable?

To sum all up: The intention is the conclusion that it is possibly best 
practise to allow some kind of heterogeneity in development, and to treat 
proposals which are not main-stream a little bit more tolerant than we have 
seen it these days (this has been, at least, my impression). Having one ore 
more alternatives can not be a disadvantage, right?


Thomas 

References

[3] http://www.freedom-to-tinker.com/archives/000661.html
[4] Edward Felten is Professor at Department of Computer Sciences, 
Princeton University, his personal website is
http://www.cs.princeton.edu/~felten/