I believe there were many issues with how PEAP progressed, if we are careful we could prevent the same things from happening with TTLS.
Ryan -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 12:36 PM To: Bernard Aboba; [email protected] Subject: RE: [Emu] Thoughts on Password-based EAP Methods I'm not sure that adding yet another version to TTLS specifically for supporting passwords will make things better for customers. Multiple versions certainly has caused quite a confusion in PEAP. > -----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 > [email protected] > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
