Subject: Re: iSCSI base64 and 12-92

From: "Julian Satran" <[email-masked]>
Date: Thu, 23 May 2002 22:40:26 +0300

If base 64 is neede for large integers there is no good reason to test 
that it is not used for short integers.

Julo

Paul Koning <[email-masked]>
05/23/2002 07:57 PM
Please respond to Paul Koning

        To:     [email-masked]
        cc:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        Subject:        Re: iSCSI base64 and  12-92

Excerpt of message (sent 23 May 2002) by Bill Studenmund:
> On Thu, 23 May 2002, Julian Satran wrote:
> 
> > Dear colleagues,
> >
> > I looked again at cryptography needs and I think that large numbers 
will
> > be needed and base64 is a decent and not invented here way to express
> > them.
> 
> Just curious, which alogorythm needs them?

I was wondering the same.  Quite possibly I muddled things by talking
earlier about cases that don't actually appear in iSCSI.  The ones
that DO appear in iSCSI all involve strings, not numbers.  (That
includes SRP -- it uses large integers at some steps of the algorithm,
but externally at the protocol level it is specified in terms of
strings.) 

Apart from that, I don't see any reason at all why that means we
should allow Base64 for "ordinary" integers.  I remember a number of
comments objecting to that idea and none in favor of it, nor any
reason why it should be done.  So why do it?

       paul

---

From: Paul Koning <[email-masked]>
Date: Thu, 23 May 2002 16:05:54 -0400

> that it is not used for short integers.

Not true.  They are fundamentally different datatypes.  "short"
integers are int, or long, or something like that.  Large integers are
a software-defined datatype, typically an octetstring perhaps with
additional control variables.  See any bignum package for the
details.  

The conversion routines used for these two are completely different
and quite unrelated.

    paul

---

From: Bill Studenmund <[email-masked]>
Date: Thu, 23 May 2002 14:52:05 -0700 (PDT)

> that it is not used for short integers.

I respectfully disagree. base64 is awkward for numbers, as it is not a
numerical encoding. At least if the length of the number (in octets) is
variable. 1, 2, 4, and 8 octet numbers are fine. But 3, 5, 6, and 7 are
just plain gross. We have to load them into a correspondingly larger data
type (32 or 64-bit unsigned int as appropriate), and then mask off
unsent bytes. Oh, and if we're on an LE box, we then have to byte-swap the
thing.

Julo, have you actually coded a base64 decoder for the small (less than
2^64) ints we use in the protocol and verified its correctness? I will
admit I haven't but that's because as I worked on it, it got very gross.
And for no discernalbe benefit. Yes, we can do it. But I'd rather put the
effort verifying this would take into making some other part of the code
work well.

I think what would be much easier for us is to just say that base64 is
only usable for binary strings. Period.

If there is a authentication protocol that needs to exchange large numbers
that does not also specify the wire-format for said numbers, I suggest
that for iSCSI we specify that the authentication protocol must provide
the iSCSI negotiation code with a binary string representing/containing
the number. The iSCSI negotiation code then passes said string to the
authentication code on the other side. The code on the other side then
interprets the string as a number.

Yes, this is a semantics step. But it means that we can get rid of
exchanging numbers so large that we would really like base64 - from
iscsi's point of view they are binary strings. The iscsi infrastructure
doesn't need to bother with trying to think of them as numbers.

Take care,

Bill

---

From: Martins Krikis <[email-masked]>
Date: Thu, 23 May 2002 17:43:29 -0700 (PDT)

--- Bill Studenmund <[email-masked]>
wrote:

> numerical encoding. 

Me too. Base64 should not be allowed for anything
that's currently negotiable in the operational stage.

> At least if the length of the
> number (in octets) is

That's not really the problem. For encoding a
small number in base64, you byte-swap if necessary,
pass the leading 0-bytes (if any), then run
your regular base64 encoding that operates on strings.
For decoding, you run the decoder (that operates
on strings) first, count the resulting bytes,
move it in your 32-bit or 64-bit register from the
"right end", add 0-bytes (if necessary) on the
left end and byteswap. 

But since we know in advance whether a key can take
just small numerical values or whether it can take
large ones (actually, none do, they all take something
to be looked up in various RFCs, which I doubt will
call them "large numbers" anyway), we don't want
to first check the key for 0b and then run it
through the procedure given above. Just calling
strtoul() is better. For those keys that can
take large number values (even though I'm fairly sure
that what's really needed there are binary strings
happening to represent large numbers),
we'll happily run just base64 decoders (and there
will not be any need to move the result into
32-bit or 64-bit registers or byteswap).

> effort verifying this would take into making some

A decoder is a decoder, it does work even
on 0-length input. It works on strings, produces
"binary strings". Putting the right number of 
0-bytes to the left and byteswapping should not
go in the decoder, it should be a separate thing,
IMHO. But I also see no benefit in even allowing
the small numbers to be given in any representation
that cannot be thrown at strtoul() as is.

> only usable for binary strings. Period.

Agreed.

> interprets the string as a number.

Absolutely.

> doesn't need to bother with trying to think of them

Yes. If no, then where are the large numbers that
we're worried about? I don't see any keys defined
as taking large numbers for values yet.

  Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not
            be those of my employer

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

---

From: Bill Studenmund <[email-masked]>
Date: Thu, 23 May 2002 19:23:21 -0700 (PDT)

On Thu, 23 May 2002, Martins Krikis wrote:

To quote David, I think we're in violent agreement. :-)

> "right end", add 0-bytes (if necessary) on the

I think we're both agreeing it's cumbersome. :-)

> that cannot be thrown at strtoul() as is.

Oh, I was talking about the whole thing, the decoder that takes base64 &
returns a #. That's the base64 decoder chained with the code to turn the
result into a number.

[violent agreement snipped :-) ]

Take care,

Bill

---

From: Martins Krikis <[email-masked]>
Date: Thu, 23 May 2002 19:59:20 -0700 (PDT)

Page 26 of 12-92 says the values are 1 to 65535.

Page 208 allows 0 as well.

Is there a special purpose for 0, or is there a typo
somewhere? I would very much like to leave 0 out
of acceptable values, it is mighty convenient to
have a nice reserved value.

---

From: Bill Studenmund <[email-masked]>
Date: Fri, 24 May 2002 10:19:09 -0700 (PDT)

> that it is not used for short integers.

Julo,

You still haven't explained why we need base64 for large numbers. What
security negotiation schemes are we using that need to exchange large
numbers as numbers; where the scheme expects the number in host byte order
as opposed to a specific on-wire format.

More specifically you have not explained why the iSCSI parameter
negotiation system needs to be able to deal with large base64 numbers.

If we actually have any protocol which strangely wants large numbers in
local byte order, why not have the keys in question defined as exchanging
a binary string which is the number in network byte order?

The advantage of the above is that we then can drop base64 as a number
encoding scheme. The key negotiation system(s) need only deal with base64
binary strings, things base64 is good (no, great) for. And we can support
any cryptographic scheme we choose to in the future; the only thing we're
loosing is pain.

So what is wrong with the above?

I mean do we really want to have to support "MaxConnections=0b0Q=="?

Take care,

Bill