Subject: Generation of CHAP Secrets...

From: [email-masked]
Date: Tue, 20 Aug 2002 13:05:38 -0400

Do the following statements mean that users should not be allowed to create
their own secrets (passwords) to ensure the randomness of all secrets? 
 
When CHAP is performed over a non-encrypted channel, it is vulnerable
to an off-line dictionary attack. Implementations MUST support
use of up to 128 bits random CHAP secrets, including the means to
generate such secrets and to accept them from an external generation
source. Implementations MUST NOT provide secret generation (or expansion)
means other than random generation.
 
---
Adam

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 20 Aug 2002 22:09:50 +0300

That is correct.  It also says that you should not knowingly provide means 
to extend a "short(weak)" secret into an apparently long secret.

Julo

[email-masked]
Sent by: [email-masked]
08/20/2002 08:05 PM

        To:     [email-masked]
        cc: 
        Subject:        Generation of CHAP Secrets...

Do the following statements mean that users should not be allowed to 
create their own secrets (passwords) to ensure the randomness of all 
secrets? 

---
Adam

---

From: [email-masked]
Date: Tue, 20 Aug 2002 22:53:11 EDT

the iSCSI draft talks of up to 128 bits of shared secret. While performing 
HASH, the MD5 will yield 128 bits, but SHA-1 (recommended Hashing algorithm, 
Sec 7.3.1) will generate 160 bits.  Seems to me that the shared secret should 
be allowed to be up to 160 bits..unless we allow MD5 for CHAP and then 
possibly pad the hash? Or am I missing something here?

---

From: [email-masked]
Date: Wed, 21 Aug 2002 09:50:08 -0400

> possibly pad the hash? Or am I missing something here?

There's no inherent upper limit on the size of the shared secret and it's
not related to the output size of the hash algorithms.  128 bits is more
than enough to get the job done, hence there's no need to require that
implementations support more than that.  Generating more random bits and
tossing some of them away is fine (e.g., IPsec ESP does exactly this to
make its MD5 and SHA-1 HMACs fit in 96 bits), but they have to be *true*
random bits - more below.

While SHA-1 is the required hash for IPsec ESP, it does not work with
CHAP for historical reasons (one has to use MD5) - see, the IANA registry,
the PPP AUTHENTICATION ALGORITHMS section of:

	http://www.iana.org/assignments/ppp-numbers

While I'm sure Vijay did not mean to imply this, I want to warn
implementers away from a potentially disastrous implementation shortcut:

	**DO NOT** run a weak secret (e.g., password) through a hash
	or similar algorithm to generate something that appears to be
	a sufficiently-sized random CHAP secret.

The result of doing this is no stronger than the original weak
secret (e.g., password) - if this shortcut technique is used, the
result falls under iSCSI's "MUST enforce IPsec encryption" language.

This is a well-known implementation mistake (e.g.,
Netscape was publicly bitten by it several years ago).  A specific
example is that if one runs a password with 15 bits of randomness through
MD5, the resulting 128 bit output still has 15 bits of randomness - an
attacker need only run the dictionary words through MD5 [15 bit search
space] to mount an exhaustive attack, and the fact that the quantities
being checked are 128 bits in size does not improve security.

If one wants 128 bits of randomness, one needs to start with 128 random
bits - it really is that simple.  Using a hash does not increase the
amount of randomness.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: [email-masked]
Date: Wed, 21 Aug 2002 18:10:31 -0400

Bill,

> How will my endpoint determine the randomness of the CHAP key and
> therefor determine if the CHAP key is valid for the encryption level of
> the link ?  I am assuming by the requirement as stated that I have to
> test the CHAP secret for randomness to determine that there are really
> more than 96 bits of randomness in the secret, and if there are not, and
> the link is not encrypted reject the connection.

The randomness requirement is placed on the "administrative entity" which
is not the iSCSI protocol endpoint.  The CHAP secret does not have to
be checked for randomness *by the iSCSI endpoint* (good thing, as it's
not possible to check a bit string for a minimum amount of randomness if
one does not know how it was generated).  The thing that an iSCSI endpoint
SHOULD do is check the size of the CHAP secret if it can determine it (e.g.,
if an external RADIUS server is being used, an iSCSI endpoint may not know
the size of the CHAP secret being used to authenticate its peer):

   A compliant implementation SHOULD NOT continue with the login step in 
   which it should send a CHAP response (CHAP_R - Section 10.1.4 Chal-
   lenge Handshake Authentication Protocol (CHAP)) unless it can verify 
   that either the CHAP secret is at least 96 bits, or that IPsec 
   encryption is being used to protect the connection.

Also, please note the following related requirement:

	Implementations MUST NOT provide secret generation (or expansion)
	means other than random generation.

This text prohibits the "disastrous implementation shortcut"
that I warned about in a previous message.

Thanks,
--David

---

From: [email-masked]
Date: Thu, 22 Aug 2002 14:30:18 -0400

Vijay,

> I believe, the secret size does have a direct impact on the cryptograohic
> strength of the hash. If the secret size is less than the hashed value of
> the algorithm, then it makes it easier for an exhaustive search attack.
For
> reference, here is a quote from the CHAP RFC page 3:
> 
>    The CHAP algorithm requires that the length of the secret MUST be at
>    least 1 octet.  The secret SHOULD be at least as large and
>    unguessable as a well-chosen password.  It is preferred that the
>    secret be at least the length of the hash value for the hashing
>    algorithm chosen (16 octets for MD5).  This is to ensure a
>    sufficiently large range for the secret to provide protection against
>    exhaustive search attacks.

iSCSI has gone above and beyond that by making the minimum length (MUST)
12 octets, and by requiring random generation, making its CHAP secrets
considerably larger and harder to guess than a well-chosen password.
The requirement for support of secrets up to 128 bits in size encompasses
the "preferred" language above.  Are you arguing that 96 bits of search
space (> 10**27 possibilities) is insufficient protection against an
exhaustive search attack?  I agree that more than 128 bits of secret
is pointless for MD5 because the output size bounds the size of the
search space at somewhere in the neighborhood of 128 bits.

Thanks,
--David