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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/