RE: iSCSI: BASE64 and numerical values

["Michael Krueger" <michael.krueger@windriver.com>]

> One thing I haven't figured out how to do is add implicit binary length to
> the numbers used for CHAP challenges (and possibly others). It's a little
> bit of semantics (since we define the length for binary strings), but the
> ones I came up with felt heavy and cumbersome.

I think we've been making this more complicated than necessary.  Here's what
I think is a relatively simple way to define the implicit lengths of binary
items that have been represented by hexadecimal or base-64 ASCII strings.

BASE-64 REPRESENTATION OF A BINARY ITEM

RFC 2045 states that "all base64 input is an integral number of octets";
therefore, base-64 representation is simply not appropriate for binary items
whose length is not a multiple of eight bits.  The RFC specifies a padding
mechanism from which the length of the original input may be determined
exactly (here, 'x' is an arbitrary base64 digit and '=' is the padding digit
specified in the RFC):

    string          input  input  padding  non-padding
    representation  bytes  bits   digits   digits
    --------------  -----  -----  -------  -----------

    0bxxxx              3     24        0            4

    0bxxxxxx==          4     32        2            6

    0bxxxxxxx=          5     40        1            7

    0bxxxxxxxx          6     48        0            8

I would suggest that iSCSI define the implicit length of a binary item
represented by a base-64 string representation as the number of "input bits"
in the table above.  More precisely, if N is the number of non-padding
(i.e., non-'=') digits in the string representation, the binary item's
length in bytes, L, is given by L = (N * 6) / 8, where '/' represents an
integer division.

HEXADECIMAL REPRESENTATION OF A BINARY ITEM

Suppose that, in analogy with RFC 2045, we limit the number of "input bits"
to a multiple of eight bits.  Let N be the number of digits in the string
representation, where N must even.  The binary item's (implicit) length in
bytes, L, is then given by L = N / 2.

I am not aware of any application in which the length of a binary item is
not a multiple of eight bits.  (It's certainly not the case for CHAP.)  The
only other multiple we could support without an explicit length field would
be multiples of 4 bits; however, this would only work with hex encoding, not
base64.  I therefore believe it makes sense to limit IMPLICIT binary item
lengths to multiples of eight bits.  If someone ever introduced a binary
item whose length were not a multiple of eight bits, it could simply be
accompanied by second key that functions as an explicit length field.

Michael

--
Michael J. Krueger              mailto:michael.krueger@windriver.com
Wind River Networks                         http://www.windriver.com
500 Wind River Way                               phone: 510-749-2130
Alameda, CA  94501                                 fax: 510-749-2010