Dan: Now you have changed to argue that tunnel method is not the right solution for the use case EMU is targeted on, instead of arguing your proposed password should be included as addition to the tunnel method. I thought working on and standardizing the tunnel method is the WG consensus for few IETF meetings now, are you going to challenge that now? Maybe this also contributes to the "snail race" of tunnel method.
As for the password method you proposed, I was at the last IETF meeting and you can also verify from he meeting minutes. The consensus is to have more security reviews and the IPR analysis. Also, since the use case it targeted maybe more broader than the EMU WG, it was suggested to bring up in SAAG as well, as multiple WGs can benefit from it. But the direction from the AD is to finish existing work first. Why are we keeping bring this up? > -----Original Message----- > From: Dan Harkins [mailto:[EMAIL PROTECTED] > Sent: Monday, April 28, 2008 12:45 PM > To: Hao Zhou (hzhou) > Cc: Yoav Nir; emu@ietf.org > Subject: Re: [Emu] EMU charter revision > > > 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
