On Wed, August 24, 2011 5:19 pm, Sam Hartman wrote: > > EAP-PWD has not met process hurtles that are important for IETF > standards.
Thanks, in part, to you. > In particular there are a number of approaches for doing that > sort of password method; we haven't decided that's the one we want to > use. That's right "we" haven't decided on One Way To Do It(tm). Nor are "we" planning to. So you're appealing to wait for the conclusion of a process that does not exist and has no plans of being started? That's absurd. There are security properties that you said you agreed are important. I am suggesting to use a method that satisfies those properties for the purposes of interoperability. Just because you don't like my choice (and apparently "we" haven't used a non-existent process to choose) doesn't mean the security properties should be downgraded. > If EAP-PWD had the sort of deployment MSCHAPv2 had, I'd support an RFC > 3967 down-ref to it: the market has spoken and MSCHAPv2 has significant > deployment. I refer you to section 4 of RFC 3967, "On the other hand...." > However, a normative down-ref to EAP-PWD would be an > end-run around the question of whether EAP-PWD is the method that does > approximately what it does that we want to recommend. That decision > should be faced directly not as part of some other spec. I can assure you that EAP-pwd is "the method that does approximately what it does". That is tautologically true. First you were opposed because it amounted to a normative reference to an Informational RFC, but that's not a consistent position to take (see RFC 2104). So now it's that "we" haven't decided on what password method to use. But "we" have not decided to use MSCHAPv2 or EAP-GPSK to handle password authentication either. Using either of those is likewise an "end-run around the question [of] what we want to recommend." But for some reason you bring these flawed protocols up as alternatives to EAP-pwd. So why are you really opposed to protocols being resistant to dictionary attack? Dan. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
