In looking at the text of Sections
2 and 2.1.1, I would propose to make the following changes in Section 2 and
2.1.1 to resolve Issue 319.
Required changes in Appendix A
will following in a separate post.
2. RADIUS Data Model
The Remote Authentication Dial In User Service (RADIUS) defined in
[RFC2865] and [RFC2866] uses elements known as attributes in order to
represent authentication, authorization and accounting data.
Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does
not define a formal data definition language.
The data type of RADIUS attributes is not transported on the wire.
Rather, the data type of a RADIUS attribute is fixed when that
attribute is defined. Based on the RADIUS attribute type code,
RADIUS clients and servers can determine the data type based on pre-
configured entries within a data dictionary.
Two distinct attribute spaces are defined: the standard space, and a
Vendor-Specific space. Attributes in the standard space generally
are composed of a type, length, value (TLV) triplet, although complex
attributes have also been defined. The Vendor-Specific space is
encapsulated within a single attribute type (Vendor-Specific
Attribute). The format of this space is defined by individual
vendors, but the same TLV encoding used by the standard space is
recommended in [RFC2865] Section 5.26. The similarity between
attribute formats has enabled implementations to leverage common
parsing functionality, although in some cases the attributes in the
Vendor-Specific space have begun to diverge from the common format.
2.1.1. Basic Data Types defined in RFC 2865
[RFC2865] and [RFC2866] utilize data types defined in [RFC2865]
Section 5, which states the following:
The format of the value field is one of five data types. Note
that type "text" is a subset of type "string".
text 1-253 octets containing UTF-8 encoded 10646 [RFC3629]
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.
address 32 bit value, most significant octet first.
integer 32 bit unsigned value, most significant octet first.
time 32 bit unsigned value, most significant octet first --
seconds since 00:00:00 UTC, January 1, 1970. The
standard Attributes do not use this data type but it is
presented here for possible use in future attributes.
In addition to the data types defined in [RFC2865], subsequent RADIUS
specifications defined attributes using additional basic data types. Since
these specifications did not explicitly define new data types as was
done in [RFC2865], nor did they consistently indicate the format of the value
field using the same conventions as [RFC2865], in some cases the intended
data type is ambiguous and may not be consistent among different
implementations.
It is out of the scope of this document to resolve all potential ambiguities
within existing RADIUS specifications. However in order to prevent future
ambiguities, it is recommended that future RADIUS attribute specifications
explicitly define newly created data types at the beginning of the document,
and indicate clearly the data type to be used for each attribute.
[RFC3162] utilizes but does not explicitly define the following data types:
IPv6 address 128 bit value, in network byte order.
IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to
128 bits of value, in network byte order.
Examples of the IPv6 address type include NAS-IPv6-Address defined in
[RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162]
Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3,
and in [RFC4818] Section 3.
While the Framed-Interface-Id attribute defined in [RFC3162] Section 2.2
included a value field of 8 octets, the data type was not explicitly
indicated, and therefore there is controversy over whether the format
of this attribute was intended to be an 8 octet String or whether a
special Interface-Id type was intended.
Given that attributes of type IPv6 address and IPv6 prefix are already
in use, it is RECOMMENDED that RADIUS server implementations include support for
these additional basic types, in addition to the types defined in [RFC2865].
Where the intent is to represent a specific IPv6 address, the IPv6
address type SHOULD be used. Although it is possible to use the IPv6
IPv6 Prefix type with a prefix length of 128 to represent an IPv6
address, this usage is NOT RECOMMENDED. Implementations supporting
the Framed-Interface-Id attribute may select a data type of their
choosing (most likely an 8 octet String or a special Interface-Id
data type).
It is worth noting that since RADIUS only supports unsigned integers
of 32 bits, attributes using signed integer data types or
unsigned integer types of other sizes will require code changes, and
SHOULD be avoided.
For [RFC2865] RADIUS VSAs, the length limitation of the String and
Text types is 247 octets instead of 253 octets, due to the additional
overhead of the Vendor-Specific Attribute.