Bernard: I am not sure reusing one of the existing EAP methods is the right approach. All three EAP method mentioned, EAP-TTLS/PEAP/EAP-FAST all has something that are outside the scope of the charter, which means we have to take some of them out. Not unitl we change the charter, then we can pick one of them and declare victory. Some (if not all) are also missing some features required, like crypto-agility, etc. This means we will change the existing protocol and make it not backward compatible. There will be the same issue with implementation whether a new EAP method or a modified EAP method. I think part of the benefits of defining a new standard EAP method, people will want to implement it, as opposed to implement according to some expired draft. The design team are aware of TTLS and is working towards something that will probably be similar and much simpler. We try to strive for something simple but extensible, then over time we can enhance it as it is in IETF control.
EAP-TTLS itself also has its own issues: 1. It's internal AVP uses Radius attribute, I am not sure that' a good idea. 2. There is also TTLSv1 draft, which is quite different than v0. I am not sure about there are actual implementations or not. But if we create another modified TTLS from TTLSv0, it might create confusions. 3. The patent issue mentioned by Pascal. > -----Original Message----- > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 27, 2007 11:07 AM > To: emu@ietf.org > 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@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
