Subject: Re: [eap] Re: SHA-0 Broken

From: Florent Bersani <[email-masked]>
Date: Fri, 10 Sep 2004 09:28:31 +0200

Nicolas Williams wrote:

> <>
>
>>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)
>>    
>>
> Have a look at EAP-PSK: This is an EAP method which is based on a 
> pre-shared
>
>
>And what if AES is broken tomorrow?  Inpractical attacks exist, but do
>they cast a shadow on AES' future?
>  
>
See Section 2.2 of EAP-PSK:

"Other block ciphers could easily be proposed for EAP-PSK, as it does 
not intricately depend on AES-128. The only parameters of AES-128 that 
EAP-PSK depends on, are its block size (16 bytes) and its key size (16 
bytes). For the sake of simplicity, it has however been chosen to 
restrict to a single mandatory block cipher and not allow the 
negotiation of other block ciphers. In case AES-128 is deprecated for 
security reasons, EAP-PSK should also be deprecated and a cut-and-paste 
EAP-PSK' should be defined with another block cipher. This EAP-PSK' 
should not be backward compatible with EAP-PSK because of the security 
issues with AES-128. EAP-PSK' should therefore use a different 
EAP-Request/Response Type number. With the EAP-Request/Response Type 
number space structure defined in [2] (Aboba, B., Blunk, L., Vollbrecht, 
J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol 
(EAP), June 2004). <#RFC3748>, this should not be a problem."

>Why EAX?  Why not GCM?
See Section 2.2.3 of EAP-PSK

"EAX was mainly chosen because:

    * It strongly relies on OMAC in its design and OMAC1, a variant of
      OMAC, had already been chosen in EAP-PSK for the authentication part.
    * Its design is simple.
    * It enjoys a security proof.
    * It is free of any Intellectual Property Rights claims."

Earlier version of EAP-PSK mentioned in Section 2.2.3:

"There are currently many other proposed modes for authenticated 
encryption with associated data - including Intellectual Property Rights 
free ones, like CCM, CWC or GCM (please refer to the NIST "Modes of 
operation for symmetric key block ciphers" web page 
<http://www.csrc.nist.gov/CryptoToolkit/modes/> for more details)."

As a matter of fact I know one of the GCM designers and I appreciate GCM 
very very much.

It is true that EAP-PSK could use GMAC instead of OMAC and GCM instead 
of EAX, which would probably improve the performance of some 
computations (a factor 2 could be expected from software benchmarks).
OMAC was chosen because it seemed to have the favors of NIST and at that 
time GCM was at its beginnings.
I did not receive many requests to change the modes of operation, that's 
why given the point where EAP-PSK is now, I am reluctant to make 
changes... but that could change if I feel compelling arguments to do so.

Any comments welcome,
Florent

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Florent Bersani <[email-masked]>
Date: Fri, 10 Sep 2004 09:31:54 +0200

Mohamad Badra wrote:

>
> I am not opposed to any protocol. Let me answer you by a question: why 
> I have to create 'new' one? Why I shall create a new protocol whereas 
> I already have the same services if I partially or if I simplify the 
> use of IKEv2 or TLS?
>
The IMHO interesting question I asked you and that you apparently 
avoided to answer technically was: "why was IKEv2 invented since we 
already had TLS"?

I do not have definitive answers as I am currently working on such 
topics but I believe that an open-minded reflexion with scientific 
arguments on this question may bring many insights.

Florent, who, before taking winners, like to understand why they have 
won ;-)
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Mohamad Badra <[email-masked]>
Date: Fri, 10 Sep 2004 17:54:47 +0200

> avoided to answer technically was: "why was IKEv2 invented since we 

I don't like to answer by a technical question I posted it three months 
ago, but it may be a good idea to repeat it here. "Why have we to adopt 
or to add new security mechanisms since we had two very *well studied* 
and *widely implemented* protocols such as IPSec and TLS?".

The real differences between the TLS and IKEv2 come from the 
distinguished requirements of several architectures (included Fixed and 
Wireless) and applications. TLS was first developed to answer specific 
needs of client/server applications (such as credit card number) where 
the authentication was just from the server side. IKE and specially 
IKEv2 has different audience in the network architectures to answer a 
symmetric initiator/responder connexions where the two communicators 
have the same authentication methods. Actually, these two protocols are 
merging with their cryptographic and authentication part: they both 
integrate PSK authentication, Identity Protection, PFS, fast 
negotiation, etc. A lot of work was already done in the IPSec and TLS 
IETF WG to produce a secure, flexible and fast security protocol. (Add 
what do you want to  these three adjectives ;-)      ).

IMHO, a new defined protocol is welcome if, and only if *it can prove* 
its advantages over TLS and IKEv2.

Badra

P.S. If I didn't answer you properly, please forward your question to 
IPSec and TLS mailing list, maybe you will get more info about that.