doc: Add RFC documents

1 files changed, 2131 insertions, 0 deletions

diff --git a/doc/rfc/rfc6158.txt b/doc/rfc/rfc6158.txt
new file mode 100644
index 0000000..6557f4e
--- /dev/null
+++ b/doc/rfc/rfc6158.txt
@@ -0,0 +1,2131 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     A. DeKok, Ed.
+Request for Comments: 6158                                    FreeRADIUS
+BCP: 158                                                        G. Weber
+Category: Best Current Practice                   Individual Contributor
+ISSN: 2070-1721                                               March 2011
+
+
+
+                        RADIUS Design Guidelines
+
+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, within the IETF
+   as well as other Standards Development Organizations (SDOs).
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   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
+   BCPs 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/rfc6158.
+
+Copyright Notice
+
+   Copyright (c) 2011 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.
+
+
+
+
+
+DeKok & Weber             Best Current Practice                 [Page 1]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................4
+      1.2. Requirements Language ......................................4
+      1.3. Applicability ..............................................5
+           1.3.1. Reviews .............................................5
+   2. Guidelines ......................................................6
+      2.1. Data Types .................................................8
+      2.2. Vendor Space ...............................................9
+      2.3. Service Definitions and RADIUS .............................9
+      2.4. Translation of Vendor Specifications ......................10
+   3. Rationale ......................................................11
+      3.1. RADIUS Operational Model ..................................11
+      3.2. Data Model Issues .........................................14
+           3.2.1. Issues with Definitions of Types ...................15
+           3.2.2. Tagging Mechanism ..................................16
+           3.2.3. Complex Data Types .................................16
+           3.2.4. Complex Data Type Exceptions .......................18
+      3.3. Vendor Space ..............................................19
+           3.3.1. Interoperability Considerations ....................20
+           3.3.2. Vendor Allocations .................................20
+           3.3.3. SDO Allocations ....................................20
+      3.4. Polymorphic Attributes ....................................21
+   4. IANA Considerations ............................................22
+   5. Security Considerations ........................................22
+      5.1. New Data Types and Complex Attributes .....................23
+   6. References .....................................................24
+      6.1. Normative References ......................................24
+      6.2. Informative References ....................................24
+   Appendix A.  Design Guidelines Checklist ..........................27
+      A.1. Types Matching the RADIUS Data Model ......................27
+         A.1.1. Transport of Basic Data Types ........................27
+         A.1.2. Transport of Authentication and Security Data ........27
+         A.1.3. Opaque Data Types ....................................27
+         A.1.4. Pre-existing Data Types ..............................28
+
+
+
+DeKok & Weber             Best Current Practice                 [Page 2]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+      A.2. Improper Data Types .......................................28
+         A.2.1. Simple Data Types ....................................28
+         A.2.2. More Complex Data Types ..............................29
+      A.3. Vendor-Specific Formats ...................................29
+      A.4. Changes to the RADIUS Operational Model ...................30
+      A.5. Allocation of Attributes ..................................31
+   Appendix B.  Complex Attributes ...................................32
+      B.1. CHAP-Password .............................................32
+      B.2. CHAP-Challenge ............................................32
+      B.3. Tunnel-Password ...........................................33
+      B.4. ARAP-Password .............................................33
+      B.5. ARAP-Features .............................................34
+      B.6. Connect-Info ..............................................34
+      B.7. Framed-IPv6-Prefix ........................................35
+      B.8. Egress-VLANID .............................................36
+      B.9. Egress-VLAN-Name ..........................................37
+      B.10. Digest-* .................................................37
+   Acknowledgments ...................................................37
+
+1.  Introduction
+
+   This document provides guidelines for the design of Remote
+   Authentication Dial In User Service (RADIUS) attributes within the
+   IETF as well as within other Standards Development Organizations
+   (SDOs).  By articulating RADIUS design guidelines, it is hoped that
+   this document will encourage the development and publication of high-
+   quality RADIUS attribute specifications.
+
+   However, the advice in this document will not be helpful unless it is
+   put to use.  As with "Guidelines for Authors and Reviewers of MIB
+   Documents" [RFC4181], it is expected that authors will check their
+   document against the guidelines in this document prior to publication
+   or requesting review (such as an "Expert Review" described in
+   [RFC3575]).  Similarly, it is expected that this document will be
+   used by reviewers (such as WG participants or the Authentication,
+   Authorization, and Accounting (AAA) Doctors [DOCTORS]), resulting in
+   an improvement in 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.  Therefore, in
+   addition to covering the most frequently encountered issues, this
+   document explains some of the considerations motivating the
+   guidelines.  These considerations include complexity trade-offs that
+   make it difficult to provide "hard and fast" rules for attribute
+   design.  This document explains those trade-offs through reviews of
+   current attribute usage.
+
+
+
+
+
+DeKok & Weber             Best Current Practice                 [Page 3]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   The rest of the document is organized as follows.  Section 1
+   discusses the applicability of the guidelines and defines a
+   recommended review process for RADIUS specifications.  Section 2
+   defines the design guidelines in terms of what is "RECOMMENDED" and
+   "NOT RECOMMENDED".  Section 3 gives a longer explanation of the
+   rationale behind the guidelines given in the previous section.
+   Appendix A repeats the guidelines in a "checklist" format.  Appendix
+   B discusses previously defined attributes that do not follow the
+   guidelines.
+
+   Authors of new RADIUS specifications can be compliant with the design
+   guidelines by working through the checklists given in Appendix A.
+   Reviewers of RADIUS specifications are expected to be familiar with
+   the entire document.
+
+1.1.  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, authorization, and accounting (AAA)
+      server is an entity that provides one or more AAA services to a
+      NAS.
+
+   Standard space
+      Codes in the RADIUS Attribute Type Space that are allocated by
+      IANA and that follow the format defined in Section 5 of RFC 2865
+      [RFC2865].
+
+   Vendor space
+      The contents of the Vendor-Specific Attribute (VSA), as defined in
+      [RFC2865], Section 5.26.  These attributes provide a unique
+      attribute type space in the "String" field for each vendor
+      (identified by the Vendor-Type field), which they can self-
+      allocate.
+
+1.2.  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].
+
+
+
+
+
+
+
+DeKok & Weber             Best Current Practice                 [Page 4]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+1.3.  Applicability
+
+   The advice in this document applies to RADIUS attributes used to
+   encode service-provisioning, authentication, or accounting data based
+   on the attribute encodings and data formats defined in RFC 2865
+   [RFC2865], RFC 2866 [RFC2866], and subsequent RADIUS RFCs.
+
+   Since this document represents a Best Current Practice, it does not
+   update or deprecate existing standards.  As a result, uses of the
+   terms "MUST" and "MUST NOT" are limited to requirements already
+   present in existing documents.
+
+   It is RECOMMENDED that these guidelines be followed for all new
+   RADIUS specifications, whether they originate from a vendor, an SDO,
+   or the IETF.  Doing so will ensure the widest possible applicability
+   and interoperability of the specifications, while requiring minimal
+   changes to existing systems.  In particular, it is expected that
+   RADIUS specifications requesting allocation within the standard space
+   will follow these guidelines and will explain why this is not
+   possible if they cannot.
+
+   However, there are situations in which vendors or SDOs can choose not
+   to follow these guidelines without major consequences.  As noted in
+   Section 5.26 of [RFC2865], Vendor-Specific Attributes (VSAs) are
+   "available to allow vendors to support their own extended Attributes
+   not suitable for general usage".  Where vendors or SDOs develop
+   specifications "not suitable for general usage", limited
+   interoperability and inability to use existing implementations may be
+   acceptable, and, in these situations, vendors and SDOs MAY choose not
+   to conform to these guidelines.
+
+   Note that the RADEXT WG is currently (as of 2011) involved in
+   developing updates to RADIUS.  Those updates will provide their own
+   usage guidelines that may modify some of the guidelines defined here,
+   such as defining new data types, practices, etc.
+
+   RADIUS protocol changes, or specification of attributes (such as
+   Service-Type), that can, in effect, provide new RADIUS commands
+   require greater expertise and deeper review, as do changes to the
+   RADIUS operational model.  As a result, such changes are outside the
+   scope of this document and MUST NOT be undertaken outside the IETF.
+
+1.3.1.  Reviews
+
+   For specifications utilizing attributes within the standard space,
+   conformance with the design guidelines in this document is expected
+   unless a good case can be made for an exception.  Reviewers SHOULD
+   use the design guidelines as a review checklist.
+
+
+
+DeKok & Weber             Best Current Practice                 [Page 5]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   While not required, IETF review may also be beneficial for
+   specifications utilizing the vendor space.  Experience has shown that
+   attributes not originally designed for general usage can subsequently
+   garner wide-spread deployment.  An example is the Vendor-Specific
+   Attributes defined in [RFC2548], which have been widely implemented
+   within IEEE 802.11 Access Points.
+
+   In order to assist in the development of specifications conforming to
+   these guidelines, authors can request review by sending an email to
+   the AAA Doctors [DOCTORS] or equivalent mailing list.  The IETF
+   Operations & Management Area Directors will then arrange for the
+   review to be completed and posted to the AAA Doctors mailing list
+   [DOCTORS], RADEXT WG mailing list, or other IETF mailing lists.
+   Since reviews are handled by volunteers, responses are provided on a
+   best-effort basis, with no service-level guarantees.  Authors are
+   encouraged to seek review as early as possible, so as to avoid
+   potential delays.
+
+   As reviewers require access to the specification, vendors and SDOs
+   are encouraged to make it publicly available.  Where the RADIUS
+   specification is embedded within a larger document that cannot be
+   made public, the RADIUS attribute and value definitions can be made
+   available on a public web site or can be published as an
+   Informational RFC, as with [RFC4679].
+
+   The review process requires neither allocation of attributes within
+   the standard space nor publication of an RFC.  Requiring SDOs or
+   vendors to rehost VSAs into the standard space solely for the purpose
+   of obtaining review would put pressure on the standard space and may
+   be harmful to interoperability since it would create two ways to
+   provision the same service.  Rehosting may also require changes to
+   the RADIUS data model, which will affect implementations that do not
+   intend to support the SDO or vendor specifications.
+
+   Similarly, vendors are encouraged to make their specifications
+   publicly available, for maximum interoperability.  However, it is not
+   necessary for a vendor to request publication of a VSA specification
+   as an RFC.
+
+2.  Guidelines
+
+   The RADIUS protocol as defined in [RFC2865] and [RFC2866] uses
+   elements known as attributes in order to represent authentication,
+   authorization, and accounting data.
+
+
+
+
+
+
+
+DeKok & Weber             Best Current Practice                 [Page 6]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   Unlike Simple Network Management Protocol (SNMP), first defined in
+   [RFC1157] and [RFC1155], RADIUS does not define a formal data
+   definition language.  The data type of RADIUS attributes is not
+   transported on the wire.  Rather, the data type of a RADIUS attribute
+   is fixed when an 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.
+
+   To explain the implications of this early RADIUS design decision, we
+   distinguish two kinds of data types, namely "basic" and "complex".
+   Basic data types use one of the existing RADIUS data types as defined
+   in Section 2.1, encapsulated in a [RFC2865] RADIUS attribute or in a
+   [RFC2865] RADIUS VSA.  All other data formats are "complex types".
+
+   RADIUS attributes can be classified into one of three broad
+   categories:
+
+      * Attributes that are of interest to a single vendor, e.g., for a
+        product or product line.  Minimal cross-vendor interoperability
+        is needed.
+
+        Vendor-Specific Attributes (VSAs) are appropriate for use in
+        this situation.  Code-point allocation is managed by the vendor
+        with the vendor space defined by their Private Enterprise Number
+        (PEN), as given in the Vendor-Id field.
+
+      * Attributes that are of interest to an industry segment, where an
+        SDO defines the attributes for that industry.  Multi-vendor
+        interoperability within an industry segment is expected.
+
+        Vendor-Specific Attributes (VSAs) MUST be used.  Code-point
+        allocation is managed by the SDO with the vendor space defined
+        by the SDO's PEN rather than the PEN of an individual vendor.
+
+      * Attributes that are of broad interest to the Internet community.
+        Multi-vendor interoperability is expected.
+
+        Attributes within the standard space are appropriate for this
+        purpose and are allocated via IANA as described in [RFC3575].
+        Since the standard space represents a finite resource, and is
+        the only attribute space available for use by IETF working
+        groups, vendors, and SDOs are encouraged to utilize the vendor
+        space rather than request allocation of attributes from the
+        standard space.  Usage of attribute type codes reserved for
+        standard attributes is considered antisocial behavior and is
+        strongly discouraged.
+
+
+
+
+
+DeKok & Weber             Best Current Practice                 [Page 7]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+2.1.  Data Types
+
+   RADIUS defines a limited set of data types, defined as "basic data
+   types".  The following data qualifies as "basic data types":
+
+      * 32-bit unsigned integer in network byte order.
+
+      * Enumerated data types, represented as a 32-bit unsigned integer
+        with a list of name to value mappings (e.g., Service-Type).
+
+      * IPv4 address in network byte order.
+
+      * Time as a 32-bit unsigned value in network byte order and in
+        seconds since 00:00:00 UTC, January 1, 1970.
+
+      * IPv6 address in network byte order.
+
+      * Interface-Id (8-octet string in network byte order).
+
+      * IPv6 prefix.
+
+      * String (i.e., binary data), totaling 253 octets or less in
+        length.  This includes the opaque encapsulation of data
+        structures defined outside of RADIUS.  See also Appendix A.1.3
+        for additional discussion.
+
+      * UTF-8 text [RFC3629], totaling 253 octets or less in length.
+
+   Note that the length limitations for VSAs of type String and Text are
+   less than 253 octets, due to the additional overhead of the Vendor-
+   Specific encoding.
+
+   The following data also qualifies as "basic data types":
+
+      * Attributes grouped into a logical container using the [RFC2868]
+        tagging mechanism.  This approach is NOT RECOMMENDED (see
+        Section 3.2.2) but is permissible where the alternatives are
+        worse.
+
+      * Attributes requiring the transport of more than 253 octets of
+        Text or String data.  This includes the opaque encapsulation of
+        data structures defined outside of RADIUS, e.g., EAP-Message.
+
+   All other data formats (including nested attributes) are defined to
+   be "complex data types" and are NOT RECOMMENDED for normal use.
+   Complex data types MAY be used in situations where they reduce
+   complexity in non-RADIUS systems or where using the basic data types
+   would be awkward (such as where grouping would be required in order
+
+
+
+DeKok & Weber             Best Current Practice                 [Page 8]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   to link related attributes).  Since there are no "hard and fast"
+   rules for where complexity is best located, each situation has to be
+   decided on a case-by-case basis.  Examples of this trade-off are
+   discussed in Appendix B.  Where a complex data type is selected, an
+   explanation SHOULD be offered as to why this was necessary.
+
+2.2.  Vendor Space
+
+   The Vendor space is defined to be the contents of the Vendor-Specific
+   Attribute ([RFC2865], Section 5.26) where the Vendor-Id defines the
+   space for a particular vendor, and the contents of the "String" field
+   define a unique attribute type space for that vendor.  As discussed
+   there, it is intended for vendors and SDOs to support their own
+   attributes not suitable for general use.
+
+   While the encoding of attributes within the vendor space is under the
+   control of vendors and SDOs, following the guidelines described here
+   is advantageous since it enables maximum interoperability with
+   minimal changes to existing systems.
+
+   For example, RADIUS server support for new attributes using "basic
+   data types" can typically be accomplished by editing a RADIUS
+   dictionary, whereas "complex data types" typically require RADIUS
+   server code changes, which can add complexity and delays in
+   implementation.
+
+   Vendor RADIUS Attribute specifications SHOULD self-allocate
+   attributes from the vendor space rather than request an allocation
+   from within the standard space.
+
+   VSA encodings that do not follow the [RFC2865], Section 5.26 encoding
+   scheme are NOT RECOMMENDED.  Although [RFC2865] does not mandate it,
+   implementations commonly assume that the Vendor Id can be used as a
+   key to determine the on-the-wire encoding of a VSA.  Vendors
+   therefore SHOULD NOT use multiple encodings for VSAs that are
+   associated with a particular Vendor Id.  A vendor wishing to use
+   multiple VSA encodings SHOULD request one Vendor Id for each VSA
+   encoding that they will use.
+
+2.3.  Service Definitions and RADIUS
+
+   RADIUS specifications define how an existing service or protocol can
+   be provisioned using RADIUS, usually via the Service-Type Attribute.
+   Therefore, it is expected that a RADIUS attribute specification will
+   reference documents defining the protocol or service to be
+   provisioned.  Within the IETF, a RADIUS attribute specification
+
+
+
+
+
+DeKok & Weber             Best Current Practice                 [Page 9]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   SHOULD NOT be used to define the protocol or service being
+   provisioned.  New services using RADIUS for provisioning SHOULD be
+   defined elsewhere and referenced in the RADIUS specification.
+
+   New attributes, or new values of existing attributes, SHOULD NOT be
+   used to define new RADIUS commands.  RADIUS attributes are intended
+   to:
+
+      * authenticate users
+
+      * authorize users (i.e., service provisioning or changes to
+        provisioning)
+
+      * account for user activity (i.e., logging of session activity)
+
+   Requirements for allocation of new commands (i.e., the Code field in
+   the packet header) and new attributes within the standard space are
+   described in [RFC3575], Section 2.1.
+
+2.4.  Translation of Vendor Specifications
+
+   [RFC2865], Section 5.26 defines Vendor-Specific Attributes as
+   follows:
+
+      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 proven to be less of a constraint
+   since 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 with gain) in functionality.
+
+
+
+DeKok & Weber             Best Current Practice                [Page 10]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   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 space.
+   We do not expect that all RADIUS attribute specifications requiring
+   interoperability will be developed within the IETF, and allocated
+   from the standard 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.
+
+   It is therefore NOT RECOMMENDED that specifications intended solely
+   for use by a vendor or SDO be translated into the standard space.
+
+3.  Rationale
+
+   This section outlines the rationale behind the above recommendations.
+
+3.1.  RADIUS Operational Model
+
+   The RADIUS operational model includes several assumptions:
+
+      * The RADIUS protocol is stateless.
+
+      * Provisioning of services is not possible within an Access-Reject
+        or Disconnect-Request.
+
+      * There is a distinction between authorization checks and user
+        authentication.
+
+      * The protocol provides for authentication and integrity
+        protection of packets.
+
+      * The RADIUS protocol is a Request/Response protocol.
+
+      * The protocol defines packet length restrictions.
+
+   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 that require stateful protocol behavior without use
+   of the State Attribute are inherently incompatible with RADIUS as
+   defined in [RFC2865] and MUST be redesigned.  See [RFC5080], Section
+   2.1.1 for additional discussion surrounding the use of the State
+   Attribute.
+
+   As noted in [RFC5080], Section 2.6, the intent of an Access-Reject is
+   to deny access to the requested service.  As a result, RADIUS does
+   not allow the provisioning of services within an Access-Reject or
+
+
+
+DeKok & Weber             Best Current Practice                [Page 11]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   Disconnect-Request.  Documents that include provisioning of services
+   within an Access-Reject or Disconnect-Request are inherently
+   incompatible with RADIUS and need to be redesigned.
+
+   [RFC5176], Section 3 notes the following:
+
+      A Disconnect-Request MUST contain only NAS and session
+      identification attributes.  If other attributes are included in a
+      Disconnect-Request, implementations MUST send a Disconnect-NAK; an
+      Error-Cause Attribute with value "Unsupported Attribute" MAY be
+      included.
+
+   As a result, documents that include provisioning of services within a
+   Disconnect-Request are inherently incompatible with RADIUS and need
+   to be redesigned.
+
+   As noted in [RFC5080], Section 2.1.1, a RADIUS Access-Request may not
+   contain user authentication attributes or a State Attribute linking
+   the Access-Request to an earlier user authentication.  Such an
+   Access-Request, known as an authorization check, provides no
+   assurance that it corresponds to a live user.  RADIUS specifications
+   defining attributes containing confidential information (such as
+   Tunnel-Password) should be careful to prohibit such attributes from
+   being returned in response to an authorization check.  Also,
+   [RFC5080], Section 2.1.1 notes that authentication mechanisms need to
+   tie a sequence of Access-Request/Access-Challenge packets together
+   into one authentication session.  The State Attribute is RECOMMENDED
+   for this purpose.
+
+   While [RFC2865] did not require authentication and integrity
+   protection of RADIUS Access-Request packets, subsequent
+   authentication mechanism specifications, such as RADIUS/EAP [RFC3579]
+   and Digest Authentication [RFC5090], have mandated authentication and
+   integrity protection for certain RADIUS packets.  [RFC5080], Section
+   2.1.1 makes this behavior RECOMMENDED for all Access-Request packets,
+   including Access-Request packets performing authorization checks.  It
+   is expected that specifications for new RADIUS authentication
+   mechanisms will continue this practice.
+
+   The RADIUS protocol as defined in [RFC2865] is a request-response
+   protocol spoken between RADIUS clients and servers.  A single RADIUS
+   request packet ([RFC2865], [RFC2866], or [RFC5176]) will solicit in
+   response at most a single response packet, sent to the IP address and
+   port of the RADIUS client that originated the request.  Changes to
+   this model are likely to require major revisions to existing
+   implementations, and this practice is NOT RECOMMENDED.
+
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 12]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   The Length field in the RADIUS packet header is defined in [RFC2865]
+   Section 3.  It is noted there that the maximum length of a RADIUS
+   packet is 4096 octets.  As a result, attribute designers SHOULD NOT
+   assume that a RADIUS implementation can successfully process RADIUS
+   packets larger than 4096 octets.
+
+   Even when packets are less than 4096 octets, they may be larger than
+   the Path Maximum Transmission Unit (PMTU).  Any packet larger than
+   the PMTU will be fragmented, making communications more brittle as
+   firewalls and filtering devices often discard fragments.  Transport
+   of fragmented UDP packets appears to be a poorly tested code path on
+   network devices.  Some devices appear to be incapable of transporting
+   fragmented UDP packets, making it difficult to deploy RADIUS in a
+   network where those devices are deployed.  We RECOMMEND that RADIUS
+   messages be kept as small possible.
+
+   If a situation is envisaged where it may be necessary to carry
+   authentication, authorization, or accounting data in a packet larger
+   than 4096 octets, then one of the following approaches is
+   RECOMMENDED:
+
+      1.  Utilization of a sequence of packets.
+          For RADIUS authentication, a sequence of Access-
+          Request/Access-Challenge packets would be used.  For this to
+          be feasible, attribute designers need to enable inclusion of
+          attributes that can consume considerable space within Access-
+          Challenge packets.  To maintain compatibility with existing
+          NASes, either the use of Access-Challenge packets needs to be
+          permissible (as with RADIUS/EAP, defined in [RFC3579]) or
+          support for receipt of an Access-Challenge needs to be
+          indicated by the NAS (as in RADIUS Location [RFC5580]).  Also,
+          the specification needs to clearly describe how attribute
+          splitting is to be signaled and how attributes included within
+          the sequence are to be interpreted, without requiring stateful
+          operation.  Unfortunately, previous specifications have not
+          always exhibited the required foresight.  For example, even
+          though very large filter rules are conceivable, the NAS-
+          Filter-Rule Attribute defined in [RFC4849] is not permitted in
+          an Access-Challenge packet, nor is a mechanism specified to
+          allow a set of NAS-Filter-Rule Attributes to be split across
+          an Access-Request/Access-Challenge sequence.
+
+          In the case of RADIUS accounting, transporting large amounts
+          of data would require a sequence of Accounting-Request
+          packets.  This is a non-trivial change to RADIUS, since RADIUS
+          accounting clients would need to be modified to split the
+
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 13]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+          attribute stream across multiple Accounting-Requests, and
+          billing servers would need to be modified to reassemble and
+          interpret the attribute stream.
+
+      2.  Utilization of names rather than values.
+          Where an attribute relates to a policy that could conceivably
+          be pre-provisioned on the NAS, then the name of the pre-
+          provisioned policy can be transmitted in an attribute rather
+          than the policy itself, which could be quite large.  An
+          example of this is the Filter-Id Attribute defined in
+          [RFC2865], Section 5.11, which enables a set of pre-
+          provisioned filter rules to be referenced by name.
+
+      3.  Utilization of Packetization Layer Path MTU Discovery
+          techniques, as specified in [RFC4821].
+          As a last resort, where the above techniques cannot be made to
+          work, it may be possible to apply the techniques described in
+          [RFC4821] to discover the maximum supported RADIUS packet size
+          on the path between a RADIUS client and a home server.  While
+          such an approach can avoid the complexity of utilization of a
+          sequence of packets, dynamic discovery is likely to be time
+          consuming and cannot be guaranteed to work with existing
+          RADIUS implementations.  As a result, this technique is not
+          generally applicable.
+
+3.2.  Data Model Issues
+
+   While [RFC2865], Section 5 defines basic data types, later
+   specifications did not follow this practice.  This problem has led
+   implementations to define their own names for data types, resulting
+   in non-standard names for those types.
+
+   In addition, the number of vendors and SDOs creating new attributes
+   within the vendor space has grown, and this has led to some
+   divergence in approaches to RADIUS attribute design.  For example,
+   vendors and SDOs have evolved the data model to support functions
+   such as new data types along with attribute grouping and attribute
+   fragmentation, with different groups taking different approaches.
+   These approaches are often incompatible, leading to additional
+   complexity in RADIUS implementations.
+
+   In order to avoid repeating old mistakes, this section describes the
+   history of the RADIUS data model and attempts to codify existing
+   practices.
+
+
+
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 14]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+3.2.1.  Issues with Definitions of Types
+
+   [RFC2865], Section 5 explicitly defines five data types: text,
+   string, address, integer, and time.  Both the names and
+   interpretations of the types are given.
+
+   Subsequent RADIUS specifications defined attributes by using type
+   names not defined in [RFC2865], without defining the new names as
+   done in [RFC2865].  They did not consistently indicate the format of
+   the value field using the same conventions as [RFC2865].  As a
+   result, the data type is ambiguous in some cases and may not be
+   consistent among different implementations.
+
+   It is out of the scope of this document to resolve all potential
+   ambiguities within existing RADIUS specifications.  However, in order
+   to prevent future ambiguities, it is RECOMMENDED that future RADIUS
+   attribute specifications explicitly define newly created data types
+   at the beginning of the document and indicate clearly the data type
+   to be used for each attribute.
+
+   For example, [RFC3162] utilizes, but does not explicitly define, a
+   type that encapsulates an IPv6 address (Sections 2.1 and 2.4) and
+   another type that encapsulates an IPv6 prefix (Section 2.3).  The
+   IPv6 address attributes confusingly are referenced as type "Address"
+   in the document.  This is a similar name as the "address" type
+   defined in [RFC2865], which was defined to refer solely to IPv4
+   addresses.
+
+   While the Framed-Interface-Id Attribute defined in [RFC3162], Section
+   2.2 included a value field of 8 octets, the data type was not
+   explicitly indicated; therefore, there is controversy over whether
+   the format of the data was intended to be an 8-octet String or
+   whether a special Interface-Id type was intended.
+
+   Given that attributes encapsulating an IPv6 address and an IPv6
+   prefix are already in use, it is RECOMMENDED that RADIUS server
+   implementations include support for these as basic types, in addition
+   to the types defined in [RFC2865].  Where the intent is to represent
+   a specific IPv6 address, an "IPv6 address" type SHOULD be used.
+   Although it is possible to use an "IPv6 Prefix" type with a prefix
+   length of 128 to represent an IPv6 address, this usage is NOT
+   RECOMMENDED.  Implementations supporting the Framed-Interface-Id
+   Attribute may select a data type of their choosing (most likely an
+   8-octet String or a special "Interface Id" data type).
+
+
+
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 15]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   It is worth noting that since RADIUS only supports unsigned integers
+   of 32 bits, attributes using signed integer data types or unsigned
+   integer types of other sizes will require code changes and SHOULD be
+   avoided.
+
+   For [RFC2865] RADIUS VSAs, the length limitation of the String and
+   Text types is 247 octets instead of 253 octets, due to the additional
+   overhead of the Vendor-Specific Attribute.
+
+3.2.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).
+
+   Other limitations of the tagging mechanism are that 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
+   having the additional data types tagged-string and tagged-integer.
+   These types increase the complexity of implementing and managing
+   RADIUS systems.
+
+   For these reasons, the tagging scheme described in RFC 2868 is NOT
+   RECOMMENDED for use as a generic grouping mechanism.
+
+3.2.3.  Complex Data Types
+
+   As described in this section, the creation of complex types can lead
+   to interoperability and deployment issues, so they need to be
+   introduced with care.  For example, 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 ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 16]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   However, some standard attributes pack multiple sub-fields into the
+   "Value" field, resulting in the creation a non-standard, i.e.,
+   complex, type.  Separating these sub-fields into different
+   attributes, each with its own type and length, would have the
+   following benefits:
+
+      * When manual data entry is required, it is easier for an
+        administrator to enter the data as well-known types rather than
+        as complex structures.
+
+      * It enables additional error checking by leveraging the parsing
+        and validation routines for well-known types.
+
+      * It simplifies 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 provide support for basic data types and define attributes
+   in a data dictionary.  This architecture enables a new attribute to
+   be supported by the addition of a dictionary entry, without requiring
+   other RADIUS server code changes.
+
+   Code changes can also be required in policy management systems and in
+   the RADIUS server's receive path.  These changes are due to
+   limitations in RADIUS server policy languages, which commonly provide
+   for limited operations (such as comparisons or arithmetic operations)
+   on the existing data types.  Many existing RADIUS policy languages
+   typically are not capable of parsing sub-elements or providing more
+   sophisticated matching functionality.
+
+   On the RADIUS client, code changes are typically required in order to
+   implement a new attribute.  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.  As a result, a detailed understanding of the
+   new attribute is required on clients, and data dictionaries are less
+   useful on clients than on servers.
+
+   Given these limitations, the introduction of new types can require
+   code changes on the RADIUS server, which would be unnecessary if
+   basic data types had been used instead.  In addition, if "ad hoc"
+   types are used, attribute-specific parsing is required, which means
+   more complex software to develop and maintain.  More complexity can
+   lead to more error-prone implementations, interoperability problems,
+
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 17]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   and even security vulnerabilities.  These issues can increase costs
+   to network administrators as well as reduce reliability and introduce
+   deployment barriers.
+
+3.2.4.  Complex Data Type Exceptions
+
+   As described in Section 2.1, the introduction of complex data types
+   is discouraged where viable alternatives are available.  A potential
+   exception is attributes that inherently require code changes on both
+   the client and server.  For example, as described in Appendix B,
+   complex attributes have been used in situations involving
+   authentication and security attributes, which need to be dynamically
+   computed and verified.  Supporting this functionality 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 to represent these methods is acceptable and does not
+   create additional interoperability or deployment issues.
+
+   Another exception to the recommendation against complex types is for
+   types that can be treated as opaque data by the RADIUS server.  For
+   example, the EAP-Message Attribute, defined in [RFC3579], Section
+   3.1, contains a complex data type that is an Extensible
+   Authentication Protocol (EAP) packet.  Since these complex types do
+   not need to be parsed by the RADIUS server, the issues arising from
+   server limitations do not arise.  Similarly, since attributes of
+   these complex types can be configured on the server using a data type
+   of String, dictionary limitations are also not encountered.  Appendix
+   A.1 includes a series of checklists that may be used to analyze a
+   design for RECOMMENDED and NOT RECOMMENDED behavior in relation to
+   complex types.
+
+   If the RADIUS Server simply passes the contents of an attribute to
+   some non-RADIUS portion of the network, then the data is opaque to
+   RADIUS and SHOULD be defined to be of type String.  A concrete way of
+   judging this requirement is whether or not the attribute definition
+   in the RADIUS document contains delineated fields for sub-parts of
+   the data.  If those fields need to be delineated in RADIUS, then the
+   data is not opaque to RADIUS, and it SHOULD be separated into
+   individual RADIUS attributes.
+
+   An examination of existing RADIUS RFCs discloses a number of complex
+   attributes that have already been defined.  Appendix B includes a
+   listing of complex attributes used within [RFC2865], [RFC2868],
+   [RFC2869], [RFC3162], [RFC4818], and [RFC4675].  The discussion of
+   these attributes includes reasons why a complex type is acceptable or
+   suggestions for how the attribute could have been defined to follow
+   the RADIUS data model.
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 18]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   In other cases, the data in the complex type are described textually
+   in a specification.  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
+   and use these data types today by matching them to the attribute's
+   textual definition.
+
+3.3.  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
+   space in situations where interoperability is not only useful but is
+   required.  For example, 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 encoding and assign
+   Vendor types within their own vendor space, as defined by their
+   unique Vendor-Id.
+
+   The use 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 Vendor-Specific Attributes has become a common
+      occurrence as part of standards activity outside the IETF.  For
+      reasons of efficiency, it is easiest if the RADIUS attributes
+      required to manage a standard are 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 the IETF in order to complete the associated RADIUS
+      attributes specification.
+
+   Attribute scarcity
+      The standard space is limited to 255 unique attributes.  Of these,
+      only about half remain available for allocation.  In the vendor
+      space, the number of attributes available is a function of the
+      encoding of the attribute (the size of the Vendor type field).
+
+
+
+DeKok & Weber             Best Current Practice                [Page 19]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+3.3.1.  Interoperability Considerations
+
+   Vendors and SDOs are reminded that the standard space and the
+   enumerated value space for enumerated attributes are reserved for
+   allocation through work published via the IETF, as noted in
+   [RFC3575], Section 2.1.  In the past, some vendors and SDOs have
+   assigned vendor-specific meaning to "unused" values from the standard
+   space.  This process results in interoperability issues and is
+   counterproductive.  Similarly, the vendor-specific enumeration
+   practice discussed in [RFC2882], Section 2.2.1 is NOT RECOMMENDED.
+
+   If it is not possible to follow the IETF process, vendors and SDOs
+   SHOULD self-allocate an attribute, which MUST be in their own vendor
+   space as defined by their unique Vendor-Id, as discussed in Sections
+   3.3.2 and 3.3.3.
+
+   The design and specification of VSAs for multi-vendor usage SHOULD be
+   undertaken with the same level of care as standard RADIUS attributes.
+   Specifically, the provisions of this document that apply to standard
+   RADIUS attributes also apply to VSAs for multi-vendor usage.
+
+3.3.2.  Vendor Allocations
+
+   As noted in [RFC3575], Section 2.1, vendors are encouraged to utilize
+   VSAs to define functions "specific only to one vendor's
+   implementation of RADIUS, where no interoperability is deemed useful.
+   For functions specific only to one vendor's implementation of RADIUS,
+   the use of that should be encouraged instead of the allocation of
+   global attribute types".
+
+   The recommendation for vendors to allocate attributes from a vendor
+   space rather than via the IETF process is a recognition that vendors
+   desire to assert change control over their own RADIUS specifications.
+   This change control can be obtained by requesting a PEN from the
+   Internet Assigned Number Authority (IANA) for use as a Vendor-Id
+   within a Vendor-Specific Attribute.  The vendor can then allocate
+   attributes within the vendor space defined by that Vendor-Id at their
+   sole discretion.  Similarly, the use of data types (complex or
+   otherwise) within that vendor space is solely under the discretion of
+   the vendor.
+
+3.3.3.  SDO Allocations
+
+   Given the expanded utilization of RADIUS, it has become apparent that
+   requiring SDOs to accomplish all their RADIUS work within the IETF is
+   inherently inefficient and unscalable.  It is therefore RECOMMENDED
+
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 20]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   that SDO RADIUS Attribute specifications allocate attributes from the
+   vendor space rather than request an allocation from the RADIUS
+   standard 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
+
+   Any new RADIUS attributes or values intended for interoperable use
+   across a broad spectrum of the Internet community SHOULD follow the
+   allocation process defined in [RFC3575].
+
+   The recommendation for SDOs to allocate attributes from a vendor
+   space rather than via the IETF process is a recognition that SDOs
+   desire to assert change control over their own RADIUS specifications.
+   This change control can be obtained by requesting a PEN from the
+   Internet Assigned Number Authority (IANA) for use as a Vendor-Id
+   within a Vendor-Specific Attribute.  The SDO can then allocate
+   attributes within the vendor space defined by that Vendor-Id at their
+   sole discretion.  Similarly, the use of data types (complex or
+   otherwise) within that vendor space is solely under the discretion of
+   the SDO.
+
+3.4.  Polymorphic Attributes
+
+   A polymorphic attribute is one whose format or meaning 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 depend on earlier packets in a
+   sequence.
+
+   RADIUS server dictionary entries are typically static, enabling the
+   user to enter the contents of an attribute without support for
+   changing the format based on dynamic conditions.  However, this
+   limitation on static types does not prevent implementations from
+   implementing policies that return 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.  Polymorphism requires code changes in the
+   RADIUS server in situations where attributes with fixed formats would
+   not require such changes.  Thus, polymorphism increases complexity
+   while decreasing generality, without delivering any corresponding
+   benefits.
+
+
+
+DeKok & Weber             Best Current Practice                [Page 21]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   Note that changing an attribute's format dynamically is not the same
+   thing as using a fixed format and computing the attribute itself
+   dynamically.  RADIUS authentication attributes, such as User-
+   Password, EAP-Message, etc., while being computed dynamically, use a
+   fixed format.
+
+4.  IANA Considerations
+
+   This document has no action items for IANA.  However, it does provide
+   guidelines for Expert Reviewers appointed as described in [RFC3575].
+
+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].
+
+   Obfuscation 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 and SHA-1 algorithms have recently become a focus of scrutiny
+   and concern in security circles, and as a result, the use of these
+   algorithms in new attributes is NOT RECOMMENDED.  In addition,
+   previous documents referred to this method as generating "encrypted"
+   data.  This terminology is no longer accepted within the
+   cryptographic community.
+
+   Where new RADIUS attributes use 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
+   [FIPS].
+
+   Where new RADIUS attributes encapsulate complex data types, or
+   transport opaque data, the security considerations discussed in
+   Section 5.1 SHOULD be addressed.
+
+   Message authentication in RADIUS is provided largely via the Message-
+   Authenticator attribute.  See Section 3.2 of [RFC3579] and also
+   Section 2.2.2 of [RFC5080], which say that client implementations
+   SHOULD include a Message-Authenticator Attribute in every Access-
+   Request.
+
+
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 22]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   In general, the security of the RADIUS protocol is poor.  Robust
+   deployments SHOULD support a secure communications protocol such as
+   IPsec.  See Section 4 of [RFC3579] and Section 5 of [RFC3580] for a
+   more in-depth explanation of these issues.
+
+   Implementations not following the suggestions outlined in this
+   document may be subject to problems such as ambiguous protocol
+   decoding, packet loss leading to loss of billing information, and
+   denial-of-service attacks.
+
+5.1.  New Data Types and Complex Attributes
+
+   The introduction of complex data types brings the potential for the
+   introduction of new security vulnerabilities.  Experience shows that
+   the common data types have few security vulnerabilities, or else that
+   all known issues have been found and fixed.  New data types require
+   new code, which may introduce new bugs and therefore new attack
+   vectors.
+
+   Some systems permit complex attributes to be defined via a method
+   that is more capable than traditional RADIUS dictionaries.  These
+   systems can reduce the security threat of new types significantly,
+   but they do not remove it entirely.
+
+   RADIUS servers are highly valued targets, as they control network
+   access and interact with databases that store usernames and
+   passwords.  An extreme outcome of a vulnerability due to a new,
+   complex type would be that an attacker is capable of taking complete
+   control over the RADIUS server.
+
+   The use of attributes representing opaque data does not reduce this
+   threat.  The threat merely moves from the RADIUS server to the system
+   that consumes that opaque data.  The threat is particularly severe
+   when the opaque data originates from the user and is not validated by
+   the NAS.  In those cases, the RADIUS server is potentially exposed to
+   attack by malware residing on an unauthenticated host.
+
+   Any system consuming opaque data that originates from a RADIUS system
+   SHOULD be properly isolated from that RADIUS system and SHOULD run
+   with minimal privileges.  Any potential vulnerabilities in the non-
+   RADIUS system will then have minimal impact on the security of the
+   system as a whole.
+
+
+
+
+
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 23]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+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.
+
+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)", RFC 1157,
+                 May 1990.
+
+   [RFC1321]     Rivest, R., "The MD5 Message-Digest Algorithm", RFC
+                 1321, April 1992.
+
+   [RFC2548]     Zorn, G., "Microsoft Vendor-specific RADIUS
+                 Attributes", RFC 2548, March 1999.
+
+   [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.
+
+   [RFC2882]     Mitton, D., "Network Access Servers Requirements:
+                 Extended RADIUS Practices", RFC 2882, July 2000.
+
+   [RFC3162]     Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
+                 RFC 3162, August 2001.
+
+
+
+DeKok & Weber             Best Current Practice                [Page 24]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   [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., and J.
+                 Roese, "IEEE 802.1X Remote Authentication Dial In User
+                 Service (RADIUS) Usage Guidelines", RFC 3580, September
+                 2003.
+
+   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
+                 10646", STD 63, RFC 3629, November 2003.
+
+   [RFC4181]     Heard, C., Ed., "Guidelines for Authors and Reviewers
+                 of MIB Documents", BCP 111, RFC 4181, September 2005.
+
+   [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.
+
+   [RFC4679]     Mammoliti, V., Zorn, G., Arberg, P., and R. Rennison,
+                 "DSL Forum Vendor-Specific RADIUS Attributes", RFC
+                 4679, September 2006.
+
+   [RFC4818]     Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
+                 Attribute", RFC 4818, April 2007.
+
+   [RFC4821]     Mathis, M. and J. Heffner, "Packetization Layer Path
+                 MTU Discovery", RFC 4821, March 2007.
+
+   [RFC4849]     Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter
+                 Rule Attribute", RFC 4849, April 2007.
+
+   [RFC5080]     Nelson, D. and A. DeKok, "Common Remote Authentication
+                 Dial In User Service (RADIUS) Implementation Issues and
+                 Suggested Fixes", RFC 5080, December 2007.
+
+   [RFC5090]     Sterman, B., Sadolevsky, D., Schwartz, D., Williams,
+                 D., and W. Beck, "RADIUS Extension for Digest
+                 Authentication", RFC 5090, February 2008.
+
+   [RFC5176]     Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
+                 Aboba, "Dynamic Authorization Extensions to Remote
+                 Authentication Dial In User Service (RADIUS)", RFC
+                 5176, January 2008.
+
+
+
+DeKok & Weber             Best Current Practice                [Page 25]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   [DOCTORS]     AAA Doctors Mailing List, www.ietf.org/mail-
+                 archive/web/aaa-doctors.
+
+   [FIPS]        FIPS 140-3 (DRAFT), "Security Requirements for
+                 Cryptographic Modules",
+                 http://csrc.nist.gov/publications/PubsFIPS.html.
+
+   [IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area
+                 Networks: Draft Standard for Virtual Bridged Local Area
+                 Networks, P802.1Q-2003, January 2003.
+
+   [RFC5580]     Tschofenig, H., Ed., Adrangi, F., Jones, M., Lior, A.,
+                 and B. Aboba, "Carrying Location Objects in RADIUS and
+                 Diameter", RFC 5580, August 2009.
+
+   [AAA-SIP]     Sterman, B., Sadolevsky, D., Schwartz, D., Williams,
+                 D., and W. Beck, "RADIUS Extension for Digest
+                 Authentication", Work in Progress, November 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 26]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+Appendix A.  Design Guidelines Checklist
+
+   The following text provides guidelines for the design of attributes
+   used by the RADIUS protocol.  Specifications that follow these
+   guidelines are expected to achieve maximum interoperability with
+   minimal changes to existing systems.
+
+A.1. Types Matching the RADIUS Data Model
+
+A.1.1. Transport of Basic Data Types
+
+   Does the data fit within the basic data types described in Section
+   2.1?  If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS
+   attribute or in a [RFC2865] format RADIUS VSA that uses one of the
+   existing RADIUS data types.
+
+A.1.2. Transport of Authentication and Security Data
+
+   Does the data provide authentication and/or security capabilities for
+   the RADIUS protocol as outlined below?  If so, use of a complex data
+   type is acceptable under the following circumstances:
+
+      * Complex data types that carry authentication methods that RADIUS
+        servers are expected to parse and verify as part of an
+        authentication process.
+
+      * Complex data types that carry security information intended to
+        increase the security of the RADIUS protocol itself.
+
+   Any data type carrying authentication and/or security data that is
+   not meant to be parsed by a RADIUS server is an "opaque data type",
+   as defined in Section A.1.3.
+
+A.1.3. Opaque Data Types
+
+   Does the attribute encapsulate an existing data structure defined
+   outside of the RADIUS specifications?  Can the attribute be treated
+   as opaque data by RADIUS servers (including proxies)?  If both
+   questions can be answered affirmatively, a complex structure MAY be
+   used in a RADIUS specification.
+
+   The specification of the attribute SHOULD define the encapsulating
+   attribute to be of type String.  The specification SHOULD refer to an
+   external document defining the structure.  The specification SHOULD
+   NOT define or describe the structure, for reasons discussed in
+   Section 3.2.3.
+
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 27]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+A.1.4. Pre-Existing Data Types
+
+   There is a trade-off in design between reusing existing formats for
+   historical compatibility or choosing new formats for a "better"
+   design.  This trade-off does not always require the "better" design
+   to be used.  As a result, pre-existing complex data types described
+   in Appendix B MAY be used.
+
+A.2. Improper Data Types
+
+   This section suggests alternatives to data types that do not fall
+   within the "basic data type" definition.  Section A.2.1 describes
+   simple data types, which should be replaced by basic data types.
+   Section A.2.2 describes more complex data types, which should be
+   replaced by multiple attributes using the basic data types.
+
+A.2.1. Simple Data Types
+
+   Does the attribute use any of the following data types?  If so, the
+   data type SHOULD be replaced with the suggested alternatives, or it
+   SHOULD NOT be used at all.
+
+      * Signed integers of any size.
+        SHOULD NOT be used.  SHOULD be replaced with one or more
+        unsigned integer attributes.  The definition of the attribute
+        can contain information that would otherwise go into the sign
+        value of the integer.
+
+      * 8-bit unsigned integers.
+        SHOULD be replaced with 32-bit unsigned integer.  There is
+        insufficient justification to save three bytes.
+
+      * 16-bit unsigned integers.
+        SHOULD be replaced with 32-bit unsigned integer.  There is
+        insufficient justification to save two bytes.
+
+      * Unsigned integers of size other than 32 bits.
+        SHOULD be replaced by an unsigned integer of 32 bits.  There is
+        insufficient justification to define a new size of integer.
+
+      * Integers of any size in non-network byte order.
+        SHOULD be replaced by unsigned integer of 32 bits in network.
+        There is no reason to transport integers in any format other
+        than network byte order.
+
+      * Multi-field text strings.
+        Each field SHOULD be encapsulated in a separate attribute.
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 28]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+      * Polymorphic attributes.
+        Multiple attributes, each with a static data type, SHOULD be
+        defined instead.
+
+      * Nested attribute-value pairs (AVPs).
+        Attributes should be defined in a flat typespace.
+
+A.2.2. More Complex Data Types
+
+   Does the attribute:
+
+      * define a complex data type not described in Appendix B?
+
+      * that a RADIUS server and/or client is expected to parse,
+        validate, or create the contents of via a dynamic computation
+        (i.e., a type that cannot be treated as opaque data (Section
+        A.1.3))?
+
+      * involve functionality that could be implemented without code
+        changes on both the client and server (i.e., a type that doesn't
+        require dynamic computation and verification, such as those
+        performed for authentication or security attributes)?
+
+   If so, this data type SHOULD be replaced with simpler types, as
+   discussed in Appendix A.2.1.  See also Section 2.1 for a discussion
+   of why complex types are problematic.
+
+A.3. Vendor-Specific Formats
+
+   Does the specification contain Vendor-Specific Attributes that match
+   any of the following criteria?  If so, the VSA encoding should be
+   replaced with the [RFC2865], Section 5.26 encoding or should not be
+   used at all.
+
+      * Vendor types of more than 8 bits.
+        SHOULD NOT be used.  Vendor types of 8 bits SHOULD be used
+        instead.
+
+      * Vendor lengths of less than 8 bits (i.e., zero bits).
+        SHOULD NOT be used.  Vendor lengths of 8 bits SHOULD be used
+        instead.
+
+      * Vendor lengths of more than 8 bits.
+        SHOULD NOT be used.  Vendor lengths of 8 bits SHOULD be used
+        instead.
+
+
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 29]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+      * Vendor-specific contents that are not in Type-Length-Value
+        format.
+        SHOULD NOT be used.  Vendor-Specific Attributes SHOULD be in
+        Type-Length-Value format.
+
+   In general, Vendor-Specific Attributes SHOULD follow the encoding
+   suggested in Section 5.26 of [RFC2865].  Vendor extensions to non-
+   standard encodings are NOT RECOMMENDED as they can negatively affect
+   interoperability.
+
+A.4. Changes to the RADIUS Operational Model
+
+   Does the specification change the RADIUS operation model as outlined
+   in the list below?  If so, then another method of achieving the
+   design objectives SHOULD be used.  Potential problem areas include
+   the following:
+
+      * Defining new commands in RADIUS using attributes.
+        The addition of new commands to RADIUS MUST be handled via
+        allocation of a new Code and not by the use of an attribute.
+        This restriction includes new commands created by overloading
+        the Service-Type Attribute to define new values that modify the
+        functionality of Access-Request packets.
+
+      * Using RADIUS as a transport protocol for data unrelated to
+        authentication, authorization, or accounting.
+        Using RADIUS to transport authentication methods such as EAP is
+        explicitly permitted, even if those methods require the
+        transport of relatively large amounts of data.  Transport of
+        opaque data relating to AAA is also permitted, as discussed in
+        Section 3.2.3. However, if the specification does not relate to
+        AAA, then RADIUS SHOULD NOT be used.
+
+      * Assuming support for packet lengths greater than 4096 octets.
+        Attribute designers cannot assume that RADIUS implementations
+        can successfully handle packets larger than 4096 octets.  If a
+        specification could lead to a RADIUS packet larger than 4096
+        octets, then the alternatives described in Section 3.3 SHOULD be
+        considered.
+
+      * Stateless operation.
+        The RADIUS protocol is stateless, and documents that require
+        stateful protocol behavior without the use of the State
+        Attribute need to be redesigned.
+
+
+
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 30]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+      * Provisioning of service in an Access-Reject.
+        Such provisioning is not permitted, and MUST NOT be used.  If
+        limited access needs to be provided, then an Access-Accept with
+        appropriate authorizations can be used instead.
+
+      * Provisioning of service in a Disconnect-Request.
+        Such provisioning is not permitted and MUST NOT be used.  If
+        limited access needs to be provided, then a CoA-Request
+        [RFC5176] with appropriate authorizations can be used instead.
+
+      * Lack of user authentication or authorization restrictions.
+        In an authorization check, where there is no demonstration of a
+        live user, confidential data cannot be returned.  Where there is
+        a link to a previous user authentication, the State Attribute
+        SHOULD be present.
+
+      * Lack of per-packet integrity and authentication.
+        It is expected that documents will support per-packet integrity
+        and authentication.
+
+      * Modification of RADIUS packet sequences.
+        In RADIUS, each request is encapsulated in its own packet and
+        elicits a single response that is sent to the requester.  Since
+        changes to this paradigm are likely to require major
+        modifications to RADIUS client and server implementations, they
+        SHOULD be avoided if possible.
+
+   For further details, see Section 3.1.
+
+A.5. Allocation of Attributes
+
+   Does the attribute have a limited scope of applicability as outlined
+   below?  If so, then the attributes SHOULD be allocated from the
+   vendor space rather than requesting allocation from the standard
+   space.
+
+      * attributes intended for a vendor to support their own systems
+        and not suitable for general usage
+
+      * 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
+
+   Note that the points listed above do not relax the recommendations
+   discussed in this document.  Instead, they recognize that the RADIUS
+   data model has limitations.  In certain situations where
+
+
+
+DeKok & Weber             Best Current Practice                [Page 31]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   interoperability can be strongly constrained by the SDO or vendor, an
+   expanded data model MAY be used.  It is RECOMMENDED, however, that
+   the RADIUS data model be used, even when it is marginally less
+   efficient than alternatives.
+
+   When attributes are used primarily within a group of SDOs, and are
+   not applicable to the wider Internet community, we expect that one
+   SDO will be responsible for allocation from their own private vendor
+   space.
+
+Appendix B.  Complex Attributes
+
+   This appendix summarizes RADIUS attributes with complex data types
+   that are defined in existing RFCs.
+
+   This appendix is published for informational purposes only and
+   reflects the usage of attributes with complex data types at the time
+   of the publication of this document.
+
+B.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 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 are required
+   on the RADIUS client and server to support it, regardless of the
+   attribute format.  Therefore, this complex data type is acceptable in
+   this situation.
+
+B.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.
+
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 32]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   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.
+
+B.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 that consists of three logical sub-fields: the Data-Length
+   (required and one octet), Password sub-fields (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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |     Tag       |   Salt
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      Salt (cont)  |   String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Since this is a security attribute, code changes are required on the
+   RADIUS client and server to support it, regardless of the attribute
+   format.  However, while use of a complex data type is acceptable in
+   this situation, the design of the Tunnel-Password Attribute is
+   problematic from a security perspective since it uses MD5 as a cipher
+   and provides a password to a NAS, potentially without proper
+   authorization.
+
+B.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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 33]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   As with the CHAP-Password Attribute, this is an authentication
+   attribute that would have required code changes on the RADIUS client
+   and server, regardless of format.
+
+B.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 Apple Remote Access
+   Protocol (ARAP):
+
+   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                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           Value5                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Unlike the 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.
+
+   While the contents of this attribute are intended to be placed in an
+   ARAP packet, the fields need to be set by the RADIUS server.  Using
+   standard RADIUS data types would have simplified RADIUS server
+   implementations and subsequent management.  The current form of the
+   attribute requires either the RADIUS server implementation or the
+   RADIUS server administrator to understand the internals of the ARAP
+   protocol.
+
+B.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...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 34]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   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 and is not directly
+   involved in authentication.  The individual sub-fields could
+   therefore have been encapsulated in separate attributes.
+
+   However, since the definition refers to potential standardization
+   activity within ITU, the Connect-Info Attribute can also be thought
+   of as opaque data whose definition is provided elsewhere.  The
+   Connect-Info Attribute could therefore qualify for an exception as
+   described in Section 3.2.4.
+
+B.7. Framed-IPv6-Prefix
+
+   Section 2.3 of [RFC3162] defines the Framed-IPv6-Prefix Attribute,
+   and Section 3 of [RFC4818] reuses this format for the Delegated-
+   IPv6-Prefix Attribute; these attributes are sent from the RADIUS
+   server to the client in an Access-Accept.
+
+    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                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 35]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+   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.
+
+B.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
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 36]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+B.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.
+
+B.10. Digest-*
+
+   [RFC5090] attempts to standardize the functionality provided by an
+   expired Internet-Draft [AAA-SIP], which improperly uses two
+   attributes from the standard space without having been assigned them
+   by IANA.  This self-allocation is forbidden, as described in Section
+   2.  In addition, the document uses nested attributes, which are
+   discouraged in Section 2.1.  The updated document uses basic data
+   types and allocates nearly 20 attributes in the process.
+
+   However, the document has seen wide-spread implementation, but
+   [RFC5090] has not.  One explanation may be that implementors
+   disagreed with the trade-offs made in the updated specification.  It
+   may have been better to simply document the existing format and
+   request IANA allocation of two attributes.  The resulting design
+   would have used nested attributes but may have gained more wide-
+   spread implementation.
+
+Acknowledgments
+
+   We would like to acknowledge David Nelson, Bernard Aboba, Emile van
+   Bergen, Barney Wolff, Glen Zorn, Avi Lior, and Hannes Tschofenig for
+   contributions to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 37]
+
+RFC 6158                RADIUS Design Guidelines              March 2011
+
+
+Authors' Addresses
+
+   Alan DeKok (editor)
+   The FreeRADIUS Server Project
+   http://freeradius.org/
+
+   EMail: aland@freeradius.org
+
+
+   Greg Weber
+   Knoxville, TN 37932
+   USA
+
+   EMail: gdweber@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok & Weber             Best Current Practice                [Page 38]
+