[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 RFC 6158

Network Working Group                                           G. Weber
INTERNET-DRAFT                                             Cisco Systems
Category: Standards Track                               Alan DeKok (ed.)
                                                              FreeRADIUS
Expires: March 4, 2008

                                                        4 September 2007


                        RADIUS Design Guidelines
                    draft-ietf-radext-design-00.txt

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document provides guidelines for the design of attributes used
   by the Remote Authentication Dial In User Service (RADIUS) protocol.
   It is expected that these guidelines will prove useful to authors and
   reviewers of future RADIUS attribute specifications, both within the
   IETF as well as other Standards Development Organizations (SDOs).





Weber, et al.             Best Current Practice                 [Page 1]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


Table of Contents

1.  Introduction .............................................    3
   1.1.  Applicability .......................................    3
   1.2.  Terminology .........................................    4
   1.3.  Requirements Language ...............................    4
2.  RADIUS Data Model ........................................    4
   2.1.  Standard Space ......................................    5
      2.1.1.  Basic Data Types ...............................    5
      2.1.2.  Tagging Mechanism ..............................    6
      2.1.3.  Complex Attribute Usage ........................    6
   2.2.  Vendor Space ........................................    8
3.  Data Model Issues ........................................   10
   3.1.  Vendor Space ........................................   10
   3.2.  Polymorphic Attributes ..............................   12
4.  IANA Considerations ......................................   13
5.  Security Considerations ..................................   13
6.  References ...............................................   13
   6.1.  Normative References ................................   13
   6.2.  Informative References ..............................   14
Full Copyright Statement .....................................   21






























Weber, et al.             Best Current Practice                 [Page 2]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


1.  Introduction

   This document provides guidelines for the design of RADIUS attributes
   both within the IETF as well as within other Standards Development
   Organizations (SDOs).

   As with "Guidelines for Authors and Reviewers of MIB Documents"
   [RFC4181], it is expected that this document will enable authors to
   check their document against the guidelines prior to requesting a
   review (such an "Expert Review" described in [RFC3575]).  Similarly,
   it is hoped that this document will be of use to reviewers (such as
   WG participants or the AAA Doctors) in improving the consistency of
   reviews.

   In order to meet these objectives, this document needs to cover not
   only the science of attribute design, but also the art.  As a result,
   in addition to covering the most frequently encountered issues, this
   document attempts to provide some of the considerations motivating
   the guidelines.

   In order to characterize current attribute usage, both the basic and
   complex data types defined in the existing RADIUS RFCs are reviewed,
   together with the ad-hoc extensions to that data model that have been
   used in Vendor Specific Attributes (VSAs).  In addition,
   recommendations are made with respect to recommended VSA formats as
   well as handling of RADIUS type 26 attributes within Diameter.

1.1.  Applicability

   The major goal of this document is to encourage the development and
   publication of high quality RADIUS attribute specifications.  By
   articulating RADIUS design guidelines, it is hoped that this document
   will be a step in that direction.  However, the advice in this
   document will not be helpful unless it is put to use.  In particular,
   the authors recommend:

      o Development of a program to encourage SDOs to make their RADIUS
      attribute specifications publicly available;

      o Review of IETF and SDO specifications according to the
      guidelines proposed in this document;

   The advice in this document applies to attributes used to encode
   data.  RADIUS protocol changes, or specification of attributes that
   can be used to provide new RADIUS commands (such as Service-Type) are
   out of scope.  Since protocol changes require greater expertise and
   deeper review, such changes should not be undertaken outside the IETF
   and when handled within the IETF require "IETF Consensus" for



Weber, et al.             Best Current Practice                 [Page 3]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


   adoption, as noted in [RFC3575] Section 2.1.

   As with protocol changes, this document does not provide guidance to
   document authors seeking to change the RADIUS operational model.
   While RADIUS server implementations may keep state, the RADIUS
   protocol is stateless, although information may be passed from one
   protocol transaction to another via the State Attribute.  As a
   result, documents which require stateful protocol behavior without
   use of the State Attribute are inherently incompatible with RADIUS as
   defined in [RFC2865], and need to be redesigned.

   See [FIXES] Section 2.1.1 for a more in-depth discussion of the use
   of the State Attribute.

1.2.  Terminology

   This document uses the following terms:

Network Access Server (NAS)
     A device that provides an access service for a user to a network.

RADIUS server
     A RADIUS authentication server is an entity that provides an
     authentication service to a NAS.

RADIUS proxy
     A RADIUS proxy acts as an authentication server to the NAS, and a
     RADIUS client to the RADIUS server.

1.3.  Requirements Language

   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.  RADIUS Data Model

   The Remote Authentication Dial In User Service (RADIUS) defined in
   [RFC2865] [RFC2866] utilizes elements known as attributes, in order
   to represent authentication, authorization and accounting (AAA) data.

   Unlike SNMP, first defined in [RFC1157] [RFC1155], RADIUS does not
   define a formal data definition language.  A handful of basic data
   types are provided, and a data type is associated with an attribute
   when that attribute is defined.

   Two distinct attribute spaces are defined: the standard space, and a
   vendor specific space.  Attributes in the standard space generally



Weber, et al.             Best Current Practice                 [Page 4]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


   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 or VSA).  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.  Standard Space

   The following subsections describe common data types and formats
   within the RADIUS standard attribute space.  Common exceptions are
   identified.

2.1.1.  Basic Data Types

   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.

   RFC 2865 [RFC2865] defines the following data types:

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

   In addition to these data types, follow-on RADIUS specifications
   define attributes using the following additional types:

   IPv6 address   128 bit value, most significant octet first.
   IPv6 prefix    8 bits of reserved, 8 bits of prefix length, up to
               128 bits of value, most significant octet first.
   integer64      64 bit unsigned value, most significant octet first.

   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,



Weber, et al.             Best Current Practice                 [Page 5]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


   and in [RFC4818] Section 3.  The integer64 type is used for the ARAP-
   Challenge-Response Attribute defined in [RFC2869] Section 5.15, and
   the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2.
   [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in
   length, but denotes it as type "String".

   Given that attributes of type IPv6 address, IPv6 prefix, and
   integer64 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].

   It is worth noting that since RADIUS only supports unsigned integers
   of 32 or 64 bits, attributes utilizing signed integer data types or
   unsigned integer types of other sizes will require code changes, and
   SHOULD be avoided.

2.1.2.  Tagging Mechanism

   [RFC2868] defines an attribute grouping mechanism based on the use of
   a one octet tag value.  Tunnel attributes that refer to the same
   tunnel are grouped together by virtue of using the same tag value.

   This tagging mechanism has some drawbacks.  There are a limited
   number of unique tags (31).  The tags are not well suited for use
   with arbitrary binary data values because it is not always possible
   to tell if the first byte after the Length is the tag or the first
   byte of the untagged value (assuming the tag is optional).

   When integer values are tagged, the value portion is reduced to three
   bytes meaning only 24-bit numbers can be represented.

   The tagging mechanism does not offer an ability to create nested
   groups of attributes.

   Some RADIUS implementations treat tagged attributes as an additional
   data type.

2.1.3.  Complex Attribute Usage

   The RADIUS attribute encoding is summarized in [RFC2865]:

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

   However, some standard attributes do not follow this format.



Weber, et al.             Best Current Practice                 [Page 6]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


   Attributes that utilize sub-fields instead of utilizing a basic data
   type are known as "complex attributes".  As described below,
   definition of complex attributes can lead to interoperability and
   deployment issues, so that they need to introduced with care.

   In general, complex attributes sent from the RADIUS server to the
   client can be supported by concatenating the values into a String
   data type field.  However, separating these values into different
   attributes, each with its own type and length, would make it easier
   for the user to enter the data, would enable additional error
   checking and would simplify implementations by eliminating special
   case, attribute specific parsing.

   One of the fundamental goals of the RADIUS protocol design was to
   allow RADIUS servers to be configured to support new attributes
   without requiring server code changes.  RADIUS server implementations
   typically utilize a data dictionary providing support for basic data
   types, enabling a new attribute to be supported by addition of a
   dictionary entry, without requiring RADIUS server code changes.

   On the RADIUS client, code changes are typically required in order to
   implement a new attribute, since the RADIUS client typically has to
   compose the attribute dynamically when sending.  When receiving, a
   RADIUS client needs to be able to parse the attribute and carry out
   the requested service, so that a detailed understanding of the new
   attribute is required.

   Given this, the introduction of a new basic or complex attribute will
   typically require code changes on the RADIUS client, although the
   magnitude of changes for the complex attribute could be greater, due
   to the potential need for custom parsing logic.

   However, the RADIUS server can be configured to send a new attribute
   by entering its type and data format in the RADIUS server dictionary,
   then filling in the value within a form based on the data type.  For
   complex attribute types not supported by RADIUS server dictionaries,
   changes to the dictionary and forms code can be required in order to
   allow the new attribute to be supported and configured by the RADIUS
   server.

   Code changes can also be required in the RADIUS server's receive
   path, due to limitations in RADIUS server policy languages, which
   typically only provide for limited operations (such as comparisons or
   arithmetic operations) on the basic data types.  Most existing RADIUS
   policy languages typically are not capable of parsing sub-elements,
   or providing sophisticated matching functionality.

   Given these limitations, the introduction of complex attributes can



Weber, et al.             Best Current Practice                 [Page 7]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


   require code changes on the RADIUS server which would be unnecessary
   if basic data types were used instead.  In addition, attribute-
   specific parsing means more complex software to develop and maintain,
   and more complexity can lead to more error prone implementations.
   This can increase costs to network administrators as well as reducing
   reliability and introducing deployment barriers.  As a result, the
   introduction of new complex data types within RADIUS attribute
   specifications SHOULD be avoided.

   The exception to this recommendation are attributes which can be
   treated as opaque data, such as the EAP-Message attribute, defined in
   [RFC3579] Section 3.1.  Since these attributes do not need to be
   parsed by the RADIUS server, the issues arising from policy language
   limitations do not arise.  Similarly, since these attributes can be
   configured on the server using a data type of String, dictionary
   limitations are also not encountered.

   An examination of existing RADIUS RFCs discloses a number of complex
   attributes that have already been defined.  Appendix A includes a
   listing of complex attributes utilized within [RFC2865], [RFC2868],
   [RFC2869], [RFC3162], [RFC4818], and [RFC4675].

   As can be seen in Appendix A, in most cases complex attributes
   involve authentication or security functionality that requires code
   changes on both the RADIUS client and server, regardless of the
   attribute format.  As a result, in most cases the use of complex
   attributes did not create additional interoperability or deployment
   issues.

   In other cases the data are described textually.  This is possible
   because the data types are not sent within the attributes, but are a
   matter for endpoint interpretation.  An implementation can define
   additional data types (e.g. IPv6 address), and use these data types
   today by matching them to the attribute's textual description.

2.2.  Vendor Space

   As noted in [RFC2865] Section 5.26, the VSA format is defined as
   follows:

    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       |            Vendor-Id
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Vendor-Id (cont)           |  String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-




Weber, et al.             Best Current Practice                 [Page 8]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


   The high-order octet of the Vendor-Id field is 0 and the low-order 3
   octets are the SMI Network Management Private Enterprise Code of the
   Vendor in network byte order.

   While the format of the String field is defined by the vendor,
   [RFC2865] Section 5.26 notes:

      It SHOULD be encoded as a sequence of vendor type / vendor length
      / value fields, as follows.  The Attribute-Specific field is
      dependent on the vendor's definition of that attribute.  An
      example encoding of the Vendor-Specific attribute using this
      method follows:

       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       |            Vendor-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Vendor-Id (cont)           | Vendor type   | Vendor length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Attribute-Specific...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

      Multiple sub-attributes MAY be encoded within a single Vendor-
      Specific attribute, although they do not have to be.

   Note that the Vendor type field in the recommended format, like the
   RADIUS type field, is only a single octet.  While this results in an
   efficient encoding, there are situations in which a vendor or SDO
   will eventually wish to define more than 255 attributes.  Also, an
   SDO can be comprised of multiple subgroups, each of whom can desire
   autonomy over the definition of attributes within their group.  In
   such a situation, a 16-bit Vendor type field would be more
   appropriate:

    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       |            Vendor-Id
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Vendor-Id (cont)           |           Vendor type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vendor length |   Attribute-Specific...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Other attribute formats are NOT RECOMMENDED.  Examples of NOT
   RECOMMENDED formats include Vendor types of more than 16 bits, Vendor
   lengths of less than 8 bits, Vendor lengths of more than 8 bits, and
   Vendor-Specific contents that are not in Type-Length-Value format.



Weber, et al.             Best Current Practice                 [Page 9]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


3.  Data Model Issues

   Since the closure of the RADIUS Working Group, the popularity and
   prevalence of RADIUS has continued to grow.  In addition to
   increasing demand for allocation of attributes within the RADIUS
   standard attribute space, the number of vendors and SDOs creating new
   attributes within the vendor-specific attribute space has grown, and
   this has lead to some divergence in approaches to RADIUS attribute
   design.

   In general, standard RADIUS attributes have a more constrained data
   model than attributes within the vendor space.  For example, vendors
   have evolved the data model to support new functions such as
   attribute grouping and attribute fragmentation, with different
   vendors taking different approaches.

   Given these enhancements, it has become difficult for vendors or SDOs
   to translate attributes from the vendor space to the more stringent
   standards space.  For example, a vendor-specific attribute utilizing
   sub-elements could require allocation of several standard space
   attributes utilizing basic data types.  In this case not only would
   translation require substantial additional work, it would further
   deplete the RADIUS standard attribute space.  Given these
   limitations, translation of vendor attributes to the standards space
   is not necessarily desirable, particularly if the VSA specification
   is publicly available and can be implemented within existing RADIUS
   clients and servers.  In such situations the costs may substantially
   outweigh the benefits.  While it is possible that some of the
   enhancements made within the vendor space may eventually become
   available within the standard attribute space, the divergence of the
   standard and vendor attribute spaces is most likely a permanent
   feature, and should be recognized as such.

   For future work, any extensions to the RADIUS data model should be
   used to minimize the use of complex attributes.

3.1.  Vendor Space

   The usage model for RADIUS VSAs is described in [RFC2865] Section
   6.2:

      Note that RADIUS defines a mechanism for Vendor-Specific
      extensions (Attribute 26) and the use of that should be encouraged
      instead of allocation of global attribute types, for functions
      specific only to one vendor's implementation of RADIUS, where no
      interoperability is deemed useful.

   Nevertheless, many new attributes have been defined in the vendor



Weber, et al.             Best Current Practice                [Page 10]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


   specific space in situations where interoperability is not only
   useful, but is required.  For example, Standards Development
   Organizations (SDOs) outside the IETF (such as the IEEE 802 and the
   3rd Generation Partnership Project (3GPP)) have been assigned Vendor-
   Ids, enabling them to define their own VSA format and assign Vendor
   types within their own space.

   The utilization of VSAs by SDOs outside the IETF has gained in
   popularity for several reasons:

Efficiency
     As with SNMP, which defines an "Enterprise" Object Identifier (OID)
     space suitable for use by vendors as well as other SDOs, the
     definition of RADIUS attributes has become a common occurrence as
     part of standards activity outside the IETF.  For reasons of
     efficiency, it is easiest for RADIUS attributes required to manage
     a standard to be developed within the same SDO that develops the
     standard itself.  As noted in "Transferring MIB Work from IETF
     Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few vendors are
     willing to simultaneously fund individuals to participate within an
     SDO to complete a standard, as well as to participate in IETF in
     order to complete the associated RADIUS attributes specification.

Attribute scarcity
     The standard RADIUS attribute space is limited to approximately 250
     unique attributes; of these, only about half remain available for
     allocation.  In the vendor specific space, the number of attributes
     available is a function of the format of the attribute (the size of
     the type field).

   Along with these advantages, some limitations of VSA usage are noted
   in [RFC2865] Section 5.26:

      This Attribute is available to allow vendors to support their own
      extended Attributes not suitable for general usage.  It MUST not
      affect the operation of the RADIUS protocol.

      Servers not equipped to interpret the vendor-specific information
      sent by a client MUST ignore it (although it may be reported).
      Clients which do not receive desired vendor-specific information
      SHOULD make an attempt to operate without it, although they may do
      so (and report they are doing so) in a degraded mode.

   The limitation on changes to the RADIUS protocol effectively
   prohibits VSAs from changing fundamental aspects of RADIUS operation,
   such as modifying RADIUS packet sequences, or adding new commands.
   However, the requirement for clients and servers to be able to
   operate in the absence of VSAs has proved less of a constraint, since



Weber, et al.             Best Current Practice                [Page 11]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


   it is still possible for a RADIUS client and server to mutually
   indicate support for VSAs, after which behavior expectations can be
   reset.

   Therefore, RFC 2865 provides considerable latitude for development of
   new attributes within the vendor space, while prohibiting development
   of protocol variants.  This flexibility implies that RADIUS
   attributes can often be developed within the vendor space without
   loss (and possibly even gain) in functionality.

   As a result, translation of RADIUS attributes developed within the
   vendor space into the standard space may provide only modest
   benefits, while accelerating the exhaustion of the standard attribute
   space.  Rather than expecting all RADIUS attribute specifications
   requiring interoperability to be developed within the IETF and
   expecting that they be allocated within the standards space, a more
   scalable approach is to recognize the flexibility of the vendor space
   while working toward improvements in the quality and availability of
   RADIUS attribute specifications, regardless of where they are
   developed.

   In particular, it is RECOMMENDED that RADIUS Attribute specifications
   allocate attributes from the vendor space, rather than requesting an
   allocation from the RADIUS standard attribute space, for attributes
   matching any of the following criteria:
      * attributes relying on data types not defined within RADIUS *
      attributes intended primarily for use within an SDO * attributes
      intended primarily for use within a group of SDOs.

3.2.  Polymorphic Attributes

   A polymorphic attribute is one whose format is dynamic.  For example,
   rather than using a fixed data format, an attribute's format might
   change based on the contents of another attribute.  Or, the meaning
   of an attribute may be dependent on earlier packets in a sequence.

   Typically RADIUS server dictionary entries are static, enabling the
   user to enter the contents of an attribute, without support for
   changing the format based on dynamic conditions.  However, this does
   not prevent implementations from returning different attributes based
   on the contents of received attributes; this is a common feature of
   existing RADIUS implementations.

   In general, polymorphism is NOT RECOMMENDED.  Polymorphism rarely
   enables capabilities that would not be available through use of
   multiple attributes, while requiring code changes in the RADIUS
   server in situations where attributes with fixed formats will not.
   Thus, polymorphism increases complexity while decreasing generality,



Weber, et al.             Best Current Practice                [Page 12]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


   without delivering any corresponding benefits.

   Note that changing an attribute's format dynamically is not the same
   thing as utilizing a fixed format and computing the attribute itself
   dynamically.  RADIUS authentication attributes such as User-Password,
   EAP-Message, etc. while being computed dynamically, utilize a fixed
   format.

4.  IANA Considerations

   This document defines the use of a RADIUS type 26 attribute code in
   the Diameter Protocol space as defined in [RFC3588] and [RFC4005].

5.  Security Considerations

   This specification provides guidelines for the design of RADIUS
   attributes used in authentication, authorization and accounting.
   Threats and security issues for this application are described in
   [RFC3579] and [RFC3580]; security issues encountered in roaming are
   described in [RFC2607].

   Encryption of RADIUS attributes on a per-attribute basis is necessary
   in some cases.  The current standard mechanism for this is described
   in [RFC2865] Section 5.2 (for obscuring User-Password values) and is
   based on the MD5 algorithm specified in [RFC1321].  The MD5 algorithm
   has recently become a focus of scrutiny and concern in security
   circles, and as a result, the use of this technique in new attributes
   is NOT RECOMMENDED.

   Where new RADIUS attributes utilize cryptographic algorithms,
   algorithm negotiation SHOULD be supported.  Specification of a
   mandatory-to-implement algorithm is REQUIRED, and it is RECOMMENDED
   that the mandatory-to-implement algorithm be certifiable under FIPS
   140.

6.  References

6.1.  Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
          Authentication Dial In User Service (RADIUS)", RFC 2865, June
          2000.

[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
          Authentication Dial In User Service)", RFC 3575, July 2003.



Weber, et al.             Best Current Practice                [Page 13]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter
          Network Access Server Application", RFC 4005, August 2005.

6.2.  Informative References

[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of
          management information for TCP/IP-based internets", STD 16,
          RFC 1155, May 1990.

[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
          Network Management Protocol (SNMP)", STD 15, RFC 1157, May
          1990.

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
          April 1992.

[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
          Implementation in Roaming", RFC 2607, June 1999.

[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.,
          and I. Goyret, "RADIUS Attributes for Tunnel Protocol
          Support", RFC 2868, June 2000.

[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions",
          RFC 2869, June 2000.

[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC
          3162, August 2001.

[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
          In User Service) Support For Extensible Authentication
          Protocol (EAP)", RFC 3579, September 2003.

[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE
          802.1X Remote Authentication Dial In User Service (RADIUS)
          Usage Guidelines", RFC3580, September 2003.

[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
          Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
          RFC 3629, November 2003.

[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
          Documents", RFC 4181, September 2005.




Weber, et al.             Best Current Practice                [Page 14]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


[RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG
          to IEEE 802.1 WG", RFC 4663, September 2006.

[RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for
          Virtual LAN and Priority Support", RFC 4675, September 2006.

[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
          Attribute", RFC 4818, April 2007.

[FIXES]   Nelson, D. and DeKok, A, "Common Remote Authentication Dial In
          User Service (RADIUS) Implementation Issues and Suggested
          Fixes", RFC XXXX, DATE YYYY

[IEEE-802.1Q]
          IEEE Standards for Local and Metropolitan Area Networks: Draft
          Standard for Virtual Bridged Local Area Networks,
          P802.1Q-2003, January 2003.


































Weber, et al.             Best Current Practice                [Page 15]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


Appendix A - Complex Attributes

   This section summarizes RADIUS attributes with complex data types
   that are defined with existing RFCs.

A.1 CHAP-Password

   [RFC2865] Section 5.3 defines the CHAP-Password Attribute which is
   sent from the RADIUS client to the RADIUS server in an Access-
   Request.  The the data type of the CHAP Identifier is not given, only
   the one octet length:

    0                   1                   2
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  CHAP Ident   |  String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Since this is an authentication attribute, code changes would have
   been required on the RADIUS client and server, regardless of the
   attribute format.

A.2 CHAP-Challenge

   [RFC2865] Section 5.40 defines the CHAP-Challenge Attribute which is
   sent from the RADIUS client to the RADIUS server in an Access-
   Request.  While the data type of the CHAP Identifier is given, the
   text also says

      If the CHAP challenge value is 16 octets long it MAY be placed in
      the Request Authenticator field instead of using this attribute.

   Defining attributes to contain values taken from the RADIUS packet
   header is NOT RECOMMENDED.  Attributes should have values that are
   packed into a RADIUS AVP.

A.3 Tunnel-Password

   [RFC2868] Section 3.5 defines the Tunnel-Password Attribute, which is
   sent from the RADIUS server to the client in an Access-Accept.  This
   attribute includes Tag and Salt fields, as well as a String field
   which consists of three logical sub-fields: the Data-Length (one
   octet) and Password sub-fields (both of which are required), and the
   optional Padding sub-field.  The attribute appears as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Weber, et al.             Best Current Practice                [Page 16]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


   |     Type      |    Length     |     Tag       |   Salt
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Salt (cont)  |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Given that the String field is encrypted, this attribute would have
   required code changes on the RADIUS client and server, regardless of
   the format.

A.4 ARAP-Password

   [RFC2869] Section 5.4 defines the ARAP-Password attribute, which is
   sent from the RADIUS client to the server in an Access-Request.  It
   contains four 4 octet values, instead of having a single Value field:

    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     |             Value1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |             Value2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |             Value3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |             Value4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   As with the CHAP-Password attribute, this is an authentication
   attribute which would have required code changes on the RADIUS client
   and server regardless of format.

A.5 ARAP-Features

   [RFC2869] Section 5.5 defines the ARAP-Features Attribute, which is
   sent from the RADIUS server to the client in an Access-Accept or
   Access-Challenge.  It contains a compound string of two single octet
   values, plus three 4-octet values, which the RADIUS client
   encapsulates in a feature flags packet in the ARAP protocol:

   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     |     Value1    |    Value2     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Value3                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Weber, et al.             Best Current Practice                [Page 17]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


   |                           Value4                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Value5                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Unlike previous attributes, this attribute contains no encrypted
   component nor is it directly involved in authentication.  The
   individual sub-fields therefore could have been encapsulated in
   separate attributes, although this would have required creation of an
   8 bit data type.

A.6 Connect-Info
   [RFC2869] Section 5.11 defines the Connect-Info attribute, which is
   used to indicate the nature of the connection.

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

   Even though the type is Text, the rest of the description indicates
   that it is a complex attribute:

      The Text field consists of UTF-8 encoded 10646 [8] characters.
      The connection speed SHOULD be included at the beginning of the
      first Connect-Info attribute in the packet.  If the transmit and
      receive connection speeds differ, they may both be included in the
      first attribute with the transmit speed first (the speed the NAS
      modem transmits at), a slash (/), the receive speed, then
      optionally other information.
      For example, "28800 V42BIS/LAPM" or "52000/31200 V90"

      More than one Connect-Info attribute may be present in an
      Accounting-Request packet to accommodate expected efforts by ITU
      to have modems report more connection information in a standard
      format that might exceed 252 octets.

   This attribute contains no encrypted component nor is it directly
   involved in authentication.  The individual sub-fields therefore
   could have been encapsulated in separate attributes

A.7 Framed-IPv6-Prefix

   [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and
   [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix
   Attribute; these attributes are sent from the RADIUS server to the
   client in an Access-Accept.



Weber, et al.             Best Current Practice                [Page 18]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


    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     |  Reserved     | Prefix-Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Prefix
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Prefix
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Prefix
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Prefix                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The sub-fields encoded in these attributes are strongly related, and
   there was no previous definition of this data structure that could be
   referenced.  Support for this attribute requires code changes on both
   the client and server, due to a new data type being defined.  In this
   case it appears to be acceptable to encode them in one attribute.

A.8 Egress-VLANID

   [RFC4675] Section 2.1 defines the Egress-VLANID Attribute which can
   be sent by a RADIUS client or server.

       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     |            Value
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   While it appears superficially to be of type Integer, the Value field
   is actually a packed structure, as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Tag Indic.   |        Pad            |       VLANID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The length of the VLANID field is defined by the [IEEE-802.1Q]
   specification.  The Tag indicator field is either 0x31 or 0x32, for
   compatibility with the Egress-VLAN-Name, as discussed below.  The
   complex structure of Egress-VLANID overlaps with that of the base
   Integer data type, meaning that no code changes are required for a
   RADIUS server to support this attribute.  Code changes are required



Weber, et al.             Best Current Practice                [Page 19]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


   on the NAS, if only to implement the VLAN ID enforcement.

   Given the IEEE VLAN requirements and the limited data model of
   RADIUS, the chosen method is likely the best of the possible
   alternatives.

A.9 Egress-VLAN-Name

   [RFC4675] Section 2.3 defines the Egress-VLAN-Name Attribute which
   can be sent by a RADIUS client or server.

       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     |   Tag Indic.  |   String...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   The Tag Indicator is either the character '1' or '2', which in ASCII
   map to the identical values for Tag Indicator in Egress-VLANID,
   above.  The complex structure of this attribute is acceptable for
   reasons identical to those given for Egress-VLANID.

Acknowledgments

   We would like to acknowledge David Nelson, Bernard Aboba, Emile van
   Bergen, Barney Wolff and Glen Zorn for contributions to this
   document.

Authors' Addresses

   Greg Weber
   Cisco Systems
   10850 Murdock Road
   Knoxville, TN  37932
   USA

   Email: gdweber@cisco.com

   Alan DeKok
   The FreeRADIUS Server Project
   http://freeradius.org/

   Email: aland@freeradius.org









Weber, et al.             Best Current Practice                [Page 20]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Weber, et al.             Best Current Practice                [Page 21]


INTERNET-DRAFT          RADIUS Design Guidelines        4 September 2007


Open issues

   Open issues relating to this document are tracked on the following
   web site:

   http://www.drizzle.com/~aboba/RADEXT/













































Weber, et al.             Best Current Practice                [Page 22]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/