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

Reply via email to