draft-ietf-radext-design-18.txt   draft-ietf-radext-design-19.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-18.txt> Individual Contributor <draft-ietf-radext-design-19.txt> Individual Contributor
Expires: Apri 12, 2011 Expires: May 8, 2011
12 October 2010 8 November 2010
RADIUS Design Guidelines RADIUS Design Guidelines
draft-ietf-radext-design-18 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, both within the
IETF as well as other Standards Development Organizations (SDOs). IETF as well as other Standards Development Organizations (SDOs).
Status of this Memo Status of this Memo
skipping to change at page 1, line 42 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 April 12, 2011. This Internet-Draft will expire on May 8, 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 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Introduction ............................................. 5 1. Introduction ............................................. 5
1.1. Terminology ......................................... 5 1.1. Terminology ......................................... 5
1.2. Requirements Language ............................... 6 1.2. Requirements Language ............................... 6
1.3. Applicability ....................................... 6 1.3. Applicability ....................................... 6
1.3.1. Reviews ........................................ 7 1.3.1. Reviews ........................................ 7
2. Guidelines ............................................... 8 2. Guidelines ............................................... 8
2.1. Data Types .......................................... 9 2.1. Data Types .......................................... 9
2.2. Vendor-Specific Attribute Space ..................... 10 2.2. Vendor-Specific Attribute Space ..................... 10
2.3. Service definitions and RADIUS ...................... 10 2.3. Service definitions and RADIUS ...................... 11
2.4. Translation of Vendor Specifications ................ 11 2.4. Translation of Vendor Specifications ................ 11
3. Rationale ................................................ 12 3. Rationale ................................................ 12
3.1. RADIUS Operational Model ............................ 12 3.1. RADIUS Operational Model ............................ 12
3.2. Data Model Issues ................................... 15 3.2. Data Model Issues ................................... 15
3.2.1. Issues with Definitions of Types ............... 15 3.2.1. Issues with Definitions of Types ............... 16
3.2.2. Tagging Mechanism .............................. 17 3.2.2. Tagging Mechanism .............................. 17
3.2.3. Complex Data Types ............................. 17 3.2.3. Complex Data Types ............................. 17
3.2.4. Complex Data Type Exceptions ................... 18 3.2.4. Complex Data Type Exceptions ................... 19
3.3. Vendor Space ........................................ 19 3.3. Vendor Space ........................................ 20
3.3.1. Interoperability Considerations ................ 20 3.3.1. Interoperability Considerations ................ 21
3.3.2. Vendor Allocations ............................. 21 3.3.2. Vendor Allocations ............................. 21
3.3.3. SDO Allocations ................................ 21 3.3.3. SDO Allocations ................................ 22
3.4. Polymorphic Attributes .............................. 22 3.4. Polymorphic Attributes .............................. 22
4. IANA Considerations ...................................... 22 4. IANA Considerations ...................................... 23
5. Security Considerations .................................. 23 5. Security Considerations .................................. 23
5.1. New Data Types and Complex Attributes ............... 23 5.1. New Data Types and Complex Attributes ............... 24
6. References ............................................... 24 6. References ............................................... 25
6.1. Normative References ................................ 24 6.1. Normative References ................................ 25
6.2. Informative References .............................. 24 6.2. Informative References .............................. 25
Appendix A - Design Guidelines ............................... 27 Appendix A - Design Guidelines ............................... 28
A.1. Types matching the RADIUS data model ................. 27 A.1. Types matching the RADIUS data model ................. 28
A.1.1. Transport of basic data types ................... 27 A.1.1. Transport of basic data types ................... 28
A.1.2. Transport of Authentication and Security Data ... 27 A.1.2. Transport of Authentication and Security Data ... 28
A.1.3. Opaque data types ............................... 27 A.1.3. Opaque data types ............................... 28
A.1.4. Pre-existing data types ......................... 27 A.1.4. Pre-existing data types ......................... 28
A.2. Improper Data Types .................................. 28 A.2. Improper Data Types .................................. 29
A.2.1. Simple Data Types ............................... 28 A.2.1. Simple Data Types ............................... 29
A.2.2. More Complex Data Types ......................... 29 A.2.2. More Complex Data Types ......................... 30
A.3. Vendor-Specific formats .............................. 29 A.3. Vendor-Specific formats .............................. 30
A.4. Changes to the RADIUS Operational Model .............. 30 A.4. Changes to the RADIUS Operational Model .............. 31
A.5. Allocation of attributes ............................. 31 A.5. Allocation of attributes ............................. 32
Appendix B - Complex Attributes .............................. 32 Appendix B - Complex Attributes .............................. 33
B.1. CHAP-Password ........................................ 32 B.1. CHAP-Password ........................................ 33
B.2. CHAP-Challenge ....................................... 32 B.2. CHAP-Challenge ....................................... 33
B.3. Tunnel-Password ...................................... 32 B.3. Tunnel-Password ...................................... 33
B.4. ARAP-Password ........................................ 33 B.4. ARAP-Password ........................................ 34
B.5. ARAP-Features ........................................ 33 B.5. ARAP-Features ........................................ 34
B.6. Connect-Info ......................................... 34 B.6. Connect-Info ......................................... 35
B.7. Framed-IPv6-Prefix ................................... 35 B.7. Framed-IPv6-Prefix ................................... 36
B.8. Egress-VLANID ........................................ 35 B.8. Egress-VLANID ........................................ 36
B.9. Egress-VLAN-Name ..................................... 36 B.9. Egress-VLAN-Name ..................................... 37
B.10. Digest-* ............................................ 36 B.10. Digest-* ............................................ 37
1. Introduction 1. Introduction
This document provides guidelines for the design of RADIUS attributes This document provides guidelines for the design of Remote
both within the IETF as well as within other SDOs. By articulating Authentication Dial In User Service (RADIUS) attributes both within
RADIUS design guidelines, it is hoped that this document will the IETF as well as within other SDOs. By articulating RADIUS design
encourage the development and publication of high quality RADIUS guidelines, it is hoped that this document will encourage the
attribute specifications. development and publication of high 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 this document will be used
by authors to check their document against the guidelines prior to by authors to check their document against the guidelines prior to
publication, or requesting review (such as an "Expert Review" publication, or requesting review (such as an "Expert Review"
described in [RFC3575]). Similarly, it is expected that this described in [RFC3575]). Similarly, it is expected that this
document will used by reviewers (such as WG participants or the AAA document will be used by reviewers (such as WG participants or the
Doctors [DOCTORS]), resulting in an improvement in the consistency of AAA Doctors [DOCTORS]), resulting in an improvement in the
reviews. 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 addition to covering the most frequently encountered issues, this in 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
discusses the applicability of the guidelines and defines a
recommended review process for RADIUS specifications. Section 2
defines the design guidelines in terms of what is "RECOMMENDED" and
"NOT RECOMMENDED". Section 3 gives a longer explanation of the
rationale behind the guidelines given in the previous section.
Appendix A repeats the guidelines in a "checklist" format. Appendix
B discusses previously defined attributes which do not follow the
guidelines.
Authors of new RADIUS specifications can be compliant with the design
guidelines by working through the checklists given in Appendix A.
Reviewers of RADIUS spcifications are expected to be familiar with
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/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 standard space
RADIUS attributes which are allocated by IANA and which follow the Codes in the RADIUS Attribute Type Space which are allocated by
format defined in RFC 2865 [RFC2865] Section 5. IANA and which follow the format defined in RFC 2865 [RFC2865]
Section 5.
vendor space vendor space
The contents of the "String" field of a Vendor-Specific Attribute The contents of the "String" field of a Vendor-Specific Attribute
(VSA), as defined in [RFC2865] Section 5.26. These attributes (VSA), as defined in [RFC2865] Section 5.26. These attributes
provide a unique attribute space for each vendor (identified by the provide a unique attribute type space for each vendor (identified
Vendor-Type field) which they can self-allocate. 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 attributes used to encode The advice in this document applies to RADIUS attributes used to
service-provisioning, authentication, or accounting data, based on encode service-provisioning, authentication, or accounting data,
the attribute encodings and data formats defined in RFC 2865 based 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 standards RADIUS specifications requesting allocation within the standard space
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
[RFC2865] Section 5.26, 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 to
not conform to these guidelines. not 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 2010) involved in
developing updates to RADIUS. Those updates will provide their own developing updates to RADIUS. Those updates will provide their own
skipping to change at page 6, line 44 skipping to change at page 7, line 15
[RFC2865] Section 5.26, 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 to
not conform to these guidelines. not 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 2010) 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 over-ride some of the guidelines discussed usage guidelines that may modify some of the guidelines defined here,
here. 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 standards 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-Specific space. Experience has
shown that attributes not originally designed for general usage can shown that attributes not originally designed for general usage can
subsequently garner wide-spread deployment. An example is the subsequently garner wide-spread deployment. An example is the
vendor-specific attributes defined in [RFC2548], which have been vendor-specific attributes defined in [RFC2548], which have been
widely implemented within IEEE 802.11 Access Points. widely implemented within IEEE 802.11 Access Points.
skipping to change at page 8, line 7 skipping to change at page 8, line 24
which will affect implementations that do not intend to support the which will affect implementations that do not 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 Informational RFC by the IETF.
2. Guidelines 2. Guidelines
The Remote Authentication Dial In User Service (RADIUS) defined in The RADIUS protocol as defined in [RFC2865] and [RFC2866] uses
[RFC2865] and [RFC2866] uses elements known as attributes in order to elements known as attributes in order to represent authentication,
represent authentication, authorization and accounting data. 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 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 defined in Basic data types use one of the existing RADIUS data types as defined
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 number space defined by their Private Enterprise Number
(PEN). (PEN).
* 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 number space defined
by the SDOs PEN, rather then the PEN of an individual vendor. by the SDOs PEN, rather then 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 standards 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 standards 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 VSA
space, rather than requesting allocation of attributes from the space, rather than requesting allocation of attributes from the
standards space. Self-allocation of standards attributes is standard space. Usage of attribute type codes reserved for
considered anti-social behavior and is strongly discouraged. standard attributes is considered anti-social behavior and is
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)
skipping to change at page 10, line 21 skipping to change at page 10, line 39
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 tradeoff 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-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 and Section 5.26). As discussed there, it is intended for vendors and
SDOs to support their own Attributes not suitable for general use. 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 requesting an
allocation (or self-allocating) from within the RADIUS standard allocation from within the RADIUS standard attribute space.
attribute 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.
skipping to change at page 11, line 22 skipping to change at page 11, line 39
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 standards 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.
skipping to change at page 12, line 11 skipping to change at page 12, line 29
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 attribute
space. We do not expect that all RADIUS attribute specifications space. We do not expect that all RADIUS attribute specifications
requiring interoperability will be developed within the IETF, and requiring interoperability will be developed within the IETF, and
allocated from the standards space. A more scalable approach is to allocated from the standard space. A more scalable approach is to
recognize the flexibility of the vendor space, while working toward recognize 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 use 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.
skipping to change at page 15, line 34 skipping to change at page 16, line 4
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-Specific attribute space has grown, and this has
lead to some divergence in approaches to RADIUS attribute design. led to some divergence in approaches to RADIUS attribute design. For
For example, vendors and SDOs have evolved the data model to support 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, 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, string,
address, integer and time. Both the names and interpretations of the address, integer and time. Both the names and interpretations of the
types are given. 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 was 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
skipping to change at page 17, line 43 skipping to change at page 18, line 12
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 of a complex type. "Value" field, resulting in the creation a non-standard, i.e. complex
Separating these sub-fields into different attributes, each with its type. Separating these sub-fields into different attributes, each
own type and length, would have the following benefits: 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 administator 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 and validation routines for well-known types; parsing 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.
skipping to change at page 19, line 37 skipping to change at page 20, line 7
into individual RADIUS attributes. into 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 suggestions for how the attribute could have been defined to or suggestions for how the attribute could have been defined to
follow the RADIUS data model. follow 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
This is possible because the data types are not sent within the in a specification. This is possible because the data types are not
attributes, but are a matter for endpoint interpretation. An sent within the attributes, but are a matter for endpoint
implementation can define additional data types, and use these data interpretation. An implementation can define additional data types,
types today by matching them to the attribute's textual description. and use these data types today by matching them to the attributes
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
skipping to change at page 20, line 43 skipping to change at page 21, line 14
allocation. In the vendor space, the number of attributes allocation. In the vendor space, the number of attributes
available is a function of the encoding of the attribute (the size available is a function of the 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 RADIUS attribute
space, and the enumerated value space for enumerated attributes, are space, and the enumerated value space for enumerated attributes, are
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 assigning vendor-specific meaning to "unused" values from the
"unused" values from the standard RADIUS attribute ID or enumerated standard space. This process results in interoperability issues, and
value space. This self-allocation results in interoperability is counter-productive. Similarly, the Vendor-Specific enumeration
issues, and is counter-productive. Similarly, the Vendor-Specific practice discussed in [RFC2882] Section 2.2.1 is NOT RECOMMENDED.
enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT
RECOMMENDED.
If it is not possible to follow the IETF process, vendors and SDOs If it is not possible to follow the IETF process, vendors and SDOs
SHOULD self-allocate an attribute, which MUST be in vendor space, as SHOULD self-allocate an attribute, which MUST be in their own vendor
discussed in Sections 3.3.2 and 3.3.3, below. space, as 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
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 PEC 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 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.
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
skipping to change at page 22, line 8 skipping to change at page 22, line 28
* 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 PEC 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 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.
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.
skipping to change at page 28, line 7 skipping to change at page 29, line 7
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 above 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 There is a trade-off in design between re-using existing formats for
historical compatibility, or choosing new formats for a "better" 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 which 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 descibes 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.
 End of changes. 39 change blocks. 
97 lines changed or deleted 114 lines changed or added

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