eap Mailing List: Future of EAP-PSK

[Thomas Otto (t.otto]

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