Dan wrote: > The real thing holding up adoption of EAP-pwd as a work > item is finishing work on the tunneled method. Which wouldn't > be such a bad thing if we were further along towards that > goal after Philly than we were after Vancouver and from the > looks of it we won't be any further after Dublin than we were > after Vancouver. :-(
I don't think tunnel method is the real thing holding up the EAP-pw as a work item, so stop attacking the tunnel method or hurry it into some kind of "sword fight." As others pointed out, EAP-pw might be quite useful for multiple WGs and should be bring to SAAG. But security review and IPR analysis need to be done before any WG is willing to take that work, I think. > -----Original Message----- > From: Dan Harkins [mailto:[EMAIL PROTECTED] > Sent: Monday, April 28, 2008 2:36 PM > To: Hao Zhou (hzhou) > Cc: Dan Harkins; Yoav Nir; emu@ietf.org > Subject: RE: [Emu] EMU charter revision > > > Hao, > > On Mon, April 28, 2008 10:32 am, Hao Zhou (hzhou) wrote: > > 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. > > It is the consensus. I'm not challenging consensus, just > answering a question. "Do you approve of this charter?" Well, > no I don't. I was told by the ADs that EAP-pwd is outside the > current charter. Fine. We can't work on it but that doesn't > mean I approve of the charter; I don't, for that very reason. > If I'm asked again I'll give the same answer again. > > Don't blame me for the pace of the work in this WG. I don't > have a stake in the outcome of the only thing we're allowed > to work on. And I don't believe a quarterly email saying "I > don't approve" (of the charter) is enough to put those who do > have a stake in the outcome off their work schedules. > > > 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. > > Yes, I remember. But you said, "Until we have a proof...we > will work on the tunneled method." IPR issues, yes that will > probably hold things up. But a proof, no. No proof is > required prior to adoption as a work item. > If it was then where's the security proof for either tunneled method? > > The real thing holding up adoption of EAP-pwd as a work > item is finishing work on the tunneled method. Which wouldn't > be such a bad thing if we were further along towards that > goal after Philly than we were after Vancouver and from the > looks of it we won't be any further after Dublin than we were > after Vancouver. :-( > > > Why are we keeping bring this up? > > You asked why are tunneled GTC and tunneled MD5 not OK; you > asked what is the use case for EAP-pwd. I answered both: > consistency principle and a need for robustness, respectively. > > Dan. > > >> -----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
