Hold on a second there Hao. A security proof was never a requirement. I'm not aware of any other IETF protocols that required security proofs or even have security proofs. There is no formal proof required of the tunneled methods and I think it would be very difficult to do one.
One of the problems with the tunneled solution is the "consistency principle" described in Hugo Krawczyk's SIGMA paper. The tunneled methods violate that security requirement. And the fact that these things can be repeatedly tunneled ad nauseum amplifies that violation. A use case? Surely you have noticed the friction between usability and security. Security needs bootstrapping of some sort and typically that is problematic for many people especially when they need to bootstrap a large number of distinct security associations. So they cut corners. How are these corners cut? "Do not verify server certificate". That's why that little check box exists. Because people don't want to enroll everybody/everything into a CA. So they use a self-signed certificate and check the "Do not verify server certificate" check box. And then they send a password over this "encrypted tunnel". So the use case is robust security that cannot be provisioned insecurely. It's scalable and doesn't require the cutting of corners by administrators who are too busy (or frankly lazy) to do it the Correct Way. I have used the "it's their network and if they aren't so concerned about security then who am I to force a workload on them" comments in the past but it really is disingenuous. There are frightfully many deployments of password-authentication-through- encrypted-TLS-tunnel that use self-signed certificates and then something analogous to PAP. And they are done that way because there isn't a viable standard alternative. That is the use case for EAP-pwd. Oh, and it can satisfy the "consistency principle" too. :-) Dan. On Mon, April 28, 2008 8:10 am, Hao Zhou (hzhou) wrote: > Yoav: > > I thought we had clear consensus in IETF 71 WG meeting and instructed by > the AD that while Dan's proposal is an interesting one, but it doesn't > work with the legacy password databases and thus out-of the scope of the > charter. Until we have the proof of security analysis and clear of IPR > issues, the WG is going to work on the tunnel method. I think this is > the use case, legacy password database, the working group is currently > working on and Gene is talking about > > Can you also explain why in the three use case you cited, EAP-GTC or MD5 > doesn't meet the requirements, as they are all running inside an > authenticated and encrypted tunnel? > > > ________________________________ > > 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 > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
