Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id h2DNB6f10775
	for ips-outgoing; Thu, 13 Mar 2003 18:11:06 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h2DNB4M10771
	for <ips@ece.cmu.edu>; Thu, 13 Mar 2003 18:11:04 -0500 (EST)
Received: by lion.ninthwonder.com (Postfix, from userid 1021)
	id 3902030706; Thu, 13 Mar 2003 18:10:52 -0500 (EST)
Date: Thu, 13 Mar 2003 16:03:08 +0000 (UTC)
From: wrstuden@wasabisystems.com
X-X-Sender: wrstuden@neverwinter.home-net.icnt.net
To: Dean Scoville <dean.scoville@qlogic.com>
Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu
Subject: Re: CHAP secret lengths
In-Reply-To: <2A8D600C919D2D41A3DAA2D2FEC717143871FB@homer.qlogic.org>
Message-ID: <Pine.NEB.4.53.0303131553150.420@neverwinter.home-net.icnt.net>
References: <2A8D600C919D2D41A3DAA2D2FEC717143871FB@homer.qlogic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

On Thu, 13 Mar 2003, Dean Scoville wrote:

> Julian,
>
> The MD5 algorithm (RFC 1321) can encode messages that are
> comprised of an arbitrary number of bits, and as such the
> message length need not be a multiple of 8-bits.
>
> The CHAP RFC (RFC 1994) describes the CHAP Response
> value as being a one-way hash calculated over a stream of octets,
> consisting of the Identifier, followed by (concatenated with) the
> "secret",  followed by (concatenated with) the Challenge Value.
>
> This would lead me to believe that the CHAP secret must be an
> integral number of octets, even though the MD5 algorithm is
> capable of encoding messages that are not a multiple of 8-bits
> and even though the iSCSI draft uses units of "bits" (96 random
> bits, 128 bit random secrets, etc.) when referring to acceptable
> CHAP secret lengths.
>
> Can we assume that CHAP secrets will always be a multiple of 8-bits?

Yes. There's no real reason to support fractions of an octet. Also, the
crypto libraries I am familiar with only support hashing a number of
bytes, not bits.

> If not, do we need to pad the secret to a multiple of 8-bits (using
> 0's as pad bits, perhaps?) before concatenating it with the Identifier
> and Challenge values and running the result through the MD5 algorithm?

Note what you describe above is not supporting a secret whose length is
not a multiple of 8-bits, you describe turning such a secret into one
which is a multiple of 8-bits. So the hashing is still only working with
octets. That's something that can be done independently of iSCSI.

Take care,

Bill
