What is the difference between defining a new method vs. a new version of the existing EAP method that is not backward compatible? I don't see how the implementation issue will go away. Some one still needs to implement it and customers need to deploy it. Might be more confusing to define another version of TTLS, as there are two version defined already, version 0 and 1. It seems to me much cleaner to start from a standard based EAP method handling password-only, and gradually extending it over time.
> -----Original Message----- > From: Ryan Hurst [mailto:[EMAIL PROTECTED] > Sent: Monday, April 02, 2007 3:48 PM > To: Joseph Salowey (jsalowey); Bernard Aboba; [email protected] > Subject: RE: [Emu] Thoughts on Password-based EAP Methods > > 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 > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
