RE: [Emu] Thoughts on Password-based EAP Methods

["Hao Zhou \(hzhou\)" <hzhou at cisco.com>]

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:Ryan.Hurst at microsoft.com] 
> Sent: Monday, April 02, 2007 3:48 PM
> To: Joseph Salowey (jsalowey); Bernard Aboba; emu at ietf.org
> 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:jsalowey at cisco.com]
> Sent: Monday, April 02, 2007 12:36 PM
> To: Bernard Aboba; emu at ietf.org
> 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:bernard_aboba at hotmail.com]
> > Sent: Tuesday, March 27, 2007 8:07 AM
> > To: emu at 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 at ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 
> _______________________________________________
> Emu mailing list
> Emu at ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu