I share the concerns expressed about defining yet another password based EAP method. As people have pointed out here, EAP-TTLSv0 also allows the use of the TLS record layer to carry a password-based authentication method without an inner tunneling of EAP.
Several months ago, I tried contacting Paul Funk, Bernard and Jari to see if there would be an interest in publishing EAP-TTLSv0. Since we never heard from Paul, that communication fizzled out. We (in Qualcomm) have an implementation of PEAPv0, PEAPv1 and TTLSv0 and would like to see the IETF publish a standard for at least one of these methods, preferably TTLSv0. The choice of an EAP method to use with some legacy authentication mechanisms in 3gpp2 has been pending for a while, due to the lack of IETF activity with respect to these protocols. Publishing a new password-based method is not going to solve this problem, since there is considerable resistance to implementing another method. I'm glad to hear from Steve here that there is support for publishing TTLSv0. I would like to see that happen regardless of whether it is done as an EMU work item or not. Vidya > -----Original Message----- > From: Stephen Hanna [mailto:[EMAIL PROTECTED] > Sent: Monday, April 02, 2007 3:00 PM > To: emu@ietf.org > Subject: [Emu] Re: Thoughts on Password-based EAP Methods > > 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: 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 at ietf.org > https://www1.ietf.org/mailman/listinfo/emu > > _______________________________________________ > 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
