On Wed, August 24, 2011 12:15 pm, Sam Hartman wrote: >>>>>> "Dan" == Dan Harkins <dhark...@lounge.org> writes: > > Dan> and MUST support EAP-pwd [RFC 5931] as a phase 2 method. > > > I support all of dan's changes regarding unauthenticated server mode > with the exception of the quoted text above. I do not generally support > a down-reference to an informational document in a case like this. (It > would need to be a normative reference in that context). I don't think > RFc 5931 is an appropriate mandatory-to-implement. I'm not sure we have > any MTI choices for this other than GPSK. > > I'd be happy either with GPSK or leaving the MTI eap method unspecified. >
EAP-GPSK is not resistant to dictionary attack and therefore would be unqualifed to be used according to the changes I propose that you already support (i.e. that the EAP method be resistant to dictionary attack). Regarding what it means to be resistant to a dictionary attack, let me quote some experts in the field [1], "One sees whether or not one has security against dictionary attacks by looking to see if maximal adversarial advantage grows primarily with the ratio of interaction to the size of the password space." You will note that with GPSK it does not. Given a password space of X (all numbers less than 2^128, or the words from Webster's, whatever) there can be one single interaction followed by computational work to exhaustively go through the password space seeing if a guess is correct. The adversarial advantage grows through computation and not interaction. Increasing the size of the password space (which is what EAP-GPSK recommends) may make a successful dictionary attack harder but it does not magically make a protocol resistant to dictionary attack. On the other hand, EAP-pwd is resistant to dictionary attack. Normative reference to Informational RFCs is done all the time. What would we do without RFC 2104! regards, Dan. [1] Mihir Bellare, David Pointcheval, and Phillip Rogaway in "Authenticated Key Exchange Secure Against Dictionary Attack". _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
