Subject: AW: [eap] Future of EAP-PSK

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 14 Jul 2005 13:49:33 +0200

hi thomas, 

i would like to thank you for the fact that you care so much about eap-psk. 
jesse provided a quite detailed review. thanks jesse. i would say that this is probably the most detailed review an eap method has ever seen. (minor comment: i would like to see more reviews by jesse -- including some eap methods that are already rfc or pretty close to it). 
 
anway, i think jesse raised good comments but i do not see a problem with the future of eap-psk. i don't see that there is a problem with pre-shared methods. i also see usefulness of eap methods that offer secure password based authentication (such as eap-ikev2).  

ciao
hannes

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Thomas Otto
> Gesendet: Donnerstag, 30. Juni 2005 16:48
> An: [email-masked]
> Betreff: [eap] Future of EAP-PSK
> 
> 
> 
> First, a brief technical comment regarding the proposal 
> 
> > It would be worth considering replacing OMAC1 by CMAC. NIST 
> SP800-38B
> > [2] defines CMAC as the "approved" CBC-MAC variant.
> 
> OMAC is short for One-Key CBC MAC. There are two variants of 
> OMAC, namely
> OMAC1 and OMAC2. 
> OMAC1 is equivalent to CMAC. The CMAC mode of authentication is the
> recommendation of NIST (see SP-800-38B, May 2005). On the 
> OMAC page [1],
> we find next to a detailed description of OMAC some pointer 
> to OMAC-related
> material, for instance "Comparison of CBC MAC variants and 
> comments on NIST's
> consultation paper. Comment to NIST (2003/05/05)" by T. Iwata 
> [2]. The author 
> compares RMAC,EMAC, XCBC, TMAC and OMAC. In the conclusion section, he
> emphasizes that OMAC gives the best performance and provide 
> an equal security
> to EMAC, XCBC and TMAC. With regard to implementations, OMAC1 
> is recommended.
> 
> So, OMAC1 has been a good choice. Since EAX relies on OMAC1, 
> the EAX mode of 
> encryption should be maintained. 
> 
> [1] http://crypt.cis.ibaraki.ac.jp/omac/omac.html
> [2] http://crypt.cis.ibaraki.ac.jp/omac/docs/omac-cm2.pdf
> 
> 
> 
> Open question to the authors of EAP-PSK: Florent, Hannes, do you have
> solutions regarding the open issues with EAP-PSK? Your comments failed
> to appear since the expert review was published, which I find 
> quite strange,
> since the issues mentioned in the review sound serious.  
> 
> Although I do not hope, it seems that it lacks somehow of 
> motivation to 
> finish EAP-PSK. 
> 
> I would highly appreciate if you tell the EAP WG your plans 
> regarding EAP-PSK.
> 
> Probably, the advantage to build a nice protocol around a 
> single cryptographic
> component is not as worthful as the fact to switch between 
> public key and
> shared key, and to provide features as PFS, provisioning and 
> identity hiding,
> as EAP-PAX does so. I think this tug-of-war of efficiency vs. 
> security must 
> be analyzed in a broader scope (see also draft-salowey-guam-00.txt).
> 
> Weak credentials like a four digit PIN are very common today. 
> This morning, I 
> attempted to make wpa_supplicant and freeradius ready to 
> perform EAP-PSK. It
> has been cumbersome to type in the 16byte preshared key 
> (since hex, these are
> 32 chars). The feature to begin (at the very first 
> authentication) with a weak
> credential, which is though most human friendly, which is immediately 
> transformed into a more secure one was first claimed by 
> EAP-FAST (concept of
> PAC).
> 
> So, it appears that EAP-PAX wants to place in the mid between 
> EAP-FAST (lot of
> features, most requiring asymmetric crypto) and EAP-PSK 
> (simplicity, only 
> symmetric crypto). So, depending on the situation, a fast and 
> less secure 
> authentication as well as a few efficient but more secure 
> authentication 
> is possible. This is also the idea behind SKEME, the Secure 
> Key Exchange 
> Mechanism Protocol, developed by IBM in 1996, which serves as 
> theoretical
> background for my own (probably too academic) EAP method EAP-SKL. 
> 
> To conclude, I hope the discussion about preshared key 
> methods becomes more
> active, that we get soon a mature, secure pre-shared key EAP 
> method, and -
> from the customer's point of view - becomes as soon as 
> possible available in
> implementations.
> 
> 
> Thomas
> 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap