tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6929

Proposed STD
Pages: 68
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: RADEXT

Remote Authentication Dial In User Service (RADIUS) Protocol Extensions

Part 1 of 3, p. 1 to 20
None       Next RFC Part

Updates:    2865    3575    6158


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                          A. DeKok
Request for Comments: 6929                                Network RADIUS
Updates: 2865, 3575, 6158                                        A. Lior
Category: Standards Track                                     April 2013
ISSN: 2070-1721

          Remote Authentication Dial-In User Service (RADIUS)
                          Protocol Extensions

Abstract

   The Remote Authentication Dial-In User Service (RADIUS) protocol is
   nearing exhaustion of its current 8-bit Attribute Type space.  In
   addition, experience shows a growing need for complex grouping, along
   with attributes that can carry more than 253 octets of data.  This
   document defines changes to RADIUS that address all of the above
   problems.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6929.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................3
      1.1. Caveats and Limitations ....................................5
           1.1.1. Failure to Meet Certain Goals .......................5
           1.1.2. Implementation Recommendations ......................5
      1.2. Terminology ................................................6
      1.3. Requirements Language ......................................7
   2. Extensions to RADIUS ............................................7
      2.1. Extended Type ..............................................8
      2.2. Long Extended Type .........................................9
      2.3. TLV Data Type .............................................12
           2.3.1. TLV Nesting ........................................14
      2.4. EVS Data Type .............................................14
      2.5. Integer64 Data Type .......................................16
      2.6. Vendor-Id Field ...........................................16
      2.7. Attribute Naming and Type Identifiers .....................17
           2.7.1. Attribute and TLV Naming ...........................17
           2.7.2. Attribute Type Identifiers .........................18
           2.7.3. TLV Identifiers ....................................18
           2.7.4. VSA Identifiers ....................................18
      2.8. Invalid Attributes ........................................19
   3. Attribute Definitions ..........................................21
      3.1. Extended-Type-1 ...........................................21
      3.2. Extended-Type-2 ...........................................22
      3.3. Extended-Type-3 ...........................................23
      3.4. Extended-Type-4 ...........................................24
      3.5. Long-Extended-Type-1 ......................................25
      3.6. Long-Extended-Type-2 ......................................26
   4. Vendor-Specific Attributes .....................................27
      4.1. Extended-Vendor-Specific-1 ................................28
      4.2. Extended-Vendor-Specific-2 ................................29
      4.3. Extended-Vendor-Specific-3 ................................30
      4.4. Extended-Vendor-Specific-4 ................................31
      4.5. Extended-Vendor-Specific-5 ................................32
      4.6. Extended-Vendor-Specific-6 ................................34
   5. Compatibility with Traditional RADIUS ..........................35
      5.1. Attribute Allocation ......................................35
      5.2. Proxy Servers .............................................36

Top      ToC       Page 3 
   6. Guidelines .....................................................37
      6.1. Updates to RFC 6158 .......................................37
      6.2. Guidelines for Simple Data Types ..........................38
      6.3. Guidelines for Complex Data Types .........................38
      6.4. Design Guidelines for the New Types .......................39
      6.5. TLV Guidelines ............................................40
      6.6. Allocation Request Guidelines .............................40
      6.7. Allocation Request Guidelines for TLVs ....................41
      6.8. Implementation Guidelines .................................42
      6.9. Vendor Guidelines .........................................42
   7. Rationale for This Design ......................................42
      7.1. Attribute Audit ...........................................43
   8. Diameter Considerations ........................................44
   9. Examples .......................................................44
      9.1. Extended Type .............................................46
      9.2. Long Extended Type ........................................47
   10. IANA Considerations ...........................................50
      10.1. Attribute Allocations ....................................50
      10.2. RADIUS Attribute Type Tree ...............................50
      10.3. Allocation Instructions ..................................52
           10.3.1. Requested Allocation from the Standard Space ......52
           10.3.2. Requested Allocation from the Short
                   Extended Space ....................................52
           10.3.3. Requested Allocation from the Long
                   Extended Space ....................................52
           10.3.4. Allocation Preferences ............................52
           10.3.5. Extending the Type Space via the TLV Data Type ....53
           10.3.6. Allocation within a TLV ...........................53
           10.3.7. Allocation of Other Data Types ....................54
   11. Security Considerations .......................................54
   12. References ....................................................54
      12.1. Normative References .....................................54
      12.2. Informative References ...................................55
   13. Acknowledgments ...............................................55
   Appendix A. Extended Attribute Generator Program ..................56

1.  Introduction

   Under current allocation pressure, we expect that the RADIUS
   Attribute Type space will be exhausted by 2014 or 2015.  We therefore
   need a way to extend the type space so that new specifications may
   continue to be developed.  Other issues have also been shown with
   RADIUS.  The attribute grouping method defined in [RFC2868] has been
   shown to be impractical, and a more powerful mechanism is needed.
   Multiple Attributes have been defined that transport more than the
   253 octets of data originally envisioned with the protocol.  Each of
   these attributes is handled as a "special case" inside of RADIUS
   implementations, instead of as a general method.  We therefore also

Top      ToC       Page 4 
   need a standardized method of transporting large quantities of data.
   Finally, some vendors are close to allocating all of the Attributes
   within their Vendor-Specific Attribute space.  It would be useful to
   leverage changes to the base protocol for extending the Vendor-
   Specific Attribute space.

   We satisfy all of these requirements through the following changes
   given in this document:

   * Defining an "Extended Type" format, which adds 8 bits of "Extended
     Type" to the RADIUS Attribute Type space, by using one octet of the
     "Value" field.  This method gives us a general way of extending the
     Attribute Type space (Section 2.1).

   * Allocating 4 attributes as using the format of "Extended Type".
     This allocation extends the RADIUS Attribute Type space by
     approximately 1000 values (Sections 3.1, 3.2, 3.3, and 3.4).

   * Defining a "Long Extended Type" format, which inserts an additional
     octet between the "Extended Type" octet and the "Value" field.
     This method gives us a general way of adding more functionality to
     the protocol (Section 2.2).

   * Defining a method that uses the additional octet in the "Long
     Extended Type" to indicate data fragmentation across multiple
     Attributes.  This method provides a standard way for an Attribute
     to carry more than 253 octets of data (Section 2.2).

   * Allocating 2 attributes as using the format "Long Extended Type".
     This allocation extends the RADIUS Attribute Type space by an
     additional 500 values (Sections 3.5 and 3.6).

   * Defining a new "Type-Length-Value" (TLV) data type.  This data type
     allows an attribute to carry TLVs as "sub-Attributes", which can in
     turn encapsulate other TLVs as "sub-sub-Attributes".  This change
     creates a standard way to group a set of Attributes (Section 2.3).

   * Defining a new "Extended-Vendor-Specific" (EVS) data type.  This
     data type allows an attribute to carry Vendor-Specific Attributes
     (VSAs) inside of the new Attribute formats (Section 2.4).

   * Defining a new "integer64" data type.  This data type allows
     counters that track more than 2^32 octets of data (Section 2.5).

   * Allocating 6 attributes using the new EVS data type.  This
     allocation extends the Vendor-Specific Attribute Type space by over
     1500 values (Sections 4.1 through 4.6).

Top      ToC       Page 5 
   * Defining the "Vendor-Id" for Vendor-Specific Attributes to
     encompass the entire 4 octets of the Vendor field.  [RFC2865]
     Section 5.26 defined it to be 3 octets, with the fourth octet being
     zero (Section 2.6).

   * Describing compatibility with existing RADIUS systems (Section 5).

   * Defining guidelines for the use of these changes for IANA,
     implementations of this specification, and for future RADIUS
     specifications (Section 6).

   As with any protocol change, the changes defined here are the result
   of a series of compromises.  We have tried to find a balance between
   flexibility, space in the RADIUS message, compatibility with existing
   deployments, and difficulty of implementation.

1.1.  Caveats and Limitations

   This section describes some caveats and limitations of the proposal.

1.1.1.  Failure to Meet Certain Goals

   One goal that was not met by the above modifications is to have an
   incentive for standards to use the new space.  That incentive is
   being provided by the exhaustion of the standard space.

1.1.2.  Implementation Recommendations

   It is RECOMMENDED that implementations support this specification.
   It is RECOMMENDED that new specifications use the formats defined in
   this specification.

   The alternative to the above recommendations is a circular argument
   of not implementing this specification because no other standards
   reference it, and also not defining new standards referencing this
   specification because no implementations exist.

   As noted earlier, the standard space is almost entirely allocated.
   Ignoring the looming crisis benefits no one.

Top      ToC       Page 6 
1.2.  Terminology

   This document uses the following terms:

   Silently discard

      This means the implementation discards the packet without further
      processing.  The implementation MAY provide the capability of
      logging the error, including the contents of the silently
      discarded packet, and SHOULD record the event in a statistics
      counter.

   Invalid attribute

      This means that the Length field of an Attribute is valid (as per
      [RFC2865], Section 5, top of page 25) but the contents of the
      Attribute do not follow the correct format, for example, an
      Attribute of type "address" that encapsulates more than four, or
      less than four, octets of data.  See Section 2.8 for a more
      complete definition.

   Standard space

      This refers to codes in the RADIUS Attribute Type space that are
      allocated by IANA and that follow the format defined in Section 5
      of [RFC2865].

   Extended space

      This refers to codes in the RADIUS Attribute Type space that
      require the extensions defined in this document and are an
      extension of the standard space, but that cannot be represented
      within the standard space.

   Short extended space

      This refers to codes in the extended space that use the "Extended
      Type" format.

   Long extended space

      This refers to codes in the extended space that use the "Long
      Extended Type" format.

   The following terms are used here with the meanings defined in BCP 26
   [RFC5226]: "namespace", "assigned value", "registration", "Private
   Use", "Reserved", "Unassigned", "IETF Review", and "Standards
   Action".

Top      ToC       Page 7 
1.3.  Requirements Language

   In this document, several words are used to signify the requirements
   of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

2.  Extensions to RADIUS

   This section defines two new Attribute formats: "Extended Type" and
   "Long Extended Type".  It defines a new Type-Length-Value (TLV) data
   type, an Extended-Vendor-Specific (EVS) data type, and an Integer64
   data type.  It defines a new method for naming attributes and
   identifying Attributes using the new Attribute formats.  It finally
   defines the new term "invalid attribute" and describes how it affects
   implementations.

   The new Attribute formats are designed to be compatible with the
   Attribute format given in [RFC2865] Section 5.  The meaning and
   interpretation of the Type and Length fields are unchanged from that
   specification.  This reuse allows the new formats to be compatible
   with RADIUS implementations that do not implement this specification.
   Those implementations can simply ignore the "Value" field of an
   attribute or forward it verbatim.

   The changes to the Attribute format come about by "stealing" one or
   more octets from the "Value" field.  This change has the effect that
   the "Value" field of [RFC2865] Section 5 contains both the new octets
   given here and any attribute-specific Value.  The result is that
   "Value"s in this specification are limited to less than 253 octets in
   size.  This limitation is overcome through the use of the "Long
   Extended Type" format.

   We reiterate that the formats given in this document do not insert
   new data into an attribute.  Instead, we "steal" one octet of Value,
   so that the definition of the Length field remains unchanged.  The
   new Attribute formats are designed to be compatible with the
   Attribute format given in [RFC2865] Section 5.  The meaning and
   interpretation of the Type and Length fields is unchanged from that
   specification.  This reuse allows the new formats to be compatible
   with RADIUS implementations that do not implement this specification.
   Those implementations can simply ignore the "Value" field of an
   attribute or forward it verbatim.

Top      ToC       Page 8 
2.1.  Extended Type

   This section defines a new Attribute format, called "Extended Type".
   A summary of the Attribute format is shown below.  The fields are
   transmitted from left to right.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     | Extended-Type |  Value ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      This field is identical to the Type field of the Attribute format
      defined in [RFC2865] Section 5.

   Length

      The Length field is one octet and indicates the length of this
      Attribute, including the Type, Length, "Extended-Type", and
      "Value" fields.  Permitted values are between 4 and 255.  If a
      client or server receives an Extended Attribute with a Length of 2
      or 3, then that Attribute MUST be considered to be an "invalid
      attribute" and handled as per Section 2.8, below.

   Extended-Type

      The Extended-Type field is one octet.  Up-to-date values of this
      field are specified according to the policies and rules described
      in Section 10.  Unlike the Type field defined in [RFC2865]
      Section 5, no values are allocated for experimental or
      implementation-specific use.  Values 241-255 are reserved and MUST
      NOT be used.

      The Extended-Type is meaningful only within a context defined by
      the Type field.  That is, this field may be thought of as defining
      a new type space of the form "Type.Extended-Type".  See
      Section 3.5, below, for additional discussion.

      A RADIUS server MAY ignore Attributes with an unknown
      "Type.Extended-Type".

      A RADIUS client MAY ignore Attributes with an unknown
      "Type.Extended-Type".

Top      ToC       Page 9 
   Value

      This field is similar to the "Value" field of the Attribute format
      defined in [RFC2865] Section 5.  The format of the data MUST be a
      valid RADIUS data type.

      The "Value" field is one or more octets.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type" to determine the interpretation
      of the "Value" field.

      The addition of the Extended-Type field decreases the maximum
      length for attributes of type "text" or "string" from 253 to
      252 octets.  Where an Attribute needs to carry more than
      252 octets of data, the "Long Extended Type" format MUST be used.

   Experience has shown that the "experimental" and "implementation-
   specific" attributes defined in [RFC2865] Section 5 have had little
   practical value.  We therefore do not continue that practice here
   with the Extended-Type field.

2.2.  Long Extended Type

   This section defines a new Attribute format, called "Long Extended
   Type".  It leverages the "Extended Type" format in order to permit
   the transport of attributes encapsulating more than 253 octets of
   data.  A summary of the Attribute format is shown below.  The fields
   are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Extended-Type |M|  Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      This field is identical to the Type field of the Attribute format
      defined in [RFC2865] Section 5.

   Length

      The Length field is one octet and indicates the length of this
      Attribute, including the Type, Length, Extended-Type, and "Value"
      fields.  Permitted values are between 5 and 255.  If a client or

Top      ToC       Page 10 
      server receives a "Long Extended Type" with a Length of 2, 3, or
      4, then that Attribute MUST be considered to be an "invalid
      attribute" and handled as per Section 2.8, below.

      Note that this Length is limited to the length of this fragment.
      There is no field that gives an explicit value for the total size
      of the fragmented attribute.

   Extended-Type

      This field is identical to the Extended-Type field defined above
      in Section 2.1.

   M (More)

      The More field is one (1) bit in length and indicates whether or
      not the current attribute contains "more" than 251 octets of data.
      The More field MUST be clear (0) if the Length field has a value
      of less than 255.  The More field MAY be set (1) if the Length
      field has a value of 255.

      If the More field is set (1), it indicates that the "Value" field
      has been fragmented across multiple RADIUS attributes.  When the
      More field is set (1), the Attribute MUST have a Length field of
      value 255, there MUST be an attribute following this one, and the
      next attribute MUST have both the same Type and "Extended Type".
      That is, multiple fragments of the same value MUST be in order and
      MUST be consecutive attributes in the packet, and the last
      attribute in a packet MUST NOT have the More field set (1).

      That is, a packet containing a fragmented attribute needs to
      contain all fragments of the Attribute, and those fragments need
      to be contiguous in the packet.  RADIUS does not support
      inter-packet fragmentation, which means that fragmenting an
      attribute across multiple packets is impossible.

      If a client or server receives an attribute fragment with the
      "More" field set (1) but for which no subsequent fragment can be
      found, then the fragmented attribute is considered to be an
      "invalid attribute" and handled as per Section 2.8, below.

   Reserved

      This field is 7 bits long and is reserved for future use.
      Implementations MUST set it to zero (0) when encoding an attribute
      for sending in a packet.  The contents SHOULD be ignored on
      reception.

Top      ToC       Page 11 
      Future specifications may define additional meaning for this
      field.  Implementations therefore MUST NOT treat this field as
      invalid if it is non-zero.

   Value

      This field is similar to the "Value" field of the Attribute format
      defined in [RFC2865] Section 5.  It may contain a complete set of
      data (when the Length field has a value of less than 255), or it
      may contain a fragment of data.

      The "Value" field is one or more octets.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type" to determine the interpretation
      of the "Value" field.

      Any interpretation of the resulting data MUST occur after the
      fragments have been reassembled.  The length of the data MUST be
      taken as the sum of the lengths of the fragments (i.e., "Value"
      fields) from which it is constructed.  The format of the data
      SHOULD be a valid RADIUS data type.  If the reassembled data does
      not match the expected format, all fragments MUST be treated as
      "invalid attributes", and the reassembled data MUST be discarded.

      We note that the maximum size of a fragmented attribute is limited
      only by the RADIUS packet length limitation (i.e., 4096 octets,
      not counting various headers and overhead).  Implementations MUST
      be able to handle the case where one fragmented attribute
      completely fills the packet.

   This definition increases the RADIUS Attribute Type space as above
   but also provides for transport of Attributes that could contain more
   than 253 octets of data.

   Note that [RFC2865] Section 5 says:

      If multiple Attributes with the same Type are present, the order
      of Attributes with the same Type MUST be preserved by any proxies.
      The order of Attributes of different Types is not required to be
      preserved.  A RADIUS server or client MUST NOT have any
      dependencies on the order of attributes of different types.  A
      RADIUS server or client MUST NOT require attributes of the same
      type to be contiguous.

   These requirements also apply to the "Long Extended Type" Attribute,
   including fragments.  Implementations MUST be able to process
   non-contiguous fragments -- that is, fragments that are mixed

Top      ToC       Page 12 
   together with other attributes of a different Type.  This will allow
   them to accept packets, so long as the Attributes can be correctly
   decoded.

2.3.  TLV Data Type

   We define a new data type in RADIUS, called "tlv".  The "tlv" data
   type is an encapsulation layer that permits the "Value" field of an
   Attribute to contain new sub-Attributes.  These sub-Attributes can in
   turn contain "Value"s of data type TLV.  This capability both extends
   the Attribute space and permits "nested" attributes to be used.  This
   nesting can be used to encapsulate or group data into one or more
   logical containers.

   The "tlv" data type reuses the RADIUS Attribute format, as given
   below:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   TLV-Type    |  TLV-Length   |     TLV-Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV-Type

      The TLV-Type field is one octet.  Up-to-date values of this field
      are specified according to the policies and rules described in
      Section 10.  Values 254-255 are "Reserved" for use by future
      extensions to RADIUS.  The value 26 has no special meaning and
      MUST NOT be treated as a Vendor-Specific Attribute.

      As with the Extended-Type field defined above, the TLV-Type is
      meaningful only within the context defined by "Type" fields of the
      encapsulating Attributes.  That is, the field may be thought of as
      defining a new type space of the form
      "Type.Extended-Type.TLV-Type".  Where TLVs are nested, the type
      space is of the form "Type.Extended-Type.TLV-Type.TLV-Type", etc.

      A RADIUS server MAY ignore Attributes with an unknown "TLV-Type".

      A RADIUS client MAY ignore Attributes with an unknown "TLV-Type".

      A RADIUS proxy SHOULD forward Attributes with an unknown
      "TLV-Type" verbatim.

Top      ToC       Page 13 
   TLV-Length

      The TLV-Length field is one octet and indicates the length of this
      TLV, including the TLV-Type, TLV-Length, and TLV-Value fields.  It
      MUST have a value between 3 and 255.  If a client or server
      receives a TLV with an invalid TLV-Length, then the Attribute that
      encapsulates that TLV MUST be considered to be an "invalid
      attribute" and handled as per Section 2.8, below.

   TLV-Value

      The TLV-Value field is one or more octets and contains information
      specific to the Attribute.  The format and length of the TLV-Value
      field are determined by the TLV-Type and TLV-Length fields.

      The TLV-Value field SHOULD encapsulate a standard RADIUS data
      type.  Non-standard data types SHOULD NOT be used within TLV-Value
      fields.  We note that the TLV-Value field MAY also contain one or
      more attributes of data type TLV; data type TLV allows for simple
      grouping and multiple layers of nesting.

      The TLV-Value field is limited to containing 253 or fewer octets
      of data.  Specifications that require a TLV to contain more than
      253 octets of data are incompatible with RADIUS and need to be
      redesigned.  Specifications that require the transport of empty
      "Value"s (i.e., Length = 2) are incompatible with RADIUS and need
      to be redesigned.

      The TLV-Value field MUST NOT contain data using the "Extended
      Type" formats defined in this document.  The base Extended
      Attributes format allows for sufficient flexibility that nesting
      them inside of a TLV offers little additional value.

   This TLV definition is compatible with the suggested format of the
   "String" field of the Vendor-Specific Attribute, as defined in
   [RFC2865] Section 5.26, though that specification does not discuss
   nesting.

   Vendors MAY use attributes of type "TLV" in any Vendor-Specific
   Attribute.  It is RECOMMENDED to use type "TLV" for VSAs, in
   preference to any other format.

   If multiple TLVs with the same TLV-Type are present, the order of
   TLVs with the same TLV-Type MUST be preserved by any proxies.  The
   order of TLVs of different TLV-Types is not required to be preserved.
   A RADIUS server or client MUST NOT have any dependencies on the order
   of TLVs of different TLV-Types.  A RADIUS server or client MUST NOT
   require TLVs of the same TLV-Type to be contiguous.

Top      ToC       Page 14 
   The interpretation of multiple TLVs of the same TLV-Type MUST be that
   of a logical "and", unless otherwise specified.  That is, multiple
   TLVs are interpreted as specifying an unordered set of values.
   Specifications SHOULD NOT define TLVs to be interpreted as a logical
   "or".  Doing so would mean that a RADIUS client or server would make
   an arbitrary and non-deterministic choice among the values.

2.3.1.  TLV Nesting

   TLVs may contain other TLVs.  When this occurs, the "container" TLV
   MUST be completely filled by the "contained" TLVs.  That is, the
   "container" TLV-Length field MUST be exactly two (2) more than the
   sum of the "contained" TLV-Length fields.  If the "contained" TLVs
   overfill the "container" TLV, the "container" TLV MUST be considered
   to be an "invalid attribute" and handled as described in Section 2.8,
   below.

   The depth of TLV nesting is limited only by the restrictions on the
   TLV-Length field.  The limit of 253 octets of data results in a limit
   of 126 levels of nesting.  However, nesting depths of more than 4 are
   NOT RECOMMENDED.  They have not been demonstrated to be necessary in
   practice, and they appear to make implementations more complex.
   Reception of packets with such deeply nested TLVs may indicate
   implementation errors or deliberate attacks.  Where implementations
   do not support deep nesting of TLVs, it is RECOMMENDED that the
   unsupported layers are treated as "invalid attributes".

2.4.  EVS Data Type

   We define a new data type in RADIUS, called "evs", for "Extended-
   Vendor-Specific".  The "evs" data type is an encapsulation layer that
   permits the EVS-Value field of an Attribute to contain a Vendor-Id,
   followed by an EVS-Type, and then vendor-defined data.  This data can
   in turn contain valid RADIUS data types or any other data as
   determined by the vendor.

   This data type is intended for use in attributes that carry vendor-
   specific information, as is done with the Vendor-Specific Attribute
   (Attribute number 26).  It is RECOMMENDED that this data type be used
   by a vendor only when the Vendor-Specific Attribute Type space has
   been fully allocated.

   Where [RFC2865] Section 5.26 makes a recommendation for the format of
   the data following the Vendor-Id, we give a strict definition.
   Experience has shown that many vendors have not followed the
   [RFC2865] recommendations, leading to interoperability issues.  We
   hope here to give vendors sufficient flexibility as to meet their
   needs while minimizing the use of non-standard VSA formats.

Top      ToC       Page 15 
   The "evs" data type MAY be used in Attributes having the format of
   "Extended Type" or "Long Extended Type".  It MUST NOT be used in any
   other Attribute definition, including standard RADIUS attributes,
   TLVs, and VSAs.

   A summary of the "evs" data type format is shown below.  The fields
   are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Vendor-Id                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  EVS-Type      |  EVS-Value ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Id

      The 4 octets of the Vendor-Id field are the Network Management
      Private Enterprise Code [PEN] of the vendor in network byte order.

   EVS-Type

      The EVS-Type field is one octet.  Values are assigned at the sole
      discretion of the vendor.

   EVS-Value

      The EVS-Value field is one or more octets.  It SHOULD encapsulate
      a standard RADIUS data type.  Using non-standard data types is NOT
      RECOMMENDED.  We note that the EVS-Value field may be of data type
      TLV.  However, it MUST NOT be of data type "evs", as the use cases
      are unclear for one vendor delegating Attribute Type space to
      another vendor.

      The actual format of the information is site or application
      specific, and a robust implementation SHOULD support the field as
      undistinguished octets.  While we recognize that vendors have
      complete control over the contents and format of the EVS-Value
      field, we recommend that good practices be followed.

      Further codification of the range of allowed usage of this field
      is outside the scope of this specification.

   Note that unlike the format described in [RFC2865] Section 5.26, this
   data type has no "Vendor-Length" field.  The length of the EVS-Value
   field is implicit and is determined by taking the "Length" of the
   encapsulating RADIUS attribute and then subtracting the length of the

Top      ToC       Page 16 
   Attribute header (2 octets), the "Extended Type" (1 octet), the
   Vendor-Id (4 octets), and the EVS-Type (1 octet).  That is, for
   "Extended Type" Attributes the length of the EVS-Value field is eight
   (8) less than the value of the Length field, and for "Long Extended
   Type" Attributes the length of the EVS-Value field is nine (9) less
   than the value of the Length field.

2.5.  Integer64 Data Type

   We define a new data type in RADIUS, called "integer64", which
   carries a 64-bit unsigned integer in network byte order.

   This data type is intended to be used in any situation where there is
   a need to have counters that can count past 2^32.  The expected use
   of this data type is within Accounting-Request packets, but this data
   type SHOULD be used in any packet where 32-bit integers are expected
   to be insufficient.

   The "integer64" data type can be used in Attributes of any format,
   standard space, extended attributes, TLVs, and VSAs.

   A summary of the "integer64" data type format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Attributes having data type "integer64" MUST have the relevant Length
   field set to eight more than the length of the Attribute header.  For
   standard space Attributes and TLVs, this means that the Length field
   MUST be set to ten (10).  For "Extended Type" Attributes, the Length
   field MUST be set to eleven (11).  For "Long Extended Type"
   Attributes, the Length field MUST be set to twelve (12).

2.6.  Vendor-Id Field

   We define the Vendor-Id field of Vendor-Specific Attributes
   to encompass the entire 4 octets of the Vendor field.
   [RFC2865] Section 5.26 defined it to be 3 octets, with the fourth
   octet being zero.  This change has no immediate impact on RADIUS, as
   the maximum Private Enterprise Code defined is still within 16 bits.

Top      ToC       Page 17 
   However, it is best to make advance preparations for changes in the
   protocol.  As such, it is RECOMMENDED that all implementations
   support four (4) octets for the Vendor-Id field, instead of
   three (3).

2.7.  Attribute Naming and Type Identifiers

   Attributes have traditionally been identified by a unique name and
   number.  For example, the Attribute "User-Name" has been allocated
   number one (1).  This scheme needs to be extended in order to be able
   to refer to attributes of "Extended Type", and to TLVs.  It will also
   be used by IANA for allocating RADIUS Attribute Type values.

   The names and identifiers given here are intended to be used only in
   specifications.  The system presented here may not be useful when
   referring to the contents of a RADIUS packet.  It imposes no
   requirements on implementations, as implementations are free to
   reference RADIUS attributes via any method they choose.

2.7.1.  Attribute and TLV Naming

   RADIUS specifications traditionally use names consisting of one or
   more words, separated by hyphens, e.g., "User-Name".  However, these
   names are not allocated from a registry, and there is no restriction
   other than convention on their global uniqueness.

   Similarly, vendors have often used their company name as the prefix
   for VSA names, though this practice is not universal.  For example,
   for a vendor named "Example", the name "Example-Attribute-Name"
   SHOULD be used instead of "Attribute-Name".  The second form can
   conflict with attributes from other vendors, whereas the first form
   cannot.

   It is therefore RECOMMENDED that specifications give names to
   Attributes that attempt to be globally unique across all RADIUS
   Attributes.  It is RECOMMENDED that a vendor use its name as a unique
   prefix for attribute names, e.g., Livingston-IP-Pool instead of
   IP-Pool.  It is RECOMMENDED that implementations enforce uniqueness
   on names; not doing so would lead to ambiguity and problems.

   We recognize that these suggestions may sometimes be difficult to
   implement in practice.

   TLVs SHOULD be named with a unique prefix that is shared among
   related attributes.  For example, a specification that defines a set
   of TLVs related to time could create attributes called "Time-Zone",
   "Time-Day", "Time-Hour", "Time-Minute", etc.

Top      ToC       Page 18 
2.7.2.  Attribute Type Identifiers

   The RADIUS Attribute Type space defines a context for a particular
   "Extended-Type" field.  The "Extended-Type" field allows for 256
   possible type code values, with values 1 through 240 available for
   allocation.  We define here an identification method that uses a
   "dotted number" notation similar to that used for Object Identifiers
   (OIDs), formatted as "Type.Extended-Type".

   For example, an attribute within the Type space of 241, having
   Extended-Type of one (1), is uniquely identified as "241.1".
   Similarly, an attribute within the Type space of 246, having
   Extended-Type of ten (10), is uniquely identified as "246.10".

2.7.3.  TLV Identifiers

   We can extend the Attribute reference scheme defined above for TLVs.
   This is done by leveraging the "dotted number" notation.  As above,
   we define an additional TLV Type space, within the "Extended Type"
   space, by appending another "dotted number" in order to identify the
   TLV.  This method can be repeated in sequence for nested TLVs.

   For example, let us say that "245.1" identifies RADIUS Attribute Type
   245, containing an "Extended Type" of one (1), which is of type
   "TLV".  That attribute will contain 256 possible TLVs, one for each
   value of the TLV-Type field.  The first TLV-Type value of one (1) can
   then be identified by appending a ".1" to the number of the
   encapsulating attribute ("241.1"), to yield "241.1.1".  Similarly,
   the sequence "245.2.3.4" identifies RADIUS attribute 245, containing
   an "Extended Type" of two (2), which is of type "TLV", which in turn
   contains a TLV with TLV-Type number three (3), which in turn contains
   another TLV, with TLV-Type number four (4).

2.7.4.  VSA Identifiers

   There has historically been no method for numerically addressing
   VSAs.  The "dotted number" method defined here can also be leveraged
   to create such an addressing scheme.  However, as the VSAs are
   completely under the control of each individual vendor, this section
   provides a suggested practice but does not define a standard of any
   kind.

   The Vendor-Specific Attribute has been assigned the Attribute
   number 26.  It in turn carries a 32-bit Vendor-Id, and possibly
   additional VSAs.  Where the VSAs follow the format recommended
   by [RFC2865] Section 5.26, a VSA can be identified as
   "26.Vendor-Id.Vendor-Type".

Top      ToC       Page 19 
   For example, Livingston has Vendor-Id 307 and has defined an
   attribute "IP-Pool" as number 6.  This VSA can be uniquely identified
   as 26.307.6, but it cannot be uniquely identified by name, as other
   vendors may have used the same name.

   Note that there are few restrictions on the size of the numerical
   values in this notation.  The Vendor-Id is a 32-bit number, and the
   VSA may have been assigned from a 16-bit Vendor-Specific Attribute
   Type space.  Implementations SHOULD be capable of handling 32-bit
   numbers at each level of the "dotted number" notation.

   For example, the company USR has historically used Vendor-Id 429 and
   has defined a "Version-Id" attribute as number 32768.  This VSA can
   be uniquely identified as 26.429.32768 but again cannot be uniquely
   identified by name.

   Where a VSA is a TLV, the "dotted number" notation can be used as
   above: 26.Vendor-Id.Vendor-Type.TLV1.TLV2.TLV3, where the "TLVn"
   values are the numerical values assigned by the vendor to the
   different nested TLVs.

2.8.  Invalid Attributes

   The term "invalid attribute" is new to this specification.  It is
   defined to mean that the Length field of an Attribute permits the
   packet to be accepted as not being "malformed".  However, the "Value"
   field of the Attribute does not follow the format required by the
   data type defined for that Attribute, and therefore the Attribute is
   "malformed".  In order to distinguish the two cases, we refer to
   "malformed" packets and "invalid attributes".

   For example, an implementation receives a packet that is well formed.
   That packet contains an Attribute allegedly of data type "address"
   but that has Length not equal to four.  In that situation, the packet
   is well formed, but the Attribute is not.  Therefore, it is an
   "invalid attribute".

   A similar analysis can be performed when an attribute carries TLVs.
   The encapsulating attribute may be well formed, but the TLV may be an
   "invalid attribute".  The existence of an "invalid attribute" in a
   packet or attribute MUST NOT result in the implementation discarding
   the entire packet or treating the packet as a negative
   acknowledgment.  Instead, only the "invalid attribute" is treated
   specially.

   When an implementation receives an "invalid attribute", it SHOULD be
   silently discarded, except when the implementation is acting as a
   proxy (see Section 5.2 for discussion of proxy servers).  If it is

Top      ToC       Page 20 
   not discarded, it MUST NOT be handled in the same manner as a well-
   formed attribute.  For example, receiving an Attribute of data type
   "address" containing either less than four octets or more than
   four octets of data means that the Attribute MUST NOT be treated as
   being of data type "address".  The reason here is that if the
   Attribute does not carry an IPv4 address, the receiver has no idea
   what format the data is in, and it is therefore not an IPv4 address.

   For Attributes of type "Long Extended Type", an Attribute is
   considered to be an "invalid attribute" when it does not match the
   criteria set out in Section 2.2, above.

   For Attributes of type "TLV", an Attribute is considered to be an
   "invalid attribute" when the TLV-Length field allows the
   encapsulating Attribute to be parsed but the TLV-Value field does not
   match the criteria for that TLV.  Implementations SHOULD NOT treat
   the "invalid attribute" property as being transitive.  That is, the
   Attribute encapsulating the "invalid attribute" SHOULD NOT be treated
   as an "invalid attribute".  That encapsulating Attribute might
   contain multiple TLVs, only one of which is an "invalid attribute".

   However, a TLV definition may require particular sub-TLVs to be
   present and/or to have specific values.  If a sub-TLV is missing or
   contains incorrect value(s), or if it is an "invalid attribute", then
   the encapsulating TLV SHOULD be treated as an "invalid attribute".
   This requirement ensures that strongly connected TLVs are either
   handled as a coherent whole or ignored entirely.

   It is RECOMMENDED that Attributes with unknown Type, Extended-Type,
   TLV-Type, or EVS-Type are treated as "invalid attributes".  This
   recommendation is compatible with the suggestion in [RFC2865]
   Section 5 that implementations "MAY ignore Attributes with an
   unknown Type".


Next RFC Part