Liaison statement
Response to Liaison Statement on ITU-T Recommendation X.1034

The EAP Method update (EMU) working group in the IETF has reviewed the document
"ITU-T Recommendation X.1034" that is the subject of a liaison statement
submitted on 2008-08-06. 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.  The members of EMU WG
provided the following comments, which we hope are useful in finalizing the
contents of X.1034.

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. The server compromised-based attack appears not to be an attack, but rather
a way to mitigate the server compromised attack.  These definitions are 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 only 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 no 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 password-based issues are not applicable. iv.     RFC 5216 provides unique
naming for keys and sessions for EAP-TLS

5. EAP-AKA

i.      EAP-AKA provides 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