Subject: iSCSI: BASE64 and numerical values

From: "Julian Satran" <[email-masked]>
Date: Sat, 18 May 2002 11:31:28 +0300

Yes for regular numerical values it makes sense. We will have to keep it 
for large numerical values used for cryptography.  Julo
----- Forwarded by Julian Satran/Haifa/IBM on 05/18/2002 11:18 AM -----

Bill Studenmund <[email-masked]>
Sent by: [email-masked]
05/15/2002 05:46 AM
Please respond to Bill Studenmund

        To:     <[email-masked]>
        cc: 
        Subject:        iSCSI: BASE64 and numerical values

I was looking at the latest draft (Julian's 12-90.pdf), and thinking about
this. I see some problems, and I'd like to suggest we DROP support for
using base64 to encode numberical values. Definitely keep it for binary
strings, just not numbers.

The reason I suggest this is base64 encodes arbitrary-length binary
streams. To consider that stream a number, we need to add some more
structure. "Network Byte Order" is the first thing that comes to mind.
We've got ntohs() and ntohl(), also known as ntoh16() and ntoh32() on some
systems, which will save the day.

Unfortunatlely since the base64 stream can be arbitrary length, we'd need
something like ntoh24() too. We could after all have used just three bytes
to encode that number, especially since the spec discourages leading
zero-characters (encoded as 'A's).

Also, since regular-numerical-values can go up to just shy of 2**64, in
principle the only thing saving us from needing ntoh40(), ntoh48(), and
ntoh56() is the fact that I don't think we have any numerical parameters
that have valid values that large.

So I'd like to suggest we disallow using base64 to encode numbers.
Byte-swapping an arbitrary-length byte stream seems really messy.
Alternatively, I'd like to suggest we constrain base64-encoded numbers to
be 1, 2, 4, or 8 bytes long when decoded, and to be in network byte order.

Sorry for not catching this last week when we were looking at section 4.1.

Thoughts?

Take care,

Bill

----- Forwarded by Julian Satran/Haifa/IBM on 05/18/2002 11:18 AM -----

"Michael Krueger" <[email-masked]>
Sent by: [email-masked]
05/15/2002 09:04 PM
Please respond to "Michael Krueger"

        To:     "Bill Studenmund" <[email-masked]>, <[email-masked]>
        cc: 
        Subject:        RE: iSCSI: BASE64 and numerical values

> So I'd like to suggest we disallow using base64 to encode numbers.
> Byte-swapping an arbitrary-length byte stream seems really messy.
> Alternatively, I'd like to suggest we constrain base64-encoded numbers 
to
> be 1, 2, 4, or 8 bytes long when decoded, and to be in network byte 
order.

Bill, thanks for bringing this up, because I wanted to make the same 
point.
Implementing base-64 encoding for numbers is a fair amount of work for 
very
little benefit--no, let me be blunt: for ZERO benefit.  As I understand 
it,
the whole idea of the text-based login was to make it human-readable and 
to
allow cutting and pasting of values from, say, a management console. Maybe
I lack imagination, but I cannot conceive of any real-world circumstance
under which a NUMBER would be displayed on a console or entered by a human
(except, perhaps, by a pathologically mischievous one ;-) in base-64
encoding.  A BINARY ITEM, yes, but a NUMBER, never.

Let's keep it simple: decimal and hexadecimal for numbers, hexadecimal and
base 64 for binary items.

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: Ajit Nipunge <[email-masked]>
Date: Sat, 18 May 2002 03:43:27 -0700 (PDT)

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

---

From: "Michael Krueger" <[email-masked]>
Date: Mon, 20 May 2002 12:37:47 -0700

On Saturday, May 18, 2002 1:31 AM, Julian Satran wrote:
> Yes for regular numerical values it makes sense. We will have to keep
> it for large numerical values used for cryptography.  Julo

I'm glad to see that base-64 encoding will be dropped for numbers, but I'm
afraid I still have a small issue with the language being used here.  As I
understand it, "large numerical values" are NOT used for cryptography; the
keys, challenges, responses, etc., are large BINARY ITEMS*, not large
numbers.  I still believe that failing to make a distinction between numbers
and binary items is what's behind a lot of the confusion and ambiguity in
this realm of the spec (e.g., decimal representation, leading zeroes,
definitions of field size, byte swapping issues, etc.).

Michael

*I have no special attachment to the term "binary items"; call them "binary
strings," "bit patterns," or whatever you like . . . but please just don't
call them "numeric" or "numbers."

---

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

> for large numerical values used for cryptography.  Julo

I realize I'm driving a semantic nit, but I don't think we should use
BASE64 for any "numeric" values, only "binary" ones. I believe we probably
agree on what we want, I'm just worried that if the wording isn't 100%
tight, the decode path can become a real mess (since we're supposed to be
liberal in what we accept :-).

I'd like to suggest we drop BASE64 from the text that mentions numerical
values. I really don't look forward to byteswapping a 256 or 512 bit
number as part of BASE64 decode. :-)

I'd also like to suggest that for encoding large binary values using
hexadecimal, we state that the hexadecimal representation is that of the
number in network byte order. i.e. if I have the five octets 02 45 78 ab
de, the hex constant is 0x024578abde. That makes the decode logic REAL
easy; grab two hex characters & convert to one octet. Repeat as needed.
Please note that this is not the output you'd get with something like
printf("0x%x", number) on a little-endian machine.

Thirdly, I'd like to suggest we drop decimal support from binary objects.
It too has the cumbersome byte-swapping issue that I started this thread
about, just in reverse. :-)

I realize that's a lot for one EMail. :-)

To try and be proactive about this, I'd like to suggest revised text for
section 4.1 (of course needs word-wrapping). For the definitions:

     hex-constant: hexadecimal constant encoded as a string start-
       ing with "0x" or "0X" followed by 1 or more digits or the
       letters a, b, c, d, e, f, A, B, C, D, E and F. Hex-constants
       are used to encode numerical values or binary strings. When
       used to encode numerical values the excessive use of leading
       0 digits is discouraged. When used to encode binary strings
       hexadecimal constants must have an even number of digits,
       and have an implicit byte-length that
       includes 4 bits for every hexadecimal digit of the constant,
       including leading zeroes (i.e., a hex-constant of n hexadeci-
       mal digits has a byte-length of n/2). Additionally, when used
       to encode binary strings, hexadecimal constants shall be
       expressed in network byte order (i.e., the octet stream 02
       45 78 ab de would be expressed as "0x024578abde").

     decimal-constant: an unsigned decimal number - the digit 0 or a
       string of 1 or more digits starting with a non-zero digit.
       This encoding is not used for numerical values equal or
       greater than 2**64.

     base64-constant: base64 constant encoded as a string starting
       with "0b" or "0B" followed by 1 or more digits or letters or
       plus or slash or equal. The encoding is done according to
       [RFC2045]. base64-constants are used to encode binary strings.
       Base64-constants have an implicit byte-length that includes 6
       bits for every character of the constant excluding trailing
       equals (i.e., a base64-constant of n base64 characters
       excluding the trailing equals and m trailing equals has a
       byte-length of ((the integer part of) ((n+3)*3/4) - m).

       regular-numerical-value :  an unsigned integer less than 2**64
         encoded as a decimal-constant, or hex constant.

       large-numerical-value :  an unsigned integer larger than or
         equal to 2**64 encoded as a hex constant.

[no change for numerical-value or numerical-range]

       binary-value :  a binary string encoded as a hex-con-
         stant or base64-constant.  The length of the string is either
         specified by the key definition or is implicit byte-length of
         the encoded string.

[delete regualar-binary-value and large-binary-value since the distinction
is gone]

I don't see it explicitly mentioned anywhere, but I think all of the CHAP
(and SRP, but not sure) keys are large numericalal values, and the
kerberos and SPKM keys are binary values.

Also, I think the CHAP keys need the field length features of hexadecimal
binary strings, but they are numbers, not binary strings. Not sure how to
word that.

Take care,

Bill