--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
projects / freeradius.git / commitdiff