Subject: [Emu] Draft liaison response for ITU-T Recommendation X.1034

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 1 Sep 2008 23:40:39 -0700

Here is a draft liaison response for ITU-T Recommendation X.1034.
Please send any comments on this by Monday 9/8.  

Thanks,

Joe

The EAP Method update (EMU) working group in the IETF has review the
document "ITU-T Recommendation X.1034" that is the subject of a liaison
statement submitted on 2008-08-06.  Below is a list of issues that
members of the working group found with the document. Does the ITU-T
have further plans in this area, such as more EAP method analysis or
definition?  If so, perhaps more coordination between the IETF and the
ITU-T in this area is needed.

A. Comments on section 3.2

1. It is not clear if the definition of PFS aligns with the definition
in other documents such as from the "Handbook of applied cryptography"
(http://www.cacr.math.uwaterloo.ca/hac/about/chap12.pdf)

2. Does the server compromised attack require access to the password
file or is it the same as an offline dictionary attack?  If it requires
access to the password file then how is this different than the Server
compromise-based dictionary attack?  It seems that this is getting at
the requirements that a method imposes on its storage, but the
connection is not clear.  

B. Comments on section 6.1

1. In figure 1 - Replace TDP with TCP, SCP with SCTP and "UDP or IP"
with "UDP over IP" 
2. Throughout the document replace DIAMETER with Diameter
3. The following sentence is misleading: "the authenticator exchanges
random numbers with the supplicant to obtain a fresh cryptographic key;
thus resulting in perfect forward secrecy." Fresh keys are not
sufficient to fulfill the criteria for PFS. 

C. Comments on section 7.2 and 7.5

1. The "Prevention of domino effect or Denning Sacco attack" is a
property of the system and not specific to the EAP method.  
2. Authorization is not communicated in EAP.  It is communicated from
the Authentication server to the authenticator based on the identity
authenticated by EAP.  
3. The requirement for "Protection against server compromised dictionary
attack" is not clear.  If encrypted storage is all that is necessary
then why is this a property of a protocol and not just a specific
implementation detail?  
4. Section 7.5 states that the appendix can be used to select from many
existing EAP methods, however section I only analyzes a small subset of
EAP methods. 

D. Comments on table I-1:

General: EAP-MD5 and EAP-SRP are not widely deployed.  This section
claims to analyze "well-known" EAP methods, however it analyzes two of
the many methods that are deployed.  There are EAP methods that provide
additional properties but they are not listed in the table. There are
more detailed investigations available, such as
http://www-public.tu-bs.de:8080/~y0013790/thesis-otto-eapmethods.pdf. 

1. EAP-SRP 

i. EAP-SRP is not defined in RFC 2945.  There is not current
documentation for an EAP-SRP (There was a draft that expired many years
ago).  It is not clear what this evaluation was done against.   

2. EAP-MD5 

i. EAP-MD5 does not provide mutual authentication or resistance to
dictionary attacks
ii. EAP-MD5 does not provide protection from dictionary attacks.
EAP-MD5 can be used with passwords.  
Iii. In general EAP-MD5 is not very useful since it does not generate
session keys. It would be more appropriate to include EAP-GPSK. 

4. EAP-TLS 

i. EAP-TLS Can provide user identity privacy (RFC 5216, section 2.1.4)
ii. EAP-TLS Provides fragmentation support
iii. EAP-TLS does not use passwords and hence it is more appropriate to
say that this issue is not applicable.
Iv. RFC 5216 provides unique naming for keys and sessions for EAP-TLS

5. EAP-AKA 

i. EAP-AKA provides some support for user privacy
Ii. EAP-AKA does not use passwords and hence it is more appropriate to
say that this issue is not applicable.
iii RFC 5247 provides unique naming for keys and sessions in EAP-AKA

E. Comments on Bibliography

1. RFC-2716 is obsolete, EAP-TLS is defined in RFC 5216 
2. draft-ietf-eapkeying-21.txt has been published as RFC 5247

_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu