Subject: Revised Resolution to Issue 319

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 27 Oct 2009 22:09:05 -0700

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 <http://tools.ietf.org/html/rfc2865> ] and [RFC2866
<http://tools.ietf.org/html/rfc2866> ] uses elements known as attributes in
order to
   represent authentication, authorization and accounting data.
 
   Unlike SNMP, first defined in [RFC1157
<http://tools.ietf.org/html/rfc1157> ] and [RFC1155
<http://tools.ietf.org/html/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
<http://tools.ietf.org/html/rfc2865#section-5.26>  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
<http://tools.ietf.org/html/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 <http://tools.ietf.org/html/rfc3162#section-2.1>  2.1
and Login-IPv6-Host defined in [RFC3162]
<http://tools.ietf.org/html/rfc3162#section-2.4> 
 <http://tools.ietf.org/html/rfc3162#section-2.4>    Section 2.4.  The IPv6
prefix type is used in [RFC3162] Section
<http://tools.ietf.org/html/rfc3162#section-2.3>  2.3,
   and in [RFC4818] Section <http://tools.ietf.org/html/rfc4818#section-3>
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 <http://tools.ietf.org/html/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 <http://tools.ietf.org/html/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.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 30 Oct 2009 14:20:07 -0400

Bernard Aboba wrote:
> 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.
> 

  I've re-worked both Section 2 and Appendix A to address these
concerns.  A proposed version is available online at:

http://git.freeradius.org/draft-ietf-radext-design-10.txt

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 30 Oct 2009 12:16:53 -0700

A few comments:

Section A.1.1 states:

"   The following data also qualifies as "simple data types":

      * Attributes grouped into a logical container, using the
        [RFC2868] tagging mechanism.  This approach is NOT
        RECOMMENDED (see Section 2.1.2), but is permissible where
        the alternatives are worse."

However, Section A.2.1 states:

"      * Tagged data types as described in [RFC2868].
        These data types SHOULD NOT be used in new specifications."

These two paragraphs appear to be in conflict; suggest deletion of the A.2.1
text. 

Section A.2 states:

"   All data types other than the ones described above in Appendix A.1
   and Appendix B SHOULD NOT be used.  This section describes in detail
   a number of data types that are NOT RECOMMENDED in new RADIUS
   specifications."

Similarly, Section A.2.2 states:

"   Does the attribute:

   * define a complex data type not described in Appendix B,"

However, Section A.2.1 states:

"      * Complex data structures defined only within RADIUS.
        SHOULD NOT be used.  This recommendation does not apply to new
        attributes for authentication or security, as described below
        in Section A.2.2."

Recommendation is to delete the material in Section A.2.1 or sync it with
A.2. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alan DeKok
Sent: Friday, October 30, 2009 11:20 AM
To: Bernard Aboba
Cc: 'radext mailing list'
Subject: Re: Revised Resolution to Issue 319

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 30 Oct 2009 15:31:30 -0400

> These two paragraphs appear to be in conflict; suggest deletion of the A.2.1

  OK.

> Recommendation is to delete the material in Section A.2.1 or sync it with

  Deleting the material seems to be the simplest approach.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 30 Oct 2009 21:54:32 -0700

In Section 1.3:

   The uses of "MUST" and "MUST NOT" in this document are limited to (a)
   requirements to follow the IETF process for IETF standards, and (b)
   quotes from other documents.  As a result, the use of MUST and MUST
   NOT in this document does not prescribe new mandatory behavior within
   implementations.
Wasn't this to have gone in Section 1.2?

Section 2.1.1 states:

   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.

   . . .

   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).

Yet Section A.1.1 says:

      * Interface-Id (8 octets in network byte order)

Should this say: 
 
    * Interface-Id (8 octet string in network byte order)