Subject: [Emu] Liaison Statement on ITU-T Recommendation X.1034

From: <[email-masked]>
Date: Thu, 7 Aug 2008 09:57:09 +0300

The liaison statement from ITU-T SG 17 on X.1034 ("Guideline on
extensible authentication protocol based authentication and key
management in a data communication network"), which was briefly
discussed in SAAG and EMU meetings, is now available here:

https://datatracker.ietf.org/liaison/466/

Joe and Alan: if the EMU WG members have comments about the 
specification, a liaison statement reply from EMU WG to ITU-T 
SG 17 would probably be a good idea; please coordinate making 
such reply.

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

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 7 Aug 2008 14:27:02 +0300

Here are a few random review comments.

Section 3.2: Terminology

The definition of PFS does not correspond to the crypto literature. Here
is the definition from the Handbook of applied cryptography:

"
12.16 Definition A protocol is said to have perfect forward secrecy if
compromise of long-term keys does not compromise past session keys.
", see 
http://www.cacr.math.uwaterloo.ca/hac/about/chap12.pdf

"
Finally, in the key management phase, 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. 

I am not so sure about the "server-compromised attack" and the "server
compromise-based dictionary attack". If the AAA server is compromised
then there is a big problem. You could delete all the subscribes and
create new onces, etc. 

Editorial: s/DIAMETER/Diameter

Figure 1: Editorial 
s/TDP/TCP
s/SCP/SCTP
s/UDP or IP/UDP over IP

When the topic was briefly discussed at the IETF meeting I was hoping to
see a long list of EAP methods being analysed. 

Now, I find only 4 EAP methods being described, namely
* EAP MD5
* EAP TLS
* EAP AKA
* EAP SRP (RFC 2945 http://www.ietf.org/rfc/rfc2945.txt is referenced
but this is not an EAP method. There was a proposal on the table a long
time ago, namely
http://tools.ietf.org/id/draft-ietf-pppext-eap-srp-03.txt, but as I far
as I can tell it never went anywhere. There are a couple of other ways
to accomplish the same results but the details would very likely vary
and the reference to the appropriate document would certainly help in
the analysis.).

The introductory words say:
"
Most well-known EAP methods are found to be noncompliant with the
criteria in Table
I.1. If some applications require the high-level EAP method, then new
EAP methods should be
developed in the future.
" 

There are EAP methods that provide additional properties but they are
not listed in the table.

Regarding Table 1.1: 

* Putting EAP-MD5 into the table isn't really so useful given that it
does not derive session keys. As such, it is pretty unsuitable for
everything you discuss in the document. It would be more appropriate to
investigate EAP-GPSK since it is meant to be a replacement for EAP-MD5. 

* If I recall the discussions correctly then providing completely
synchronized state between the peer and the eap server is not possible. 

* Resistance to dictionary attacks: EAP-MD5 -- only when the password /
key that is being used is randomly chosen. 

* "Confidentiality of Master Key" is not a good evaluation criteria for
an EAP method given that it is accomplished using mechanisms outside the
protocol. The same is true for "Seamless compatibility" as there is no
EAP method available that would not work with RADIUS or Diameter ---
otherwise it would probably not be an EAP method. 

* EAP-AKA provides some form of user identity confidentiality. 

* EAP-TLS provides fragmentation support

* Every EAP method can be updated to provide channel bindings; currently
no method provides it....

* Resistance to dictionary attacks: This is only applicable for methods
that use passwords. EAP-TLS and EAP-AKA do not use passwords and hence
it is more appropriate to say that this issue is not applicable. 

After reading through the document I was wondering what ITU-T is going
todo next? Analysing more EAP methods? Developing EAP methods? 

Ciao
Hannes

PS: A more detailed EAP method investigation can be found in the
following master thesis by Thomas Otto:
http://www-public.tu-bs.de:8080/~y0013790/thesis-otto-eapmethods.pdf

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext [email-masked]
>Sent: 07 August, 2008 09:57
>To: [email-masked]
>Cc: [email-masked]
>Subject: [Emu] Liaison Statement on ITU-T Recommendation X.1034
>
>The liaison statement from ITU-T SG 17 on X.1034 ("Guideline 
>on extensible authentication protocol based authentication and 
>key management in a data communication network"), which was 
>briefly discussed in SAAG and EMU meetings, is now available here:
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 8 Aug 2008 08:30:31 -0700

Please send comments no later than 8/27 so we have time to prepare a
response.  

Thanks,

Joe

> Behalf Of [email-masked]
> Sent: Wednesday, August 06, 2008 11:57 PM
> To: [email-masked]
> Cc: [email-masked]
> on extensible authentication protocol based authentication 
> and key management in a data communication network"), which 
> was briefly discussed in SAAG and EMU meetings, is now available here:
>

---

From: Klaas Wierenga <[email-masked]>
Date: Fri, 08 Aug 2008 18:42:31 +0200

> Please send comments no later than 8/27 so we have time to prepare a

quick first glance comments:

- The EAP-methods they evaluate are not very much in line with what I 
think are the most widespread ones (is that because the other ones are 
only draft status?)

- EAP-MD5: they claim it provides mutual authentication

Klaas

---

From: Stefan Winter <[email-masked]>
Date: Mon, 11 Aug 2008 14:21:49 +0200

Hi,

> - EAP-MD5: they claim it provides mutual authentication

That table has a few more flaws.

EAP-MD5
--------------
- MD5 and Resistance to dictionary attacks. RFC3748 states "No", the ITU 
document states "Yes".
- MD5 and replay protection. Ditto.

EAP-TLS
-------------
- they quote RFC2716 as source, while this has been obsoleted by 5216
- 2.1.4 of RFC5216 explains how to achieve privacy, while the table in 
X.1034 states "No"

Luckily, the table is apparently not part of the recommendation, but an 
informational appendix only.

I have no experience with SRP and AKA to say more about these.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Tue, 12 Aug 2008 15:52:10 +0200

Hi,

> - MD5 and Resistance to dictionary attacks. RFC3748 states "No", the 
> ITU document states "Yes".

Further to these:

- why is Protection against the server compromise-based dictionary 
attack marked as "not applicable" for EAP-MD5? To perform MD5 auth, the 
server must be in possession of the user's clear text credential. If the 
server is compromised, an attacker can gain access to the backend 
password information. It seems to me that this criterion is very much 
applicable, and should be a No.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473