RE: Issue: Treatment of null Identity Response

["Nelson, David" <dnelson@enterasys.com>]

Barney Wolff writes...

> I believe the CUI was to be a single byte of 0-bits, thus NUL rather
> than NULL and not a violation.

I don't believe so.  The intent of the "hint" flavor of CUI was not to
change the underlying base type from printable-string to binary-string.
Sending a single byte of value zero would only be permissible for a
binary-string and not a UTF-8 printable-string.

The CUI type is defined as: "The string identifies the CUI of the
end-user and is of type UTF8String."  Of course, type UTF8String is not
a recognized data type in RFC 2865.  Can anyone point me to a formal
definition of this, within a RADIUS RFC? 

This leads me to believe that the CUI attribute value field ought to
have been defined as a text type, rather than a string type.  See the
RFC 2865 definitions of the basic types: 

	text      1-253 octets containing UTF-8 encoded 10646 [7]
                characters.  Text of length zero (0) MUST NOT be sent;
                omit the entire attribute instead.

      string    1-253 octets containing binary data (values 0 through
                255 decimal, inclusive).  Strings of length zero (0)
                MUST NOT be sent; omit the entire attribute instead.

Having noted that types discrepancy (a bit too late, alas), I don't
think there has ever been a substantive difference between the NULL
string and the NUL string.  Both are a string containing a binary-zero
as the first element of the array.  NUL is the abbreviation you'll find
in the US-ASCII character set definition for the character with hex
value zero.  The three character abbreviations for ASCII characters are
a historical artifact.  AFAIK, NULL means the same thing. 

RADIUS specifically indicates that strings (text and binary) are not
NULL-terminated strings, but are counted strings.  In converting a
C-language NULL (or NUL) string to a RADIUS attribute, it would become a
RADIUS string type of zero length.

See the relevant text from RFC 2865:

      Note that none of the types in RADIUS terminate with a NUL (hex
      00). In particular, types "text" and "string" in RADIUS do not
      terminate with a NUL (hex 00).  The Attribute has a length field
      and does not use a terminator.  Text contains UTF-8 encoded 10646
      [7] characters and String contains 8-bit binary data.  Servers and
      servers and clients MUST be able to deal with embedded nulls.
      RADIUS implementers using C are cautioned not to use strcpy() when
      handling strings.

> I must say, in passing, that I never understood why zero-length
strings
> were forbidden.  Can anyone point to a logical, or historical, reason?

I believe that the historical reason was that zero-length attributes
contained no data, and were presumed to have no semantics, and for
reasons of bits-on-the-wire efficiency and protocol clarity it was
deemed preferable to omit the attribute rather than send an "empty
container".


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>