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 PROTECTED] [mailto:[EMAIL PROTECTED] On >Behalf Of ext [EMAIL PROTECTED] >Sent: 07 August, 2008 09:57 >To: emu@ietf.org >Cc: [EMAIL PROTECTED] >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: > >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 >Emu@ietf.org >https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
