draft-ietf-radext-design-05.txt   draft-ietf-radext-design-06.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-05.txt> FreeRADIUS <draft-ietf-radext-design-06.txt> FreeRADIUS
Expires: February 26, 2009 Expires: August 24, 2009
26 August 2008 24 February 2009
RADIUS Design Guidelines RADIUS Design Guidelines
draft-ietf-radext-design-05.txt draft-ietf-radext-design-06.txt
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 January 7, 2009. This Internet-Draft will expire on August 24, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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
1. Introduction ............................................. 4 1. Introduction ............................................. 5
1.1. Applicability ....................................... 4 1.1. Applicability ....................................... 5
1.2. Terminology ......................................... 5 1.2. Terminology ......................................... 6
1.3. Requirements Language ............................... 5 1.3. Requirements Language ............................... 7
2. RADIUS Data Model ........................................ 5 2. RADIUS Data Model ........................................ 7
2.1. Standard Space ...................................... 6 2.1. Standard Space ...................................... 7
2.1.1. Basic Data Types ............................... 6 2.1.1. Basic Data Types ............................... 7
2.1.2. Tagging Mechanism .............................. 7 2.1.2. Tagging Mechanism .............................. 9
2.1.3. Complex Attribute Usage ........................ 8 2.1.3. Complex Attribute Usage ........................ 9
2.1.4. Complex Attributes and Security ................ 10 2.1.4. Complex Attributes and Security ................ 12
2.1.5. Service definitions and RADIUS ................. 11 2.1.5. Service definitions and RADIUS ................. 12
2.2. Extended RADIUS Attributes .......................... 11 2.2. Extended RADIUS Attributes .......................... 13
2.3. Vendor Space ........................................ 12 2.3. Vendor Space ........................................ 13
3. Data Model Issues ........................................ 13 3. Data Model Issues ........................................ 14
3.1. Vendor Space ........................................ 14 3.1. Vendor Space ........................................ 15
3.1.1. Interoperability Considerations ................ 16 3.1.1. Interoperability Considerations ................ 17
3.1.2. Vendor Allocations ............................. 16 3.1.2. Vendor Allocations ............................. 18
3.1.3. SDO Allocations ................................ 17 3.1.3. SDO Allocations ................................ 18
3.1.4. Publication of specifications .................. 17 3.1.4. Publication of specifications .................. 19
3.2. Polymorphic Attributes .............................. 18 3.2. Polymorphic Attributes .............................. 19
3.3. RADIUS Operational Model ............................ 18 3.3. RADIUS Operational Model ............................ 20
4. IANA Considerations ...................................... 21 4. IANA Considerations ...................................... 22
5. Security Considerations .................................. 21 5. Security Considerations .................................. 23
6. References ............................................... 22 6. References ............................................... 24
6.1. Normative References ................................ 22 6.1. Normative References ................................ 24
6.2. Informative References .............................. 22 6.2. Informative References .............................. 24
Appendix A - Design Guidelines ............................... 25 Appendix A - Design Guidelines ............................... 27
A.1. Types matching the RADIUS data model ................. 25 A.1. Types matching the RADIUS data model ................. 27
A.1.1. Transport of simple data ........................ 25 A.1.1. Transport of simple data ........................ 27
A.1.2. Extended data types ............................. 25 A.1.2. Extended data types ............................. 27
A.1.3. Opaque data types ............................... 26 A.1.3. Opaque data types ............................... 28
A.2. Improper Data Types .................................. 26 A.2. Improper Data Types .................................. 28
A.2.1. Simple Data Types ............................... 26 A.2.1. Simple Data Types ............................... 28
A.2.2. Complex Data Types .............................. 27 A.2.2. Complex Data Types .............................. 29
A.3. Vendor-Specific formats .............................. 27 A.3. Vendor-Specific formats .............................. 29
A.4. Changes to the RADIUS Operational Model .............. 28 A.4. Changes to the RADIUS Operational Model .............. 30
A.5. Allocation of attributes ............................. 29 A.5. Allocation of attributes ............................. 31
Appendix B - Complex Attributes .............................. 30 Appendix B - Complex Attributes .............................. 32
B.1. CHAP-Password ........................................ 30 B.1. CHAP-Password ........................................ 32
B.2. CHAP-Challenge ....................................... 30 B.2. CHAP-Challenge ....................................... 32
B.3. Tunnel-Password ...................................... 30 B.3. Tunnel-Password ...................................... 32
B.4. ARAP-Password ........................................ 31 B.4. ARAP-Password ........................................ 33
B.5. ARAP-Features ........................................ 31 B.5. ARAP-Features ........................................ 33
B.6. Connect-Info ......................................... 32 B.6. Connect-Info ......................................... 34
B.7. Framed-IPv6-Prefix ................................... 32 B.7. Framed-IPv6-Prefix ................................... 35
B.8. Egress-VLANID ........................................ 33 B.8. Egress-VLANID ........................................ 35
B.9. Egress-VLAN-Name ..................................... 34 B.9. Egress-VLAN-Name ..................................... 36
Full Copyright Statement ..................................... 35
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 SDOs. By articulating
Organizations (SDOs). By articulating RADIUS design guidelines, it RADIUS design guidelines, it is hoped that this document will
is hoped that this document will encourage the development and encourage the development and publication of high quality RADIUS
publication of high quality RADIUS attribute specifications. 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
requesting review (such as an "Expert Review" described in requesting review (such as an "Expert Review" described in
[RFC3575]). Similarly, it is expected that this document will used [RFC3575]). Similarly, it is expected that this document will used
by reviewers (such as WG participants or the AAA Doctors [DOCTORS]), by reviewers (such as WG participants or the AAA Doctors [DOCTORS]),
resulting in an improvement in the consistency of reviews. 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
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,
its 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 out of the IETF to design their own RADIUS attributes
Specific Attribute (VSA) space, seeking review from the IETF. In within the Vendor-Specific Attribute (VSA) space.
order to enable IETF review of SDO RADIUS attribute specifications,
the authors recommend that: It is RECOMMENDED that SDOs follow the guidelines articulated in this
document. Doing so will ensure the widest possible applicability and
interoperability of the specifications, while requiring minimal
changes to existing systems. Specifications that do not follow the
guidelines articulated herein or in [EXTEN] are NOT RECOMMENDED.
However, we recognize that there are some situations where SDOs or
vendors require the creation of specifications not following these
guidelines. We do not forbid these specifications, but it is
RECOMMENDED that they are created only if they have a limited scope
of applicability, and all attributes defined in those specifications
are VSAs, as discussed Section A.5, below.
It is RECOMMENDED that SDOs and vendors seek review of RADIUS
attribute specifications from the IETF. However, when specifications
are SDO specific, re-use existing data types, and follow these
guidelines, they do not require IETF review.
In order to enable IETF review of such specifications, the authors
recommend that:
* SDOs make their RADIUS attribute specifications publicly * SDOs make their RADIUS attribute specifications publicly
available; available;
* SDOs request review of RADIUS attribute specifications by * SDOs request review of RADIUS attribute specifications by
sending email to the AAA Doctors [DOCTORS] or equivalent mailing sending email to the AAA Doctors [DOCTORS] or equivalent mailing
list; list;
* IETF and SDO RADIUS attribute specifications are reviewed * IETF and SDO RADIUS attribute specifications are reviewed
according to the guidelines proposed in this document; according to the guidelines proposed in this document;
* Reviews of specifications are posted to the RADEXT WG mailing * Reviews of specifications are posted to the RADEXT WG mailing
list, the AAA Doctors mailing list [DOCTORS] or another IETF list, the AAA Doctors mailing list [DOCTORS] or another IETF
mailing list suggested by the Operations & Management Area mailing list suggested by the Operations & Management Area
Directors of the IETF. Directors of the IETF.
These reviews can assist with creation of specifications that meet
the SDO requirements, and which are also compatible with the
traditional data model and uses of RADIUS. While these reviews
require access to public specifications, the review process does not
require publication of an IETF RFC.
The advice in this document applies to attributes used to encode The advice in this document applies to attributes used to encode
service-provisioning or authentication data. RADIUS protocol service-provisioning or authentication data. RADIUS protocol
changes, or specification of attributes (such as Service-Type) that changes, or specification of attributes (such as Service-Type) that
can be used to, in effect, provide new RADIUS commands require can be used to, in effect, provide new RADIUS commands require
greater expertise and deeper review, as do changes to the RADIUS greater expertise and deeper review, as do changes to the RADIUS
operational model, as described in Section 3.3 . Such changes should operational model, as described in Section 3.3 . Such changes SHOULD
not be undertaken outside the IETF and when handled within the IETF NOT be undertaken outside the IETF and when handled within the IETF
require "IETF Consensus" for adoption, as noted in [RFC3575] Section require "IETF Consensus" for adoption, as noted in [RFC3575] Section
2.1. 2.1.
1.2. Terminology 1.2. 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.
skipping to change at page 7, line 49 skipping to change at page 9, line 21
[RFC2868] defines an attribute grouping mechanism based on the use of [RFC2868] defines an attribute grouping mechanism based on the use of
a one octet tag value. Tunnel attributes that refer to the same a one octet tag value. Tunnel attributes that refer to the same
tunnel are grouped together by virtue of using the same tag value. tunnel are grouped together by virtue of using the same tag value.
This tagging mechanism has some drawbacks. There are a limited This tagging mechanism has some drawbacks. There are a limited
number of unique tags (31). The tags are not well suited for use number of unique tags (31). The tags are not well suited for use
with arbitrary binary data values, because it is not always possible with arbitrary binary data values, because it is not always possible
to tell if the first byte after the Length is the tag or the first to tell if the first byte after the Length is the tag or the first
byte of the untagged value (assuming the tag is optional). byte of the untagged value (assuming the tag is optional).
Other limitations of the tagging mechaism are that when integer Other limitations of the tagging mechanism are that when integer
values are tagged, the value portion is reduced to three bytes values are tagged, the value portion is reduced to three bytes
meaning only 24-bit numbers can be represented. The tagging meaning only 24-bit numbers can be represented. The tagging
mechanism does not offer an ability to create nested groups of mechanism does not offer an ability to create nested groups of
attributes. Some RADIUS implementations treat tagged attributes as attributes. Some RADIUS implementations treat tagged attributes as
having additional data types tagged-string and tagged-integer. These having additional data types tagged-string and tagged-integer. These
types increase the complexity of implementing and managing RADIUS types increase the complexity of implementing and managing RADIUS
systems. systems.
New attributes SHOULD NOT use this tagging method because of the New attributes SHOULD NOT use this tagging method because of the
limitations described above. New attributes SHOULD use the grouping limitations described above. New attributes SHOULD use the grouping
skipping to change at page 8, line 45 skipping to change at page 10, line 17
* 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
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.
One of the fundamental goals of the RADIUS protocol design was to One of the fundamental goals of the RADIUS protocol design was to
allow RADIUS servers to be configured to support new attributes allow RADIUS servers to be configured to support new attributes
without requiring server code changes. RADIUS server implementations without requiring server code changes. RADIUS server implementations
typically use provide support for basic data types, and define typically provide support for basic data types, and define attributes
attributes in a data dictionary. This architecture enables a new in a data dictionary. This architecture enables a new attribute to
attribute to be supported by the addition of a dictionary entry, be supported by the addition of a dictionary entry, without requiring
without requiring RADIUS server code changes. RADIUS server code changes.
On the RADIUS client, code changes are typically required in order to On the RADIUS client, code changes are typically required in order to
implement a new attribute. The RADIUS client typically has to implement a new attribute. The RADIUS client typically has to
compose the attribute dynamically when sending. When receiving, a compose the attribute dynamically when sending. When receiving, a
RADIUS client needs to be able to parse the attribute and carry out RADIUS client needs to be able to parse the attribute and carry out
the requested service. As a result, a detailed understanding of the the requested service. As a result, a detailed understanding of the
new attribute is required on clients, and data dictionaries are less new attribute is required on clients, and data dictionaries are less
useful on clients than on servers. useful on clients than on servers.
Given these considerations, the introduction of a new basic or Given these considerations, the introduction of a new basic or
skipping to change at page 9, line 36 skipping to change at page 11, line 8
limited operations (such as comparisons or arithmetic operations) on limited operations (such as comparisons or arithmetic operations) on
the basic data types. Many existing RADIUS policy languages the basic data types. Many existing RADIUS policy languages
typically are not capable of parsing sub-elements, or providing typically are not capable of parsing sub-elements, or providing
sophisticated matching functionality. 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, More complexity can lead to more error prone implementations,
interoperatibility problems, and even security vulnerabilities. interoperability problems, and even security vulnerabilities. These
These issues can increase costs to network administrators as well as issues can increase costs to network administrators as well as
reducing reliability and introducing deployment barriers. As a reducing reliability and introducing deployment barriers. As a
result, the introduction of new complex data types within RADIUS result, the introduction of new complex data types within RADIUS
attribute specifications SHOULD be avoided, except in the case of attribute specifications SHOULD be avoided, except in the case of
complex attributes involving authentication or security complex attributes involving authentication or security
functionality. functionality.
As can be seen in Appendix B, most of the existing complex attributes As can be seen in Appendix B, most of the existing complex attributes
involve authentication or security functionality. Supporting this involve 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
skipping to change at page 14, line 33 skipping to change at page 16, line 4
6.2: 6.2:
Note that RADIUS defines a mechanism for Vendor-Specific Note that RADIUS defines a mechanism for Vendor-Specific
extensions (Attribute 26) and the use of that should be encouraged extensions (Attribute 26) and the use of that should be encouraged
instead of allocation of global attribute types, for functions instead of allocation of global attribute types, for functions
specific only to one vendor's implementation of RADIUS, where no specific only to one vendor's implementation of RADIUS, where no
interoperability is deemed useful. interoperability is deemed useful.
Nevertheless, many new attributes have been defined in the vendor Nevertheless, many new attributes have been defined in the vendor
specific space in situations where interoperability is not only specific space in situations where interoperability is not only
useful, but is required. For example, Standards Development useful, but is required. For example, SDOs outside the IETF (such as
Organizations (SDOs) outside the IETF (such as the IEEE 802 and the the IEEE 802 and the 3rd Generation Partnership Project (3GPP)) have
3rd Generation Partnership Project (3GPP)) have been assigned Vendor- been assigned Vendor-Ids, enabling them to define their own VSA
Ids, enabling them to define their own VSA format and assign Vendor format and assign Vendor types within their own space.
types within their own space.
The use of VSAs by SDOs outside the IETF has gained in popularity for The use of VSAs by SDOs outside the IETF has gained in popularity for
several reasons: several reasons:
Efficiency Efficiency
As with SNMP, which defines an "Enterprise" Object Identifier (OID) As with SNMP, which defines an "Enterprise" Object Identifier (OID)
space suitable for use by vendors as well as other SDOs, the space suitable for use by vendors as well as other SDOs, the
definition of Vendor-Specific RADIUS attributes has become a common definition of Vendor-Specific RADIUS attributes has become a common
occurrence as part of standards activity outside the IETF. For occurrence as part of standards activity outside the IETF. For
reasons of efficiency, it is easiest if the RADIUS attributes reasons of efficiency, it is easiest if the RADIUS attributes
required to manage a standard are developed within the same SDO required to manage a standard are developed within the same SDO
that develops the standard itself. As noted in "Transferring MIB that develops the standard itself. As noted in "Transferring MIB
Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few
vendors are willing to simultaneously fund individuals to vendors are willing to simultaneously fund individuals to
participate within an SDO to complete a standard, as well as to participate within an SDO to complete a standard, as well as to
participate in IETF in order to complete the associated RADIUS participate in the IETF in order to complete the associated RADIUS
attributes specification. attributes specification.
Attribute scarcity Attribute scarcity
The standard RADIUS attribute space is limited to 255 unique The standard RADIUS attribute space is limited to 255 unique
attributes. Of these, only about half remain available for attributes. Of these, only about half remain available for
allocation. In the Vendor-Specific space, the number of attributes allocation. In the Vendor-Specific space, the number of attributes
available is a function of the format of the attribute (the size of available is a function of the format of the attribute (the size of
the Vendor type field). the Vendor type field).
Along with these advantages, some limitations of VSA usage are noted Along with these advantages, some limitations of VSA usage are noted
skipping to change at page 15, line 41 skipping to change at page 17, line 11
However, the requirement for clients and servers to be able to However, the requirement for clients and servers to be able to
operate in the absence of VSAs has proven to be less of a constraint, operate in the absence of VSAs has proven to be less of a constraint,
since it is still possible for a RADIUS client and server to mutually since it is still possible for a RADIUS client and server to mutually
indicate support for VSAs, after which behavior expectations can be indicate support for VSAs, after which behavior expectations can be
reset. reset.
Therefore, RFC 2865 provides considerable latitude for development of Therefore, RFC 2865 provides considerable latitude for development of
new attributes within the vendor space, while prohibiting development new attributes within the vendor space, while prohibiting development
of protocol variants. This flexibility implies that RADIUS of protocol variants. This flexibility implies that RADIUS
attributes can often be developed within the vendor space without attributes can often be developed within the vendor space without
loss (and possibly even 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 standards 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.
skipping to change at page 16, line 43 skipping to change at page 18, line 13
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 SSAs or VSAs for multi-vendor usage. RADIUS attributes also apply to SSAs or VSAs for multi-vendor usage.
3.1.2. Vendor Allocations 3.1.2. Vendor Allocations
Vendor RADIUS Attribute specifications SHOULD allocate attributes Vendor RADIUS Attribute specifications SHOULD allocate attributes
from the vendor space, rather than requesting an allocation from the from the vendor space, rather than requesting an allocation from the
RADIUS standard attribute space. RADIUS standard attribute space.
As discussed in [RFC2865] Section 5.26, the vendor space is intended As discussed in [RFC2865] Section 5.26, the vendor space is intended
for vendors to support their own extended attributes not suitable for for vendors to support their own Attributes not suitable for general
general use. However, it is RECOMMENDED that vendors follow the use. However, it is RECOMMENDED that vendors follow the guidelines
guidelines outlined here, which are intended to enable maximum outlined here, which are intended to enable maximum interoperability
interoperability with minimal changes to existing systems. with minimal changes to existing systems.
Following these guidelines means that RADIUS servers can be updated Following these guidelines means that RADIUS servers can be updated
to support the vendor's equipment by editing a RADIUS dictionary. If to support the vendor's equipment by editing a RADIUS dictionary. If
these guidelines are not followed, then the vendor's equipment can these guidelines are not followed, then the vendor's equipment can
only be supported via code changes in RADIUS server implementations. only be supported via code changes in RADIUS server implementations.
Such code changes add complexity and delay to implementations. Such code changes add complexity and delay to implementations.
3.1.3. SDO Allocations 3.1.3. SDO Allocations
SDO RADIUS Attribute specifications SHOULD allocate attributes from SDO RADIUS Attribute specifications SHOULD allocate attributes from
skipping to change at page 17, line 46 skipping to change at page 19, line 17
Rehosting puts pressure on the standards space, and may be harmful to Rehosting puts pressure on the standards space, and may be harmful to
interoperability, since it can create two ways to provision the same interoperability, since it can create two ways to provision the same
service. Rehosting may also require changes to the RADIUS data model service. Rehosting may also require changes to the RADIUS data model
which will affect implementations that do not intend to support the which will affect implementations that do not intend to support the
SDO specifications. SDO specifications.
3.1.4. Publication of specifications 3.1.4. Publication of specifications
SDOs are encouraged to seek early review of SSA specifications by the SDOs are encouraged to seek early review of SSA specifications by the
IETF. This review may be initiated by sending mail to the AAA IETF. This review may be initiated by sending mail to the AAA
Doctors list [DOCTORS]. Since the IETF is not a membership Doctors list [DOCTORS], with the understanding that this review is a
organization, in order to enable the RADIUS SSA specification to be voluntary-based service offered on best-effort basis. Since the IETF
reviewed, it is RECOMMENDED that it be made publicly available; this is not a membership organization, in order to enable the RADIUS SSA
also encourages interoperability. Where the RADIUS SSA specification specification to be reviewed, it is RECOMMENDED that it be made
is embedded within a larger document which cannot be made public, the publicly available; this also encourages interoperability. Where the
RADIUS attribute and value definitions SHOULD be published instead as RADIUS SSA specification is embedded within a larger document which
an Informational RFC, as with [RFC4679]. This process SHOULD be cannot be made public, the RADIUS attribute and value definitions
followed instead of requesting IANA allocations from within the SHOULD be published instead as an Informational RFC, as with
standard RADIUS attribute space. [RFC4679]. This process SHOULD be followed instead of requesting
IANA allocations from within the standard RADIUS attribute space.
Similarly, vendors are encouraged to make their specifications Similarly, vendors are encouraged to make their specifications
publicly available, for maximum interoperability. However, it is not publicly available, for maximum interoperability. However, it is not
necessary for them to request publication of their VSA specifications necessary for them to request publication of their VSA specifications
as Informational RFCs by the IETF. as Informational RFCs by the IETF.
All other specifications, including new authentication and/or All other specifications, including new authentication,
security mechanisms SHOULD be allocated via the standard RADIUS authorization, and/or security mechanisms SHOULD be allocated via the
space, as noted in [RFC3575] Section 2.1. standard RADIUS space, as noted in [RFC3575] Section 2.1.
3.2. Polymorphic Attributes 3.2. Polymorphic Attributes
A polymorphic attribute is one whose format or meaning is dynamic. A polymorphic attribute is one whose format or meaning is dynamic.
For example, rather than using a fixed data format, an attribute's For example, rather than using a fixed data format, an attribute's
format might change based on the contents of another attribute. Or, format might change based on the contents of another attribute. Or,
the meaning of an attribute may depend on earlier packets in a the meaning of an attribute may depend on earlier packets in a
sequence. sequence.
RADIUS server dictionary entries are typically static, enabling the RADIUS server dictionary entries are typically static, enabling the
skipping to change at page 20, line 14 skipping to change at page 21, line 34
Access-Request packet will solicit in response at most a single Access-Request packet will solicit in response at most a single
Access-Accept, Access-Reject or Access-Challenge packet, sent to the Access-Accept, Access-Reject or Access-Challenge packet, sent to the
IP address and port of the RADIUS Client that originated the Access- IP address and port of the RADIUS Client that originated the Access-
Request. Similarly, a single Change-of-Authorization (CoA)-Request Request. Similarly, a single Change-of-Authorization (CoA)-Request
packet [RFC5176] will solicit in response at most a single CoA-ACK or packet [RFC5176] will solicit in response at most a single CoA-ACK or
CoA-NAK packet, sent to the IP address and port of the Dynamic CoA-NAK packet, sent to the IP address and port of the Dynamic
Authorization Client (DAC) that originated the CoA-Request. A single Authorization Client (DAC) that originated the CoA-Request. A single
Disconnect-Request packet will solicit in response at most a single Disconnect-Request packet will solicit in response at most a single
Disconnect-ACK or Disconnect-NAK packet, sent to the IP address and Disconnect-ACK or Disconnect-NAK packet, sent to the IP address and
port of the Dynamic Authorization Client (DAC) that originated the port of the Dynamic Authorization Client (DAC) that originated the
CoA-Request. Changes to this model are likely to require major Disconnect-Request. Changes to this model are likely to require
revisions to existing implementations and so this practice is NOT major revisions to existing implementations and so this practice is
RECOMMENDED. NOT RECOMMENDED.
The Length field in the RADIUS packet header is defined in [RFC2865] The Length field in the RADIUS packet header is defined in [RFC2865]
Section 3. It is noted there that the maximum length of a RADIUS Section 3. It is noted there that the maximum length of a RADIUS
packet is 4096 octets. As a result, attribute designers SHOULD NOT packet is 4096 octets. As a result, attribute designers SHOULD NOT
assume that a RADIUS implementation can successfully process RADIUS assume that a RADIUS implementation can successfully process RADIUS
packets larger than 4096 octets. If a situation is envisaged where packets larger than 4096 octets. If a situation is envisaged where
it may be necessary to carry authentication, authorization or it may be necessary to carry authentication, authorization or
accounting data in a packet larger than 4096 octets, then one of the accounting data in a packet larger than 4096 octets, then one of the
following approaches is RECOMMENDED: following approaches is RECOMMENDED:
skipping to change at page 21, line 19 skipping to change at page 22, line 40
pre-provisioned on the NAS, then the name of the pre-provisioned pre-provisioned on the NAS, then the name of the pre-provisioned
policy can be transmitted in an attribute, rather than the policy can be transmitted in an attribute, rather than the
policy itself, which could be quite large. An example of this policy itself, which could be quite large. An example of this
is the Filter-Id Attribute defined in [RFC2865] Section 5.11, is the Filter-Id Attribute defined in [RFC2865] Section 5.11,
which enables a set of pre-provisioned filter rules to be which enables a set of pre-provisioned filter rules to be
referenced by name. referenced by name.
3. Utilization of Packetization Layer Path MTU Discovery 3. Utilization of Packetization Layer Path MTU Discovery
techniques, as specified in [RFC4821]. As a last resort, where techniques, as specified in [RFC4821]. As a last resort, where
the above techniques cannot be made to work, it may be possible the above techniques cannot be made to work, it may be possible
to apply the techniques described in [RFC4821] to discovery of to apply the techniques described in [RFC4821] to discovery the
of the maximum supported RADIUS packet size on the path between maximum supported RADIUS packet size on the path between a
a RADIUS client and a home server. While such an approach can RADIUS client and a home server. While such an approach can
avoid the complexity of utilization of a sequence of packets, avoid the complexity of utilization of a sequence of packets,
dynamic discovery is likely to be time consuming and cannot be dynamic discovery is likely to be time consuming and cannot be
guaranteed to work with existing RADIUS implementations. As a guaranteed to work with existing RADIUS implementations. As a
result, this technique is not generally applicable. result, this technique is not generally applicable.
4. IANA Considerations 4. IANA Considerations
This document requires no action by IANA. This document does not require that the IANA update any existing
registry or create any new registry, but includes information that
affects the IANA, for example:
* includes guidelines that recommend against allocation from the
RADIUS standard attribute space in other SDO RADIUS Attribute
specifications.
* recommends that SDOs request a Private Enterprise Code (PEC)
from the IANA, for use as a Vendor-Id within a Vendor-Specific
attribute.
5. Security Considerations 5. Security Considerations
This specification provides guidelines for the design of RADIUS This specification provides guidelines for the design of RADIUS
attributes used in authentication, authorization and accounting. attributes used in authentication, authorization and accounting.
Threats and security issues for this application are described in Threats and security issues for this application are described in
[RFC3579] and [RFC3580]; security issues encountered in roaming are [RFC3579] and [RFC3580]; security issues encountered in roaming are
described in [RFC2607]. described in [RFC2607].
Encryption of RADIUS attributes on a per-attribute basis is necessary Obfuscation of RADIUS attributes on a per-attribute basis is
in some cases. The current standard mechanism for this is described necessary in some cases. The current standard mechanism for this is
in [RFC2865] Section 5.2 (for obscuring User-Password values) and is described in [RFC2865] Section 5.2 (for obscuring User-Password
based on the MD5 algorithm specified in [RFC1321]. The MD5 and SHA-1 values) and is based on the MD5 algorithm specified in [RFC1321].
algorithms have recently become a focus of scrutiny and concern in The MD5 and SHA-1 algorithms have recently become a focus of scrutiny
security circles, and as a result, the use of these algorithms in new and concern in security circles, and as a result, the use of these
attributes is NOT RECOMMENDED. algorithms in new attributes is NOT RECOMMENDED. In addition,
previous documents referred to this method as generating "encrypted"
data. This terminology is no longer accepted within the
cryptographic community.
Where new RADIUS attributes use cryptographic algorithms, algorithm Where new RADIUS attributes use cryptographic algorithms, algorithm
negotiation SHOULD be supported. Specification of a mandatory-to- negotiation SHOULD be supported. Specification of a mandatory-to-
implement algorithm is REQUIRED, and it is RECOMMENDED that the implement algorithm is REQUIRED, and it is RECOMMENDED that the
mandatory-to-implement algorithm be certifiable under FIPS 140 mandatory-to-implement algorithm be certifiable under FIPS 140
[FIPS]. [FIPS].
Where new RADIUS attributes encapsulate complex data types, or Where new RADIUS attributes encapsulate complex data types, or
transport opaque data, the security considerations discussed in transport opaque data, the security considerations discussed in
Section 2.1.4 SHOULD be addressed. Section 2.1.4 SHOULD be addressed.
Message authentication in RADIUS is provided largely via the Message-
Authenticator attribute. See [RFC3579] Section 3.2, and also
[RFC5080] 2.2.2.
In general, the security of the RADIUS protocol is poor. Robust
deployments SHOULD support a secure communications protocol such as
IPSec. See [RFC3579] Section 4, and [RFC3580] Section 5 for a more
in-depth explanation of these issues.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000. 2000.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575, July 2003. Authentication Dial In User Service)", RFC 3575, July 2003.
[EXTEN] Li, Y., et al., "Extended Remote Authentication Dial In User
Service (RADIUS) Attributes", draft-ietf-radext-extended-
attributes-05.txt, (work in progress).
6.2. Informative References 6.2. Informative References
[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of
management information for TCP/IP-based internets", STD 16, management information for TCP/IP-based internets", STD 16,
RFC 1155, May 1990. RFC 1155, May 1990.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol (SNMP)", STD 15, RFC 1157, May Network Management Protocol (SNMP)", STD 15, RFC 1157, May
1990. 1990.
skipping to change at page 23, line 50 skipping to change at page 25, line 50
[RFC5090] Sterman, B. et al., "RADIUS Extension for Digest [RFC5090] Sterman, B. et al., "RADIUS Extension for Digest
Authentication", RFC 5090, February 2008. Authentication", RFC 5090, February 2008.
[RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176, Authentication Dial In User Service (RADIUS)", RFC 5176,
January 2008. January 2008.
[DOCTORS] AAA Doctors Mailing list <aaa-doctors@ops.ietf.org> [DOCTORS] AAA Doctors Mailing list <aaa-doctors@ops.ietf.org>
[EXTEN] Li, Y., et al., "Extended Remote Authentication Dial In User
Service (RADIUS) Attributes", draft-ietf-radext-extended-
attributes-04.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/
[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.
[RADIUSLOC] [RADIUSLOC]
Tschofenig, H. (Ed.), "Carrying Location Objects in RADIUS and Tschofenig, H. (Ed.), "Carrying Location Objects in RADIUS and
Diameter", draft-ietf-geopriv-radius-lo-19.txt, (work in Diameter", draft-ietf-geopriv-radius-lo-22.txt, (work in
progress) progress)
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.
A.1. Types matching the RADIUS data model A.1. Types matching the RADIUS data model
A.1.1. Transport of simple data A.1.1. Transport of simple data
Does the data fit within the existing RADIUS data model, as outlined Does the data fit within the existing RADIUS data model, as outlined
below? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS below? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS
attribute, or in a [RFC2865] format RADIUS VSA. attribute, or in a [RFC2865] format RADIUS VSA that uses one of the
existing RADIUS data types.
* 32-bit unsigned integer, most significant octet first. * 32-bit unsigned integer, most significant octet first.
* 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)
* 64-bit unsigned integer, most significant octet first. * 64-bit unsigned integer, most significant octet first.
* IPv4 address in network byte order. * IPv4 address in network byte order.
* IPv6 address in network byte order. * IPv6 address in network byte order.
* IPv6 prefix. * IPv6 prefix.
* time as 32 bit unsigned value, most significant octet first, in * time as 32 bit unsigned value, most significant octet first, in
seconds since 00:00:00 UTC, January 1, 1970. seconds since 00:00:00 UTC, January 1, 1970.
skipping to change at page 26, line 36 skipping to change at page 28, line 36
A.2. Improper Data Types A.2. Improper Data Types
All data types other than the ones described above in Section A.1 All data types other than the ones described above in Section A.1
SHOULD NOT be used. This section describes in detail a number of SHOULD NOT be used. This section describes in detail a number of
data types that are NOT RECOMMENDED in new RADIUS specifications. data types that are NOT RECOMMENDED in new RADIUS specifications.
Where possible, replacement data types are suggested. Where possible, replacement data types are suggested.
A.2.1. Simple Data Types A.2.1. Simple Data Types
Does the attribute use any of the following data types? If so, the Does the attribute use any of the following data types? If so, the
data type SHOULD be replaced with the suggested alternatives, or data type SHOULD be replaced with the suggested alternatives, or it
SHOULD NOT be used at all. SHOULD NOT be used at all.
* Signed integers of any size. * Signed integers of any size.
SHOULD NOT be used. SHOULD be replaced with one or more SHOULD NOT be used. SHOULD be replaced with one or more
unsigned integer attributes. The definition of the attribute unsigned integer attributes. The definition of the attribute
can contain information that would otherwise go into the sign can contain information that would otherwise go into the sign
value of the integer. value of the integer.
* 8 bit unsigned integers. * 8 bit unsigned integers.
SHOULD be replaced with 32-bit unsigned integer. There is SHOULD be replaced with 32-bit unsigned integer. There is
insufficient justification to save three bytes. insufficient justification to save three bytes.
skipping to change at page 27, line 25 skipping to change at page 29, line 25
instead. This recommendation does not apply to new attributes instead. This recommendation does not apply to new attributes
for authentication or security, as described below in Section for authentication or security, as described below in Section
A.2.2. A.2.2.
* Multi-field text strings. * Multi-field text strings.
Each field SHOULD be encapsulated in a separate attribute. Each field SHOULD be encapsulated in a separate attribute.
Where grouping of fields is desired, the additional Where grouping of fields is desired, the additional
functionality defined in [EXTEN] SHOULD be used instead. functionality defined in [EXTEN] SHOULD be used instead.
* Polymorphic attributes. * Polymorphic attributes.
Multiple attributes, each with a static data type SHOULD be Multiple attributes, each with a static data type SHOULD be
defined instead. defined instead.
* Nested AVPs.
Attributes should be defined in a flat typespace, possibly using
a 16-bit Vendor type field (see Section 2.3). Where grouping of
fields is desired, the additional functionality defined in
[EXTEN] SHOULD be used instead.
A.2.2. Complex Data Types A.2.2. Complex Data Types
Does the attribute define a complex data type for purposes other than Does the attribute define a complex data type for purposes other than
authentication or security? If so, this data type SHOULD be replaced authentication or security? If so, this data type SHOULD be replaced
with simpler types, as discussed above in Section A.2.1. Also see with simpler types, as discussed above in Section A.2.1. Also see
Section 2.1.3 for a discussion of why complex types are problematic. Section 2.1.3 for a discussion of why complex types are problematic.
A.3. Vendor-Specific formats A.3. Vendor-Specific formats
skipping to change at page 28, line 19 skipping to change at page 30, line 26
However, SDOs SHOULD NOT use Vendor types of 16 bits unless there are However, SDOs SHOULD NOT use Vendor types of 16 bits unless there are
immediate requirements. Future-proofing a specification is immediate requirements. Future-proofing a specification is
insufficient grounds for using 16-bit Vendor types. insufficient grounds for using 16-bit Vendor types.
In general, Vendor-Specific attributes SHOULD follow the [RFC2865] In general, Vendor-Specific attributes SHOULD follow the [RFC2865]
suggested format, or the [EXTEN] format if more functionality or a suggested format, or the [EXTEN] format if more functionality or a
larger attribute space is necessary. larger attribute space is necessary.
A.4. Changes to the RADIUS Operational Model A.4. Changes to the RADIUS Operational Model
Does the specification extend change the RADIUS operation model, as Does the specification change the RADIUS operation model, as outlined
outlined in the list below? If so, then another method of achieving in the list below? If so, then another method of achieving the
the design objectives SHOULD be used. Potential problem areas design objectives SHOULD be used. Potential problem areas include:
include:
* Defining new commands in RADIUS using attributes. * Defining new commands in RADIUS using attributes.
The addition of new commands to RADIUS MUST be handled via The addition of new commands to RADIUS MUST be handled via
allocation of a new Code, and not by the use of an attribute. allocation of a new Code, and not by the use of an attribute.
This restriction includes new commands created by overloading This restriction includes new commands created by overloading
the Service-Type attribute to define new values that modify the Service-Type attribute to define new values that modify
the functionality of Access-Request packets. the functionality of Access-Request packets.
* Using RADIUS as a transport protocol for data unrelated to * Using RADIUS as a transport protocol for data unrelated to
authentication, authorization, or accounting. Using RADIUS to authentication, authorization, or accounting. Using RADIUS to
transport authentication methods such as EAP is explicitly transport authentication methods such as EAP is explicitly
skipping to change at page 29, line 35 skipping to change at page 31, line 40
* attributes intended for a vendor to support their own systems, * attributes intended for a vendor to support their own systems,
and not suitable for general usage and not suitable for general usage
* attributes relying on data types not defined within RADIUS * attributes relying on data types not defined within RADIUS
* attributes intended primarily for use within an SDO * attributes intended primarily for use within an SDO
* attributes intended primarily for use within a group of SDOs. * attributes intended primarily for use within a group of SDOs.
Note that the points listed above do not relax the recommendations Note that the points listed above do not relax the recommendations
discussed in this document. Instead, they recognize that the RADIUS discussed in this document. Instead, they recognize that the RADIUS
data model has limitations. In certain situations where data model has limitations. In certain situations where
interoperability can be strongly constrained, a data model extended interoperability can be strongly constrained by the SDO or vendor, an
by the SDO or vendor MAY be used. We recommend, however, that the expanded data model MAY be used. We recommend, however, that the
RADIUS data model SHOULD be used, even if it is marginally less RADIUS data model SHOULD be used, even if it is marginally less
efficient than alternatives. efficient than alternatives.
When attributes are used primarily within a group of SDOs, and are When attributes are used primarily within a group of SDOs, and are
not applicable to the wider Internet community, we expect that one not applicable to the wider Internet community, we expect that one
SDO will be responsible for allocation from their own private space. SDO will be responsible for allocation from their own private space.
Appendix B - Complex Attributes Appendix B - Complex Attributes
This section summarizes RADIUS attributes with complex data types This section summarizes RADIUS attributes with complex data types
that are defined in existing RFCs. that are defined in existing RFCs.
This appendix is published for informational purposes only, and
reflects the usage of attributes with complex data types at the time
of the publication of this document.
B.1. CHAP-Password B.1. CHAP-Password
[RFC2865] Section 5.3 defines the CHAP-Password Attribute which is [RFC2865] Section 5.3 defines the CHAP-Password Attribute which is
sent from the RADIUS client to the RADIUS server in an Access- sent from the RADIUS client to the RADIUS server in an Access-
Request. The the data type of the CHAP Identifier is not given, only Request. The data type of the CHAP Identifier is not given, only the
the one octet length: one octet length:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | CHAP Ident | String ... | Type | Length | CHAP Ident | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Since this is an authentication attribute, code changes are required Since this is an authentication attribute, code changes are required
on the RADIUS client and server to support it, regardless of the on the RADIUS client and server to support it, regardless of the
attribute format. Therefore, this complex data type is acceptable in attribute format. Therefore, this complex data type is acceptable in
this situation. this situation.
B.2. CHAP-Challenge B.2. CHAP-Challenge
[RFC2865] Section 5.40 defines the CHAP-Challenge Attribute which is [RFC2865] Section 5.40 defines the CHAP-Challenge Attribute which is
sent from the RADIUS client to the RADIUS server in an Access- sent from the RADIUS client to the RADIUS server in an Access-
Request. While the data type of the CHAP Identifier is given, the Request. While the data type of the CHAP Identifier is given, the
text also says text also says:
If the CHAP challenge value is 16 octets long it MAY be placed in If the CHAP challenge value is 16 octets long it MAY be placed in
the Request Authenticator field instead of using this attribute. the Request Authenticator field instead of using this attribute.
Defining attributes to contain values taken from the RADIUS packet Defining attributes to contain values taken from the RADIUS packet
header is NOT RECOMMENDED. Attributes should have values that are header is NOT RECOMMENDED. Attributes should have values that are
packed into a RADIUS AVP. packed into a RADIUS AVP.
B.3. Tunnel-Password B.3. Tunnel-Password
skipping to change at page 32, line 16 skipping to change at page 34, line 20
| Value4 | | Value4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value5 | | Value5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unlike the previous attributes, this attribute contains no encrypted Unlike the previous attributes, this attribute contains no encrypted
component, nor is it directly involved in authentication. The component, nor is it directly involved in authentication. The
individual sub-fields therefore could have been encapsulated in individual sub-fields therefore could have been encapsulated in
separate attributes. separate attributes.
While the contents of this attribute is intended to be placed in an
ARAP packet, the fields need to be set by the RADIUS server. Using
standard RADIUS data types would have simplified RADIUS server
implementations, and subsequent management. The current form of the
attribute requires either the RADIUS server implementation, or the
RADIUS server administrator, to understand the internals of the ARAP
protocol.
B.6. Connect-Info B.6. Connect-Info
[RFC2869] Section 5.11 defines the Connect-Info attribute, which is [RFC2869] Section 5.11 defines the Connect-Info attribute, which is
used to indicate the nature of the connection. used to indicate the nature of the connection.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text... | Type | Length | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 32, line 48 skipping to change at page 35, line 12
More than one Connect-Info attribute may be present in an More than one Connect-Info attribute may be present in an
Accounting-Request packet to accommodate expected efforts by ITU Accounting-Request packet to accommodate expected efforts by ITU
to have modems report more connection information in a standard to have modems report more connection information in a standard
format that might exceed 252 octets. format that might exceed 252 octets.
This attribute contains no encrypted component, and is it not This attribute contains no encrypted component, and is it not
directly involved in authentication. The individual sub-fields could directly involved in authentication. The individual sub-fields could
therefore have been encapsulated in separate attributes. therefore have been encapsulated in separate attributes.
Since the form of the text string is well defined, there is no
benefit in using a text string. Instead, an integer attribute should
have been assigned for each of the transmit speed and the receive
speed. A separate enumerated integer should have been assigned for
the additional information, as is done for the NAS-Port-Type
attribute.
B.7. Framed-IPv6-Prefix B.7. Framed-IPv6-Prefix
[RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and
[RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix
Attribute; these attributes are sent from the RADIUS server to the Attribute; these attributes are sent from the RADIUS server to the
client in an Access-Accept. client in an Access-Accept.
0 1 2 3 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 35, line 4 skipping to change at line 1620
Knoxville, TN 37932 Knoxville, TN 37932
USA USA
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
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Open issues
Open issues relating to this document are tracked on the following
web site:
http://www.drizzle.com/~aboba/RADEXT/
 End of changes. 41 change blocks. 
132 lines changed or deleted 204 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/