Subject: RE: iSCSI: BASE64 and numerical values

From: "Julian Satran" <[email-masked]>
Date: Tue, 21 May 2002 21:28:00 +0300

Bill,

Your point was clear. I am still loking at the cases where LARGE NUMBERS 
might be needed and I am sure we don't want them to be strings but 
numbers.

Julo

Bill Studenmund <[email-masked]>
05/21/2002 07:27 PM
Please respond to Bill Studenmund

        To:     Robert Snively <[email-masked]>
        cc:     Julian Satran/Haifa/IBM@IBMIL, <[email-masked]>
        Subject:        RE: iSCSI: BASE64 and numerical values

On Tue, 21 May 2002, Robert Snively wrote:

> I have been having continuing problems understanding why
> iSCSI is considering any use of base64, and I find myself
> in total agreement with Bill's clear exposition of the
> situation.
>
> Upon reviewing RFC-2045, it is clear that base64 is a method
> for containing handy binary values in a EMAIL structure that does
> not use TCP/IP to transmit data, but rather uses obsolete
> 7-bit ASCII or (slightly less obsolete) EBCDIC strings to
> carry the data.  TCP/IP transmits data neutral octets,
> so binary values can be carried in their native binary
> string format (allowing for a possible requirement to pad
> strings to an octet boundary).  The most standard way to
> present those binary strings on a printer or as an input
> value to a program is hexadecimal encoding.
>
> For those reasons, I agree with Bill that we should delete
> base64 from the text and use hexadecimal as he suggests.

I must not have been totally clear. I'm not suggesting we remove base64,
I'm suggesting we limit its use to the cases where (IMHO) it makes sense.
While there will be much fewer cases in the text with the changes I
suggest, it will still be in the spec.

Some of the cryptographic authentications throw around large binary
strings. Quite large (compared to the numbers and strings we often use)
binary strings. The fact that if you support these modes of authentication
you are supposed to be able to accept four times as much text in login
commands reflects the size of these strings.

Base64 is a real win for these. Hex can encode 4 bits per byte, while
base64 can encode 6. Thus an n byte string will be about 1.33*n bytes in
base 64, while it will be 2n bytes in hex. That size difference is why we
want base64.

The main point I've been trying to make is that binary strings and numbers
are different things, and that encoding methods for one aren't really
appropriate for the other. Specifics: decimal & hex work great for
numbers, and hex and base64 work great for binary strings. That's it.
Also, the hex for numbers isn't the same as the hex for binary strings.
One is the number in hex, the other is more like hexdump -x without the
spaces and without the offsets.

Take care,

Bill

---

From: Bill Studenmund <[email-masked]>
Date: Tue, 21 May 2002 11:37:54 -0700 (PDT)

> might be needed and I am sure we don't want them to be strings but

Sounds excelent.

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.

Take care,

Bill

---

From: Paul Koning <[email-masked]>
Date: Tue, 21 May 2002 16:06:05 -0400

> ones I came up with felt heavy and cumbersome.

CHAP challenges are strings, not numbers.

     paul

---

From: Bill Studenmund <[email-masked]>
Date: Tue, 21 May 2002 13:21:11 -0700 (PDT)

> CHAP challenges are strings, not numbers.

Ahh.. You are correct. I had a brain-freeze about how exactly CHAP worked
(how you generated the response).

Take care,

Bill

---

From: "Michael Krueger" <[email-masked]>
Date: Tue, 21 May 2002 14:09:06 -0700

> 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:[email-masked]
Wind River Networks                         http://www.windriver.com
500 Wind River Way                               phone: 510-749-2130
Alameda, CA  94501                                 fax: 510-749-2010

---

From: Bill Studenmund <[email-masked]>
Date: Tue, 21 May 2002 14:20:05 -0700 (PDT)

> > ones I came up with felt heavy and cumbersome.

Please note I was mistaken about CHAP. It uses strings, so numbers don't
need lengths AFAIK.

> I think we've been making this more complicated than necessary.  Here's what

Probably. :-)

> BASE-64 REPRESENTATION OF A BINARY ITEM

[snip]

> to a multiple of eight bits.  Let N be the number of digits in the string

Sounds good. Also, if we don't, when decoding hex strings, you have to get
to the end of the string to figure out if you have an odd or even # of
nibbles. Really messy.

> accompanied by second key that functions as an explicit length field.

Sounds good.

Take care,

Bill