draft-ietf-radext-design-13.txt   draft-ietf-radext-design-14.txt 
Network Working Group Alan DeKok (ed.) Network Working Group Alan DeKok (ed.)
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Category: Best Current Practice G. Weber Category: Best Current Practice G. Weber
<draft-ietf-radext-design-13.txt> Individual Contributor <draft-ietf-radext-design-14.txt> Individual Contributor
Expires: October 14, 2010 Expires: January 7, 2011
14 April 2010 7 June 2010
RADIUS Design Guidelines RADIUS Design Guidelines
draft-ietf-radext-design-13 draft-ietf-radext-design-14
Abstract
This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 14, 2010. This Internet-Draft will expire on January 7, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 2, line 17 skipping to change at page 3, line 5
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
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.
Abstract
This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).
Table of Contents Table of Contents
1. Introduction ............................................. 5 1. Introduction ............................................. 5
1.1. Terminology ......................................... 5 1.1. Terminology ......................................... 5
1.2. Requirements Language ............................... 5 1.2. Requirements Language ............................... 6
1.3. Applicability ....................................... 6 1.3. Applicability ....................................... 6
1.3.1. Impact on SDOs ................................. 7
2. Guidelines ............................................... 7 2. Guidelines ............................................... 7
2.1. Data Types .......................................... 8 2.1. Data Types .......................................... 8
2.2. Vendor-Specific Attribute Space ..................... 9 2.2. Vendor-Specific Attribute Space ..................... 9
2.3. Service definitions and RADIUS ...................... 10 2.3. Service definitions and RADIUS ...................... 10
2.4. Translation of Vendor Specifications ................ 11 2.4. Translation of Vendor Specifications ................ 11
3. Rationale ................................................ 11 3. Rationale ................................................ 11
3.1. RADIUS Operational Model ............................ 11 3.1. RADIUS Operational Model ............................ 11
3.2. Data Model Issues ................................... 14 3.2. Data Model Issues ................................... 14
3.2.1. Basic Data Types ............................... 15 3.2.1. Basic Data Types ............................... 15
3.2.2. Tagging Mechanism .............................. 16 3.2.2. Tagging Mechanism .............................. 16
3.2.3. Complex Data Types ............................. 17 3.2.3. Complex Data Types ............................. 17
3.3. Vendor Space ........................................ 20 3.3. Vendor Space ........................................ 20
3.3.1. Interoperability Considerations ................ 21 3.3.1. Interoperability Considerations ................ 21
3.3.2. Vendor Allocations ............................. 21 3.3.2. Vendor Allocations ............................. 21
3.3.3. SDO Allocations ................................ 22 3.3.3. SDO Allocations ................................ 22
3.3.4. Publication of specifications .................. 22 3.3.4. Publication of specifications .................. 22
3.4. Polymorphic Attributes .............................. 24 3.4. Polymorphic Attributes .............................. 23
4. IANA Considerations ...................................... 24 4. IANA Considerations ...................................... 24
5. Security Considerations .................................. 25 5. Security Considerations .................................. 24
5.1. New Data Types and Complex Attributes ............... 26 5.1. New Data Types and Complex Attributes ............... 25
6. References ............................................... 26 6. References ............................................... 26
6.1. Normative References ................................ 26 6.1. Normative References ................................ 26
6.2. Informative References .............................. 27 6.2. Informative References .............................. 26
Appendix A - Design Guidelines ............................... 29 Appendix A - Design Guidelines ............................... 29
A.1. Types matching the RADIUS data model ................. 29 A.1. Types matching the RADIUS data model ................. 29
A.1.1. Transport of basic data types ................... 29 A.1.1. Transport of basic data types ................... 29
A.1.2. Transport of Authentication and Security Data ... 30 A.1.2. Transport of Authentication and Security Data ... 30
A.1.3. Opaque data types ............................... 30 A.1.3. Opaque data types ............................... 30
A.2. Improper Data Types .................................. 30 A.1.4. Pre-existing data types ......................... 30
A.2. Improper Data Types .................................. 31
A.2.1. Basic Data Types ................................ 31 A.2.1. Basic Data Types ................................ 31
A.2.2. Complex Data Types .............................. 31 A.2.2. Complex Data Types .............................. 32
A.3. Vendor-Specific formats .............................. 32 A.3. Vendor-Specific formats .............................. 32
A.4. Changes to the RADIUS Operational Model .............. 32 A.4. Changes to the RADIUS Operational Model .............. 33
A.5. Allocation of attributes ............................. 34 A.5. Allocation of attributes ............................. 34
Appendix B - Complex Attributes .............................. 35 Appendix B - Complex Attributes .............................. 35
B.1. CHAP-Password ........................................ 35 B.1. CHAP-Password ........................................ 35
B.2. CHAP-Challenge ....................................... 35 B.2. CHAP-Challenge ....................................... 35
B.3. Tunnel-Password ...................................... 35 B.3. Tunnel-Password ...................................... 35
B.4. ARAP-Password ........................................ 36 B.4. ARAP-Password ........................................ 36
B.5. ARAP-Features ........................................ 36 B.5. ARAP-Features ........................................ 36
B.6. Connect-Info ......................................... 37 B.6. Connect-Info ......................................... 37
B.7. Framed-IPv6-Prefix ................................... 38 B.7. Framed-IPv6-Prefix ................................... 38
B.8. Egress-VLANID ........................................ 38 B.8. Egress-VLANID ........................................ 38
skipping to change at page 5, line 44 skipping to change at page 5, line 44
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/or 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
The 256 possible attributes that follow the format defined in
[RFC2865] Section 5.
vendor space
The contents of the "String" field of a Vendor-Specific Attribute
(VSA) ([RFC2865] Section 5.26).
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].
The uses of "MUST" and "MUST NOT" in this document are limited to (a) We emphasize that the uses of "MUST" and "MUST NOT" in this document
requirements to follow the IETF process for IETF standards, and (b) are limited to requirements to follow the IETF process for IETF
quotes from other documents. As a result, the uses of "MUST" and standards, and quotes from other documents. As a result, the uses of
"MUST NOT" in this document do not prescribe new mandatory behavior "MUST" and "MUST NOT" in this document do not prescribe new mandatory
within implementations. behavior within implementations.
1.3. Applicability 1.3. Applicability
The reviews and advice in this document applies to attributes used to The reviews and advice in this document applies to attributes used to
encode service-provisioning, authentication, or accounting data, encode service-provisioning, authentication, or accounting data,
based on the attribute formats and data encodings defined in RFC 2865 based on the attribute encodings and data formats defined in RFC 2865
and subsequent RADIUS RFCs. It is RECOMMENDED that these guidelines and subsequent RADIUS RFCs. It is RECOMMENDED that these guidelines
be applied to reviews of documents that request allocations within be followed for all new RADIUS specifications, whether they originate
the IETF standard attribute space defined in [RFC2865]. Doing so from a vendor, an SDO, or the IETF. Doing so will ensure the widest
will ensure the widest possible applicability and interoperability of possible applicability and interoperability of the specifications,
the specifications, while requiring minimal changes to existing while requiring minimal changes to existing systems.
systems.
These guidelines may also prove useful in the design of attributes When new attributes are defined, they can be classified into one of
within the Vendor-Specific Attribute (VSA) space. As noted in RFC three broad categories:
2865 Section 5.26, RADIUS VSAs were created "to allow vendors to
support their own extended Attributes not suitable for general
usage." Rather than requesting allocation of standard attributes for
those uses, [RFC2865] Section 6.2 notes that utilization of VSAs
"should be encouraged instead of allocation of global attribute
types, for functions specific only to one vendor's implementation of
RADIUS, where no interoperability is deemed useful."
However, experience has shown that attributes not originally designed * Attributes that are of interest to a single vendor, e.g., for a
for general usage can subsequently garner wide-spread deployment. An product or product line. Minimal cross-vendor interoperability
example is the vendor-specific attributes defined in [RFC2548], which is needed.
have been widely implemented within IEEE 802.11 Access Points.
While SDOs and vendors MAY choose to create specifications not Vendor-Specific Attributes (VSAs) MUST be used. Code-point
following these guidelines, this should be done only when those allocation is managed by the vendor with the number space
specifications are intended for use in scenarios within a limited defined by their Private Enterprise Number (PEN).
scope of applicability. Where general usage is possible, adhering to
these guidelines is RECOMMENDED.
Guidelines are provided for vendor allocations in Section 3.3.2; and * Attributes that are of interest to an industry segment, where an
for SDO allocations in Section 3.3.3. SDOs and vendors desiring SDO defines the attributes for that industry. Multi-vendor
review of their specifications by the IETF are encouraged to follow interoperability within an industry segment is expected.
the advice presented in Section 3.3.4.
RADIUS protocol changes, or specification of attributes (such as Vendor-Specific Attributes (VSAs) MUST be used. Code-point
Service-Type) that can, in effect, provide new RADIUS commands allocation is managed by the SDO with the number space defined
require greater expertise and deeper review, as do changes to the by the SDOs PEN, rather then the PEN of an individual vendor.
RADIUS operational model. As a result, such changes are outside the
scope of this document and MUST NOT be undertaken outside the IETF.
1.3.1. Impact on SDOs * Attributes that are of broad interest to the Internet Community.
Global Internet multi-vendor interoperability is expected.
As RADIUS has become more widely accepted as a management protocol, Standard (i.e. non-VSA) Attributes SHOULD be used. All code-
its usage has become more prevalent, both within the IETF as well as point allocation for Standard Attributes MUST be done via IANA,
within other SDOs. Given the expanded utilization of RADIUS, it has and MUST follow "IETF consensus", as discussed in [RFC3575].
become apparent that requiring SDOs to accomplish all their RADIUS
work within the IETF is inherently inefficient and unscalable. By
articulating guidelines for RADIUS attribute design, this document
enables SDOs out of the IETF to design their own RADIUS attributes
within the Vendor-Specific Attribute (VSA) space.
It is RECOMMENDED that SDOs follow the guidelines articulated in this Strict conformance with the design guidelines is expected,
document. However, we recognize that there are some situations where unless a good case can be made for an exception. Those tasked
SDOs or vendors require the creation of specifications not following with reviewing the proposals SHOULD use the design guidelines as
these guidelines. We do not forbid these specifications, but it is a review checklist.
RECOMMENDED that they are created only if they have a limited scope
of applicability, and all new attributes defined in those
specifications are VSAs. See Section 3, below, for additional
discussion of this topic.
It is RECOMMENDED that SDOs and vendors seek review of RADIUS IETF review is RECOMMENDED for all RADIUS specifications, as
attribute specifications from the IETF. However, specifications do experience has shown that attributes not originally designed for
not require IETF review when they satisfy all of the following general usage can subsequently garner wide-spread deployment. An
criteria: example is the vendor-specific attributes defined in [RFC2548], which
have been widely implemented within IEEE 802.11 Access Points. See
Section 3.3.4 for instructions on the review process.
* are SDO specific; IETF review of a specification MAY be avoided when it satisfies all
of the following criteria:
* reference attributes from pre-existing IETF or SDO * it is not intended for publication as an IETF RFC;
* it references pre-existing attributes from IETF or SDO
specifications; specifications;
* define new attributes only in the VSA space; * it defines new attributes only in the VSA space;
* use only the "basic data types" (see below) for all VSAs; * it uses only the "basic data types" (see Section 2.1) for all
VSAs;
* follow the guidelines given in this document. * it follows the guidelines given in this document.
We recognize that SDOs and vendors may still choose to create
specifications not following these guidelines. We do not forbid that
practice, though it is NOT RECOMMENDED.
RADIUS protocol changes, or specification of attributes (such as
Service-Type) that can, in effect, provide new RADIUS commands
require greater expertise and deeper review, as do changes to the
RADIUS operational model. As a result, such changes are outside the
scope of this document and MUST NOT be undertaken outside the IETF.
2. Guidelines 2. Guidelines
The Remote Authentication Dial In User Service (RADIUS) defined in The Remote Authentication Dial In User Service (RADIUS) defined in
[RFC2865] and [RFC2866] uses elements known as attributes in order to [RFC2865] and [RFC2866] uses elements known as attributes in order to
represent authentication, authorization and accounting data. represent authentication, authorization and accounting data.
Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does
not define a formal data definition language. The data type of not define a formal data definition language. The data type of
RADIUS attributes is not transported on the wire. Rather, the data RADIUS attributes is not transported on the wire. Rather, the data
type of a RADIUS attribute is fixed when an attribute is defined. type of a RADIUS attribute is fixed when an attribute is defined.
Based on the RADIUS attribute type code, RADIUS clients and servers Based on the RADIUS attribute type code, RADIUS clients and servers
can determine the data type based on preconfigured entries within a can determine the data type based on preconfigured entries within a
data dictionary. 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 types of data types, namely "basic" and "complex". distinguish two types 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
below, encapsulated in a [RFC2865] format RADIUS attribute, or in a below, encapsulated in a [RFC2865] RADIUS attribute, or in a
[RFC2865] format RADIUS VSA. All other data formats are "complex [RFC2865] RADIUS VSA. All other data formats are "complex types".
types".
RADIUS attributes are also divided into two distinct attribute RADIUS attributes are also divided into two distinct attribute
spaces: the "standard space", and a "Vendor-Specific Attribute spaces: the "standard space", and a "Vendor-Specific Attribute
space". Attributes in the "standard space" follow the [RFC2865] space". Attributes in the "standard space" follow the [RFC2865]
attribute format, with allocation managed by the Internet Assigned attribute encoding, with allocation managed by the Internet Assigned
Number Authority (IANA). Vendors MUST NOT "self-allocate" attributes Number Authority (IANA). Vendors MUST NOT "self-allocate" attributes
in this space, as they are not authoritative for it. in this space, as they are not authoritative for it.
The VSA space is defined to be the contents of the "String" field of The VSA space is defined to be the contents of the "String" field of
the Vendor-Specific Attribute ([RFC2865] Section 5.26). Allocation the Vendor-Specific Attribute ([RFC2865] Section 5.26). Allocation
in this space is managed independently by each vendor. See Section in this space is managed independently by each vendor. See Section
2.2, below, for a more in-depth discussion. 2.2, below, for a more in-depth discussion.
2.1. Data Types 2.1. Data Types
skipping to change at page 8, line 49 skipping to change at page 8, line 49
* 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), totalling 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. below, for additional discussion.
* UTF-8 text, totalling 253 octets or less in length. * UTF-8 text, totalling 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 format. 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] tagging mechanism. This approach is NOT RECOMMENDED, [RFC2868] tagging mechanism. This approach is NOT RECOMMENDED,
but is permissible where the alternatives are worse. but is permissible where the alternatives are worse.
* Attributes requiring the transport of more than 247 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 data structures defined outside of RADIUS. of data structures defined outside of RADIUS.
(e.g. EAP-Message) (e.g. EAP-Message)
All other data formats are defined to be "complex data types", and All other data formats are defined to be "complex data types", and
are NOT RECOMMENDED for normal use. Nested attributes, or attributes are NOT RECOMMENDED for normal use. Nested attributes, or attributes
grouped via methods other than defined in [RFC2868] do not qualify as grouped via methods other than defined in [RFC2868] do not qualify as
"basic data types", and SHOULD NOT be used. "basic data types", and SHOULD NOT be used.
There may be situations where complex attributes are acceptable There may be situations where complex attributes are acceptable
skipping to change at page 9, line 39 skipping to change at page 9, line 39
best be located. Each situation has to be decided on a case-by-case best be located. Each situation has to be decided on a case-by-case
basis. The cost-benefit trade-off may result in a "complex data basis. The cost-benefit trade-off may result in a "complex data
type" being defined in RADIUS, as discussed in Appendix B. When this type" being defined in RADIUS, as discussed in Appendix B. When this
is done, an explanation SHOULD be offered as to why the complex data is done, an explanation SHOULD be offered as to why the complex data
type was used. type was used.
2.2. Vendor-Specific Attribute Space 2.2. Vendor-Specific Attribute Space
The Vendor-Specific Attribute space is defined to be the contents of The Vendor-Specific Attribute space is defined to be the contents of
the "String" field of the Vendor-Specific Attribute ([RFC2865] the "String" field of the Vendor-Specific Attribute ([RFC2865]
Section 5.26). As discussed there, it is intended for vendors to Section 5.26). As discussed there, it is intended for vendors and
support their own Attributes not suitable for general use. It is SDOs to support their own Attributes not suitable for general use.
RECOMMENDED that vendors follow the guidelines outlined here, which It is RECOMMENDED that vendors and SDOs follow the guidelines
are intended to enable maximum interoperability with minimal changes outlined here, which are intended to enable maximum interoperability
to existing systems. with minimal changes to existing systems.
Following these guidelines means that RADIUS servers can be updated Following these guidelines means that RADIUS servers can be updated
to support the vendor's equipment by editing a RADIUS dictionary. If to support a new attribute by editing a RADIUS dictionary. If these
these guidelines are not followed, then the vendor's equipment can guidelines are not followed, then the new attribute can only be
only be supported via code changes in RADIUS server implementations. supported via code changes in RADIUS server implementations. Such
Such code changes add complexity and delay to implementations. code changes add complexity and delays to implementations.
Vendor RADIUS Attribute specifications SHOULD allocate attributes Vendor RADIUS Attribute specifications SHOULD self-allocate
from the vendor space, rather than requesting an allocation from the attributes from the vendor space, rather than asking the IETF and
RADIUS standard attribute space. IANA for an allocation from the RADIUS standard attribute space.
All VSA schemes that do not follow the [RFC2865] recommendations are All data formats other than described above as "basic data types" are
NOT RECOMMENDED. All data formats other than described above as NOT RECOMMENDED. These non-standard formats will typically not be
"basic data types" are NOT RECOMMENDED. These non-standard formats implementable without RADIUS server code changes.
will typically not be implementable without RADIUS server code
changes.
Although [RFC2865] does not mandate it, implementations commonly All VSA encodings that do not follow the [RFC2865] Section 5.26
assume that the Vendor Id can be used as a key to determine the on- scheme are NOT RECOMMENDED. Although [RFC2865] does not mandate it,
the-wire format of a VSA. Vendors therefore SHOULD NOT use multiple implementations commonly assume that the Vendor Id can be used as a
formats for VSAs that are associated with a particular Vendor Id. A key to determine the on-the-wire encoding of a VSA. Vendors
vendor wishing to use multiple VSA formats SHOULD request one Vendor therefore SHOULD NOT use multiple encodings for VSAs that are
Id for each VSA format that they will use. associated with a particular Vendor Id. A vendor wishing to use
multiple VSA encodings SHOULD request one Vendor Id for each VSA
encoding that they will use.
Notwithstanding the above recommendations, the format of the Vendor- Notwithstanding the above recommendations, the encoding of the vendor
Specific space is under the complete control of individual vendors space is under the complete control of individual vendors and SDOs.
and SDOs. The guidelines outlined here are only recommendations, and The guidelines outlined here are recommendations, and therefore do
do not define any requirements or restrictions on the Vendor-Specific not define any requirements or restrictions on the vendor space.
space.
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. Therefore, it is expected that a RADIUS be provisioned using RADIUS. Therefore, it is expected that a RADIUS
attribute specification will reference documents defining the attribute specification will reference documents defining the
protocol or service to be provisioned. Within the IETF, a RADIUS protocol or service to be provisioned. Within the IETF, a RADIUS
attribute specification SHOULD NOT be used to define the protocol or attribute specification SHOULD NOT be used to define the protocol or
service being provisioned. New services using RADIUS for service being provisioned. New services using RADIUS for
provisioning SHOULD be defined elsewhere and referenced in the RADIUS provisioning SHOULD be defined elsewhere and referenced in the RADIUS
skipping to change at page 10, line 48 skipping to change at page 10, line 47
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)
New commands (i.e., the Code field in the packet header) and new New commands (i.e., the Code field in the packet header) and new
attributes in the "standard space" are allocated only through "IETF attributes in the standard space are allocated only through "IETF
Consensus" as noted in [RFC3575] Section 2.1. Consensus" as noted in [RFC3575] Section 2.1.
2.4. Translation of Vendor Specifications 2.4. Translation of Vendor Specifications
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
skipping to change at page 12, line 14 skipping to change at page 12, line 14
* 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 which require stateful protocol behavior without
use of the State Attribute are inherently incompatible with RADIUS as use of the State Attribute are inherently incompatible with RADIUS as
defined in [RFC2865], and need to be redesigned. See [RFC5080] defined in [RFC2865], and SHOULD be redesigned. See [RFC5080]
Section 2.1.1 for a more in-depth discussion of the use of the State Section 2.1.1 for additional discussion surrounding the use of the
Attribute. State 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. not allow the provisioning of services within an Access-Reject.
Documents which include provisioning of services within an Access- Documents which include provisioning of services within an Access-
Reject are inherently incompatible with RADIUS, and need to be Reject are inherently incompatible with RADIUS, and SHOULD be
redesigned. 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,
skipping to change at page 15, line 5 skipping to change at page 15, line 5
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-Specific attribute space has grown, and this has
lead to some divergence in approaches to RADIUS attribute design. lead to some divergence in approaches to RADIUS attribute design.
For example, vendors and SDOs have evolved the data model to support For example, vendors and SDOs have evolved the data model to support
functions such as new data types, along with attribute grouping and functions such as new data types, along with attribute grouping and
attribute fragmentation, with different groups taking different attribute fragmentation, with different groups taking different
approaches. These approaches are often incompatible, leading to approaches. These approaches are often incompatible, leading to
additional complexity in RADIUS implementations. additional complexity in RADIUS implementations.
In order to avoid repeating old mistakes, his 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. Basic Data Types 3.2.1. Basic Data Types
[RFC2865] and [RFC2866] utilize data types defined in [RFC2865] [RFC2865] and [RFC2866] utilize data types defined in [RFC2865]
Section 5, which states the following: Section 5, which states the following:
The format of the value field is one of five data types. Note The format of the value field is one of five data types. Note
that type "text" is a subset of type "string". that type "text" is a subset of type "string".
skipping to change at page 16, line 16 skipping to change at page 16, line 16
128 bits of value, in network byte order. 128 bits of value, in network byte order.
The IPv6 address type is used for the NAS-IPv6-Address defined in The IPv6 address type is used for the NAS-IPv6-Address defined in
[RFC3162] Section 2.1 and the Login-IPv6-Host defined in [RFC3162] [RFC3162] Section 2.1 and the Login-IPv6-Host defined in [RFC3162]
Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3,
and in [RFC4818] Section 3. and in [RFC4818] Section 3.
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, and therefore there is controversy over whether
the format of this attribute 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 of type "IPv6 address" and "IPv6 prefix" are Given that attributes of type "IPv6 address" and "IPv6 prefix" are
already in use, it is RECOMMENDED that RADIUS server implementations already in use, it is RECOMMENDED that RADIUS server implementations
include support for these additional basic types, in addition to the include support for these additional basic types, in addition to the
types defined in [RFC2865]. Where the intent is to represent a types defined in [RFC2865]. Where the intent is to represent a
specific IPv6 address, the "IPv6 address" type SHOULD be used. specific IPv6 address, the "IPv6 address" type SHOULD be used.
Although it is possible to use the "IPv6 Prefix" type with a prefix Although it is possible to use the "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
skipping to change at page 17, line 25 skipping to change at page 17, line 25
3.2.3. Complex Data Types 3.2.3. Complex Data Types
The RADIUS attribute encoding is summarized in [RFC2865]: The RADIUS attribute encoding is 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 do not follow this format. However, some standard attributes do not follow this encoding.
Attributes that use a format other than the basic data types as Attributes that use an encoding other than the basic data types as
discussed above are defined to be "complex types". As described discussed above are defined to be "complex types". As described
below in this section, the creation of complex types can lead to below in this section, the creation of complex types can lead to
interoperability and deployment issues, so they need to be introduced interoperability and deployment issues, so they need to be introduced
with care. with care.
In general, complex types containing multiple sub-fields can be In general, complex types containing multiple sub-fields can be
supported by concatenating the sub-fields into a String data type supported by concatenating the sub-fields into a String data type
field. However, separating these sub-fields into different field. However, separating these sub-fields into different
attributes, each with its own type and length, would have the attributes, each with its own type and length, would have the
following benefits: following benefits:
skipping to change at page 20, line 21 skipping to change at page 20, line 21
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 specific space in situations where interoperability is not only
useful, but is required. For example, SDOs outside the IETF (such as useful, but is required. For example, SDOs outside the IETF (such as
the IEEE 802 and the 3rd Generation Partnership Project (3GPP)) have the IEEE 802 and the 3rd Generation Partnership Project (3GPP)) have
been assigned Vendor-Ids, enabling them to define their own VSA been assigned Vendor-Ids, enabling them to define their own VSA
format and assign Vendor types within their own space. encoding and assign Vendor types within their own space.
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 (OID) As with SNMP, which defines an "Enterprise" Object Identifier (OID)
space suitable for use by vendors as well as other SDOs, the space suitable for use by vendors as well as other SDOs, the
definition of Vendor-Specific RADIUS attributes has become a common definition of Vendor-Specific RADIUS attributes has become a common
occurrence as part of standards activity outside the IETF. For occurrence as part of standards activity outside the IETF. For
reasons of efficiency, it is easiest if the RADIUS attributes reasons of efficiency, it is easiest if the RADIUS attributes
skipping to change at page 20, line 43 skipping to change at page 20, line 43
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 few Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few
vendors are willing to simultaneously fund individuals to 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 RADIUS attribute space is limited to 255 unique
attributes. Of these, only about half remain available for attributes. Of these, only about half remain available for
allocation. In the Vendor-Specific space, the number of attributes allocation. In the vendor space, the number of attributes
available is a function of the format of the attribute (the size of available is a function of the encoding of the attribute (the size
the Vendor type field). of the Vendor type field).
Along with these advantages, some limitations of VSA usage are noted Along with these advantages, some limitations of VSA usage are noted
in [RFC2865] Section 5.26: in [RFC2865] Section 5.26:
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).
skipping to change at page 21, line 25 skipping to change at page 21, line 25
reserved for allocation through work published via the IETF, as noted reserved for allocation through work published via the IETF, as noted
in [RFC3575] Section 2.1. Some vendors and SDOs have in the past in [RFC3575] Section 2.1. Some vendors and SDOs have in the past
performed self-allocation by assigning vendor-specific meaning to performed self-allocation by assigning vendor-specific meaning to
"unused" values from the standard RADIUS attribute ID or enumerated "unused" values from the standard RADIUS attribute ID or enumerated
value space. This self-allocation results in interoperability value space. This self-allocation results in interoperability
issues, and is counter-productive. Similarly, the Vendor-Specific issues, and is counter-productive. Similarly, the Vendor-Specific
enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT
RECOMMENDED. 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 from their Vendor-Specific space, SHOULD self-allocate an attribute, which MUST be in vendor space, as
as discussed in Sections 3.3.2 and 3.3.3, below. discussed in Sections 3.3.2 and 3.3.3, below.
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
skipping to change at page 22, line 6 skipping to change at page 22, line 6
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 PEC from the This change control can be obtained by requesting a PEC 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 VSA 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 VSA space is solely under the discretion of
the vendor. the vendor.
Nevertheless, following the guidelines outlined within this document Nevertheless, following the guidelines outlined within this document
has many advantages. It is therefore RECOMMENDED that vendors follow has many advantages. Following these guidelines means that RADIUS
servers can be updated to support the vendor's equipment by editing a
RADIUS dictionary. It is therefore RECOMMENDED that vendors follow
the guidelines outlined here, which are intended to enable maximum the guidelines outlined here, which are intended to enable maximum
interoperability with minimal changes to existing systems. If these interoperability with minimal changes to existing systems. If these
guidelines are not followed, the result will be increased complexity guidelines are not followed, then the vendor's equipment can only be
with little or no benefit. supported via code changes in RADIUS server implementations. Such
code changes add complexity and delay to implementations.
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. Is 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 requesting an allocation from the RADIUS
standard attribute space, for attributes matching any of the standard attribute space, for attributes matching any of the
following criteria: following criteria:
skipping to change at page 22, line 43 skipping to change at page 22, line 46
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 PEC from the This change control can be obtained by requesting a PEC 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 VSA 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 VSA space is solely under the discretion of
the SDO. the SDO.
Nevertheless, following the guidelines outlined within this document
has many advantages. It is therefore RECOMMENDED that SDOs follow
the guidelines outlined here, which are intended to enable maximum
interoperability with minimal changes to existing systems.
3.3.4. Publication of specifications 3.3.4. Publication of specifications
In order to enable IETF review of SDO specifications, it is SDOs or vendors desiring review of their RADIUS specifications by the
RECOMMENDED that: IETF are encouraged to seek review as early as possible, so as to
avoid potential delays. Since reviews are handled by volunteers,
* SDOs make their RADIUS attribute specifications publicly responses are provided on a best-effort basis, with no service level
available; guarantees. In order to provide reviewers with access to the
specification, vendors and SDOs are encouraged to make them publicly
* SDOs request review of RADIUS attribute specifications by available.
sending email to the AAA Doctors [DOCTORS] or equivalent mailing
list;
* IETF and SDO RADIUS attribute specifications are reviewed Where the RADIUS specification is embedded within a larger document
according to the guidelines proposed in this document; which cannot be made public, the RADIUS attribute and value
definitions can be made available on a public web site or can be
published as an Informational RFC, as with [RFC4679].
* Reviews of specifications are posted to the RADEXT WG mailing Review can be requested by sending email to the AAA Doctors [DOCTORS]
list, or equivalent mailing list. The IETF Operations & Management Area
the AAA Doctors mailing list [DOCTORS] or another IETF mailing Directors will then arrange for the review to be completed and posted
list to the AAA Doctors mailing list [DOCTORS], RADEXT WG mailing list, or
suggested by the Operations & Management Area Directors of the other IETF mailing list.
IETF.
It should be understood that SDOs do not have to rehost VSAs into the The review process requires neither allocation of attributes within
standards space solely for the purpose of obtaining IETF review. the IETF standard attribute space nor publication of an IETF RFC.
Rehosting puts pressure on the standards space, and may be harmful to Requiring SDOs or vendors to rehost VSAs into the IETF standards
interoperability, since it can create two ways to provision the same attribute space solely for the purpose of obtaining review would put
pressure on the standards space, and may be harmful to
interoperability, since would create two ways to provision the same
service. Rehosting may also require changes to the RADIUS data model service. Rehosting may also require changes to the RADIUS data model
which will affect implementations that do not intend to support the which will affect implementations that do not intend to support the
SDO specifications. SDO or vendor specifications.
These reviews can assist with creation of specifications that meet
the SDO requirements, and which are also compatible with the
traditional data model and uses of RADIUS. While these reviews
require access to public specifications, the review process does not
require publication of an IETF RFC.
SDOs are encouraged to seek early review of their specifications by
the IETF. It should be understood that reviews are a voluntary-based
service offered on best-effort basis.
Where the RADIUS specification is embedded within a larger document
which cannot be made public, the RADIUS attribute and value
definitions SHOULD be published instead as an Informational RFC, as
with [RFC4679]. This process SHOULD be followed instead of
requesting IANA allocations from within the standard RADIUS attribute
space.
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 them to request publication of their VSA specifications necessary for a vendor to request publication of a VSA specification
as Informational RFCs by the IETF. as an Informational RFC by the IETF.
All other specifications, including new authentication, All other specifications, including new authentication,
authorization, and/or security mechanisms SHOULD follow the authorization, and/or security mechanisms SHOULD follow the
allocation process defined in [RFC3575]. allocation process defined in [RFC3575], as they are likely to have
impact on the Internet Community.
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.
RADIUS server dictionary entries are typically static, enabling the RADIUS server dictionary entries are typically static, enabling the
skipping to change at page 30, line 18 skipping to change at page 30, line 18
of data structures defined outside of RADIUS. See also Section of data structures defined outside of RADIUS. See also Section
A.1.3, below. A.1.3, below.
Nested groups or attributes do not qualify as "basic data types", and Nested groups or attributes do not qualify as "basic data types", and
SHOULD NOT be used. SHOULD NOT be used.
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, it SHOULD be the RADIUS protocol, as outlined below? If so, it SHOULD be
encapsulated in a [RFC2865] format RADIUS attribute. It SHOULD NOT allocated from the standard space via "IETF consensus", and SHOULD
be encapsulated in a [RFC2865] format RADIUS VSA. NOT be allocated from the vendor space.
* Complex data types that carry authentication methods which * Complex data types that carry authentication methods which
RADIUS servers are expected to parse and verify as part of RADIUS servers are expected to parse and verify as part of
an authentication process. an authentication process.
* Complex data types that carry security information intended * Complex data types that carry security information intended
to increase the security of the RADIUS protocol itself. to 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",
skipping to change at page 30, line 43 skipping to change at page 30, line 43
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, as discussed above in Section NOT define or describe the structure, for reasons discussed above in
2.1.3. Section 2.1.3.
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"
design. This trade-off does not always require the "better" design
to be used. As a result. pre-existing complex data types described
in Appendix B MAY be used, though this practice is NOT RECOMMENDED.
A.2. Improper Data Types A.2. Improper Data Types
All data types other than the ones described above in Appendix A.1 All data types other than the ones described above in Appendix A.1
and Appendix B SHOULD NOT be used. This section describes in detail and Appendix B SHOULD NOT be used. This section describes in detail
a number of data types that are NOT RECOMMENDED in new RADIUS a number of data types that are NOT RECOMMENDED in new RADIUS
specifications. Where possible, replacement data types are specifications. Where possible, replacement data types are
suggested. suggested.
A.2.1. Basic Data Types A.2.1. Basic Data Types
skipping to change at page 31, line 26 skipping to change at page 31, line 34
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 * 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 insufficient justification to define a new size of There is 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.
skipping to change at page 32, line 14 skipping to change at page 32, line 23
* 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. Also see Section 2.1.3 for a discussed above in Appendix A.2.1. See also Section 2.1.3 for a
discussion of why complex types are problematic. discussion 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 data type should be any of the following criteria? If so, the VSA encoding should be
replaced with the suggested alternatives, or should not be used at replaced with the [RFC2865] Section 5.26 encoding, or should not be
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 [RFC2865]
suggested format. Vendor extensions to non-standard formats are NOT Section 5.26 suggested encoding. Vendor extensions to non-standard
RECOMMENDED as they can negatively affect interoperability. encodings are NOT RECOMMENDED as they can negatively affect
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:
* 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 functionality of Access-Request packets. the 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. Using RADIUS to
transport authentication methods such as EAP is explicitly transport authentication methods such as EAP is explicitly
permitted, even if those methods require the transport of permitted, even if those methods require the transport of
skipping to change at page 33, line 40 skipping to change at page 33, line 48
* Provisioning of service in an Access-Reject. Such provisioning * Provisioning of service in an Access-Reject. Such provisioning
is not permitted, and MUST NOT be used. If limited access needs is not permitted, and MUST NOT be used. If limited access needs
to be provided, then an Access-Accept with appropriate to be provided, then an Access-Accept with appropriate
authorizations can be used instead. 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 a link to a previous user authentication, the State attribute is a link to a previous user authentication, the State attribute
needs to 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 and authentication. integrity 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.3. For further details, see Section 3.3.
A.5. Allocation of attributes A.5. Allocation of attributes
Does the attribute have a limited scope of applicability, as outlined 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-Specific space. vendor space, rather than requesting allocation from the standard
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.
skipping to change at page 38, line 16 skipping to change at page 38, line 16
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 it not
directly involved in authentication. The individual sub-fields could directly involved in authentication. The individual sub-fields could
therefore have been encapsulated in separate attributes. therefore have been encapsulated in separate attributes.
Since the form of the text string is well defined, there is no Since the form of the text string is well defined, there is no
benefit in using a text string. Instead, an integer attribute should benefit in using a text string. Instead, an integer attribute should
have been assigned for each of the transmit speed and the receive have been assigned for each of the transmit speed and the receive
speed. A separate enumerated integer should have been assigned for speed. A separate enumerated integer should have been assigned for
the additional information, as is done for the NAS-Port-Type the additional information, as was done with the NAS-Port-Type
attribute. attribute.
B.7. Framed-IPv6-Prefix B.7. Framed-IPv6-Prefix
[RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and
[RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix
Attribute; these attributes are sent from the RADIUS server to the Attribute; these attributes are sent from the RADIUS server to the
client in an Access-Accept. client in an Access-Accept.
0 1 2 3 0 1 2 3
skipping to change at page 39, line 51 skipping to change at page 39, line 51
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. The complex structure of this attribute is acceptable for above. The complex structure of this attribute is acceptable for
reasons identical to those given for Egress-VLANID. reasons identical to those given for Egress-VLANID.
B.9. Digest-* B.9. 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 used two attributes
from the "standard space" without being assigned them by IANA. This from the standard space without being assigned them by IANA. This
self-allocation is forbidden, as described above in Section 1.3 and self-allocation is forbidden, as described above in Section 1.3 and
in Section 2. In addition, the draft uses nested attributes, which in Section 2. In addition, the draft uses nested attributes, which
are discouraged in Section 2.1. The updated document uses basic data are discouraged in Section 2.1. The updated document uses basic data
types, and 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 draft has seen wide-spread implementation, where
[RFC5090] has not. While there are a number of factors involved, one [RFC5090] has not. While there are a number of factors involved, one
factor may be that implementors disagreed with the trade-offs made in factor may be that implementors disagreed with the trade-offs made in
the updated specification. It may have been better to simply the updated specification. It may have been better to simply
document the existing format, and request IANA allocation of two document the existing format, and request IANA allocation of two
 End of changes. 71 change blocks. 
202 lines changed or deleted 194 lines changed or added

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