Sorry it took me a few days to respond to this thread. I agree with Bernard that there's no benefit in creating Yet Another Password-Based EAP Method (YAPBEM). There's no point in reinventing the wheel for a fourth time and it's not the IETF way. We're not researchers. We're practical engineers who respect running code and rough consensus. So, yes, we should have a bias toward existing, well-tested and well-understood protocols.
In a security group, it's especially important to avoid the temptation to reinvent the wheel. We should focus our efforts on one secure tunneled EAP method and make that one secure. We should consider existing methods and only invent something new if we need to. I have spoken to Paul Funk, the primary author of the EAP-TTLSv0 spec. He is glad to proceed as Bernard suggested: 1. Publish an updated EAP-TTLSv0 spec that documents current practice (as Informational or Experimental) 2. Give up change control to the IETF so that the EMU WG can make any necessary changes or additions to EAP-TTLS I'm also glad to assist with this effort, since Paul is pretty busy these days. Thanks, Steve -----Original Message----- From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 27, 2007 8:07 AM To: [email protected] Subject: [Emu] Thoughts on Password-based EAP Methods After listening to the IETF 68 presentation on a password-based EAP method, I would like to voice some concerns. Today we already have an "over abundance" of such methods. These include PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and EAP-FAST. In my discussions with customers, I invariably hear complaints about this explosion, and about various interoperability and compatibility problems that it causes. Simply put, customers do not want "yet another password-based EAP method"; they want a single method that is widely implemented and interoperable. I am concerned that by defining yet another password-based authentication mechanism, EMU WG will be making this problem worse, not better. Creating yet another mechanism which differs little from the existing ones also seems to have very little chance of being implemented. There is a better alternative that EMU WG should consider. This is to choose an existing method for inclusion on the IETF Standards Track, rather than creating a new one. In order to maintain backward compatibility, this would require that the owners give up change control to the IETF. I would suggest that the best candidate for this would be EAP-TTLSv0, since it is very widely implemented, and has an existing certification program in WFA. Also, EAP-TTLSv0 had previously been on the Standards Track in the PPPEXT WG, before work on EAP methods was removed from the PPPEXT WG charter and the EAP WG was formed. In terms of steps to be taken, this would require the following actions: a. Review and publication of the existing EAP-TTLSv0 specification as an RFC. The goal here would be to document EAP-TTLSv0 as it exists today. b. Agreement by the authors to give up change control to the IETF. c. EMU WG efforts to publish an EAP-TTLSv0 "bis" document, specifying additional capabilities (such as Channel Bindings). _______________________________________________ Emu mailing list Emu at ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
