Subject: RE: [eap] A synthesis on the existing (shared key) EAP methods...

From: <[email-masked]>
Date: Fri, 2 Apr 2004 15:34:55 +0300

Hi,

This document looks like a very useful summary of existing 
EAP methods, thanks for taking the time to write it!

I agree with you wish to standardize a replacement for EAP-MD5.
However, it's worth noting that the current version of 
draft-walker-ieee802-req practically requires the use of 
public key cryptography for this, since the "Dictionary attack
resistance" security claim MUST be supported.

2284bis says that "A method may be said to provide protection
against dictionary attacks if, when it uses a password as a
secret, the method does not allow an offline attack that
has a work factor based on the number of passwords in an
attacker's dictionary."

As far as I know, this requires either some form of public key 
cryptography, or enforcing that the shared secret cannot be 
chosen by the user. 

Using e.g. PBKDF2 from PKCS#5 is not sufficient, since the work 
load is still basically the same: if the user's password is the 
Nth word in the dictionary, an attacker can find it in N 
operations (each operation takes slightly longer than without 
PBKDF2, though).

As to the second alternative, IMHO totally prohibiting user-chosen
shared secrets would reduce the usefulness of EAP-PSK (or whatever
will be chosen as successor-of-EAP-MD5). 

However, I don't think this is an argument against EAP-PSK but 
instead an argument for making dictionary attack resistance a 
"SHOULD" instead of "MUST" in draft-walker-ieee802-req...

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Florent Bersani
> Sent: Friday, April 02, 2004 12:49 PM
> To: [email-masked]
> Subject: [eap] A synthesis on the existing (shared key) EAP methods...
> 
> 
> 
> ...is available at this URL before it reaches the archive: 
> http://eappsk.chez.tiscali.fr/draft-bersani-eap-synthesis-shar
> edkeymethods-00.txt
> 
> Any comments, feedback or additional information is most welcome.
> 
> Florent, who wishes that a standard replacement for EAP-MD5 
> be drafted (not especially EAP-PSK which is only a proposal 
> to stimulate the community ;-))
> 
> P.S : (Abstract of the draft) The purpose of this draft is to 
> gives a broad picture of the existing proposed EAP methods, 
> with a focus on shared key EAP methods. Indeed, it is the 
> belief of the author that a standard replacement for EAP-MD5 
> (that is deprecated due to security reasons) is needed. By 
> listing the existing shared key EAP methods, the goal is to 
> gather consensus that such a multiplication of methods is 
> detrimental and that a single method retaining the best of 
> the existing proposals could and should be drafted. 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Florent Bersani <[email-masked]>
Date: Fri, 02 Apr 2004 18:12:52 +0200

Hi Pasi,

I agree with your remark.

Although, I would rather have dictionary attack resistance (as per RFC 
2284bis definition) in all EAP methods (in particular, those compliant 
to IEEE 802 requirements), I think that enforcing a MUST might be 
premature and that more discussion is needed to perhaps relax it to a 
SHOULD, since as you clearly point out a MUST places very strong (too 
strong?) requirements.

See some more comments in-line.

Best regards,
Florent

>EAP methods, thanks for taking the time to write it!
:-)

>I agree with you wish to standardize a replacement for EAP-MD5.
Great, at least I have on official supporter. Others?

>has a work factor based on the number of passwords in an
Thanks for pointing this out!

In fact, I find this definition a little bit problematic, since it is 
not that trivial to scientifically define what is meant by resistance 
against dictionary attacks (cf. the existing definitions available at 
the URL given below). One could argue that it does not make much sense 
as is, since it does not specify that the number of passwords in an 
attacker's dictionary must be essentially the *only* factor the 
complexity of the attack depends upon and it does not differentiate 
between a linear and an exponential complexity and does not speak of the 
best attack,... ;-) However, I bet it is however quite reasonable as 
everybody ought to understand what is informally meant.

I also find it to be quite a tight definition since it imposes 
resistance to off-line attacks making no difference between for instance 
EAP-MSCHAPv2 and EAP-PSK, although EAP-PSK offers informally IMHO better 
resistance to dictionary attacks thanks first to the mapping between 
password and shared key provided in Annex B and second thanks to MAP (a 
Nonce from the client *and* a nonce from the server is included in the 
first MAC)...

I (quickly) looked for discussions on the definition in the mailing 
archive and came across the following:

-----------

*Original definition:*

"Where password authentication is used, users are notoriously prone to 
selection of poor passwords. A method may be said to be dictionary 
attack resistant if a brute force attack would require, on average, 
sorting through 2^64 or more possibilities. This can be accomplished, 
for example, by avoiding the use of passwords altogether (e.g. 
certificates, token cards), or by using a shared secret with 
sufficiently high entropy."

-----------

*Discussion on Dec 11 2002*

"Bernard Aboba: Is the text on dictionary attack sufficient? Glen: Does 
not sound too good yet. Bernard: Even liveness doesn't prove resistance. 
Glen: Last part makes sense. Jari: I would just put in that the spec 
must describe whether you are vulnerable to dictionary attacks. Glen: 
There is a difference between dictionary attack to a weak password vs. a 
method. DECISION: The following text can be used: Assuming there is a 
weak password in the secret, does the method allow a an attack better 
than brute force? John: There is a further distinction between off-line 
and on-line attacks. DECISION: Let's not describe different variants of 
dictionary attacks, instead reference text books on the subject.

-----------

*Second definition:*

"Where password authentication is used, users are notoriously prone to 
selection of poor passwords. A method may be said to be dictionary 
attack resistant if, when there is a weak password in the secret,  the 
method does not allow an attack more efficient than brute force."

-----------

*Discussion by David Jablon (with Uri and Bernard)*

"I see some potential confusion in the proposed EAP-04 definition
for Dictionary attack protection
On Monday, July 7, 2003 8:09 PM -0700 Bernard Aboba 
<[email-masked]> wrote:
 >>"7.2.1 Security claims terminology for EAP methods
...
 >>  Dictionary attack protection
 >>             Where password authentication is used, users are
 >>             notoriously prone to select poor passwords.  A method may
 >>             be said to be dictionary attack resistant if, when there is
 >>             a weak password in the secret,  the method does not allow
 >>             an attack more efficient than brute force.
Here's a suggested rewording.
        "Where password authentication is used, passwords are
        commonly selected from a set that is small,
        as compared to a set of N-bit keys.  A method may
        be said to be dictionary attack resistant if, when it uses
        a password as a secret, the method does not allow
        an offline attack that has a work factor based on
        the number of passwords in an attacker's dictionary."
The changes are intended to address the following concerns:
-- Since dictionary attack may be regarded as a form of brute force attack,
a reader might wonder how dictionary attack could ever be more efficient 
than
brute force attack.  A significant distinction can be drawn if "dictionary"
more clearly refers to a work factor based on the set of password guesses
rather than key size.
-- Underqualified use of derogatory terms like "poor" and "weak" leads to
a confusingly circular definition.  The value of using a specific password
depends, in part, on the characteristics of the method, one of which is 
being
defined here.
-- Users are not alone in being responsible for selecting passwords from
a small set.  Systems, including their developers and administrators, are
"notoriously prone" to encouraging such practice too.
-- There was no mention of whether the attack is offline or online.

-----------

*Uri's suggestion*

Here's a suggested rewording.

         "Where password authentication is used, commonly selected
          passwords are weak because they are selected from a
          small set (as compared to a set of N-bit keys).
          A method may be said to be dictionary attack resistant if,
          when it uses a password as a secret, the method does not allow
          an offline attack that has a work factor based on
          the number of passwords in an attacker's dictionary."

-----------

*David's reply*

The first sentence in the above version has a problem similar to the 
original
version.  It does not make sense to characterize password quality outside
the context of a specific method.  How about:

        "Where password authentication is used, passwords are
        commonly selected from a small set (as compared to a set
        of N-bit keys), which raises the concern of dictionary attack. ..."
       
-----------

Since, it appears that the current definition comes from David Jablon 
(the author of SPEKE), hence somebody much more expert in the field than 
I am, I won't keep on arguing uselessly, I'll go back to esoteric books 
and experts and see if I can do better ;-)

>cryptography, or enforcing that the shared secret cannot be 
This theme is really interesting and I stumbled against it while writing 
my synthesis and examining SRP-SHA1 and EAP-SPEKE.

Since I am (not yet ;-)) familiar enough with the domain, I won't keep 
expanding my informal remarks (like the bad ones on the dictionary 
attack definition).

A nice link on the matter is http://www.integritysciences.com/links.html

I am in touch with cryptographers to gain more understanding and I'll 
try and come back to the list to give some insights.

>operations (each operation takes slightly longer than without 
All is in evaluating how slightly, though ;-) In some cases you can 
precompute with your dictionary in other you cannot, as you perfectly know

Do we (for a replacement for EAP-MD5) or IEEE 802 (for the requirements 
on EAP methods) really want a requirement this strong on dictionary 
attacks... Frankly, I don't know.

My conclusion in the synthesis on shared key EAP methods was to study 
more carefully the pros and cons between say SRP-SHA1/SPEKE and EAP-PSK. 
And frankly I am not that biased to have an a priori conclusion - the 
former methods seemed to have IPR encumbrance but I think those can be 
avoided and also seemed to require some heavier implementations. However 
I do not think that these points are really valid and as of now, I think 
that if we can get the same IPR freeness and performance with the former 
as with the latter (my answer is probably yes) then we should drop the 
latter :-(

>will be chosen as successor-of-EAP-MD5). 
BTW, I'll update the security claims section of EAP-PSK to indicate that 
it does unfortunately not provide dictionary attack resistance under the 
RFC 2284bis definition and the text about IEEE 802 requirements :-(

>"SHOULD" instead of "MUST" in draft-walker-ieee802-req...
I tend to concur