RE: iSCSI: BASE64 and numerical values

[Paul Koning <ni1d@arrl.net>]

Excerpt of message (sent 22 May 2002) by Martin, Nick (Server Storage):
> Julo,
>... 
> I have seen discussion about not allowing excess leading zeroes.
> This defeats inferring the correct storage size of a number from its
> encoding.  Outside of security, the sizes of numbers are already
> fixed and this is not a problem.  Within security, I am not sure
> this is true.  (I am nothing like a security expert yet.)

If you're dealing with numbers, then leading zeroes don't matter
because the value of a number is not changed when you slap leading
zeroes onto its representation.  For example, the basic Diffie-Hellman
exchange would have that property.

If you're also doing string operations, then you have to have a
precise rule on which string representation you use.  For example, SRP
does D-H style operations, but also crypto hashes (which operate on
strings, and care very much whether you put on a leading zero byte).
So SRP spells out explicitly that when it talks about strings it means
the big endian format with leading zeroes prohibited.

> Another confusion factor is numbers of arbitrary length.  Without
> knowing the format required internally by security algorithms which
> use these, I am not sure whether they will want big endian or little
> endian format on little endian hardware.  I hope they in fact want a
> b64 or hex representation in big endian a.k.a. network byte order (a
> string) and convert it to internal format themselves.  Suppose the
> algorithm wants a string in hex, but I receive a string in b64!
> Whether these are used internally as numbers or strings is not
> relevant if they are always delivered to the algorithms as strings.

That's really an implementation detail.  You may need to do
transcoding when going from iSCSI login exchange to/from the format
used by your crypto library.  For example, suppose a hypothetical SRP
implementation has an API that uses the octetstrings as defined by the
RFC -- then you would have to encode/decode those to/from a form you
can put in iSCSI exchanges.  Hex and Base64 would both serve.  You
would have to be careful to preseve the exact length in bytes of the
strings SRP is dealing with.
  
> If b64 is only used for security strings and the login process can
> treat them as strings and pass them to security algorithms as
> strings, then whether the string contains b64, hex, or decimal is
> transparent to parsing during login. 

I've seen Base64, hex strings, and raw octetstrings used in security
libraries, so I'm not comfortable suggesting a single encoding in
iSCSI on the theory that it can then be passed straight to whatever
crypto libraries you might want to use.  Instead, pick an encoding (or
at most two) that are easily converted to/from octetstrings.  That's
clearly true for hex strings, and it seems to be true for Base64 as
well.

> I see no reason to require an
> implementation to accept b64 for login operational parameters like
> MaxBurstSize.

I quite agree!

     paul