The distinction between "passwords" and "random keys" is really open to interpretation using them in email is therefore somewhat problematic. A "random key" could be 8 uniformly random bits while a "password" could be drawn from a pool (each having equal likelihood of being chosen) of 2^16 entries. So let me interpret your email to mean that "passwords" are easy to guess and "random keys" are not.
On Wed, August 24, 2011 1:33 pm, Sam Hartman wrote: >>>>>> "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. But areas where passwords "might be used" are more expansive, and I might add include, the areas where one might have random keys. So something that has resistance to dictionary attack is "fine" everywhere that any secret blob credential (i.e. "password" or "random key") is used. In fact, if you have the ability to to provision 128-bit (or greater) blobs in disparate places then you have the ability to provision a certificate or something that makes EAP-GPSK pointless. If, on the other hand, you really really want to provision 128-bit blobs in lieu of certificates then you really have no need to do the tunneled method with an anonymous DH ciphersuite in phase 1. Just do EAP-GPSK and be done with it. > 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. No one is banning EAP-GPSK. You're free to use it. It just doesn't seem to make sense relaxing security requirements to provide solutions to problems that don't really exist. > I absolutely do not support EAP-PWD as a MTI for this document unless > EAP-PWD is moved to the standards track. So you're drawing a line in the sand over the capricious nature of a past IESG decision and not on security? Really? Why are you not running around insisting that RFC 2104 be moved to standards track? Dan. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
