Yoav, I ask for some latitude in my choice of words to describe some of the use cases that interest me. It feels to me (possibly its must me being naive) that we are tip-toeing around the dual use of some EAP methods to support some interesting use cases. These use cases are out of scope for EMU.
Explicitly I am interested in both authentication which is in scope for EMU and NAC which is out of scope. The tunneled EAP methods, esp. EAP-FAST and EAP-TTLS, are used for both purposes. We can easily create methods that would only meet the needs of authentication and useless for NAC. I am not interested in spending efforts to such an outcome. Gene ------------------------------------------------------------------------ ---- Eugene Chang (genchang) Cisco Systems Office: 603-559-2978 Mobile: 781-799-0233 Skype: gene02421 ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yoav Nir Sent: Monday, April 28, 2008 8:13 AM To: emu@ietf.org Subject: Re: [Emu] EMU charter revision Gene Chang said: Dan, I am not sure I am able to clearly understand the end result you seek. It seems there is a clear consensus for a tunneled method. Are you pushing for the addition of a tunneled method? Ok... I am easily baited. What would you like to see to achieve more than a snail race? I am assuming we both believe the term "snail race" is a pejorative. Thus I ask you, how do we do better? I clearly hear your comment that there have been a paucity of comments, if nothing else, simply to affirm we are on track. I agree with the proposed charter. I am open to a discussion to add a non-tunneled method if there is sufficient demand. A non-tunneled method does not seem to promise enough features for the use cases that interest me. Gene Hi Gene, You did not specify what the uses that interest you are, and I don't know about the use cases that interest Dan either, but I can speak for the use cases that interest me. EAP has been used in several cases as a magic way to use legacy credentials in protocols. I'll cite three examples: 1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, Apple, Cisco and others, where an EAP method is used to authenticate the user. 2. IKEv2 (RFC 4306) where EAP is used to magically authenticate the initiator using non-cert and non-PSK credentials. 3. TEE (draft-nir-tls-eap-03) where EAP is used to authenticate the user. In all three cases EAP is used by a protocol inside an encrypted tunnel, where the server, which is either trusted by the authenticator or co-located with it is already authenticated by a certificate or PSK. IMO EAP was used in all cases an some magical way of making passwords into a secure authentication mechanism. The problem is that there really is no publicly available EAP method for passwords. Tunneled methods don't really make sense here. There's no benefit in putting a TLS tunnel inside an IKEv2 exchange just to pass the password. Something like EAP-SRP would be great if it (a) existed and (b) didn't have all that IPR baggage. The method that Dan is proposing would also be beneficial here, if we could get a WG behind it so we can get some solid security review. Instead, what implementors are doing is EAP-MD5 or EAP-GTC, which don't quite meet the requirements for any of the above protocols. Yoav
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
