RE: CHAP secret lengths

["Dean Scoville" <dean.scoville@qlogic.com>]

Although it is true that any CHAP values sent across the wire
are encoded (hex or 64-byte constant, challenges, responses, etc.),
the CHAP secrets are never sent across the wire. They are only
concatenated with other info and fed into the MD5 algorithm
which always generates a 16-byte result.

Since the CHAP RFC describes the protocol as working on a stream
of octets, maybe we can infer that CHAP secrets MUST be a multiple
of 8-bits in length and that is the answer.

If this is true, perhaps the iSCSI draft describes CHAP secret
length requirements in terms of bits because some implementations
limit the secrets to ASCII character strings, which reduces the 
number of bits of randomness per byte and thus increases the number
of required bytes per secret.

-Dean

-----Original Message-----
From: Paul Koning [mailto:pkoning@equallogic.com]
Sent: Thursday, March 13, 2003 2:35 PM
To: Dean Scoville
Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu
Subject: Re: CHAP secret lengths


>>>>> "Dean" == Dean Scoville <dean.scoville@qlogic.com> writes:

 Dean> Julian, The MD5 algorithm (RFC 1321) can encode messages that
 Dean> are comprised of an arbitrary number of bits, and as such the
 Dean> message length need not be a multiple of 8-bits.

 Dean> The CHAP RFC (RFC 1994) describes the CHAP Response value as
 Dean> being a one-way hash calculated over a stream of octets,
 Dean> consisting of the Identifier, followed by (concatenated with)
 Dean> the "secret", followed by (concatenated with) the Challenge
 Dean> Value.

 Dean> This would lead me to believe that the CHAP secret must be an
 Dean> integral number of octets, even though the MD5 algorithm is
 Dean> capable of encoding messages that are not a multiple of 8-bits
 Dean> and even though the iSCSI draft uses units of "bits" (96 random
 Dean> bits, 128 bit random secrets, etc.) when referring to
 Dean> acceptable CHAP secret lengths.

 Dean> Can we assume that CHAP secrets will always be a multiple of
 Dean> 8-bits?  If not, do we need to pad the secret to a multiple of
 Dean> 8-bits (using 0's as pad bits, perhaps?) before concatenating
 Dean> it with the Identifier and Challenge values and running the
 Dean> result through the MD5 algorithm?

I don't think you need anything further.  The CHAP values are indeed
multiples of bytes.  That follows from the definition of the protocol
encoding.  They are carried as binary-values, which in this case
should always be a large-binary-value.  That's encoded as a
hex-constant or a base64-constant.  For both of these, the spec
defines the resulting length, which is described as a "byte-length"
and given by a formula that produces an integral number of bytes.

So yes, even though MD5 works on any bit count, CHAP doesn't, and
iSCSI already constrains it to byte multiples.

      paul