Internet DRAFT - draft-weber-radius-attr-guidelines
draft-weber-radius-attr-guidelines
Network Working Group G. Weber
Internet-Draft Cisco Systems
Expires: December 28, 2006 June 26, 2006
Design Guidelines for RADIUS Attributes
draft-weber-radius-attr-guidelines-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo explores various issues related to the data model used by
the Remote Authentication Dial In User Service (RADIUS) protocol.
Recommendations are made to facilitate internal alignment and
uniformity. Attribute design guidelines are provided both as an aid
to IETF development work, and to facilitate independent work by other
Standards Development Organizations (SDOs).
Weber Expires December 28, 2006 [Page 1]
Internet-Draft RADIUS Attribute Guidelines June 2006
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Divergent Data Models . . . . . . . . . . . . . . . . . . 4
3.2. Attribute Space Exhaustion . . . . . . . . . . . . . . . . 5
3.3. Diameter Alignment . . . . . . . . . . . . . . . . . . . . 5
4. Current Data Model . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. General Attribute Format . . . . . . . . . . . . . . . . . 6
4.3. Tagging Mechanism . . . . . . . . . . . . . . . . . . . . 7
4.4. Vendor-Specific Attribute Format . . . . . . . . . . . . . 7
4.5. Value Packing . . . . . . . . . . . . . . . . . . . . . . 8
5. Data Model Features in the Vendor Space . . . . . . . . . . . 8
5.1. Grouping . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Attribute Encryption . . . . . . . . . . . . . . . . . . . 8
5.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 9
6. Scope and Solution Characteristics . . . . . . . . . . . . . . 9
6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 9
6.1.1. Intermediate Nodes . . . . . . . . . . . . . . . . . . 9
6.1.2. Dictionary-based Implementations . . . . . . . . . . . 9
6.1.3. Unaware Endpoints . . . . . . . . . . . . . . . . . . 10
6.2. Existing Vendor-Specific Attribute Usage . . . . . . . . . 10
6.3. Transport Impact . . . . . . . . . . . . . . . . . . . . . 10
6.4. Non-AAA Applications . . . . . . . . . . . . . . . . . . . 10
6.5. Diameter Compatibility . . . . . . . . . . . . . . . . . . 10
6.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Deviation from Standard Practice . . . . . . . . . . . . . 11
7.2. Structured Data . . . . . . . . . . . . . . . . . . . . . 11
7.3. Additional Guidance . . . . . . . . . . . . . . . . . . . 11
8. Diameter Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Weber Expires December 28, 2006 [Page 2]
Internet-Draft RADIUS Attribute Guidelines June 2006
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introduction
The Remote Authentication Dial In User Service (RADIUS) protocol
[RFC2865] [RFC2866] uses an attribute paradigm as the basis for
representing authentication, authorization and accounting (AAA) data.
RADIUS messages exchanged between client and server contain lists of
similarly formatted attributes.
Unlike SNMP [RFC1157] [RFC1155], RADIUS does not use a formal data
definition language to describe its attributes or attribute formats.
A handful of basic data types are provided, and a data type is
associated with a particular attribute when that attribute is
defined.
Two distinct attribute spaces are defined: the standard space, and a
vendor specific space. Attributes in the standard space generally
are composed of a type, length, value (TLV) triplet. The vendor
specific space is encapsulated within a single attribute type
(Vendor-Specific Attribute or VSA). The format of this space is
defined by individual vendors, but the same TLV encoding used by the
standard space is recommended.
The similarity between attribute formats has enabled implementations
to leverage a common parsing functionality, though attributes in the
vendor specific space have begun to diverge in some cases from use of
the common formatting. In addition, many new attributes in the
vendor specific space are actually not intended to be vendor specific
at all, such as those attributes defined by Standards Development
Organizations (SDOs) outside the IETF, e.g. the 3rd Generation
Partnership Project (3GPP). Perhaps a contributing factor in the
SDOs' decision to use the vendor specific space, is that the standard
attribute space is limited to approximately 250 unique attributes; of
these, only about half remain available for allocation. In the
vendor specific space, the number of attributes available is a
function of the format of the attribute (the size of the type field).
This document analyzes some of the issues around rationalizing the
RADIUS attribute data model and recommends extending the model to
allow more alignment between the standard and vendor attribute
spaces. The extension mechanism, defined in [EXTATTR], is in the
form of a new RADIUS attribute which accommodates some of the
Weber Expires December 28, 2006 [Page 3]
Internet-Draft RADIUS Attribute Guidelines June 2006
features that have evolved over time in the vendor space including
attribute grouping and an expanded attribute number space.
This document also analyzes the usage of the basic data types defined
in [RFC2865] and [RFC2866], together with the ad-hoc extensions to
that data model that have been used in VSAs. A proposal is included
for additional base data types, as well as the formation of complex
or structured data types, in a standard way. This recommendation
leads to a more regular, if not formal, data model for all RADIUS
attributes. These recommendations are made for both the traditional
and the extended RADIUS attribute formats.
Part of the intention of this work is to create a reference that may
be used by future IETF RADIUS attribute designers and by other SDOs
that work with RADIUS. The guidelines presented here may also be
used to facilitate the "Expert Review" process for reviewing RADIUS
work described in [RFC3575].
3. Motivation
Since the closure of the IETF's RADIUS Working Group, the popularity
and prevalence of RADIUS usage has continued to grow and is now
commonly applied to various access media in addition to dial in
access. The large number of vendors and SDOs developing and
providing RADIUS-based solutions has led to some technical
splintering in the approach to RADIUS attribute design.
3.1. Divergent Data Models
In particular, the data model covering the standard RADIUS attributes
is much more constrained than the data model for vendor space
attributes. Vendors have evolved the data model they use to support
new functions like attribute grouping and attribute fragmentation.
Multiple methods have been developed to achieve these desirable
features.
There is no motivation for vendors or SDOs to move generally useful
attributes from the vendor space to the more stringent standard
space, so the data models continue to diverge.
One of RADIUS's design goals was that new attributes should be able
to be added without modifying the client or server core protocol
parsing code. As attributes continue to take on new formats, this
advantage will fade. Many implementations of RADIUS servers use a
data dictionary driven parser implementation. Attribute formats that
do not follow established conventions often break the ability to add
new attributes to servers by adding their definitions to the data
Weber Expires December 28, 2006 [Page 4]
Internet-Draft RADIUS Attribute Guidelines June 2006
dictionary.
In addition, more attribute-specific parsing means more complex
software to develop and maintain, and more complexity may lead to
more error prone implementations.
3.2. Attribute Space Exhaustion
Another impending problem is that eventually the standard attribute
space may become depleted over time. The type code field for
standard attributes is one octet, so a maximum of 255 attributes may
be defined; approximately half of which are currently unallocated.
3.3. Diameter Alignment
Section 9 of [RFC4005] describes RADIUS/Diameter interactions. While
Diameter [RFC3588] has much more functionality than RADIUS [RFC2865],
it may facilitate interoperation to align the RADIUS and Diameter
data models at least at some basic level.
4. Current Data Model
The following subsections describe how RADIUS data are typed and
formatted according to the current specification set. Some
exceptions to the rules are identified.
4.1. Data Types
RADIUS attributes are typed by reference. In other words, the data
type of a particular attribute is fixed when that attribute is
defined. The data type information is not transported on the wire.
The reference to the attribute type allows RADIUS entities to know
the data type because typically, each RADIUS entity has access to a
dictionary or some other mechanism describing all defined attributes.
The RADIUS specifications define these data types:
text 1-253 octets containing UTF-8 encoded 10646 [RFC2279]
characters. Text of length zero (0) MUST NOT be sent; omit
the entire attribute instead.
string 1-253 octets containing binary data (values 0 through 255
decimal, inclusive). Strings of length zero (0) MUST NOT
be sent; omit the entire attribute instead.
Weber Expires December 28, 2006 [Page 5]
Internet-Draft RADIUS Attribute Guidelines June 2006
address 32 bit value, most significant octet first.
integer 32 bit unsigned value, most significant octet first.
time 32 bit unsigned value, most significant octet first --
seconds since 00:00:00 UTC, January 1, 1970. The standard
Attributes do not use this data type but it is presented
here for possible use in future attributes
The current specifications do not always adhere to specifying a data
type from this set.
For example, in the attribute definition for Framed-Interface-Id
(from [RFC3162]), the data type is not given; the value is simply
defined as an 8 octet value.
Likewise in the definition of CHAP-Password (from [RFC2865]), the
data type of the CHAP Identifier is not given, only the one octet
length.
As you can see, in some cases the data are described textually. This
is possible because the data types are not sent inside the
attributes. They are largely a matter for endpoint interpretation.
In fact, an implementation could define additional data types, say
for example, for IPv6 address, and use these data types today by
matching them to the attribute's textual description.
In fact, some RADIUS implementations treat tagged attributes (see
section 4.3) as an additional data type.
4.2. General Attribute Format
The attribute TLV encoding is summarized in [RFC2865] as:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
However, some standard attributes do not follow this format. The
definition of CHAP-Password above demonstrates this inconsistency.
Similarly, the ARAP-Password attribute definition (from [RFC2869]),
instead of having a single Value field, contains four 4-octet values.
In general, these types of multi-valued attributes may treat the
concatenation of all the values as a String data type field.
However, separating these values into different attributes, each with
its own type and length, would enable additional error checking and
would simplify implementations by eliminating special case, attribute
Weber Expires December 28, 2006 [Page 6]
Internet-Draft RADIUS Attribute Guidelines June 2006
specific parsing.
4.3. Tagging Mechanism
[RFC2868] defines an attribute grouping mechanism based on the use of
a one octet tag value. Tunnel attributes that refer to the same
tunnel are grouped together by virtue of using the same tag value.
This tagging mechanism has some drawbacks. There are a limited
number of unique tags (31). The tags are not well suited for use
with arbitrary binary data values because it is not always possible
to tell if the first byte after the Length is the tag or the first
byte of the untagged value (assuming the tag is optional).
When integer values are tagged, the value portion is reduced to three
bytes meaning only 24-bit numbers can be represented.
The tagging mechanism does not offer an ability to create nested
groups of attributes.
4.4. Vendor-Specific Attribute Format
[RFC2865] allows each vendor to define its own attribute space under
the Vendor-Specific attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
The format of data in the String field of Vendor-Specific attributes
is under each vendor's control, but the specification advises that
this field SHOULD be encoded as show below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Multiple sub-attributes MAY be encoded within a single Vendor-
Weber Expires December 28, 2006 [Page 7]
Internet-Draft RADIUS Attribute Guidelines June 2006
Specific attribute, although they do not have to be.
Allowing multiple sub-attributes does provide a form of grouping.
4.5. Value Packing
Some attributes pack multiple data items into a single attribute
value field. For example, the Connect-Info attribute defined in
[RFC2869] may contain values like "28800 V42BIS/LAPM" or "52000/31200
V90".
Encoding multiple values within a Text attribute reduces the amount
of data validation that can be performed when the attribute is first
encountered. This particular attribute is used in Access-Request
messages. If authorization decisions are based on connection speed
information, it would perhaps be better to validate it separately
from the remainder of the Text attribute.
5. Data Model Features in the Vendor Space
Vendors, of course, are under no obligation to publish their
proprietary usages of RADIUS. Through SDOs, however, we can see some
of the RADIUS usages that have developed in the vendor space.
5.1. Grouping
Various strategies and justifications for organizing attribute data
into groups have proven popular. The most common of these is
probably the sub-attribute scheme introduced in the Vendor-Specific
format recommendation. Another method is to concatenate multiple
values into a single String or Text attribute.
Here are some of the reasons given for grouping attributes:
o Compactness - As with bit flags or multiply valued attributes,
e.g. a list of IP addresses.
o Logical Relationship - For attributes which describe multiple
aspects of a single entity or which have interdependencies.
o Shared Information - As with a group of attributes related to a
single timestamp or remote IP address.
5.2. Attribute Encryption
Some legal environments restrict particular types of data from being
transmitted in clear text. Some vendors have developed means of
encrypting particular RADIUS attributes within messages for use in
deployments where the operators want to avoid various deployment
Weber Expires December 28, 2006 [Page 8]
Internet-Draft RADIUS Attribute Guidelines June 2006
issues related to IPsec [RFC4301].
5.3. Fragmentation
Several different methods are in use to handle attributes which
exceed the 253 octet length limit. One vendor has specified use of
multiple attributes with an embedded sequence number to transfer MS-
CHAP-LM-Enc-PW (as described in [RFC2548]). One SDO uses multiple
attributes, requiring them to be consecutive but without embedded
sequence info (see Section 13.1.5.2 in [PKT-SP-EM1.5]) to transfer
several large attributes.
6. Scope and Solution Characteristics
These subsections describe the desirable scope of any recommended
changes to make the RADIUS data model more uniform.
6.1. Backwards Compatibility
It is imperative that any changes to the data model do not impact
functioning deployments.
6.1.1. Intermediate Nodes
RADIUS deployments can include complex proxy architectures.
Intermediate nodes may be under separate administrative or
operational control from the endpoint client and server. In these
scenarios it would not be likely that intermediate nodes would make
software or configuration changes to support new functionality at the
endpoints.
Any data model changes should be transparent to intermediate nodes.
This means no changes in wire formats outside the value portion of
attributes.
6.1.2. Dictionary-based Implementations
Support for structured data or attribute groupings would likely
impact dictionary-based implementations. Typically, such an
implementation would use the attribute type as an index into a single
description of the attribute.
There is some precedent for requiring software changes to deploy new
RADIUS functionality. This happened with the addition of tagged
attribute support and the dynamic authorization extensions [RFC3576].
Weber Expires December 28, 2006 [Page 9]
Internet-Draft RADIUS Attribute Guidelines June 2006
6.1.3. Unaware Endpoints
Any changes must recognize the fact that any combination of client or
server might not understand the new functionality. That said, this
document will not address the idea of capability negotiation or
advertisement. This would seem to be a problem common to other
features and should be addressed separately.
6.2. Existing Vendor-Specific Attribute Usage
No new, retroactive requirements should be placed on vendors with
regard to existing use of Vendor-Specific attributes. However,
recommendations may be made for SDOs specifying attributes intended
for use by multiple vendors.
6.3. Transport Impact
No changes will be made to the RADIUS transport or (related) maximum
packet sizes.
6.4. Non-AAA Applications
This document is not targeted at non-AAA applications which use
RADIUS as a transport such as the Extensible Authentication Protocol
(EAP) [RFC3748] [RFC3579]. These applications do not need to conform
to the RADIUS data model as the RADIUS client and server are not the
real endpoints of such conversations. For AAA applications, however,
the RADIUS data model should not be circumvented; RADIUS is not
intended as a generalized "carrier protocol".
6.5. Diameter Compatibility
Changes to the RADIUS data model should be Diameter-friendly. It is
not the intent to reproduce all or even significant Diameter
functionality, or to support all Diameter applications via RADIUS.
Ensuring that the data models are somewhat aligned, however, will
facilitate the work of Translation Agents for common applications
(see section 2.8.4 of [RFC3588]).
6.6. Security
This document does not define any new security mechanisms to protect
RADIUS attribute content, though there may be future IETF work in
this area. See Section 10 for further information.
7. Guidelines
Weber Expires December 28, 2006 [Page 10]
Internet-Draft RADIUS Attribute Guidelines June 2006
These guidelines apply to all future RADIUS work, including both
traditional standard space attributes and attributes which make use
of the extension mechanism specified in [EXTATTR].
7.1. Deviation from Standard Practice
In general, new attributes SHOULD comply with the attribute design
guidelines given in [RFC2865] unless one or more of the following
applies:
o The standard attribute space for new attributes has been
exhausted.
o The proposed maximum attribute length exceeds that available for
attributes specified by [RFC2865].
o The native data type of the data element is defined by [EXTATTR]
but not [RFC2865].
o Structured data must be explicitly represented (as discussed in
Section 7.2).
7.2. Structured Data
As mentioned in Section 5.1, logically grouping data within RADIUS
messages has been a popular feature within the individual vendor
attribute spaces. The guidance for when to use which mechanism to
affect the logical grouping of data depends on the intended consumer
of the attribute values.
Intended consumers of RADIUS attributes include:
1. Humans: consume attributes intended to aid in troubleshooting and
operational problem determination.
2. Billing: accounting data are typically consumed by a business
mediation layer in preparation for billing systems.
3. Non-RADIUS authorization applications: these entities include
policy servers, EAP servers, and other consumers of data which
are typically opaque to RADIUS servers and proxies.
4. RADIUS servers and proxies: parse and operate on individual
elements within RADIUS messages.
Attributes designed to be consumed or parsed by RADIUS servers and
proxies SHOULD explicitly represent their structured data using the
extension mechanism specified in [EXTATTR]. Attributes designed to
be consumed by the other entities above may use the existing
mechanisms to group or structure data such as overloading String
values.
7.3. Additional Guidance
In the cases from Section 7.1, it is RECOMMENDED that the extended
attribute encoding specified by [EXTATTR] be used.
Weber Expires December 28, 2006 [Page 11]
Internet-Draft RADIUS Attribute Guidelines June 2006
Additionally, it is RECOMMENDED that:
1. The Vendor-Specific Enumeration (VSE) encoding mechanism as
proposed by Section 2.2.1 of [RFC2882] SHOULD NOT be used.
Instead, vendors should comply with the recommendations of
[RFC3575]
2. The message lengths specified by RADIUS standards MUST NOT be
exceeded.
3. Variable attribute content SHOULD NOT be specified. Separate
attributes SHOULD be defined instead.
4. SDOs are RECOMMENDED to design attributes using the guidelines in
this document 'as if' they were destined for the standard
attribute space, but of course, may continue to implement new
attributes in their own attributes spaces.
8. Diameter Considerations
This document defines guidelines for RADIUS attribute design, but
does not specify any new attributes. As such, there are no Diameter
considerations other than those already specified by section 9 of
[RFC4005].
See section 3 of [EXTATTR] for the Diameter considerations related to
using the extended RADIUS attribute space.
9. IANA Considerations
This document does not allocate any new values from IANA registries.
10. Security Considerations
This document does not specify any new functionality. The security
considerations related to using RADIUS are discussed in [RFC2865] and
section 4.2 of [RFC3579].
The security recommendations in [RFC3579] are based on usage of IPsec
[RFC4301]. In some common implementations of IPsec for particular
operating systems, applications and higher layer protocols do not
have the ability to determine if the underlying security support is
in place and functioning correctly. For RADIUS, this may result in
an inability for RADIUS clients and servers to determine whether the
security recommendations in [RFC3579] are being met.
As mentioned in Section 5.2, encrypting RADIUS data on a per-
attribute basis is desirable for some deployments. The current
Weber Expires December 28, 2006 [Page 12]
Internet-Draft RADIUS Attribute Guidelines June 2006
standard mechanism for doing this is described in Section 5.2 of
[RFC2865] (for obscuring User-Password values) and is based on the
MD5 algorithm specified in [RFC1321]. The MD5 algorithm has recently
become a focus of scrutiny and concern in security circles. Future
IETF work will likely include the ability for RADIUS to support
alternative algorithms. When or if stronger algorithms are supported
by RADIUS in the future, that work should be leveraged to provide
stronger support for per-attribute encryption as well.
11. References
11.1. Normative References
[EXTATTR] Wolff, B. and G. Weber, "Extended RADIUS Attributes",
draft-wolff-radext-ext-attribute-00 (work in progress),
March 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000.
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
Extensions", RFC 2869, June 2000.
[RFC2882] Mitton, D., "Network Access Servers Requirements: Extended
RADIUS Practices", RFC 2882, July 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575,
July 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Weber Expires December 28, 2006 [Page 13]
Internet-Draft RADIUS Attribute Guidelines June 2006
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
August 2005.
11.2. Informative References
[PKT-SP-EM1.5]
CableLabs PacketCable Project, "Event Messages",
PacketCable Specifications 1.5, January 2005.
[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification
of management information for TCP/IP-based internets",
STD 16, RFC 1155, May 1990.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", STD 15,
RFC 1157, May 1990.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 3576,
July 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
Appendix A. Acknowledgments
Many of the issues discussed in this document are a distillation of
email threads on the RADEXT WG list which is archived here:
http://ops.ietf.org/lists/radiusext/
Weber Expires December 28, 2006 [Page 14]
Internet-Draft RADIUS Attribute Guidelines June 2006
Informal discussions with Barney Wolff, Alan DeKok, Dave Nelson, and
Emile van Bergen aided immensely in formulating and refining the
ideas in this document.
Weber Expires December 28, 2006 [Page 15]
Internet-Draft RADIUS Attribute Guidelines June 2006
Author's Address
Greg Weber
Cisco Systems
10850 Murdock Road
Knoxville, TN 37932
USA
Email: gdweber@cisco.com
Weber Expires December 28, 2006 [Page 16]
Internet-Draft RADIUS Attribute Guidelines June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Weber Expires December 28, 2006 [Page 17]
