From: Alan T. DeKok Date: Sat, 19 Mar 2011 15:16:12 +0000 (+0100) Subject: How RADIUS should be done. X-Git-Tag: release_3_0_0_beta0~973 X-Git-Url: http://www.project-moonshot.org/gitweb/?a=commitdiff_plain;h=c86f16b8cdf2dd90825c9282d196e1fafee46309;p=freeradius.git How RADIUS should be done. --- 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] +