draft-ietf-radext-design-02.txt   draft-ietf-radext-design-03.txt 
Network Working Group G. Weber Network Working Group G. Weber
INTERNET-DRAFT Individual Contributor INTERNET-DRAFT Individual Contributor
Category: Best Current Practice Alan DeKok (ed.) Category: Best Current Practice Alan DeKok (ed.)
<draft-ietf-radext-design-02.txt> FreeRADIUS <draft-ietf-radext-design-03.txt> FreeRADIUS
Expires: June 5, 2008 Expires: December 25, 2008
5 December 2007
RADIUS Design Guidelines RADIUS Design Guidelines
draft-ietf-radext-design-02.txt draft-ietf-radext-design-03.txt
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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 38 skipping to change at page 1, line 36
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 June 5, 2008. This Internet-Draft will expire on June 5, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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).
Table of Contents Table of Contents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
B.8. Egress-VLANID ........................................ 28 B.8. Egress-VLANID ........................................ 28
B.9. Egress-VLAN-Name ..................................... 29 B.9. Egress-VLAN-Name ..................................... 29
Full Copyright Statement ..................................... 30 Full Copyright Statement ..................................... 30
1. Introduction 1. Introduction
This document provides guidelines for the design of RADIUS attributes This document provides guidelines for the design of RADIUS attributes
both within the IETF as well as within other Standards Development both within the IETF as well as within other Standards Development
Organizations (SDOs). By articulating RADIUS design guidelines, it Organizations (SDOs). By articulating RADIUS design guidelines, it
is hoped that this document will encourage the development and is hoped that this document will encourage the development and
publication of high quality RADIUS attribute specifications. The publication of high quality RADIUS attribute specifications.
advice in this document will not be helpful unless it is put to use.
As with "Guidelines for Authors and Reviewers of MIB Documents" However, the advice in this document will not be helpful unless it is
[RFC4181], it is expected that this document will enable authors to put to use. As with "Guidelines for Authors and Reviewers of MIB
check their document against the guidelines prior to requesting a Documents [RFC4181], it is expected that this document will be used
review (such an "Expert Review" described in [RFC3575]). Similarly, by authors to check their document against the guidelines prior to
it is hoped that this document will be of use to reviewers (such as requesting review (such an "Expert Review" described in [RFC3575]).
WG participants or the AAA Doctors) in improving the consistency of Similarly, it is expected that this document will used by reviewers
reviews. (such as WG participants or the AAA Doctors), resulting in an
improvement in the consistency of reviews.
In order to meet these objectives, this document needs to cover not In order to meet these objectives, this document needs to cover not
only the science of attribute design, but also the art. As a result, only the science of attribute design, but also the art. As a result,
in addition to covering the most frequently encountered issues, this in addition to covering the most frequently encountered issues, this
document attempts to provide some of the considerations motivating document attempts to provide some of the considerations motivating
the guidelines. the guidelines.
In order to characterize current attribute usage, both the basic and In order to characterize current attribute usage, both the basic and
complex data types defined in the existing RADIUS RFCs are reviewed, complex data types defined in the existing RADIUS RFCs are reviewed,
together with the ad-hoc extensions to that data model that have been together with the ad-hoc extensions to that data model that have been
used in Vendor-Specific Attributes. used in Vendor-Specific Attributes.
1.1. Applicability 1.1. Applicability
As RADIUS has become more widely accepted as a management protocol, As RADIUS has become more widely accepted as a management protocol,
it's usage has become more prevalent, both within the IETF as well as its usage has become more prevalent, both within the IETF as well as
within other SDOs. Given the expanded utilization of RADIUS, it has within other SDOs. Given the expanded utilization of RADIUS, it has
become apparent that requiring SDOs to accomplish all their RADIUS become apparent that requiring SDOs to accomplish all their RADIUS
work within the IETF is inherently inefficient and unscalable. By work within the IETF is inherently inefficient and unscalable. By
articulating guidelines for RADIUS attribute design, this document articulating guidelines for RADIUS attribute design, this document
enables SDOs to design their own RADIUS attributes within the Vendor- enables SDOs to design their own RADIUS attributes within the Vendor-
Specific Attribute (VSA) space, seeking review from the IETF. In Specific Attribute (VSA) space, seeking review from the IETF. In
order enable IETF review of SDO RADIUS attribute specifications, the order enable IETF review of SDO RADIUS attribute specifications, the
authors recommend: authors recommend:
* Development of a program to encourage SDOs to make their RADIUS * Development of a program to encourage SDOs to make their RADIUS
skipping to change at page 7, line 29 skipping to change at page 7, line 29
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 format.
Attributes that use sub-fields instead of using a basic data type are Attributes that use sub-fields instead of using a basic data type are
known as "complex attributes". As described below, the definition of known as "complex attributes". As described below, the definition of
complex attributes can lead to interoperability and deployment complex attributes can lead to interoperability and deployment
issues, so they need to introduced with care. issues, so they need to be introduced with care.
In general, complex attributes sent from the RADIUS server to the In general, complex attributes sent from the RADIUS server to the
client can be supported by concatenating the values into a String client can be supported by concatenating the values into a String
data type field. However, separating these values into different data type field. However, separating these values 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:
* it is easier for the user to enter the data as well-known * it is easier for the user to enter the data as well-known
types, rather than complex structures types, rather than complex structures
* it enables additional error checking by leveraging the * it enables additional error checking by leveraging the
skipping to change at page 8, line 39 skipping to change at page 8, line 39
typically only provide for limited operations (such as comparisons or typically only provide for limited operations (such as comparisons or
arithmetic operations) on the basic data types. Many existing RADIUS arithmetic operations) on the basic data types. Many existing RADIUS
policy languages typically are not capable of parsing sub-elements, policy languages typically are not capable of parsing sub-elements,
or providing sophisticated matching functionality. or providing sophisticated matching functionality.
Given these limitations, the introduction of complex attributes can Given these limitations, the introduction of complex attributes can
require code changes on the RADIUS server which would be unnecessary require code changes on the RADIUS server which would be unnecessary
if basic data types had been used instead. In addition, attribute- if basic data types had been used instead. In addition, attribute-
specific parsing means more complex software to develop and maintain. specific parsing means more complex software to develop and maintain.
More complexity can lead to more error prone implementations, and More complexity can lead to more error prone implementations, and
interoperatibility problems. This issues can increase costs to interoperatibility problems. These issues can increase costs to
network administrators as well as reducing reliability and network administrators as well as reducing reliability and
introducing deployment barriers. As a result, the introduction of introducing deployment barriers. As a result, the introduction of
new complex data types within RADIUS attribute specifications SHOULD new complex data types within RADIUS attribute specifications SHOULD
be avoided, except in the case of complex attributes involve be avoided, except in the case of complex attributes involving
authentication or security functionality. authentication or security functionality.
As can be seen in Appendix B, most of the complex attributes involve As can be seen in Appendix B, most of the complex attributes involve
authentication or security functionality. Supporting this authentication or security functionality. Supporting this
functionality requires code changes on both the RADIUS client and functionality requires code changes on both the RADIUS client and
server, regardless of the attribute format. As a result, in most server, regardless of the attribute format. As a result, in most
cases, the use of complex attributes to represent these methods is cases, the use of complex attributes to represent these methods is
acceptable, and does not create additional interoperability or acceptable, and does not create additional interoperability or
deployment issues. deployment issues.
skipping to change at page 9, line 36 skipping to change at page 9, line 36
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 This is possible because the data types are not sent within the
attributes, but are a matter for endpoint interpretation. An attributes, but are a matter for endpoint interpretation. An
implementation can define additional data types (e.g., IPv6 address), implementation can define additional data types, and use these data
and use these data types today by matching them to the attribute's types today by matching them to the attribute's textual description.
textual description.
2.1.4. Complex Attributes and Security 2.1.4. Complex Attributes and Security
The introduction of complex data types brings the potential for the The introduction of complex data types brings the potential for the
introduction of new security vulnerabilities. Experience shows that introduction of new security vulnerabilities. Experience shows that
the common data types have few security vulnerabilities, or else that the common data types have few security vulnerabilities, or else that
all known issues have been found and fixed. New data types require all known issues have been found and fixed. New data types require
new code, which may introduce new bugs, and therefore new attack new code, which may introduce new bugs, and therefore new attack
vectors. vectors.
skipping to change at page 12, line 4 skipping to change at page 11, line 51
would be more appropriate: would be more appropriate:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id | Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor-Id (cont) | Vendor type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor length | Attribute-Specific... | Vendor length | Attribute-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Other attribute formats are NOT RECOMMENDED. Examples of NOT Other attribute formats are NOT RECOMMENDED. Examples of NOT
RECOMMENDED formats include Vendor types of more than 16 bits, Vendor RECOMMENDED formats include Vendor types of more than 16 bits, Vendor
lengths of less than 8 bits, Vendor lengths of more than 8 bits, and lengths of less than 8 bits, Vendor lengths of more than 8 bits, and
Vendor-Specific contents that are not in Type-Length-Value format. Vendor-Specific contents that are not in Type-Length-Value format.
In order to be compatible with the above recommendations for attribute In order to be compatible with the above recommendations for
definitions, it is RECOMMENDED that RADIUS servers support attributes attribute definitions, it is RECOMMENDED that RADIUS servers support
using a 16-bit Vendor type field. attributes using a 16-bit Vendor type field.
3. Data Model Issues 3. Data Model Issues
Since the closure of the RADIUS Working Group, the popularity and Since the closure of the RADIUS Working Group, the popularity and
prevalence of RADIUS has continued to grow. In addition to prevalence of RADIUS has continued to grow. In addition to
increasing demand for allocation of attributes within the RADIUS increasing demand for allocation of attributes within the RADIUS
standard attribute space, the number of vendors and SDOs creating new standard attribute space, the number of vendors and SDOs creating new
attributes within the Vendor-Specific attribute space has grown, and attributes within the Vendor-Specific attribute space has grown, and
this has lead to some divergence in approaches to RADIUS attribute this has lead to some divergence in approaches to RADIUS attribute
design. design.
skipping to change at page 15, line 6 skipping to change at page 14, line 51
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 above procedure, vendors and SDOs If it is not possible to follow the above procedure, vendors and SDOs
they SHOULD self-allocate an attribute from their Vendor-Specific SHOULD self-allocate an attribute from their Vendor-Specific space,
space, and define an appropriate value for it. and define an appropriate value for it.
As a side note, [RFC2865] Section 5.26 uses the term "Vendor-Specific As a side note, [RFC2865] Section 5.26 uses the term "Vendor-Specific
Attribute" to refer to an encoding format which can be used by Attribute" to refer to an encoding format which can be used by
individual vendors to define attributes not suitable for general individual vendors to define attributes not suitable for general
usage. However, since then VSAs have also become widely used by SDOs usage. However, since then VSAs have also become widely used by SDOs
defining attributes intended for multi-vendor interoperability. As defining attributes intended for multi-vendor interoperability. As
such, these attributes are not specific to any single vendor, and the such, these attributes are not specific to any single vendor, and the
term "Vendor-Specific" may be misleading. An alternate term which term "Vendor-Specific" may be misleading. An alternate term which
better describes this use case is SDO-Specific Attribute (SSA). better describes this use case is SDO-Specific Attribute (SSA).
skipping to change at page 17, line 44 skipping to change at page 17, line 42
This specification provides guidelines for the design of RADIUS This specification provides guidelines for the design of RADIUS
attributes used in authentication, authorization and accounting. attributes used in authentication, authorization and accounting.
Threats and security issues for this application are described in Threats and security issues for this application are described in
[RFC3579] and [RFC3580]; security issues encountered in roaming are [RFC3579] and [RFC3580]; security issues encountered in roaming are
described in [RFC2607]. described in [RFC2607].
Encryption of RADIUS attributes on a per-attribute basis is necessary Encryption of RADIUS attributes on a per-attribute basis is necessary
in some cases. The current standard mechanism for this is described in some cases. The current standard mechanism for this is described
in [RFC2865] Section 5.2 (for obscuring User-Password values) and is in [RFC2865] Section 5.2 (for obscuring User-Password values) and is
based on the MD5 algorithm specified in [RFC1321]. The MD5 algorithm based on the MD5 algorithm specified in [RFC1321]. The MD5 and SHA-1
has recently become a focus of scrutiny and concern in security algorithms have recently become a focus of scrutiny and concern in
circles, and as a result, the use of this technique in new attributes security circles, and as a result, the use of these algorithms in new
is NOT RECOMMENDED. attributes is NOT RECOMMENDED.
Where new RADIUS attributes use cryptographic algorithms, algorithm Where new RADIUS attributes use cryptographic algorithms, algorithm
negotiation SHOULD be supported. Specification of a mandatory-to- negotiation SHOULD be supported. Specification of a mandatory-to-
implement algorithm is REQUIRED, and it is RECOMMENDED that the implement algorithm is REQUIRED, and it is RECOMMENDED that the
mandatory-to-implement algorithm be certifiable under FIPS 140 mandatory-to-implement algorithm be certifiable under FIPS 140
[FIPS]. [FIPS].
Where new RADIUS attributes encapsulate complex data types, or Where new RADIUS attributes encapsulate complex data types, or
transport opaque data, the security considerations discussed in transport opaque data, the security considerations discussed in
Section 2.1.4 SHOULD be addressed. Section 2.1.4 SHOULD be addressed.
skipping to change at page 19, line 45 skipping to change at page 19, line 42
User Service (RADIUS) Implementation Issues and Suggested User Service (RADIUS) Implementation Issues and Suggested
Fixes", RFC 5080, December 2007. Fixes", RFC 5080, December 2007.
[IEEE-802.1Q] [IEEE-802.1Q]
IEEE Standards for Local and Metropolitan Area Networks: Draft IEEE Standards for Local and Metropolitan Area Networks: Draft
Standard for Virtual Bridged Local Area Networks, Standard for Virtual Bridged Local Area Networks,
P802.1Q-2003, January 2003. P802.1Q-2003, January 2003.
[EXTEN] Li, Y., et al., "Extended Remote Authentication Dial In User [EXTEN] Li, Y., et al., "Extended Remote Authentication Dial In User
Service (RADIUS) Attributes", draft-ietf-radext-extended- Service (RADIUS) Attributes", draft-ietf-radext-extended-
attributes-00.txt (work in progress). attributes-03.txt (work in progress).
[FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic [FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic
Modules", http://csrc.nist.gov/publications/fips/fips140-3/ Modules", http://csrc.nist.gov/publications/fips/fips140-3/
Appendix A - Design Guidelines Appendix A - Design Guidelines
The following text provides guidelines for the design of attributes The following text provides guidelines for the design of attributes
used by the RADIUS protocol. Specifications that follow these used by the RADIUS protocol. Specifications that follow these
guidelines are expected to achieve maximum interoperability with guidelines are expected to achieve maximum interoperability with
minimal changes to existing systems. minimal changes to existing systems.
skipping to change at page 21, line 5 skipping to change at page 21, line 5
Where possible, the data types defined above in Section A.1.2 SHOULD Where possible, the data types defined above in Section A.1.2 SHOULD
be used. The extended data types SHOULD be used only where there is be used. The extended data types SHOULD be used only where there is
no clear method of expressing the data using existing types. no clear method of expressing the data using existing types.
Does the data fit within the extended RADIUS data model, as outlined Does the data fit within the extended RADIUS data model, as outlined
below? If so, it SHOULD be encapsulated in a [EXTEN] format RADIUS below? If so, it SHOULD be encapsulated in a [EXTEN] format RADIUS
VSA. VSA.
* Attributes grouped into a logical container. * Attributes grouped into a logical container.
This does not included nested groups. This does not include nested groups.
* Attributes requiring the transport of more than 247 octets of * Attributes requiring the transport of more than 247 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. See also Section of data structures defined outside of RADIUS. See also Section
A.1.3, below. A.1.3, below.
A.1.3. Complex data types A.1.3. Complex data types
Does the attribute encapsulate an existing data structure defined Does the attribute encapsulate an existing data structure defined
outside of the RADIUS specifications? Can the attribute be treated outside of the RADIUS specifications? Can the attribute be treated
as opaque data by RADIUS servers (including proxies?) If both as opaque data by RADIUS servers (including proxies?) If both
skipping to change at page 30, line 7 skipping to change at page 30, line 7
Email: gdweber@gmail.com Email: gdweber@gmail.com
Alan DeKok Alan DeKok
The FreeRADIUS Server Project The FreeRADIUS Server Project
http://freeradius.org/ http://freeradius.org/
Email: aland@freeradius.org Email: aland@freeradius.org
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 18 change blocks. 
36 lines changed or deleted 31 lines changed or added

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