| Re: A synthesis on the existing (shared key) EAP methods... | <– Date –> <– Thread –> |
From: Florent Bersani (florent.bersani rd.francetelecom.fr)
|
|
| Date: Fri, 2 Apr 2004 11:01:00 -0500 (EST) | |
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.
Pasi.Eronen [at] nokia.com wrote:
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 <aboba [at] internaut.com> 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.
-----------
*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 ;-)
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.
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 :-(
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
Pasi.Eronen [at] nokia.com wrote:
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.Great, at least I have on official supporter. Others?
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 attackThanks for pointing this out!
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."
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 <aboba [at] internaut.com> 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 ;-)
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.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.
All is in evaluating how slightly, though ;-) In some cases you can precompute with your dictionary in other you cannot, as you perfectly know
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).
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 :-(
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 :-(
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).
I tend to concur
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: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com]On Behalf Of
ext Florent Bersani
Sent: Friday, April 02, 2004 12:49 PM
To: eap [at] frascone.com
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.
-
A synthesis on the existing (shared key) EAP methods... Florent Bersani, April 2 2004
-
RE: A synthesis on the existing (shared key) EAP methods... Pasi.Eronen, April 2 2004
- Re: A synthesis on the existing (shared key) EAP methods... Florent Bersani, April 2 2004
-
RE: A synthesis on the existing (shared key) EAP methods... Pasi.Eronen, April 2 2004
Results generated by Tiger Technologies using MHonArc.