Very nice writeup, Joe. You might want to point out to them that they can develop EAP methods and publish them as informational documents without any special reaon or new set of requirements even if other EAP methods already provide similar functionality.
>-----Original Message----- >From: [email protected] [mailto:[email protected]] On >Behalf Of ext Joseph Salowey (jsalowey) >Sent: 02 March, 2010 21:56 >To: [email protected] >Subject: [Emu] Draft response for ITU-T X.1034 liaison statement > >Below is a draft response to the ITU-T - X.1034 liaison statement. >Please review and indicate if it looks OK or if you have any >corrections or additions. > >Thanks, > >Joe > >Members of the IETF EAP Method Update working group have >reviewed the revised ITU-T X.1034 document. The following is >a summary of their >comments: > >1. Reviewers were not clear on the purpose of the document > >Reviewers did not really understand the purpose of the >document. There are several documents that discuss EAP method >requirements and classify EAP methods such as: RFC 4017, NIST >SP 800-120. > >Is the group aware of these documents? What is this document >providing beyond what is provided in these documents? > >2. Out-of-Date discussion of EAP > >The main part of the document does not include any reference >to much of the recent EAP work such as: > >RFC 5247 - Extensible Authentication Protocol (EAP) Key >Management Framework RFC 5296 - EAP Extensions for EAP >Re-authentication Protocol (ERP) RFC 5295 - Specification for >the Derivation of Root Keys from an Extended Master Session >Key (EMSK) RFC 5247 - Extensible Authentication Protocol (EAP) >Key Management Framework > >Also, in numerous places the document uses terminology specific to IEEE >802. For example, the document discusses "types of PTK", and "group >key handshake". Non-IEEE 802 technologies typically don't use >the term "PTK", and IEEE 802.1X-REV does not include a "group >key handshake". >Moreover the "general flow of key management" described in >Section 8.4 is not general at all, since this does not >describe the lower layer key management used in IKEv2 or IEEE 802.16. > >3. Out-of-Date discussion of EAP-Methods > >The appendices discussing EAP methods have improved, however >they still contain many discrepancies with the state of the >art. Appendix I claims it is presents an evaluation of the >most well-known EAP methods. >EAP-SRP is abandoned work so it is not clear how this would >qualify as well-known. EAP-MD5 cannot be used in environments >that require key generation so its evaluation is not all that >useful. Some additional methods are discussed in appendix >III, but there are not discussed in >Appendix I. It is not clear why there are two different appendices or >why the focus of appendix I is mostly on Obsolete or abandoned >protocols. Appendix I does not appear to provide much value. > >Appendix III contains many inaccuracies. > >- RFC 2284 was obsolete by RFC 3748. >- EAP-SRP is abandoned work >- There is a standards track PSK EAP method EAP-GPSK (RFC >5433), it would be better to include this in the analysis >- An improved EAP-AKA mechanism has been published in RFC 5448 >- EAP-FAST is also a tunnel method >- The PEAP internet draft has been abandoned, current >documentation of the PEAP protocol is available from Microsoft. > >4. Out of date references > >- For EAP RFC 3748 should be referenced instead of RFC 2284. >- RFC 2716 is been made obsolete by RFC 5216 >- The document should reference RFC 5247 - Extensible >Authentication Protocol (EAP) Key Management Framework >- The EAP-SRP reference is to an expired document >- The PEAP reference is to an expired document >- RADIUS references should include RFC 3579 > > >_______________________________________________ >Emu mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
