>>>>> "Dan" == Dan Harkins <dhark...@lounge.org> writes:
Dan> 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
Dan> be unqualifed to be used according to the changes I propose
Dan> that you already support (i.e. that the EAP method be resistant
Dan> to dictionary attack).
OK. Then I think we need to broaden up your text somewhat. I think
GPSK is fine in a deployment where you expect random keys. I think
something that has offline dictionary attack resistance would be fine in
an area where passwords might be used.
I'd like to relax your text to permit both.
Dan> Regarding what it means to be resistant to a dictionary
Dan> attack, let me quote some experts in the field [1], "One sees
Dan> whether or not one has security against dictionary attacks by
Dan> looking to see if maximal adversarial advantage grows primarily
Dan> with the ratio of interaction to the size of the password
Dan> space."
I think that definition is OK. I don't want us to require ZKPP to get
the dictionary attack resistance security claim. I agree GPSK should not
have the dictionary attack resistance security claim.
I do want GPSK to be permitted in environments where it is appropriate.
I absolutely do not support EAP-PWD as a MTI for this document unless
EAP-PWD is moved to the standards track.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
