eap Mailing List: AW: [eap] RE: Comments to <draft-vanderveen-eap-make-00.txt>

[t . otto (t.otto]

Hi Hesham, 

thanks for your immediate response! 


 > > Some of the advantages of EAP-MAKE consist of:
>
> > o based on well-established Bellare-Rogaway mutual
> > authentication protocol.
> > o relies on the IEEE 802.11i function for key derivation and
> > message integrity. This way a device implementing a lower-layer
> > secure association protocol compliant with IEEE 802.11i
> standard will
> > not need additional cryptographic code.
> > o encryption algorithm is securely negotiated (with no extra
> > messages) but encryption use is optional.
> o keys used for authentication and those used for encryption are
> cryptographically separate.
> o user identity anonymity can be optionally supported.
> o no synchronization (e.g. of counters) needed between
> server and
> peer.
> o no one-time key pre-processing step.
>
> Sorry, this does not convince the reader :-/

=> Which one ? all of the above?


In detail: 


   Some of the advantages of EAP-MAKE consist of:

     o based on well-established Bellare-Rogaway mutual authentication
   protocol.

You can not say it is an advantage to make use of a well-analyzed
cryptographic algorithm which enjoys a security proof (at least in 
the Bellare-Rogaway attack model). 



     o supports key derivation for local EAP method use and for export
   to other third parties to use them independently of EAP.

Where is the advantage? Since you offer encryption (at least optional)
it makes sense to generate keying material for usage within the EAP method,
and then keying material to meet the requirements of RFC 4017. 


     o employs only two request/response exchanges.

Not only important is the number of roundtrips, but also the computational
costs of their construction (for the sender) and their verification (for the 
receiver). However, there are a lot of proposals which have only two rountrips.


     o relies on the IEEE 802.11i function for key derivation and
   message integrity. This way a device implementing a lower-layer
   secure association protocol compliant with IEEE 802.11i standard will
   not need additional cryptographic code.


Take EAP-FAST as an example. As PRF, the following construction serves


<snip>    
To generate the desired OutputLength octet length of key material, 
the T-PRF is iterated as follows:  
     
  T-PRF (Key, S, OutputLength) = T1 + T2 + T3 + T4 + ... 
          Where S = label + 0x00 + seed;  and 
     
    T1 = HMAC-SHA1 (Key, S + OutputLength + 0x01) 
    T2 = HMAC-SHA1 (Key, T1 + S + OutputLength + 0x02) 
    T3 = HMAC-SHA1 (Key, T2 + S + OutputLength + 0x03) 
    T4 = HMAC-SHA1 (Key, T3 + S + OutputLength + 0x04) 
</snip>

How much lines of code would this require? One? Two? 



     o encryption algorithm is securely negotiated (with no extra
   messages) but encryption use is optional.


Yes .. because this is a *mandatory* requirement of RFC 4017, 
that ciphersuite negotiation must be adequately protected.
Again, no advantage, but an attempt to meet the requirements.



     o keys used for authentication and those used for encryption are
   cryptographically separate.

But this is a rule of thumb in theory, isnt it? 


     o user identity anonymity can be optionally supported.

This is a recommended requirement of RFC 4017. Since other methods
does not provide this feature, it belongs to the advantages of "EAP-MAKE"
over other EAP methods. 


     o no synchronization (e.g. of counters) needed between server and
   peer.

No advantage. You can not say it is an advantage not to use a thing
which is not needed at all.  Am I right?


     o no one-time key pre-processing step.

See previous comment. 





The point is, that I have followed the development process of another EAP 
method,
which was initiated in January 2004 and is currently in version 09 and still in 
review. That is, a almost two years enduring process has yielded in some result 
which is worth to be called "mature". 

Now, over night, a new EAP method is published which 
* apparently (although further analysis is needed) does not have all the 
teeting 
  problems new proposals usually have, but seems moreover to be very mature. 
* and does not introduce (except perhaps the optional identity protection) new
  features, but is very very close to existing proposals 

This may not be understood as reproach, but however, this might
explain you as an author my missing enthusiasm for "EAP-MAKE".


Regards  

Thomas