Re: CHAP secret lengths

[Paul Koning <pkoning@equallogic.com>]

>>>>> "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