draft-ietf-radext-radius-extensions-13.txt   rfc6929.txt 
Network Working Group Alan DeKok Internet Engineering Task Force (IETF) A. DeKok
INTERNET-DRAFT Network RADIUS Request for Comments: 6929 Network RADIUS
Category: Proposed Standard Avi Lior Updates: 2865, 3575, 6158 A. Lior
Updates: 2865, 2866, 3575, 5176, 6158 Category: Standards Track April 2013
<draft-ietf-radext-radius-extensions-13.txt> ISSN: 2070-1721
Expires: August 25, 2013
25 February 2013
Remote Authentication Dial In User Service (RADIUS) Protocol Remote Authentication Dial-In User Service (RADIUS)
Extensions Protocol Extensions
draft-ietf-radext-radius-extensions-13.txt
Abstract Abstract
The Remote Authentication Dial In User Service (RADIUS) protocol is The Remote Authentication Dial-In User Service (RADIUS) protocol is
nearing exhaustion of its current 8-bit Attribute Type space. In nearing exhaustion of its current 8-bit Attribute Type space. In
addition, experience shows a growing need for complex grouping, along addition, experience shows a growing need for complex grouping, along
with attributes which can carry more than 253 octets of data. This with attributes that can carry more than 253 octets of data. This
document defines changes to RADIUS which address all of the above document defines changes to RADIUS that address all of the above
problems. problems.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on June 26, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6929.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ............................................. 5 1. Introduction ....................................................3
1.1. Caveats and Limitations ............................. 6 1.1. Caveats and Limitations ....................................5
1.1.1. Failure to Meet Certain Goals .................. 6 1.1.1. Failure to Meet Certain Goals .......................5
1.1.2. Implementation Recommendations ................. 6 1.1.2. Implementation Recommendations ......................5
1.2. Terminology ......................................... 7 1.2. Terminology ................................................6
1.3. Requirements Language ............................... 8 1.3. Requirements Language ......................................7
2. Extensions to RADIUS ..................................... 9 2. Extensions to RADIUS ............................................7
2.1. Extended Type ....................................... 10 2.1. Extended Type ..............................................8
2.2. Long Extended Type .................................. 11 2.2. Long Extended Type .........................................9
2.3. TLV Data Type ....................................... 14 2.3. TLV Data Type .............................................12
2.3.1. TLV Nesting .................................... 16 2.3.1. TLV Nesting ........................................14
2.4. EVS Data Type ....................................... 16 2.4. EVS Data Type .............................................14
2.5. Integer64 Data Type ................................. 18 2.5. Integer64 Data Type .......................................16
2.6. Vendor-ID Field ..................................... 18 2.6. Vendor-Id Field ...........................................16
2.7. Attribute Naming and Type Identifiers ............... 19 2.7. Attribute Naming and Type Identifiers .....................17
2.7.1. Attribute and TLV Naming ....................... 19 2.7.1. Attribute and TLV Naming ...........................17
2.7.2. Attribute Type Identifiers ..................... 19 2.7.2. Attribute Type Identifiers .........................18
2.7.3. TLV Identifiers ................................ 20 2.7.3. TLV Identifiers ....................................18
2.7.4. VSA Identifiers ................................ 20 2.7.4. VSA Identifiers ....................................18
2.8. Invalid Attributes .................................. 21 2.8. Invalid Attributes ........................................19
3. Attribute Definitions .................................... 22 3. Attribute Definitions ..........................................21
3.1. Extended-Type-1 ..................................... 23 3.1. Extended-Type-1 ...........................................21
3.2. Extended-Type-2 ..................................... 23 3.2. Extended-Type-2 ...........................................22
3.3. Extended-Type-3 ..................................... 24 3.3. Extended-Type-3 ...........................................23
3.4. Extended-Type-4 ..................................... 25 3.4. Extended-Type-4 ...........................................24
3.5. Long-Extended-Type-1 ................................ 26 3.5. Long-Extended-Type-1 ......................................25
3.6. Long-Extended-Type-2 ................................ 27 3.6. Long-Extended-Type-2 ......................................26
4. Vendor Specific Attributes ............................... 28 4. Vendor-Specific Attributes .....................................27
4.1. Extended-Vendor-Specific-1 .......................... 29 4.1. Extended-Vendor-Specific-1 ................................28
4.2. Extended-Vendor-Specific-2 .......................... 30 4.2. Extended-Vendor-Specific-2 ................................29
4.3. Extended-Vendor-Specific-3 .......................... 31 4.3. Extended-Vendor-Specific-3 ................................30
4.4. Extended-Vendor-Specific-4 .......................... 32 4.4. Extended-Vendor-Specific-4 ................................31
4.5. Extended-Vendor-Specific-5 .......................... 33 4.5. Extended-Vendor-Specific-5 ................................32
4.6. Extended-Vendor-Specific-6 .......................... 35 4.6. Extended-Vendor-Specific-6 ................................34
5. Compatibility with traditional RADIUS .................... 36 5. Compatibility with Traditional RADIUS ..........................35
5.1. Attribute Allocation ................................ 36 5.1. Attribute Allocation ......................................35
5.2. Proxy Servers ....................................... 37 5.2. Proxy Servers .............................................36
6. Guidelines ............................................... 38
6.1. Updates to RFC 6158 ................................. 38 6. Guidelines .....................................................37
6.2. Guidelines for Simple Data Types .................... 38 6.1. Updates to RFC 6158 .......................................37
6.3. Guidelines for Complex Data Types ................... 39 6.2. Guidelines for Simple Data Types ..........................38
6.4. Design Guidelines For the New Types ................. 40 6.3. Guidelines for Complex Data Types .........................38
6.5. TLV Guidelines ...................................... 41 6.4. Design Guidelines for the New Types .......................39
6.6. Allocation Request Guidelines ....................... 41 6.5. TLV Guidelines ............................................40
6.7. Allocation Requests Guidelines for TLVs ............. 42 6.6. Allocation Request Guidelines .............................40
6.8. Implementation Guidelines ........................... 43 6.7. Allocation Request Guidelines for TLVs ....................41
6.9. Vendor Guidelines ................................... 43 6.8. Implementation Guidelines .................................42
7. Rationale for This Design ................................ 43 6.9. Vendor Guidelines .........................................42
7.1. Attribute Audit ..................................... 44 7. Rationale for This Design ......................................42
8. Diameter Considerations .................................. 45 7.1. Attribute Audit ...........................................43
9. Examples ................................................. 45 8. Diameter Considerations ........................................44
9.1. Extended Type ....................................... 46 9. Examples .......................................................44
9.2. Long Extended Type .................................. 47 9.1. Extended Type .............................................46
10. IANA Considerations ..................................... 50 9.2. Long Extended Type ........................................47
10.1. Attribute Allocations .............................. 50 10. IANA Considerations ...........................................50
10.2. RADIUS Attribute Type Tree ......................... 50 10.1. Attribute Allocations ....................................50
10.3. Allocation Instructions ............................ 51 10.2. RADIUS Attribute Type Tree ...............................50
10.3.1. Requested Allocation from the Standard Space .. 52 10.3. Allocation Instructions ..................................52
10.3.2. Requested Allocation from the short extended sp 52 10.3.1. Requested Allocation from the Standard Space ......52
10.3.3. Requested Allocation from the long extended spa 52 10.3.2. Requested Allocation from the Short
10.3.4. Allocation Preferences ........................ 52 Extended Space ....................................52
10.3.5. Extending the Type Space via TLV Data Type .... 53 10.3.3. Requested Allocation from the Long
10.3.6. Allocation within a TLV ....................... 53 Extended Space ....................................52
10.3.7. Allocation of Other Data Types ................ 54 10.3.4. Allocation Preferences ............................52
11. Security Considerations ................................. 54 10.3.5. Extending the Type Space via the TLV Data Type ....53
12. References .............................................. 54 10.3.6. Allocation within a TLV ...........................53
12.1. Normative references ............................... 54 10.3.7. Allocation of Other Data Types ....................54
12.2. Informative references ............................. 55 11. Security Considerations .......................................54
Appendix A - Extended Attribute Generator Program ............ 56 12. References ....................................................54
12.1. Normative References .....................................54
12.2. Informative References ...................................55
13. Acknowledgments ...............................................55
Appendix A. Extended Attribute Generator Program ..................56
1. Introduction 1. Introduction
Under current allocation pressure, we expect that the RADIUS Under current allocation pressure, we expect that the RADIUS
Attribute Type space will be exhausted by 2014 or 2015. We therefore Attribute Type space will be exhausted by 2014 or 2015. We therefore
need a way to extend the type space, so that new specifications may need a way to extend the type space so that new specifications may
continue to be developed. Other issues have also been shown with continue to be developed. Other issues have also been shown with
RADIUS. The attribute grouping method defined in [RFC2868] has been RADIUS. The attribute grouping method defined in [RFC2868] has been
shown to be impractical, and a more powerful mechanism is needed. shown to be impractical, and a more powerful mechanism is needed.
Multiple attributes have been defined which transport more than the Multiple Attributes have been defined that transport more than the
253 octets of data originally envisioned with the protocol. Each of 253 octets of data originally envisioned with the protocol. Each of
these attributes is handled as a "special case" inside of RADIUS these attributes is handled as a "special case" inside of RADIUS
implementations, instead of as a general method. We therefore also implementations, instead of as a general method. We therefore also
need a standardized method of transporting large quantities of data. need a standardized method of transporting large quantities of data.
Finally, some vendors are close to allocating all of the Attributes Finally, some vendors are close to allocating all of the Attributes
within their Vendor-Specific Attribute space. It would be useful to within their Vendor-Specific Attribute space. It would be useful to
leverage changes to the base protocol for extending the Vendor- leverage changes to the base protocol for extending the Vendor-
Specific Attribute space. Specific Attribute space.
We satisfy all of these requirements through the following changes We satisfy all of these requirements through the following changes
given in this document: given in this document:
* defining an "Extended Type" format, which adds 8 bits of "Extended * Defining an "Extended Type" format, which adds 8 bits of "Extended
Type" to the RADIUS Attribute Type space, by using one octet of the Type" to the RADIUS Attribute Type space, by using one octet of the
"Value" field. This method gives us a general way of extending "Value" field. This method gives us a general way of extending the
the Attribute Type Space. (Section 2.1) Attribute Type space (Section 2.1).
* allocating 4 attributes as using the format of "Extended Type". * Allocating 4 attributes as using the format of "Extended Type".
This allocation extends the RADIUS Attribute Type Space by This allocation extends the RADIUS Attribute Type space by
approximately 1000 values. (Sections 3.1, 3.2, 3.3, and 3.4) approximately 1000 values (Sections 3.1, 3.2, 3.3, and 3.4).
* defining a "Long Extended Type" format, which inserts an additional * Defining a "Long Extended Type" format, which inserts an additional
octet between the "Extended Type" octet, and the "Value" field. octet between the "Extended Type" octet and the "Value" field.
This method gives us a general way of adding additional This method gives us a general way of adding more functionality to
functionality to the protocol. (Section 2.2) the protocol (Section 2.2).
* defining a method which uses the additional octet in the "Long * Defining a method that uses the additional octet in the "Long
Extended Type" to indicate data fragmentation across multiple Extended Type" to indicate data fragmentation across multiple
Attributes. This method provides a standard way for an Attribute Attributes. This method provides a standard way for an Attribute
to carry more than 253 octets of data. (Section 2.2) to carry more than 253 octets of data (Section 2.2).
* allocating 2 attributes as using the format "Long Extended Type". * Allocating 2 attributes as using the format "Long Extended Type".
This allocation extends the RADIUS Attribute Type Space This allocation extends the RADIUS Attribute Type space by an
by an additional 500 values. (Sections 3.5 and 3.6) additional 500 values (Sections 3.5 and 3.6).
* defining a new "Type Length Value" (TLV) data type. The data type * Defining a new "Type-Length-Value" (TLV) data type. This data type
allows an attribute to carry TLVs as "sub-attributes", which can in allows an attribute to carry TLVs as "sub-Attributes", which can in
turn encapsulate other TLVs as "sub-sub-attributes." This change turn encapsulate other TLVs as "sub-sub-Attributes". This change
creates a standard way to group a set of Attributes. (Section 2.3) creates a standard way to group a set of Attributes (Section 2.3).
* defining a new "extended Vendor-Specific" (EVS) data type. The * Defining a new "Extended-Vendor-Specific" (EVS) data type. This
data type allows an attribute to carry Vendor-Specific Attributes data type allows an attribute to carry Vendor-Specific Attributes
(VSAs) inside of the new attribute formats. (Section 2.4) (VSAs) inside of the new Attribute formats (Section 2.4).
* defining a new "integer64" data type. The data type allows * Defining a new "integer64" data type. This data type allows
counters which track more than 2^32 octets of data. (Section 2.5) counters that track more than 2^32 octets of data (Section 2.5).
* allocating 6 attributes using the new EVS data type. This * Allocating 6 attributes using the new EVS data type. This
allocation extends the Vendor-Specific Attribute Type space by allocation extends the Vendor-Specific Attribute Type space by over
over 1500 values. (Sections 4.1 through 4.6) 1500 values (Sections 4.1 through 4.6).
* Define the "Vendor-ID" for Vendor-Specific attributes to encompass * Defining the "Vendor-Id" for Vendor-Specific Attributes to
the entire 4 octets of the Vendor field. [RFC2865] Section 5.26 encompass the entire 4 octets of the Vendor field. [RFC2865]
defined it to be 3 octets, with the high octet being zero. Section 5.26 defined it to be 3 octets, with the fourth octet being
(Section 2.5) zero (Section 2.6).
* Describing compatibility with existing RADIUS systems. (Section 5) * Describing compatibility with existing RADIUS systems (Section 5).
* Defining guidelines for the use of these changes for IANA, * Defining guidelines for the use of these changes for IANA,
implementations of this specification, and for future RADIUS implementations of this specification, and for future RADIUS
specifications. (Section 6) specifications (Section 6).
As with any protocol change, the changes defined here are the result As with any protocol change, the changes defined here are the result
of a series of compromises. We have tried to find a balance between of a series of compromises. We have tried to find a balance between
flexibility, space in the RADIUS message, compatibility with existing flexibility, space in the RADIUS message, compatibility with existing
deployments, and implementation difficulty. deployments, and difficulty of implementation.
1.1. Caveats and Limitations 1.1. Caveats and Limitations
This section describes some caveats and limitations with the This section describes some caveats and limitations of the proposal.
proposal.
1.1.1. Failure to Meet Certain Goals 1.1.1. Failure to Meet Certain Goals
One goal which was not met by the above modifications is to have an One goal that was not met by the above modifications is to have an
incentive for standards to use the new space. That incentive is incentive for standards to use the new space. That incentive is
being provided by the exhaustion of the standard space. being provided by the exhaustion of the standard space.
1.1.2. Implementation Recommendations 1.1.2. Implementation Recommendations
It is RECOMMENDED that implementations support this specification. It is RECOMMENDED that implementations support this specification.
It is RECOMMENDED that new specifications use the formats defined in It is RECOMMENDED that new specifications use the formats defined in
this specification. this specification.
The alternative to the above recommendations is a circular argument The alternative to the above recommendations is a circular argument
of not implementing this specification because no other standards of not implementing this specification because no other standards
reference it, and also not defining new standards referencing this reference it, and also not defining new standards referencing this
specification because no implementations exist. specification because no implementations exist.
As noted earlier, the "standard space" is almost entirely allocated. As noted earlier, the standard space is almost entirely allocated.
Ignoring the looming crisis benefits no one. Ignoring the looming crisis benefits no one.
1.2. Terminology 1.2. Terminology
This document uses the following terms: This document uses the following terms:
Silently discard Silently discard
This means the implementation discards the packet without further
processing. The implementation MAY provide the capability of
logging the error, including the contents of the silently discarded
packet, and SHOULD record the event in a statistics counter.
Invalid attribute This means the implementation discards the packet without further
This means that the Length field of an Attribute is valid (as per processing. The implementation MAY provide the capability of
[RFC2865], Section 5, top of page 25), but the contents of the logging the error, including the contents of the silently
Attribute do not follow the correct format. For example, an discarded packet, and SHOULD record the event in a statistics
Attribute of type "address" which encapsulates more than four, or counter.
less than four, octets of data. See Section 2.8 for a more
complete definition.
Standard space Invalid attribute
Codes in the RADIUS Attribute Type Space that are allocated by IANA
and that follow the format defined in Section 5 of [RFC2865].
Extended space This means that the Length field of an Attribute is valid (as per
Codes in the RADIUS Attribute Type Space that require the [RFC2865], Section 5, top of page 25) but the contents of the
extensions defined in this document, and are an extension of the Attribute do not follow the correct format, for example, an
standard space, but which cannot be represented within the standard Attribute of type "address" that encapsulates more than four, or
space. less than four, octets of data. See Section 2.8 for a more
complete definition.
Short extended space Standard space
Codes in the extended space which use the "Extended Type" format.
Long extended space This refers to codes in the RADIUS Attribute Type space that are
Codes in the extended space which use the "Long Extended Type" allocated by IANA and that follow the format defined in Section 5
format. of [RFC2865].
The following terms are used here with the meanings defined in BCP Extended space
26 [RFC5226]: "name space", "assigned value", "registration",
"Private Use", "Reserved", "Unassigned", "IETF Review", and This refers to codes in the RADIUS Attribute Type space that
"Standards Action". require the extensions defined in this document and are an
extension of the standard space, but that cannot be represented
within the standard space.
Short extended space
This refers to codes in the extended space that use the "Extended
Type" format.
Long extended space
This refers to codes in the extended space that use the "Long
Extended Type" format.
The following terms are used here with the meanings defined in BCP 26
[RFC5226]: "namespace", "assigned value", "registration", "Private
Use", "Reserved", "Unassigned", "IETF Review", and "Standards
Action".
1.3. Requirements Language 1.3. Requirements Language
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in and "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. Extensions to RADIUS 2. Extensions to RADIUS
This section defines two new attribute formats; "Extended Type"; and This section defines two new Attribute formats: "Extended Type" and
"Long Extended Type". It defines a new Type-Length-Value (TLV) data "Long Extended Type". It defines a new Type-Length-Value (TLV) data
type, an Extended-Vendor-Specific (EVS) data type, and an Integer64 type, an Extended-Vendor-Specific (EVS) data type, and an Integer64
data type. It defines a new method for naming attributes and data type. It defines a new method for naming attributes and
identifying Attributes using the new attribute formats. It finally identifying Attributes using the new Attribute formats. It finally
defines the new term "invalid attribute", and describes how it defines the new term "invalid attribute" and describes how it affects
affects implementations. implementations.
The new attribute formats are designed to be compatible with the The new Attribute formats are designed to be compatible with the
attribute format given in [RFC2865] Section 5. The meaning and Attribute format given in [RFC2865] Section 5. The meaning and
interpretation of the Type and Length fields is unchanged from that interpretation of the Type and Length fields are unchanged from that
specification. This reuse allows the new formats to be compatible specification. This reuse allows the new formats to be compatible
with RADIUS implementations which do not implement this with RADIUS implementations that do not implement this specification.
specification. Those implementations can simply ignore the Value Those implementations can simply ignore the "Value" field of an
field of an attribute, or forward it verbatim. attribute or forward it verbatim.
The changes to the attribute format come about by "stealing" one or The changes to the Attribute format come about by "stealing" one or
more octets from the Value field. This change has the effect that more octets from the "Value" field. This change has the effect that
the Value field of [RFC2865] Section 5 contains both the new octets the "Value" field of [RFC2865] Section 5 contains both the new octets
given here, and any attribute-specific Value. The result is that given here and any attribute-specific Value. The result is that
Values in this specification are limited to less than 253 octets in "Value"s in this specification are limited to less than 253 octets in
size. This limitation is overcome through the use of the "Long size. This limitation is overcome through the use of the "Long
Extended Type" format. Extended Type" format.
We reiterate that the formats given in this document do not insert We reiterate that the formats given in this document do not insert
new data into an attribute. Instead, we "steal" one octet of Value, new data into an attribute. Instead, we "steal" one octet of Value,
so that the definition of the Length field remains unchanged. The so that the definition of the Length field remains unchanged. The
new attribute formats are designed to be compatible with the new Attribute formats are designed to be compatible with the
attribute format given in [RFC2865] Section 5. The meaning and Attribute format given in [RFC2865] Section 5. The meaning and
interpretation of the Type and Length fields is unchanged from that interpretation of the Type and Length fields is unchanged from that
specification. This reuse allows the new formats to be compatible specification. This reuse allows the new formats to be compatible
RADIUS implementations which do not implement this specification. with RADIUS implementations that do not implement this specification.
Those implementations can simply ignore the Value field of an Those implementations can simply ignore the "Value" field of an
attribute, or forward it verbatim. attribute or forward it verbatim.
The changes to the attribute format come about by "stealing" one or
more octets from the Value field. This change has the effect that
the Value field of [RFC2865] Section 5 contains both the new octets
given here, and any attribute-specific Value. The result is that
Values in this specification are limited to less than 253 octets in
size. This limitation is overcome through the use of the "Long
Extended Type" format.
2.1. Extended Type 2.1. Extended Type
This section defines a new attribute format, called "Extended Type". This section defines a new Attribute format, called "Extended Type".
A summary of the Attribute format is shown below. The fields are A summary of the Attribute format is shown below. The fields are
transmitted from left to right. transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Value ... | Type | Length | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
This field is identical to the Type field of the Attribute format This field is identical to the Type field of the Attribute format
defined in [RFC2865] Section 5. defined in [RFC2865] Section 5.
Length Length
The Length field is one octet, and indicates the length of this The Length field is one octet and indicates the length of this
Attribute including the Type, Length, Extended-Type, and Value Attribute, including the Type, Length, "Extended-Type", and
fields. Permitted values are between 4 and 255. If a client or "Value" fields. Permitted values are between 4 and 255. If a
server receives an Extended Attribute with a Length of 2 or 3, client or server receives an Extended Attribute with a Length of 2
then that Attribute MUST be considered to be an "invalid or 3, then that Attribute MUST be considered to be an "invalid
attribute", and handled as per Section 2.8, below. attribute" and handled as per Section 2.8, below.
Extended-Type Extended-Type
The Extended-Type field is one octet. Up-to-date values of this The Extended-Type field is one octet. Up-to-date values of this
field are specified according to the policies and rules described field are specified according to the policies and rules described
in Section 10. Unlike the Type field defined in [RFC2865] Section in Section 10. Unlike the Type field defined in [RFC2865]
5, no values are allocated for experimental or implementation- Section 5, no values are allocated for experimental or
specific use. Values 241-255 are reserved and MUST NOT be used. implementation-specific use. Values 241-255 are reserved and MUST
NOT be used.
The Extended-Type is meaningful only within a context defined by The Extended-Type is meaningful only within a context defined by
the Type field. That is, this field may be thought of as defining the Type field. That is, this field may be thought of as defining
a new type space of the form "Type.Extended-Type". See Section a new type space of the form "Type.Extended-Type". See
2.5, below, for additional discussion. Section 3.5, below, for additional discussion.
A RADIUS server MAY ignore Attributes with an unknown A RADIUS server MAY ignore Attributes with an unknown
"Type.Extended-Type". "Type.Extended-Type".
A RADIUS client MAY ignore Attributes with an unknown A RADIUS client MAY ignore Attributes with an unknown
"Type.Extended-Type". "Type.Extended-Type".
Value Value
This field is similar to the Value field of the Attribute format This field is similar to the "Value" field of the Attribute format
defined in [RFC2865] Section 5. The format of the data MUST be a defined in [RFC2865] Section 5. The format of the data MUST be a
valid RADIUS data type. valid RADIUS data type.
The Value field is one or more octets. The "Value" field is one or more octets.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the interpretation identifier of "Type.Extended-Type" to determine the interpretation
of the Value field. of the "Value" field.
The addition of the Extended-Type field decreases the maximum The addition of the Extended-Type field decreases the maximum
length for attributes of type "text" or "string" from 253 to 252 length for attributes of type "text" or "string" from 253 to
octets. Where an Attribute needs to carry more than 252 octets of 252 octets. Where an Attribute needs to carry more than
data, the "Long Extended Type" format MUST be used. 252 octets of data, the "Long Extended Type" format MUST be used.
Experience has shown that the "experimental" and "implementation Experience has shown that the "experimental" and "implementation-
specific" attributes defined in [RFC2865] Section 5 have had little specific" attributes defined in [RFC2865] Section 5 have had little
practical value. We therefore do not continue that practice here practical value. We therefore do not continue that practice here
with the Extended-Type field. with the Extended-Type field.
2.2. Long Extended Type 2.2. Long Extended Type
This section defines a new attribute format, called "Long Extended This section defines a new Attribute format, called "Long Extended
Type". It leverages the "Extended Type" format in order to permit Type". It leverages the "Extended Type" format in order to permit
the transport of attributes encapsulating more than 253 octets of the transport of attributes encapsulating more than 253 octets of
data. A summary of the Attribute format is shown below. The fields data. A summary of the Attribute format is shown below. The fields
are transmitted from left to right. are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type |M| Reserved | | Type | Length | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
This field is identical to the Type field of the Attribute format This field is identical to the Type field of the Attribute format
defined in [RFC2865] Section 5. defined in [RFC2865] Section 5.
Length Length
The Length field is one octet, and indicates the length of this The Length field is one octet and indicates the length of this
Attribute including the Type, Length, Extended-Type, and Value Attribute, including the Type, Length, Extended-Type, and "Value"
fields. Permitted values are between 5 and 255. If a client or fields. Permitted values are between 5 and 255. If a client or
server receives a "Long Extended Type" with a Length of 2, 3, or server receives a "Long Extended Type" with a Length of 2, 3, or
4, then that Attribute MUST be considered to be an "invalid 4, then that Attribute MUST be considered to be an "invalid
attribute", and be handled as per Section 2.8, below. attribute" and handled as per Section 2.8, below.
Note that this Length is limited to the length of this fragment. Note that this Length is limited to the length of this fragment.
There is no field which gives an explicit value for the total size There is no field that gives an explicit value for the total size
of the fragmented attribute. of the fragmented attribute.
Extended-Type Extended-Type
This field is identical to the Extended-Type field defined above This field is identical to the Extended-Type field defined above
in Section 2.1. in Section 2.1.
M (More) M (More)
The More field is one (1) bit in length, and indicates whether or The More field is one (1) bit in length and indicates whether or
not the current attribute contains "more" than 251 octets of data. not the current attribute contains "more" than 251 octets of data.
The More field MUST be clear (0) if the Length field has value The More field MUST be clear (0) if the Length field has a value
less than 255. The More field MAY be set (1) if the Length field of less than 255. The More field MAY be set (1) if the Length
has value of 255. field has a value of 255.
If the More field is set (1), it indicates that the Value field If the More field is set (1), it indicates that the "Value" field
has been fragmented across multiple RADIUS attributes. When the has been fragmented across multiple RADIUS attributes. When the
More field is set (1), the attribute MUST have a Length field of More field is set (1), the Attribute MUST have a Length field of
value 255; there MUST be an attribute following this one; and the value 255, there MUST be an attribute following this one, and the
next attribute MUST have both the same Type and Extended Type. next attribute MUST have both the same Type and "Extended Type".
That is, multiple fragments of the same value MUST be in order and That is, multiple fragments of the same value MUST be in order and
MUST be consecutive attributes in the packet, and the last MUST be consecutive attributes in the packet, and the last
attribute in a packet MUST NOT have the More field set (1). attribute in a packet MUST NOT have the More field set (1).
That is, a packet containing a fragmented attribute needs to That is, a packet containing a fragmented attribute needs to
contain all fragments of the attribute, and those fragments need contain all fragments of the Attribute, and those fragments need
to be contiguous in the packet. RADIUS does not support inter- to be contiguous in the packet. RADIUS does not support
packet fragmentation, which means that fragmenting an attribute inter-packet fragmentation, which means that fragmenting an
across multiple packets is impossible. attribute across multiple packets is impossible.
If a client or server receives an attribute fragment with the If a client or server receives an attribute fragment with the
"More" field set (1), but for which no subsequent fragment can be "More" field set (1) but for which no subsequent fragment can be
found, then the fragmented attribute is considered to be an found, then the fragmented attribute is considered to be an
"invalid attribute", and handled as per Section 2.8, below. "invalid attribute" and handled as per Section 2.8, below.
Reserved Reserved
This field is 7 bits long, and is reserved for future use. This field is 7 bits long and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an attribute Implementations MUST set it to zero (0) when encoding an attribute
for sending in a packet. The contents SHOULD be ignored on for sending in a packet. The contents SHOULD be ignored on
reception. reception.
Future specifications may define additional meaning for this Future specifications may define additional meaning for this
field. Implementations therefore MUST NOT treat this field as field. Implementations therefore MUST NOT treat this field as
invalid if it is non-zero. invalid if it is non-zero.
Value Value
This field is similar to the Value field of the Attribute format This field is similar to the "Value" field of the Attribute format
defined in [RFC2865] Section 5. It may contain a complete set of defined in [RFC2865] Section 5. It may contain a complete set of
data (when the Length field has value less than 255), or it may data (when the Length field has a value of less than 255), or it
contain a fragment of data. may contain a fragment of data.
The Value field is one or more octets. The "Value" field is one or more octets.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the interpretation identifier of "Type.Extended-Type" to determine the interpretation
of the Value field. of the "Value" field.
Any interpretation of the resulting data MUST occur after the Any interpretation of the resulting data MUST occur after the
fragments have been reassembled. The length of the data MUST be fragments have been reassembled. The length of the data MUST be
taken as the sum of the lengths of the fragments (i.e. Value taken as the sum of the lengths of the fragments (i.e., "Value"
fields) from which it is constructed. The format of the data fields) from which it is constructed. The format of the data
SHOULD be a valid RADIUS data type. If the reassembled data does SHOULD be a valid RADIUS data type. If the reassembled data does
not match the expected format, all fragments MUST be treated as not match the expected format, all fragments MUST be treated as
"invalid attributes", and the reassembled data MUST be discarded. "invalid attributes", and the reassembled data MUST be discarded.
We note that the maximum size of a fragmented attribute is limited We note that the maximum size of a fragmented attribute is limited
only by the RADIUS packet length limitation (i.e. 4096 octets, not only by the RADIUS packet length limitation (i.e., 4096 octets,
counting various headers and overhead). Implementations MUST be not counting various headers and overhead). Implementations MUST
able to handle the case where one fragmented attribute completely be able to handle the case where one fragmented attribute
fills the packet. completely fills the packet.
This definition increases the RADIUS Attribute Type space as above, This definition increases the RADIUS Attribute Type space as above
but also provides for transport of Attributes which could contain but also provides for transport of Attributes that could contain more
more than 253 octets of data. than 253 octets of data.
Note that [RFC2865] Section 5 says: Note that [RFC2865] Section 5 says:
If multiple Attributes with the same Type are present, the order If multiple Attributes with the same Type are present, the order
of Attributes with the same Type MUST be preserved by any proxies. of Attributes with the same Type MUST be preserved by any proxies.
The order of Attributes of different Types is not required to be The order of Attributes of different Types is not required to be
preserved. A RADIUS server or client MUST NOT have any preserved. A RADIUS server or client MUST NOT have any
dependencies on the order of attributes of different types. A dependencies on the order of attributes of different types. A
RADIUS server or client MUST NOT require attributes of the same RADIUS server or client MUST NOT require attributes of the same
type to be contiguous. type to be contiguous.
These requirements also apply to the "Long Extended Type" attribute, These requirements also apply to the "Long Extended Type" Attribute,
including fragments. Implementations MUST be able to process non- including fragments. Implementations MUST be able to process
contiguous fragments -- that is, fragments which are mixed together non-contiguous fragments -- that is, fragments that are mixed
with other attributes of a different Type. This will allow them to together with other attributes of a different Type. This will allow
accept packets, so long as the attributes can be correctly decoded. them to accept packets, so long as the Attributes can be correctly
decoded.
2.3. TLV Data Type 2.3. TLV Data Type
We define a new data type in RADIUS, called "tlv". The "tlv" data We define a new data type in RADIUS, called "tlv". The "tlv" data
type is an encapsulation layer which permits the "Value" field of an type is an encapsulation layer that permits the "Value" field of an
Attribute to contain new sub-Attributes. These sub-Attributes can in Attribute to contain new sub-Attributes. These sub-Attributes can in
turn contain "Value"s of data type TLV. This capability both extends turn contain "Value"s of data type TLV. This capability both extends
the attribute space, and permits "nested" attributes to be used. the Attribute space and permits "nested" attributes to be used. This
This nesting can be used to encapsulate or group data into one or nesting can be used to encapsulate or group data into one or more
more logical containers. logical containers.
The "tlv" data type re-uses the RADIUS attribute format, as given The "tlv" data type reuses the RADIUS Attribute format, as given
below: below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV-Type | TLV-Length | TLV-Value ... | TLV-Type | TLV-Length | TLV-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV-Type TLV-Type
The Type field is one octet. Up-to-date values of this field are The TLV-Type field is one octet. Up-to-date values of this field
specified according to the policies and rules described in Section are specified according to the policies and rules described in
10. Values 254-255 are "Reserved" for use by future extensions to Section 10. Values 254-255 are "Reserved" for use by future
RADIUS. The value 26 has no special meaning, and MUST NOT be extensions to RADIUS. The value 26 has no special meaning and
treated as a Vendor Specific attribute. MUST NOT be treated as a Vendor-Specific Attribute.
As with Extended-Type above, the TLV-Type is meaningful only As with the Extended-Type field defined above, the TLV-Type is
within the context defined by "Type" fields of the encapsulating meaningful only within the context defined by "Type" fields of the
Attributes. That is, the field may be thought of as defining a encapsulating Attributes. That is, the field may be thought of as
new type space of the form "Type.Extended-Type.TLV-Type". Where defining a new type space of the form
TLVs are nested, the type space is of the form "Type.Extended- "Type.Extended-Type.TLV-Type". Where TLVs are nested, the type
Type.TLV-Type.TLV-Type", etc. space is of the form "Type.Extended-Type.TLV-Type.TLV-Type", etc.
A RADIUS server MAY ignore Attributes with an unknown "TLV-Type". A RADIUS server MAY ignore Attributes with an unknown "TLV-Type".
A RADIUS client MAY ignore Attributes with an unknown "TLV-Type". A RADIUS client MAY ignore Attributes with an unknown "TLV-Type".
A RADIUS proxy SHOULD forward Attributes with an unknown "TLV- A RADIUS proxy SHOULD forward Attributes with an unknown
Type" verbatim. "TLV-Type" verbatim.
TLV-Length TLV-Length
The TLV-Length field is one octet, and indicates the length of The TLV-Length field is one octet and indicates the length of this
this TLV including the TLV-Type, TLV-Length and TLV-Value fields. TLV, including the TLV-Type, TLV-Length, and TLV-Value fields. It
It MUST have a value between 3 and 255. If a client or server MUST have a value between 3 and 255. If a client or server
receives a TLV with an invalid TLV-Length, then the attribute receives a TLV with an invalid TLV-Length, then the Attribute that
which encapsulates that TLV MUST be considered to be an "invalid encapsulates that TLV MUST be considered to be an "invalid
attribute", and handled as per Section 2.8, below. attribute" and handled as per Section 2.8, below.
TLV-Value TLV-Value
The TLV-Value field is one or more octets and contains information The TLV-Value field is one or more octets and contains information
specific to the Attribute. The format and length of the TLV-Value specific to the Attribute. The format and length of the TLV-Value
field is determined by the TLV-Type and TLV-Length fields. field are determined by the TLV-Type and TLV-Length fields.
The TLV-Value field SHOULD encapsulate a standard RADIUS data The TLV-Value field SHOULD encapsulate a standard RADIUS data
type. Non-standard data types SHOULD NOT be used within TLV-Value type. Non-standard data types SHOULD NOT be used within TLV-Value
fields. We note that the TLV-Value field MAY also contain one or fields. We note that the TLV-Value field MAY also contain one or
more attributes of data type "tlv", which allows for simple more attributes of data type TLV; data type TLV allows for simple
grouping and multiple layers of nesting. grouping and multiple layers of nesting.
The TLV-Value field is limited to containing 253 or fewer octets The TLV-Value field is limited to containing 253 or fewer octets
of data. Specifications which require a TLV to contain more than of data. Specifications that require a TLV to contain more than
253 octets of data are incompatible with RADIUS, and need to be 253 octets of data are incompatible with RADIUS and need to be
redesigned. Specifications which require the transport of empty redesigned. Specifications that require the transport of empty
Values (i.e. Length = 2) are incompatible with RADIUS, and need to "Value"s (i.e., Length = 2) are incompatible with RADIUS and need
be redesigned. to be redesigned.
The TLV-Value field MUST NOT contain data using the "Extended The TLV-Value field MUST NOT contain data using the "Extended
Type" formats defined in this document. The base Extended Type" formats defined in this document. The base Extended
Attributes format allows for sufficient flexibility that nesting Attributes format allows for sufficient flexibility that nesting
them inside of a TLV offers little additional value. them inside of a TLV offers little additional value.
This TLV definition is compatible with the suggested format of the This TLV definition is compatible with the suggested format of the
"String" field of the Vendor-Specific attribute, as defined in "String" field of the Vendor-Specific Attribute, as defined in
[RFC2865] Section 5.26, though that specification does not discuss [RFC2865] Section 5.26, though that specification does not discuss
nesting. nesting.
Vendors MAY use attributes of type "tlv" in any Vendor Specific Vendors MAY use attributes of type "TLV" in any Vendor-Specific
Attribute. It is RECOMMENDED to use type "tlv" for VSAs, in Attribute. It is RECOMMENDED to use type "TLV" for VSAs, in
preference to any other format. preference to any other format.
If multiple TLVs with the same TLV-Type are present, the order of If multiple TLVs with the same TLV-Type are present, the order of
TLVs with the same TLV-Type MUST be preserved by any proxies. The TLVs with the same TLV-Type MUST be preserved by any proxies. The
order of TLVs of different TLV-Types is not required to be preserved. order of TLVs of different TLV-Types is not required to be preserved.
A RADIUS server or client MUST NOT have any dependencies on the order A RADIUS server or client MUST NOT have any dependencies on the order
of TLVs of different TLV-Types. A RADIUS server or client MUST NOT of TLVs of different TLV-Types. A RADIUS server or client MUST NOT
require TLVs of the same TLV-type to be contiguous. require TLVs of the same TLV-Type to be contiguous.
The interpretation of multiple TLVs of the same TLV-Type MUST be that The interpretation of multiple TLVs of the same TLV-Type MUST be that
of a logical "and", unless otherwise specified. That is, multiple of a logical "and", unless otherwise specified. That is, multiple
TLVs are interpreted as specifying an unordered set of values. TLVs are interpreted as specifying an unordered set of values.
Specifications SHOULD NOT define TLVs to be interpreted as a logical Specifications SHOULD NOT define TLVs to be interpreted as a logical
"or". Doing so would mean that a RADIUS client or server would make "or". Doing so would mean that a RADIUS client or server would make
an arbitrary, and non-deterministic choice among the values. an arbitrary and non-deterministic choice among the values.
2.3.1. TLV Nesting 2.3.1. TLV Nesting
TLVs may contain other TLVs. When this occurs, the "container" TLV TLVs may contain other TLVs. When this occurs, the "container" TLV
MUST be completely filled by the "contained" TLVs. That is, the MUST be completely filled by the "contained" TLVs. That is, the
"container" TLV-Length field MUST be exactly two (2) more than the "container" TLV-Length field MUST be exactly two (2) more than the
sum of the "contained" TLV-Length fields. If the "contained" TLVs sum of the "contained" TLV-Length fields. If the "contained" TLVs
over-fill the "container" TLV, the "container" TLV MUST be considered overfill the "container" TLV, the "container" TLV MUST be considered
to be an "invalid attribute", and handled as described in Section to be an "invalid attribute" and handled as described in Section 2.8,
2.8, below. below.
The depth of TLV nesting is limited only by the restrictions on the The depth of TLV nesting is limited only by the restrictions on the
TLV-Length field. The limit of 253 octets of data results in a limit TLV-Length field. The limit of 253 octets of data results in a limit
of 126 levels of nesting. However, nesting depths of more than 4 are of 126 levels of nesting. However, nesting depths of more than 4 are
NOT RECOMMENDED. They have not been demonstrated to be necessary in NOT RECOMMENDED. They have not been demonstrated to be necessary in
practice, and they appear to make implementations more complex. practice, and they appear to make implementations more complex.
Reception of packets with such deeply nest TLVs may indicate Reception of packets with such deeply nested TLVs may indicate
implementation errors or deliberate attacks. Where implementations implementation errors or deliberate attacks. Where implementations
do not support deep nesting of TLVs, it is RECOMMENDED that the do not support deep nesting of TLVs, it is RECOMMENDED that the
unsupported layers are treated as "invalid attributes". unsupported layers are treated as "invalid attributes".
2.4. EVS Data Type 2.4. EVS Data Type
We define a new data type in RADIUS, called "evs", for "Extended We define a new data type in RADIUS, called "evs", for "Extended-
Vendor-Specific". The "evs" data type is an encapsulation layer Vendor-Specific". The "evs" data type is an encapsulation layer that
which permits the "Value" field of an Attribute to contain a Vendor- permits the EVS-Value field of an Attribute to contain a Vendor-Id,
Id, followed by a Vendor-Type, and then vendor-defined data. This followed by an EVS-Type, and then vendor-defined data. This data can
data can in turn contain valid RADIUS data types, or any other data in turn contain valid RADIUS data types or any other data as
as determined by the vendor. determined by the vendor.
This data type is intended use in attributes which carry Vendor- This data type is intended for use in attributes that carry vendor-
Specific information, as is done with the Vendor-Specific Attribute specific information, as is done with the Vendor-Specific Attribute
(26). It is RECOMMENDED that this data type be used by a vendor only (Attribute number 26). It is RECOMMENDED that this data type be used
when the Vendor-Specific Attribute Type space has been fully by a vendor only when the Vendor-Specific Attribute Type space has
allocated. been fully allocated.
Where [RFC2865] Section 5.26 makes a recommendation for the format of Where [RFC2865] Section 5.26 makes a recommendation for the format of
the data following the Vendor-Id, we give a strict definition. the data following the Vendor-Id, we give a strict definition.
Experience has shown that many vendors have not followed the Experience has shown that many vendors have not followed the
[RFC2865] recommendations, leading to interoperability issues. We [RFC2865] recommendations, leading to interoperability issues. We
hope here to give vendors sufficient flexibility as to meet their hope here to give vendors sufficient flexibility as to meet their
needs, while minimizing the use of non-standard VSA formats. needs while minimizing the use of non-standard VSA formats.
The "evs" data type MAY be used in Attributes having the format of The "evs" data type MAY be used in Attributes having the format of
"Extended Type" or "Long Extended Type". It MUST NOT be used in any "Extended Type" or "Long Extended Type". It MUST NOT be used in any
other Attribute definition, including standard RADIUS Attributes, other Attribute definition, including standard RADIUS attributes,
TLVs, and VSAs. TLVs, and VSAs.
A summary of the "evs" data type format is shown below. The fields A summary of the "evs" data type format is shown below. The fields
are transmitted from left to right. are transmitted from left to right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id | | Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Value .... | EVS-Type | EVS-Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id Vendor-Id
The 4 octets are the Network Management Private Enterprise Code The 4 octets of the Vendor-Id field are the Network Management
[PEN] of the Vendor in network byte order. Private Enterprise Code [PEN] of the vendor in network byte order.
Vendor-Type EVS-Type
The Vendor-Type field is one octet. Values are assigned at the The EVS-Type field is one octet. Values are assigned at the sole
sole discretion of the Vendor. discretion of the vendor.
Vendor-Value EVS-Value
The Vendor-Value field is one or more octets. It SHOULD The EVS-Value field is one or more octets. It SHOULD encapsulate
encapsulate a standard RADIUS data type. Using non-standard data a standard RADIUS data type. Using non-standard data types is NOT
types is NOT RECOMMENDED. We note that the Value field may be of RECOMMENDED. We note that the EVS-Value field may be of data type
data type "tlv". However, it MUST NOT be of data type "evs", as TLV. However, it MUST NOT be of data type "evs", as the use cases
the use cases are unclear for one vendor delegating Attribute Type are unclear for one vendor delegating Attribute Type space to
space to another vendor. another vendor.
The actual format of the information is site or application The actual format of the information is site or application
specific, and a robust implementation SHOULD support the field as specific, and a robust implementation SHOULD support the field as
undistinguished octets. We recognise that Vendors have complete undistinguished octets. While we recognize that vendors have
control over the contents and format of the Value field, while at complete control over the contents and format of the EVS-Value
the same time recommending that good practices be followed. field, we recommend that good practices be followed.
Further codification of the range of allowed usage of this field Further codification of the range of allowed usage of this field
is outside the scope of this specification. is outside the scope of this specification.
Note that unlike the format described in [RFC2865] Section 5.26, this Note that unlike the format described in [RFC2865] Section 5.26, this
data type has no "Vendor length" field. The length of the Vendor- data type has no "Vendor-Length" field. The length of the EVS-Value
Value field is implicit, and is determined by taking the "Length" of field is implicit and is determined by taking the "Length" of the
the encapsulating RADIUS Attribute, and subtracting the length of the encapsulating RADIUS attribute and then subtracting the length of the
attribute header (2 octets), the extended type (1 octet), the Vendor- Attribute header (2 octets), the "Extended Type" (1 octet), the
Id (4 octets), and the Vendor-type (1 octet). i.e. For "Extended Vendor-Id (4 octets), and the EVS-Type (1 octet). That is, for
Type" attributes, the length of the Vendor-Value field is eight (8) "Extended Type" Attributes the length of the EVS-Value field is eight
less than the value of the Length field. For "Long Extended Type" (8) less than the value of the Length field, and for "Long Extended
attributes, the length of the Vendor-Value field is nine (9) less Type" Attributes the length of the EVS-Value field is nine (9) less
than the value of the Length field. than the value of the Length field.
2.5. Integer64 Data Type 2.5. Integer64 Data Type
We define a new data type in RADIUS, called "integer64", which We define a new data type in RADIUS, called "integer64", which
carries a 64-bit unsigned integer in network byte order. carries a 64-bit unsigned integer in network byte order.
This data type is intended to be used in any situation where there is This data type is intended to be used in any situation where there is
a need to have counters which can count past 2^32. The expected use a need to have counters that can count past 2^32. The expected use
of this data type is within Accounting-Request packets, but this data of this data type is within Accounting-Request packets, but this data
type SHOULD be used in any packet where 32-bit integers are expected type SHOULD be used in any packet where 32-bit integers are expected
to be insufficient. to be insufficient.
The "integer64" data type can be used in Attributes of any format, The "integer64" data type can be used in Attributes of any format,
standard space, extended attributes, TLVs, and VSAs. standard space, extended attributes, TLVs, and VSAs.
A summary of the "integer64" data type format is shown below. The A summary of the "integer64" data type format is shown below. The
fields are transmitted from left to right. fields are transmitted from left to right.
skipping to change at page 18, line 37 skipping to change at page 16, line 43
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attributes having data type "integer64" MUST have the relevant Length Attributes having data type "integer64" MUST have the relevant Length
field set to eight more than the length of the Attribute header. For field set to eight more than the length of the Attribute header. For
standard space Attributes and TLVs, this means that the Length field standard space Attributes and TLVs, this means that the Length field
MUST be set to ten (10). For "Extended Type" Attributes, the Length MUST be set to ten (10). For "Extended Type" Attributes, the Length
field MUST be set to eleven (11). For "Long Extended Type" field MUST be set to eleven (11). For "Long Extended Type"
Attributes, the Length field MUST be set to twelve (12). Attributes, the Length field MUST be set to twelve (12).
2.6. Vendor-ID Field 2.6. Vendor-Id Field
We define the Vendor-ID field of Vendor-Specific Attributes to We define the Vendor-Id field of Vendor-Specific Attributes
encompass the entire 4 octets of the Vendor field. [RFC2865] Section to encompass the entire 4 octets of the Vendor field.
5.26 defined it to be 3 octets, with the high octet being zero. This [RFC2865] Section 5.26 defined it to be 3 octets, with the fourth
change has no immediate impact on RADIUS, as the maximum Private octet being zero. This change has no immediate impact on RADIUS, as
Enterprise Code defined is still within 16 bits. the maximum Private Enterprise Code defined is still within 16 bits.
However, it is best to make advance preparations for changes in the However, it is best to make advance preparations for changes in the
protocol. As such, it is RECOMMENDED that all implementations protocol. As such, it is RECOMMENDED that all implementations
support four (4) octets for the Vendor-ID field, instead of three support four (4) octets for the Vendor-Id field, instead of
(3). three (3).
2.7. Attribute Naming and Type Identifiers 2.7. Attribute Naming and Type Identifiers
Attributes have traditionally been identified by a unique name and Attributes have traditionally been identified by a unique name and
number. For example, the attribute named "User-Name" has been number. For example, the Attribute "User-Name" has been allocated
allocated number one (1). This scheme needs to be extended in order number one (1). This scheme needs to be extended in order to be able
to be able to refer to attributes of Extended Type, and to TLVs. It to refer to attributes of "Extended Type", and to TLVs. It will also
will also be used by IANA for allocating RADIUS Attribute Type be used by IANA for allocating RADIUS Attribute Type values.
values.
The names and identifiers given here are intended to be used only in The names and identifiers given here are intended to be used only in
specifications. The system presented here may not be useful when specifications. The system presented here may not be useful when
referring to the contents of a RADIUS packet. It imposes no referring to the contents of a RADIUS packet. It imposes no
requirements on implementations, as implementations are free to requirements on implementations, as implementations are free to
reference RADIUS Attributes via any method they choose. reference RADIUS attributes via any method they choose.
2.7.1. Attribute and TLV Naming 2.7.1. Attribute and TLV Naming
RADIUS specifications traditionally use names consisting of one or RADIUS specifications traditionally use names consisting of one or
more words, separated by hyphens, e.g. "User-Name". However, these more words, separated by hyphens, e.g., "User-Name". However, these
names are not allocated from a registry, and there is no restriction names are not allocated from a registry, and there is no restriction
other than convention on their global uniqueness. other than convention on their global uniqueness.
Similarly, vendors have often used their company name as the prefix Similarly, vendors have often used their company name as the prefix
for VSA names, though this practice is not universal. For example, for VSA names, though this practice is not universal. For example,
for a vendor named "Example", the name "Example-Attribute-Name" for a vendor named "Example", the name "Example-Attribute-Name"
SHOULD be used instead of "Attribute-Name". The second form can SHOULD be used instead of "Attribute-Name". The second form can
conflict with attributes from other vendors, whereas the first form conflict with attributes from other vendors, whereas the first form
cannot. cannot.
It is therefore RECOMMENDED that specifications give names to It is therefore RECOMMENDED that specifications give names to
Attributes which attempt to be globally unique across all RADIUS Attributes that attempt to be globally unique across all RADIUS
Attributes. It is RECOMMENDED that vendors use their name as a Attributes. It is RECOMMENDED that a vendor use its name as a unique
unique prefix for attribute names, e.g. Livingston-IP-Pool instead of prefix for attribute names, e.g., Livingston-IP-Pool instead of
IP-Pool. It is RECOMMENDED that implementations enforce uniqueness IP-Pool. It is RECOMMENDED that implementations enforce uniqueness
on names, which would otherwise lead to ambiguity and problems. on names; not doing so would lead to ambiguity and problems.
We recognise that these suggestions may sometimes be difficult to We recognize that these suggestions may sometimes be difficult to
implement in practice. implement in practice.
TLVs SHOULD be named with a unique prefix that is shared among TLVs SHOULD be named with a unique prefix that is shared among
related attributes. For example, a specification that defines a set related attributes. For example, a specification that defines a set
of TLVs related to time could create attributes named "Time-Zone", of TLVs related to time could create attributes called "Time-Zone",
"Time-Day", "Time-Hour", "Time-Minute", etc. "Time-Day", "Time-Hour", "Time-Minute", etc.
2.7.2. Attribute Type Identifiers 2.7.2. Attribute Type Identifiers
The RADIUS Attribute Type space defines a context for a particular The RADIUS Attribute Type space defines a context for a particular
"Extended-Type" field. The "Extended-Type" field allows for 256 "Extended-Type" field. The "Extended-Type" field allows for 256
possible type code values, with values 1 through 240 available for possible type code values, with values 1 through 240 available for
allocation. We define here an identification method that uses a allocation. We define here an identification method that uses a
"dotted number" notation similar to that used for Object Identifiers "dotted number" notation similar to that used for Object Identifiers
(OIDs), formatted as "Type.Extended-Type". (OIDs), formatted as "Type.Extended-Type".
For example, an attribute within the Type space of 241, having For example, an attribute within the Type space of 241, having
Extended-Type of one (1), is uniquely identified as "241.1". Extended-Type of one (1), is uniquely identified as "241.1".
Similarly, an attribute within the Type space of 246, having Similarly, an attribute within the Type space of 246, having
Extended-Type of ten (10), is uniquely identified as "246.10". Extended-Type of ten (10), is uniquely identified as "246.10".
2.7.3. TLV Identifiers 2.7.3. TLV Identifiers
We can extend the Attribute reference scheme defined above for TLVs. We can extend the Attribute reference scheme defined above for TLVs.
This is done by leveraging the "dotted number" notation. As above, This is done by leveraging the "dotted number" notation. As above,
we define an additional TLV type space, within the "Extended Type" we define an additional TLV Type space, within the "Extended Type"
space, by appending another "dotted number" in order to identify the space, by appending another "dotted number" in order to identify the
TLV. This method can be repeated in sequence for nested TLVs. TLV. This method can be repeated in sequence for nested TLVs.
For example, let us say that "245.1" identifies RADIUS Attribute Type For example, let us say that "245.1" identifies RADIUS Attribute Type
245, containing an "Extended Type" of one (1), which is of type 245, containing an "Extended Type" of one (1), which is of type
"tlv". That attribute will contain 256 possible TLVs, one for each "TLV". That attribute will contain 256 possible TLVs, one for each
value of the TLV-Type field. The first TLV-Type value of one (1) can value of the TLV-Type field. The first TLV-Type value of one (1) can
then be identified by appending a ".1" to the number of the then be identified by appending a ".1" to the number of the
encapsulating attribute ("241.1"), to yield "241.1.1". Similarly, encapsulating attribute ("241.1"), to yield "241.1.1". Similarly,
the sequence "245.2.3.4" identifies RADIUS attribute 245, containing the sequence "245.2.3.4" identifies RADIUS attribute 245, containing
an "Extended Type" of two (2) which is of type "tlv", which in turn an "Extended Type" of two (2), which is of type "TLV", which in turn
contains a TLV with TLV-Type number three (3), which in turn contains contains a TLV with TLV-Type number three (3), which in turn contains
another TLV, with TLV-Type number four (4). another TLV, with TLV-Type number four (4).
2.7.4. VSA Identifiers 2.7.4. VSA Identifiers
There has historically been no method for numerically addressing There has historically been no method for numerically addressing
VSAs. The "dotted number" method defined here can also be leveraged VSAs. The "dotted number" method defined here can also be leveraged
to create such an addressing scheme. However, as the VSAs are to create such an addressing scheme. However, as the VSAs are
completely under the control of each individual vendor, this section completely under the control of each individual vendor, this section
provides a suggested practice, but does not define a standard of any provides a suggested practice but does not define a standard of any
kind. kind.
The Vendor-Specific Attribute has been assigned the Attribute number The Vendor-Specific Attribute has been assigned the Attribute
26. It in turn carries a 24-bit Vendor-Id, and possibly additional number 26. It in turn carries a 32-bit Vendor-Id, and possibly
VSAs. Where the VSAs follow the [RFC2865] Section 5.26 recommended additional VSAs. Where the VSAs follow the format recommended
format, a VSA can be identified as "26.Vendor-Id.Vendor-Type". by [RFC2865] Section 5.26, a VSA can be identified as
"26.Vendor-Id.Vendor-Type".
For example, Livingston has Vendor-Id 307, and has defined an For example, Livingston has Vendor-Id 307 and has defined an
attribute "IP-Pool" as number 6. This VSA can be uniquely identified attribute "IP-Pool" as number 6. This VSA can be uniquely identified
as 26.307.6, but it cannot be uniquely identified by name, as other as 26.307.6, but it cannot be uniquely identified by name, as other
vendors may have used the same name. vendors may have used the same name.
Note that there are few restrictions on the size of the numerical Note that there are few restrictions on the size of the numerical
values in this notation. The Vendor-Id is a 24-bit number, and the values in this notation. The Vendor-Id is a 32-bit number, and the
VSA may have been assigned from a 16-bit vendor-specific Attribute VSA may have been assigned from a 16-bit Vendor-Specific Attribute
Type space. Implementations SHOULD be capable of handling 32-bit Type space. Implementations SHOULD be capable of handling 32-bit
numbers at each level of the "dotted number" notation. numbers at each level of the "dotted number" notation.
For example, the company USR has been allocated Vendor-Id 429, and For example, the company USR has historically used Vendor-Id 429 and
has defined a "Version-Id" attribute as number 32768. This VSA can has defined a "Version-Id" attribute as number 32768. This VSA can
be uniquely identified as 26.429.32768, and again cannot be uniquely be uniquely identified as 26.429.32768 but again cannot be uniquely
identified by name. identified by name.
Where a VSA is a TLV, the "dotted number" notation can be used as Where a VSA is a TLV, the "dotted number" notation can be used as
above: 26.Vendor-Id.Vendor-Type.TLV1.TLV2.TLV3 where "TLVn" are the above: 26.Vendor-Id.Vendor-Type.TLV1.TLV2.TLV3, where the "TLVn"
numerical values assigned by the vendor to the different nested TLVs. values are the numerical values assigned by the vendor to the
different nested TLVs.
2.8. Invalid Attributes 2.8. Invalid Attributes
The term "invalid attribute" is new to this specification. It is The term "invalid attribute" is new to this specification. It is
defined to mean that the Length field of an Attribute permits the defined to mean that the Length field of an Attribute permits the
packet to be accepted as not being "malformed". However, the Value packet to be accepted as not being "malformed". However, the "Value"
field of the attribute does not follow the format required by the field of the Attribute does not follow the format required by the
data type defined for that Attribute, and therefore the attribute is data type defined for that Attribute, and therefore the Attribute is
"malformed". In order to distinguish the two cases, we refer to "malformed". In order to distinguish the two cases, we refer to
"malformed" packets, and "invalid attributes". "malformed" packets and "invalid attributes".
For example, an implementation receives a packet which is well- For example, an implementation receives a packet that is well formed.
formed. That packet contains an Attribute allegedly of data type That packet contains an Attribute allegedly of data type "address"
"address", but which has Length not equal to four. In that but that has Length not equal to four. In that situation, the packet
situation, the packet is well formed, but the attribute is not. is well formed, but the Attribute is not. Therefore, it is an
Therefore, it is an "invalid attribute". "invalid attribute".
A similar analysis can be performed when an attribute carries TLVs. A similar analysis can be performed when an attribute carries TLVs.
The encapsulating attribute may be well formed, but the TLV may be an The encapsulating attribute may be well formed, but the TLV may be an
"invalid attribute". The existence of an "invalid attribute" in a "invalid attribute". The existence of an "invalid attribute" in a
packet or attribute MUST NOT result in the implementation discarding packet or attribute MUST NOT result in the implementation discarding
the entire packet, or treating the packet as a negative the entire packet or treating the packet as a negative
acknowledgment. Instead, only the "invalid attribute" is treated acknowledgment. Instead, only the "invalid attribute" is treated
specially. specially.
When an implementation receives an "invalid attribute", it SHOULD be When an implementation receives an "invalid attribute", it SHOULD be
silently discarded, except when the implementation is acting as a silently discarded, except when the implementation is acting as a
proxy (see Section 5.2 for discussion of proxy servers). If it is proxy (see Section 5.2 for discussion of proxy servers). If it is
not discarded, it MUST NOT be handled in the same manner as a well- not discarded, it MUST NOT be handled in the same manner as a well-
formed attribute. For example, receiving an Attribute of data type formed attribute. For example, receiving an Attribute of data type
"address" containing less than four octets, or more than four octets "address" containing either less than four octets or more than
of data means that the Attribute MUST NOT be treated as being of data four octets of data means that the Attribute MUST NOT be treated as
type "address". The reason here is that if the attribute does not being of data type "address". The reason here is that if the
carry an IPv4 address, the receiver has no idea what format the data Attribute does not carry an IPv4 address, the receiver has no idea
is in, and it is therefore not an IPv4 address. what format the data is in, and it is therefore not an IPv4 address.
For Attributes of type "Long Extended Type", an Attribute is For Attributes of type "Long Extended Type", an Attribute is
considered to be an "invalid attribute" when it does not match the considered to be an "invalid attribute" when it does not match the
criteria set out in Section 2.2, above. criteria set out in Section 2.2, above.
For Attributes of type "TLV", an Attribute is considered to be an For Attributes of type "TLV", an Attribute is considered to be an
"invalid attribute" when the TLV-Length field allows the "invalid attribute" when the TLV-Length field allows the
encapsulating Attribute to be parsed, but the TLV-Value field does encapsulating Attribute to be parsed but the TLV-Value field does not
not match the criteria for that TLV. Implementations SHOULD NOT match the criteria for that TLV. Implementations SHOULD NOT treat
treat the "invalid attribute" property as being transitive. That is, the "invalid attribute" property as being transitive. That is, the
the Attribute encapsulating the "invalid attribute" SHOULD NOT be Attribute encapsulating the "invalid attribute" SHOULD NOT be treated
treated as an "invalid attribute". That encapsulating Attribute as an "invalid attribute". That encapsulating Attribute might
might contain multiple TLVs, only one of which is an "invalid contain multiple TLVs, only one of which is an "invalid attribute".
attribute".
However, a TLV definition may require particular sub-TLVs to be However, a TLV definition may require particular sub-TLVs to be
present, and/or to have specific values. If a sub-TLV is missing, or present and/or to have specific values. If a sub-TLV is missing or
contains incorrect value(s), or is an "invalid attribute", then the contains incorrect value(s), or if it is an "invalid attribute", then
encapsulating TLV SHOULD be treated as an "invalid attribute". This the encapsulating TLV SHOULD be treated as an "invalid attribute".
requirement ensures that strongly connected TLVs are handled either This requirement ensures that strongly connected TLVs are either
as a coherent whole, or are ignored entirely. handled as a coherent whole or ignored entirely.
It is RECOMMENDED that Attributes with unknown Type, Ext-Type, TLV- It is RECOMMENDED that Attributes with unknown Type, Extended-Type,
Type, or VSA-Type are treated as "invalid attributes". This TLV-Type, or EVS-Type are treated as "invalid attributes". This
recommendation is compatible with the suggestion in [RFC2865] Section recommendation is compatible with the suggestion in [RFC2865]
5, that implementations "MAY ignore Attributes with an unknown Type". Section 5 that implementations "MAY ignore Attributes with an
unknown Type".
3. Attribute Definitions 3. Attribute Definitions
We define four (4) attributes of "Extended Type", which are allocated We define four (4) attributes of "Extended Type", which are allocated
from the "Reserved" Attribute Type codes of 241, 242, 243, and 244. from the "Reserved" Attribute Type codes of 241, 242, 243, and 244.
We also define two (2) attributes of "Long Extended Type", which are We also define two (2) attributes of "Long Extended Type", which are
allocated from the "Reserved" Attribute Type codes of 245 and 246. allocated from the "Reserved" Attribute Type codes of 245 and 246.
Type Name Type Name
---- ---- ---- ----
241 Extended-Type-1 241 Extended-Type-1
242 Extended-Type-2 242 Extended-Type-2
243 Extended-Type-3 243 Extended-Type-3
244 Extended-Type-4 244 Extended-Type-4
245 Long-Extended-Type-1 245 Long-Extended-Type-1
246 Long-Extended-Type-2 246 Long-Extended-Type-2
The rest of this section gives a detailed definition for each The rest of this section gives detailed definitions for each
Attribute based on the above summary. Attribute based on the above summary.
3.1. Extended-Type-1 3.1. Extended-Type-1
Description Description
This attribute encapsulates attributes of the "Extended Type" This attribute encapsulates attributes of the "Extended Type"
format, in the RADIUS Attribute Type Space of 241.{1-255}. format, in the RADIUS Attribute Type space of 241.{1-255}.
A summary of the Extended-Type-1 Attribute format is shown below. A summary of the Extended-Type-1 Attribute format is shown below.
The fields are transmitted from left to right. The fields are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Value ... | Type | Length | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 33 skipping to change at page 22, line 9
241 for Extended-Type-1. 241 for Extended-Type-1.
Length Length
>= 4 >= 4
Extended-Type Extended-Type
The Extended-Type field is one octet. Up-to-date values of this The Extended-Type field is one octet. Up-to-date values of this
field are specified in the 241.{1-255} RADIUS Attribute Type field are specified in the 241.{1-255} RADIUS Attribute Type
Space, according to the policies and rules described in Section space, according to the policies and rules described in
10. Further definition of this field is given in Section 2.1, Section 10. Further definition of this field is given in
above. Section 2.1, above.
Value Value
The Value field is one or more octets. The "Value" field is one or more octets.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the interpretation identifier of "Type.Extended-Type" to determine the interpretation
of the Value field. of the "Value" field.
3.2. Extended-Type-2 3.2. Extended-Type-2
Description Description
This attribute encapsulates attributes of the "Extended Type" This attribute encapsulates attributes of the "Extended Type"
format, in the RADIUS Attribute Type Space of 242.{1-255}. format, in the RADIUS Attribute Type space of 242.{1-255}.
A summary of the Extended-Type-2 Attribute format is shown below. A summary of the Extended-Type-2 Attribute format is shown below.
The fields are transmitted from left to right. The fields are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Value ... | Type | Length | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 26 skipping to change at page 22, line 49
242 for Extended-Type-2. 242 for Extended-Type-2.
Length Length
>= 4 >= 4
Extended-Type Extended-Type
The Extended-Type field is one octet. Up-to-date values of this The Extended-Type field is one octet. Up-to-date values of this
field are specified in the 242.{1-255} RADIUS Attribute Type field are specified in the 242.{1-255} RADIUS Attribute Type
Space, according to the policies and rules described in Section space, according to the policies and rules described in
10. Further definition of this field is given in Section 2.1, Section 10. Further definition of this field is given in
above. Section 2.1, above.
Value Value
The Value field is one or more octets. The "Value" field is one or more octets.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the interpretation identifier of "Type.Extended-Type" to determine the interpretation
of the Value field of the "Value" field.
3.3. Extended-Type-3 3.3. Extended-Type-3
Description Description
This attribute encapsulates attributes of the "Extended Type" This attribute encapsulates attributes of the "Extended Type"
format, in the RADIUS Attribute Type Space of 243.{1-255}. format, in the RADIUS Attribute Type space of 243.{1-255}.
A summary of the Extended-Type-3 Attribute format is shown below. A summary of the Extended-Type-3 Attribute format is shown below.
The fields are transmitted from left to right. The fields are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Value ... | Type | Length | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
243 for Extended-Type-3. 243 for Extended-Type-3.
Length Length
>= 4 >= 4
skipping to change at page 25, line 19 skipping to change at page 23, line 41
243 for Extended-Type-3. 243 for Extended-Type-3.
Length Length
>= 4 >= 4
Extended-Type Extended-Type
The Extended-Type field is one octet. Up-to-date values of this The Extended-Type field is one octet. Up-to-date values of this
field are specified in the 243.{1-255} RADIUS Attribute Type field are specified in the 243.{1-255} RADIUS Attribute Type
Space, according to the policies and rules described in Section space, according to the policies and rules described in
10. Further definition of this field is given in Section 2.1, Section 10. Further definition of this field is given in
above. Section 2.1, above.
Value Value
The Value field is one or more octets. The "Value" field is one or more octets.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the interpretation identifier of "Type.Extended-Type" to determine the interpretation
of the Value field. of the "Value" field.
3.4. Extended-Type-4 3.4. Extended-Type-4
Description Description
This attribute encapsulates attributes of the "Extended Type" This attribute encapsulates attributes of the "Extended Type"
format, in the RADIUS Attribute Type Space of 244.{1-255}. format, in the RADIUS Attribute Type space of 244.{1-255}.
A summary of the Extended-Type-4 Attribute format is shown below. A summary of the Extended-Type-4 Attribute format is shown below.
The fields are transmitted from left to right. The fields are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Value ... | Type | Length | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 4 skipping to change at page 24, line 26
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Value ... | Type | Length | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
244 for Extended-Type-4. 244 for Extended-Type-4.
Length Length
>= 4 >= 4
Extended-Type Extended-Type
The Extended-Type field is one octet. Up-to-date values of this The Extended-Type field is one octet. Up-to-date values of this
field are specified in the 244.{1-255} RADIUS Attribute Type field are specified in the 244.{1-255} RADIUS Attribute Type
Space, according to the policies and rules described in Section space, according to the policies and rules described in
10. Further definition of this field is given in Section 2.1, Section 10. Further definition of this field is given in
above. Section 2.1, above.
Value Value
The Value field is one or more octets. The "Value" field is one or more octets.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the interpretation identifier of "Type.Extended-Type" to determine the interpretation
of the Value Field. of the Value Field.
3.5. Long-Extended-Type-1 3.5. Long-Extended-Type-1
Description Description
This attribute encapsulates attributes of the "Long Extended Type" This attribute encapsulates attributes of the "Long Extended Type"
format, in the RADIUS Attribute Type Space of 245.{1-255}. format, in the RADIUS Attribute Type space of 245.{1-255}.
A summary of the Long-Extended-Type-1 Attribute format is shown A summary of the Long-Extended-Type-1 Attribute format is shown
below. The fields are transmitted from left to right. below. The fields are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type |M| Reserved | | Type | Length | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... | Value ...
skipping to change at page 27, line 5 skipping to change at page 25, line 35
245 for Long-Extended-Type-1 245 for Long-Extended-Type-1
Length Length
>= 5 >= 5
Extended-Type Extended-Type
The Extended-Type field is one octet. Up-to-date values of this The Extended-Type field is one octet. Up-to-date values of this
field are specified in the 245.{1-255} RADIUS Attribute Type field are specified in the 245.{1-255} RADIUS Attribute Type
Space, according to the policies and rules described in Section space, according to the policies and rules described in
10. Further definition of this field is given in Section 2.1, Section 10. Further definition of this field is given in
above. Section 2.1, above.
M (More) M (More)
The More field is one (1) bit in length, and indicates whether or The More field is one (1) bit in length and indicates whether or
not the current attribute contains "more" than 251 octets of data. not the current attribute contains "more" than 251 octets of data.
Further definition of this field is given in Section 2.2, above. Further definition of this field is given in Section 2.2, above.
Reserved Reserved
This field is 7 bits long, and is reserved for future use. This field is 7 bits long and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an attribute Implementations MUST set it to zero (0) when encoding an attribute
for sending in a packet. The contents SHOULD be ignored on for sending in a packet. The contents SHOULD be ignored on
reception. reception.
Value Value
The Value field is one or more octets. The "Value" field is one or more octets.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the interpretation identifier of "Type.Extended-Type" to determine the interpretation
of the Value field. of the "Value" field.
3.6. Long-Extended-Type-2 3.6. Long-Extended-Type-2
Description Description
This attribute encapsulates attributes of the "Long Extended Type" This attribute encapsulates attributes of the "Long Extended Type"
format, in the RADIUS Attribute Type Space of 246.{1-255}. format, in the RADIUS Attribute Type space of 246.{1-255}.
A summary of the Long-Extended-Type-2 Attribute format is shown A summary of the Long-Extended-Type-2 Attribute format is shown
below. The fields are transmitted from left to right. below. The fields are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type |M| Reserved | | Type | Length | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... | Value ...
skipping to change at page 28, line 13 skipping to change at page 26, line 43
246 for Long-Extended-Type-2 246 for Long-Extended-Type-2
Length Length
>= 5 >= 5
Extended-Type Extended-Type
The Extended-Type field is one octet. Up-to-date values of this The Extended-Type field is one octet. Up-to-date values of this
field are specified in the 246.{1-255} RADIUS Attribute Type field are specified in the 246.{1-255} RADIUS Attribute Type
Space, according to the policies and rules described in Section space, according to the policies and rules described in
10. Further definition of this field is given in Section 2.1, Section 10. Further definition of this field is given in
above. Section 2.1, above.
M (More) M (More)
The More field is one (1) bit in length, and indicates whether or The More field is one (1) bit in length and indicates whether or
not the current attribute contains "more" than 251 octets of data. not the current attribute contains "more" than 251 octets of data.
Further definition of this field is given in Section 2.2, above. Further definition of this field is given in Section 2.2, above.
Reserved Reserved
This field is 7 bits long, and is reserved for future use. This field is 7 bits long and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an attribute Implementations MUST set it to zero (0) when encoding an attribute
for sending in a packet. The contents SHOULD be ignored on for sending in a packet. The contents SHOULD be ignored on
reception. reception.
Value Value
The Value field is one or more octets. The "Value" field is one or more octets.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the interpretation identifier of "Type.Extended-Type" to determine the interpretation
of the Value field. of the "Value" field.
4. Vendor Specific Attributes 4. Vendor-Specific Attributes
We define six new attributes which can carry Vendor Specific We define six new attributes that can carry vendor-specific
information. We define four (4) attributes of the "Extended Type" information. We define four (4) attributes of the "Extended Type"
format, with Type codes (241.26, 242.26, 243.26, 244.26), using the format, with Type codes (241.26, 242.26, 243.26, 244.26), using the
"evs" data type. We also define two (2) attributes using "Long "evs" data type. We also define two (2) attributes using "Long
Extended Type" format, with Type codes (245.26, 246.26), which are of Extended Type" format, with Type codes (245.26, 246.26), which are of
the "evs" data type. the "evs" data type.
Type.Extended-Type Name Type.Extended-Type Name
------------------ ---- ------------------ ----
241.26 Extended-Vendor-Specific-1 241.26 Extended-Vendor-Specific-1
242.26 Extended-Vendor-Specific-2 242.26 Extended-Vendor-Specific-2
243.26 Extended-Vendor-Specific-3 243.26 Extended-Vendor-Specific-3
244.26 Extended-Vendor-Specific-4 244.26 Extended-Vendor-Specific-4
245.26 Extended-Vendor-Specific-5 245.26 Extended-Vendor-Specific-5
246.26 Extended-Vendor-Specific-6 246.26 Extended-Vendor-Specific-6
The rest of this section gives a detailed definition for each The rest of this section gives detailed definitions for each
Attribute based on the above summary. Attribute based on the above summary.
4.1. Extended-Vendor-Specific-1 4.1. Extended-Vendor-Specific-1
Description Description
This attribute defines a RADIUS Type Code of 241.26, using the This attribute defines a RADIUS Type Code of 241.26, using the
"evs" data type. "evs" data type.
A summary of the Extended-Vendor-Specific-1 Attribute format is shown A summary of the Extended-Vendor-Specific-1 Attribute format is shown
skipping to change at page 29, line 40 skipping to change at page 28, line 35
Type.Extended-Type Type.Extended-Type
241.26 for Extended-Vendor-Specific-1 241.26 for Extended-Vendor-Specific-1
Length Length
>= 9 >= 9
Vendor-Id Vendor-Id
The 4 octets are the Network Management Private Enterprise Code The 4 octets of the Vendor-Id field are the Network Management
[PEN] of the Vendor in network byte order. Private Enterprise Code [PEN] of the vendor in network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the vendor.
Value Value
The Value field is one or more octets. The actual format of the The "Value" field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets. implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is The codification of the range of allowed usage of this field is
outside the scope of this specification. outside the scope of this specification.
The length of the Value field is eight (8) less than the value of The length of the "Value" field is eight (8) less than the value
the Length field. of the Length field.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to
determine the interpretation of the Value field. determine the interpretation of the "Value" field.
4.2. Extended-Vendor-Specific-2 4.2. Extended-Vendor-Specific-2
Description Description
This attribute defines a RADIUS Type Code of 242.26, using the This attribute defines a RADIUS Type Code of 242.26, using the
"evs" data type. "evs" data type.
A summary of the Extended-Vendor-Specific-2 Attribute format is shown A summary of the Extended-Vendor-Specific-2 Attribute format is shown
below. The fields are transmitted from left to right. below. The fields are transmitted from left to right.
skipping to change at page 30, line 46 skipping to change at page 29, line 42
Type.Extended-Type Type.Extended-Type
242.26 for Extended-Vendor-Specific-2 242.26 for Extended-Vendor-Specific-2
Length Length
>= 9 >= 9
Vendor-Id Vendor-Id
The 4 octets are the Network Management Private Enterprise Code The 4 octets of the Vendor-Id field are the Network Management
[PEN] of the Vendor in network byte order. Private Enterprise Code [PEN] of the vendor in network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the vendor.
Value Value
The Value field is one or more octets. The actual format of the The "Value" field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets. implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is The codification of the range of allowed usage of this field is
outside the scope of this specification. outside the scope of this specification.
The length of the Value field is eight (8) less than the value of The length of the "Value" field is eight (8) less than the value
the Length field. of the Length field.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to
determine the interpretation of the Value field. determine the interpretation of the "Value" field.
4.3. Extended-Vendor-Specific-3 4.3. Extended-Vendor-Specific-3
Description Description
This attribute defines a RADIUS Type Code of 243.26, using the This attribute defines a RADIUS Type Code of 243.26, using the
"evs" data type. "evs" data type.
A summary of the Extended-Vendor-Specific-3 Attribute format is shown A summary of the Extended-Vendor-Specific-3 Attribute format is shown
below. The fields are transmitted from left to right. below. The fields are transmitted from left to right.
skipping to change at page 32, line 4 skipping to change at page 30, line 50
Type.Extended-Type Type.Extended-Type
243.26 for Extended-Vendor-Specific-3 243.26 for Extended-Vendor-Specific-3
Length Length
>= 9 >= 9
Vendor-Id Vendor-Id
The 4 octets are the Network Management Private Enterprise Code
[PEN] of the Vendor in network byte order. The 4 octets of the Vendor-Id field are the Network Management
Private Enterprise Code [PEN] of the vendor in network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the vendor.
Value Value
The Value field is one or more octets. The actual format of the The "Value" field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets. implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is The codification of the range of allowed usage of this field is
outside the scope of this specification. outside the scope of this specification.
The length of the Value field is eight (8) less than the value of The length of the "Value" field is eight (8) less than the value
the Length field. of the Length field.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to
determine the interpretation of the Value field. determine the interpretation of the "Value" field.
4.4. Extended-Vendor-Specific-4 4.4. Extended-Vendor-Specific-4
Description Description
This attribute defines a RADIUS Type Code of 244.26, using the This attribute defines a RADIUS Type Code of 244.26, using the
"evs" data type. "evs" data type.
A summary of the Extended-Vendor-Specific-3 Attribute format is shown A summary of the Extended-Vendor-Specific-4 Attribute format is shown
below. The fields are transmitted from left to right. below. The fields are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Vendor-Id ... | Type | Length | Extended-Type | Vendor-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Vendor-Id (cont) | Vendor-Type | ... Vendor-Id (cont) | Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value .... | Value ....
skipping to change at page 33, line 11 skipping to change at page 32, line 7
Type.Extended-Type Type.Extended-Type
244.26 for Extended-Vendor-Specific-4 244.26 for Extended-Vendor-Specific-4
Length Length
>= 9 >= 9
Vendor-Id Vendor-Id
The 4 octets are the Network Management Private Enterprise Code The 4 octets of the Vendor-Id field are the Network Management
[PEN] of the Vendor in network byte order. Private Enterprise Code [PEN] of the vendor in network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the vendor.
Value Value
The Value field is one or more octets. The actual format of the The "Value" field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets. implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is The codification of the range of allowed usage of this field is
outside the scope of this specification. outside the scope of this specification.
The length of the Value field is eight (8) less than the value of The length of the "Value" field is eight (8) less than the value
the Length field. of the Length field.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to
determine the interpretation of the Value field. determine the interpretation of the "Value" field.
4.5. Extended-Vendor-Specific-5 4.5. Extended-Vendor-Specific-5
Description Description
This attribute defines a RADIUS Type Code of 245.26, using the This attribute defines a RADIUS Type Code of 245.26, using the
"evs" data type. "evs" data type.
A summary of the Extended-Vendor-Specific-5 Attribute format is shown A summary of the Extended-Vendor-Specific-5 Attribute format is shown
below. The fields are transmitted from left to right. below. The fields are transmitted from left to right.
skipping to change at page 34, line 18 skipping to change at page 33, line 15
245.26 for Extended-Vendor-Specific-5 245.26 for Extended-Vendor-Specific-5
Length Length
>= 10 (first fragment) >= 10 (first fragment)
>= 5 (subsequent fragments) >= 5 (subsequent fragments)
When a VSA is fragmented across multiple Attributes, only the When a VSA is fragmented across multiple Attributes, only the
first Attribute contains the Vendor-Id and Vendor-Type fields. first Attribute contains the Vendor-Id and Vendor-Type fields.
Subsequent Attributes contain fragments of the Value field only. Subsequent Attributes contain fragments of the "Value" field only.
M (More) M (More)
The More field is one (1) bit in length, and indicates whether or The More field is one (1) bit in length and indicates whether or
not the current attribute contains "more" than 251 octets of data. not the current attribute contains "more" than 251 octets of data.
Further definition of this field is given in Section 2.2, above. Further definition of this field is given in Section 2.2, above.
Reserved Reserved
This field is 7 bits long, and is reserved for future use. This field is 7 bits long and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an attribute Implementations MUST set it to zero (0) when encoding an attribute
for sending in a packet. The contents SHOULD be ignored on for sending in a packet. The contents SHOULD be ignored on
reception. reception.
Vendor-Id Vendor-Id
The 4 octets are the Network Management Private Enterprise Code The 4 octets of the Vendor-Id field are the Network Management
[PEN] of the Vendor in network byte order. Private Enterprise Code [PEN] of the vendor in network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the vendor.
Value Value
The Value field is one or more octets. The actual format of the The "Value" field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets. implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is The codification of the range of allowed usage of this field is
outside the scope of this specification. outside the scope of this specification.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to
determine the interpretation of the Value field. determine the interpretation of the "Value" field.
4.6. Extended-Vendor-Specific-6 4.6. Extended-Vendor-Specific-6
Description Description
This attribute defines a RADIUS Type Code of 246.26, using the This attribute defines a RADIUS Type Code of 246.26, using the
"evs" data type. "evs" data type.
A summary of the Extended-Vendor-Specific-6 Attribute format is shown A summary of the Extended-Vendor-Specific-6 Attribute format is shown
below. The fields are transmitted from left to right. below. The fields are transmitted from left to right.
skipping to change at page 35, line 38 skipping to change at page 34, line 36
246.26 for Extended-Vendor-Specific-6 246.26 for Extended-Vendor-Specific-6
Length Length
>= 10 (first fragment) >= 10 (first fragment)
>= 5 (subsequent fragments) >= 5 (subsequent fragments)
When a VSA is fragmented across multiple Attributes, only the When a VSA is fragmented across multiple Attributes, only the
first Attribute contains the Vendor-Id and Vendor-Type fields. first Attribute contains the Vendor-Id and Vendor-Type fields.
Subsequent Attributes contain fragments of the Value field only. Subsequent Attributes contain fragments of the "Value" field only.
M (More) M (More)
The More field is one (1) bit in length, and indicates whether or The More field is one (1) bit in length and indicates whether or
not the current attribute contains "more" than 251 octets of data. not the current attribute contains "more" than 251 octets of data.
Further definition of this field is given in Section 2.2, above. Further definition of this field is given in Section 2.2, above.
Reserved Reserved
This field is 7 bits long, and is reserved for future use. This field is 7 bits long and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an attribute Implementations MUST set it to zero (0) when encoding an attribute
for sending in a packet. The contents SHOULD be ignored on for sending in a packet. The contents SHOULD be ignored on
reception. reception.
Vendor-Id Vendor-Id
The 4 octets are the Network Management Private Enterprise Code The 4 octets of the Vendor-Id field are the Network Management
[PEN] of the Vendor in network byte order. Private Enterprise Code [PEN] of the vendor in network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the vendor.
Value Value
The Value field is one or more octets. The actual format of the The "Value" field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets. implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is The codification of the range of allowed usage of this field is
outside the scope of this specification. outside the scope of this specification.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to
determine the interpretation of the Value field. determine the interpretation of the "Value" field.
5. Compatibility with traditional RADIUS 5. Compatibility with Traditional RADIUS
There are a number of potential compatibility issues with traditional There are a number of potential compatibility issues with traditional
RADIUS, as defined in [RFC6158] and earlier. This section describes RADIUS, as defined in [RFC6158] and earlier. This section describes
them. them.
5.1. Attribute Allocation 5.1. Attribute Allocation
Some vendors have used Attribute Type codes from the "Reserved" Some vendors have used Attribute Type codes from the "Reserved" space
space, as part of vendor-defined dictionaries. This practice is as part of vendor-defined dictionaries. This practice is considered
considered anti-social behavior, as noted in [RFC6158]. These vendor antisocial behavior, as noted in [RFC6158]. These vendor definitions
definitions conflict with the attributes in the RADIUS Attribute Type conflict with the Attributes in the RADIUS Attribute Type space. The
space. The conflicting definitions may make it difficult for conflicting definitions may make it difficult for implementations to
implementations to support both those Vendor Attributes, and the new support both those Vendor Attributes, and the new Extended Attribute
Extended Attribute formats. formats.
We RECOMMEND that RADIUS client and server implementations delete all We RECOMMEND that RADIUS client and server implementations delete all
references to these improperly defined attributes. Failing that, we references to these improperly defined attributes. Failing that, we
RECOMMEND that RADIUS server implementations have a per-client RECOMMEND that RADIUS server implementations have a per-client
configurable flag which indicates which type of attributes are being configurable flag that indicates which type of attributes are being
sent from the client. If the flag is set to "Non-Standard sent from the client. If the flag is set to "Non-Standard
Attributes", the conflicting attributes can be interpreted as being Attributes", the conflicting attributes can be interpreted as being
improperly defined Vendor Specific Attributes. If the flag is set the improperly defined Vendor-Specific Attributes. If the flag is set to
"IETF Attributes", the attributes MUST be interpreted as being of the "IETF Attributes", the Attributes MUST be interpreted as being of the
Extended Attributes format. The default SHOULD be to interpret the Extended Attributes format. The default SHOULD be to interpret the
attributes as being of the Extended Attributes format. Attributes as being of the Extended Attributes format.
Other methods of determining how to decode the attributes into a Other methods of determining how to decode the Attributes into a
"correct" form are NOT RECOMMENDED. Those methods are likely to be "correct" form are NOT RECOMMENDED. Those methods are likely to be
fragile and prone to error. fragile and prone to error.
We RECOMMEND that RADIUS server implementations re-use the above flag We RECOMMEND that RADIUS server implementations reuse the above flag
to determine which type of attributes to send in a reply message. If to determine which types of attributes to send in a reply message.
the request is expected to contain the improperly defined attributes, If the request is expected to contain the improperly defined
the reply SHOULD NOT contain Extended Attributes. If the request is attributes, the reply SHOULD NOT contain Extended Attributes. If the
expected to contain Extended Attributes, the reply MUST NOT contain request is expected to contain Extended Attributes, the reply MUST
the improper Attributes. NOT contain the improper Attributes.
RADIUS clients will have fewer issues than servers. Clients MUST NOT RADIUS clients will have fewer issues than servers. Clients MUST NOT
send improperly defined Attributes in a request. For replies, send improperly defined Attributes in a request. For replies,
clients MUST interpret attributes as being of the Extended Attributes clients MUST interpret attributes as being of the Extended Attributes
format, instead of the improper definitions. These requirements format, instead of the improper definitions. These requirements
impose no change in the RADIUS specifications, as such usage by impose no change in the RADIUS specifications, as such usage by
vendors has always been in conflict with the standard requirements vendors has always been in conflict with the standard requirements
and the standards process. and the standards process.
Existing clients that send these improperly defined attributes Existing clients that send these improperly defined attributes
usually have a configuration setting which can disable this behavior. usually have a configuration setting that can disable this behavior.
We RECOMMEND that vendors ship products with the default set to We RECOMMEND that vendors ship products with the default set to
"disabled". We RECOMMEND that administrators set this flag to "disabled". We RECOMMEND that administrators set this flag to
"disabled" on all equipment that they manage. "disabled" on all equipment that they manage.
5.2. Proxy Servers 5.2. Proxy Servers
RADIUS Proxy servers will need to forward Attributes having the new RADIUS proxy servers will need to forward Attributes having the new
format, even if they do not implement support for the encoding and format, even if they do not implement support for the encoding and
decoding of those attributes. We remind implementers of the decoding of those attributes. We remind implementers of the
following text in [RFC2865] Section 2.3: following text in [RFC2865] Section 2.3:
The forwarding server MUST NOT change the order of any attributes The forwarding server MUST NOT change the order of any attributes
of the same type, including Proxy-State. of the same type, including Proxy-State.
This requirement solves some of the issues related to proxying of the This requirement solves some of the issues related to proxying of the
new format, but not all. The reason is that proxy servers are new format, but not all. The reason is that proxy servers are
permitted to examine the contents of the packets that they forward. permitted to examine the contents of the packets that they forward.
Many proxy implementations not only examine the attributes, but they Many proxy implementations not only examine the Attributes, but they
refuse to forward attributes which they do not understand (i.e. refuse to forward attributes that they do not understand (i.e.,
attributes for which they have no local dictionary definitions). attributes for which they have no local dictionary definitions).
This practice is NOT RECOMMENDED. Proxy servers SHOULD forward This practice is NOT RECOMMENDED. Proxy servers SHOULD forward
attributes, even ones which they do not understand, or which are not attributes, even attributes that they do not understand or that are
in a local dictionary. When forwarded, these attributes SHOULD be not in a local dictionary. When forwarded, these attributes SHOULD
sent verbatim, with no modifications or changes. This requirement be sent verbatim, with no modifications or changes. This requirement
includes "invalid attributes", as there may be some other system in includes "invalid attributes", as there may be some other system in
the network which understands them. the network that understands them.
The only exception to this recommendation is when local site policy The only exception to this recommendation is when local site policy
dictates that filtering of attributes has to occur. For example, a dictates that filtering of attributes has to occur. For example, a
filter at a visited network may require removal of certain filter at a visited network may require removal of certain
authorization rules which apply to the home network, but not to the authorization rules that apply to the home network but not to the
visited network. This filtering can sometimes be done even when the visited network. This filtering can sometimes be done even when the
contents of the attributes are unknown, such as when all Vendor- contents of the Attributes are unknown, such as when all Vendor-
Specific Attributes are designated for removal. Specific Attributes are designated for removal.
As seen in [EDUROAM] many proxies do not follow these practices for As seen during testing performed in 2010 via the EDUcation ROAMing
unknown Attributes. Some proxies filter out unknown attributes or (EDUROAM) service (A. DeKok, unpublished data), many proxies do not
attributes which have unexpected lengths (24%, 17/70), some truncate follow these practices for unknown Attributes. Some proxies filter
the attributes to the "expected" length (11%, 8/70), some discard the out unknown attributes or attributes that have unexpected lengths
request entirely (1%, 1/70), with the rest (63%, 44/70) following the (24%, 17/70), some truncate the Attributes to the "expected" length
recommended practice of passing the attributes verbatim. It will be (11%, 8/70), some discard the request entirely (1%, 1/70), and the
difficult to widely use the Extended Attributes format until all non- rest (63%, 44/70) follow the recommended practice of passing the
conformant proxies are fixed. We therefore RECOMMEND that all Attributes verbatim. It will be difficult to widely use the Extended
proxies which do not support the Extended Attributes (241 through Attributes format until all non-conformant proxies are fixed. We
246) define them as being of data type "string", and delete all other therefore RECOMMEND that all proxies that do not support the Extended
local definitions for those attributes. Attributes (241 through 246) define them as being of data type
"string" and delete all other local definitions for those attributes.
This last change should enable wider usage of the Extended Attributes This last change should enable wider usage of the Extended Attributes
format. format.
6. Guidelines 6. Guidelines
This specification proposes a number of changes to RADIUS, and This specification proposes a number of changes to RADIUS and
therefore requires a set of guidelines, as has been done in therefore requires a set of guidelines, as has been done in
[RFC6158]. These guidelines include suggestions around design, [RFC6158]. These guidelines include suggestions related to design,
interaction with IANA, usage, and implementation of attributes using interaction with IANA, usage, and implementation of attributes using
the new formats. the new formats.
6.1. Updates to RFC 6158 6.1. Updates to RFC 6158
This specification updates [RFC6158] by adding the data types "evs", This specification updates [RFC6158] by adding the data types "evs",
"tlv" and "integer64"; defining them to be "basic" data types; and "tlv", and "integer64"; defining them to be "basic" data types; and
permitting their use subject to the restrictions outlined below. permitting their use subject to the restrictions outlined below.
The recommendations for the use of the new data types and attribute The recommendations for the use of the new data types and Attribute
formats are given below. formats are given below.
6.2. Guidelines for Simple Data Types 6.2. Guidelines for Simple Data Types
[RFC6158] Section A.2.1 says in part: [RFC6158] Section A.2.1 says in part:
* Unsigned integers of size other than 32 bits. * Unsigned integers of size other than 32 bits. SHOULD be replaced
by an unsigned integer of 32 bits. There is insufficient
SHOULD be replaced by an unsigned integer of 32 bits. There is justification to define a new size of integer.
insufficient justification to define a new size of integer.
We update that specification to permit unsigned integers of 64 bits, We update that specification to permit unsigned integers of 64 bits,
for the reasons defined above in Section 2.5. The updated text is as for the reasons defined above in Section 2.5. The updated text is as
follows: follows:
* Unsigned integers of size other than 32 or 64 bits. * Unsigned integers of size other than 32 or 64 bits. SHOULD be
SHOULD be replaced by an unsigned integer of 32 or 64 bits. replaced by an unsigned integer of 32 or 64 bits. There is
There is insufficient justification to define a new size insufficient justification to define a new size of integer.
of integer.
That section later continues with the following list item: That section later continues with the following list item:
* Nested attribute-value pairs (AVPs). * Nested attribute-value pairs (AVPs). Attributes should be defined
Attributes should be defined in a flat typespace. in a flat typespace.
We update that specification to permit nested TLVs, as defined in We update that specification to permit nested TLVs, as defined in
this document: this document:
* Nested attribute-value pairs (AVPs) using the extended * Nested attribute-value pairs (AVPs) using the extended Attribute
attribute format MAY be used. All other nested AVP or TLV format MAY be used. All other nested AVP or TLV formats MUST NOT
formats MUST NOT be used. be used.
The [RFC6158] recommendations for "basic" data types apply to the The [RFC6158] recommendations for "basic" data types apply to the
three types listed above. All other recommendations given in three types listed above. All other recommendations given in
[RFC6158] for "basic" data types remain unchanged. [RFC6158] for "basic" data types remain unchanged.
6.3. Guidelines for Complex Data Types 6.3. Guidelines for Complex Data Types
[RFC6158] Section 2.1 says: [RFC6158] Section 2.1 says:
Complex data types MAY be used in situations where they reduce Complex data types MAY be used in situations where they reduce
complexity in non-RADIUS systems or where using the basic data complexity in non-RADIUS systems or where using the basic data
types types would be awkward (such as where grouping would be required
would be awkward (such as where grouping would be required in in order to link related attributes).
order
to link related attributes).
Since the extended attribute format allows for grouping of complex Since the extended Attribute format allows for grouping of complex
types via TLVs, the guidelines for complex data types need to be types via TLVs, the guidelines for complex data types need to be
updated as follows: updated as follows:
[RFC6158], Section 3.2.4, describes situations in which complex [RFC6158], Section 3.2.4, describes situations in which complex
data types might be appropriate. They SHOULD NOT be used even in data types might be appropriate. They SHOULD NOT be used even in
those situations, without careful consideration of the described those situations, without careful consideration of the described
limitations. In all other cases not covered by the complex data limitations. In all other cases not covered by the complex data
type exceptions, complex data types MUST NOT be used. Instead, type exceptions, complex data types MUST NOT be used. Instead,
complex data types MUST be decomposed into TLVs. complex data types MUST be decomposed into TLVs.
The checklist in Appendix A.2.2 is similarly updated to add a new The checklist in [RFC6158] Appendix A.2.2 is similarly updated to add
requirement at the top of that section, a new requirement at the top of that section, as follows:
Does the attribute: Does the Attribute
* define a complex type which can be represented via TLVs? * define a complex type that can be represented via TLVs?
If so, this data type MUST be represented via TLVs. If so, this data type MUST be represented via TLVs.
Note that this requirement does not over-ride Section A.1, which Note that this requirement does not override [RFC6158] Appendix A.1,
permits the transport of complex types in certain situations. which permits the transport of complex types in certain situations.
All other recommendations given in [RFC6158] for "complex" data types All other recommendations given in [RFC6158] for "complex" data types
remain unchanged. remain unchanged.
6.4. Design Guidelines For the New Types 6.4. Design Guidelines for the New Types
This section gives design guidelines for specifications defining This section gives design guidelines for specifications defining
attributes using the new format. The items listed below are not attributes using the new format. The items listed below are not
exhaustive. As experience is gained with the new formats, later exhaustive. As experience is gained with the new formats, later
specifications may define additional guidelines. specifications may define additional guidelines.
* The data type "evs" MUST NOT be used for standard RADIUS * The data type "evs" MUST NOT be used for standard RADIUS
Attributes, or for TLVs, or for VSAs. Attributes, or for TLVs, or for VSAs.
* The data type "tlv" SHOULD NOT be used for standard RADIUS * The data type TLV SHOULD NOT be used for standard RADIUS
attributes. attributes.
* [RFC2866] "tagged" attributes MUST NOT be defined in the * [RFC2866] "tagged" attributes MUST NOT be defined in the
Extended-Type space. The "tlv" data type should be used instead Extended-Type space. The "tlv" data type should be used instead to
to group attributes. group attributes.
* The "integer64" data type MAY be used in any RADIUS attribute. * The "integer64" data type MAY be used in any RADIUS attribute. The
The use of 64-bit integers was not recommended in [RFC6158], use of 64-bit integers was not recommended in [RFC6158], but their
but their utility is now evident. utility is now evident.
* Any attribute which is allocated from the "long extended space" of * Any attribute that is allocated from the long extended space of
data type "text", "string", or "tlv" can potentially carry more data type "text", "string", or "tlv" can potentially carry more
than 251 octets of data. Specifications defining such attributes than 251 octets of data. Specifications defining such attributes
SHOULD define a maximum length to guide implementations. SHOULD define a maximum length to guide implementations.
All other recommendations given in [RFC6158] for attribute design All other recommendations given in [RFC6158] for attribute design
guidelines apply to attributes using the "short extended space" and guidelines apply to attributes using the short extended space and
"long extended space". long extended space.
6.5. TLV Guidelines 6.5. TLV Guidelines
The following items give design guidelines for specifications using The following items give design guidelines for specifications using
TLVs. TLVs.
* when multiple attributes are intended to be grouped or managed * When multiple Attributes are intended to be grouped or managed
together, the use of TLVs to group related attributes is together, the use of TLVs to group related attributes is
RECOMMENDED. RECOMMENDED.
* more than 4 layers (depth) of TLV nesting is NOT RECOMMENDED. * More than 4 layers (depth) of TLV nesting is NOT RECOMMENDED.
* Interpretation of an attribute depends only on its type * Interpretation of an attribute depends only on its type definition
definition (e.g. Type.Extended-Type.TLV-Type), and (e.g., Type.Extended-Type.TLV-Type) and not on its encoding or
not on its encoding or location in the RADIUS packet. location in the RADIUS packet.
* Where a group of TLVs is strictly defined, and not expected to * Where a group of TLVs is strictly defined, and not expected to
change, and totals less than 247 octets of data, they SHOULD change, and totals less than 247 octets of data, the specifications
request allocation from the "short extended space". SHOULD request allocation from the short extended space.
* Where a group of TLVs is loosely defined, or is expected to change, * Where a group of TLVs is loosely defined or is expected to change,
they SHOULD request allocation from the "long extended space". the specifications SHOULD request allocation from the long extended
space.
All other recommendations given in [RFC6158] for attribute design All other recommendations given in [RFC6158] for attribute design
guidelines apply to attributes using the TLV format. guidelines apply to attributes using the TLV format.
6.6. Allocation Request Guidelines 6.6. Allocation Request Guidelines
The following items give guidelines for allocation requests made in a The following items give guidelines for allocation requests made in a
RADIUS specification. RADIUS specification.
* Discretion is recommended when requesting allocation of attributes. * Discretion is recommended when requesting allocation of attributes.
The new space is much larger than the old one, but it is not The new space is much larger than the old one, but it is not
infinite. infinite.
* Specifications which allocate many attributes MUST NOT request that * Specifications that allocate many attributes MUST NOT request that
allocation be made from the standard space. That space is under allocation be made from the standard space. That space is under
allocation pressure, and the extended space is more suitable for allocation pressure, and the extended space is more suitable for
large allocations. As a guideline, we suggest that one large allocations. As a guideline, we suggest that one
specification allocating twenty percent (20%) or more of the specification allocating twenty percent (20%) or more of the
standard space would meet the above criteria. standard space would meet the above criteria.
* Specifications which allocate many related attributes SHOULD define * Specifications that allocate many related attributes SHOULD define
one or more TLVs to contain related attributes. one or more TLVs to contain related attributes.
* Specifications SHOULD request allocation from a specific space. * Specifications SHOULD request allocation from a specific space.
The IANA considerations given in Section 9, below, give instruction The IANA considerations given in Section 10, below, give
to IANA, but authors should assist IANA where possible. instructions to IANA, but authors should assist IANA where
possible.
* Specifications of an attribute which encodes 252 octets or less of * Specifications of an attribute that encodes 252 octets or less of
data MAY request allocation from the "short extended space". data MAY request allocation from the short extended space.
* Specifications of an attribute which always encode less than 253 * Specifications of an attribute that always encode less than
octets of data MUST NOT request allocation from the long extended 253 octets of data MUST NOT request allocation from the long
space. The standard space, or the short extended space MUST be extended space. The standard space or the short extended space
used instead. MUST be used instead.
* Specifications of an attribute which encodes 253 octets or more of * Specifications of an attribute that encodes 253 octets or more of
data MUST request allocation from the "long extended space". data MUST request allocation from the long extended space.
* When the extended space is nearing exhaustion, a new specification * When the extended space is nearing exhaustion, a new specification
will have to be written which requests allocation of one or more will have to be written that requests allocation of one or more
RADIUS Attributes from the "Reserved" portion of the standard RADIUS attributes from the "Reserved" portion of the standard
space, values 247-255, using an appropriate format ("Short space, values 247-255, using an appropriate format ("Short Extended
Extended Type", or "Long Extended Type") Type", or "Long Extended Type").
An allocation request made in a specification SHOULD use one of the An allocation request made in a specification SHOULD use one of the
following formats when allocating an attribute type code: following formats when allocating an attribute type code:
* TBDn - request allocation of an attribute from the "standard * TBDn - request allocation of an attribute from the standard space.
space". The value "n" should be "1" or more, to track individual The value "n" should be 1 or more, to track individual attributes
attributes which are to be allocated. that are to be allocated.
* SHORT-TBDn - request allocation of an attribute from the "short * SHORT-TBDn - request allocation of an attribute from the short
extended space". The value "n" should be "1" or more, to track extended space. The value "n" should be 1 or more, to track
individual attributes which are to be allocated. individual attributes that are to be allocated.
* LONG-TBDn - request allocation of an attribute from the "long * LONG-TBDn - request allocation of an attribute from the long
extended space". The value "n" should be "1" or more, to track extended space. The value "n" should be 1 or more, to track
individual attributes which are to be allocated. individual attributes that are to be allocated.
These guidelines should help specification authors and IANA These guidelines should help specification authors and IANA
communicate effectively and clearly. communicate effectively and clearly.
6.7. Allocation Requests Guidelines for TLVs 6.7. Allocation Request Guidelines for TLVs
Specifications may allocate a new attribute of type TLV, and at the Specifications may allocate a new attribute of type TLV and at the
same time, allocate sub-attributes within that TLV. These same time allocate sub-Attributes within that TLV. These
specifications SHOULD request allocation of specific values for the specifications SHOULD request allocation of specific values for the
sub-TLV. The "dotted number" notation MUST be used. sub-TLV. The "dotted number" notation MUST be used.
For example, a specification may request allocation of a TLV as For example, a specification may request allocation of a TLV as
SHORT-TBD1. Within that attribute, it could request allocation of SHORT-TBD1. Within that attribute, it could request allocation of
three sub-TLVs, as SHORT-TBD1.1, SHORT-TBD1.2, and SHORT-TBD1.3. three sub-TLVs, as SHORT-TBD1.1, SHORT-TBD1.2, and SHORT-TBD1.3.
Specifications may request allocation of additional sub-TLVs within Specifications may request allocation of additional sub-TLVs within
an existing attribute of type TLV. Those specifications SHOULD use an existing attribute of type TLV. Those specifications SHOULD use
the "TBDn" format for every entry in the "dotted number" notation. the "TBDn" format for every entry in the "dotted number" notation.
For example, a specification may request allocation within an For example, a specification may request allocation within an
existing TLV, with "dotted number" notation MM.NN. Within that existing TLV, with "dotted number" notation MM.NN. Within that
attribute, the specification could request allocation of three sub- attribute, the specification could request allocation of three
TLVs, as MM.NN.TBD1, MM.NN.TBD2, and MM.NN.TBD3. sub-TLVs, as MM.NN.TBD1, MM.NN.TBD2, and MM.NN.TBD3.
6.8. Implementation Guidelines 6.8. Implementation Guidelines
* RADIUS client implementations SHOULD support this specification, * RADIUS client implementations SHOULD support this specification in
in order to permit the easy deployment of specifications using order to permit the easy deployment of specifications using the
the changes defined herein. changes defined herein.
* RADIUS server implementations SHOULD support this specification, * RADIUS server implementations SHOULD support this specification in
in order to permit the easy deployment of specifications using order to permit the easy deployment of specifications using the
the changes defined herein. changes defined herein.
* RADIUS proxy servers MUST follow the specifications in section 5.2 * RADIUS proxy servers MUST follow the specifications in Section 5.2.
6.9. Vendor Guidelines 6.9. Vendor Guidelines
* Vendors SHOULD use the existing Vendor-Specific Attribute Type * Vendors SHOULD use the existing Vendor-Specific Attribute Type
space in preference to the new Extended-Vendor-Specific space in preference to the new Extended-Vendor-Specific Attributes,
attributes, as this specification may take time to become widely as this specification may take time to become widely deployed.
deployed.
* Vendors SHOULD implement this specification. The changes to * Vendors SHOULD implement this specification. The changes to RADIUS
RADIUS are relatively small, and are likely to quickly be used are relatively small and are likely to quickly be used in new
in new specifications. specifications.
7. Rationale for This Design 7. Rationale for This Design
The path to extending the RADIUS protocol has been long and arduous. The path to extending the RADIUS protocol has been long and arduous.
A number of proposals have been made and discarded by the RADEXT A number of proposals have been made and discarded by the RADEXT
working group. These proposals have been judged to be either too working group. These proposals have been judged to be either too
bulky, too complex, too simple, or to be unworkable in practice. We bulky, too complex, too simple, or unworkable in practice. We do not
do not otherwise explain here why earlier proposals did not obtain otherwise explain here why earlier proposals did not obtain working
working group consensus. group consensus.
The changes outlined here have the benefit of being simple, as the The changes outlined here have the benefit of being simple, as the
"Extended Type" format requires only a one octet change to the "Extended Type" format requires only a one-octet change to the
Attribute format. The downside is that the "Long Extended Type" Attribute format. The downside is that the "Long Extended Type"
format is awkward, and the 7 Reserved bits will likely never be used format is awkward, and the 7 Reserved bits will likely never be used
for anything. for anything.
7.1. Attribute Audit 7.1. Attribute Audit
An audit of almost five thousand publicly available attributes [ATTR] An audit of almost five thousand publicly available attributes [ATTR]
(2010), shows the statistics summarized below. The attributes include (2010) shows the statistics summarized below. The Attributes include
over 100 Vendor dictionaries, along with the IANA assigned over 100 Vendor dictionaries, along with the IANA-assigned
attributes: attributes:
Count Data Type Count Data Type
----- --------- ----- ---------
2257 integer 2257 integer
1762 text 1762 text
273 IPv4 Address 273 IPv4 Address
225 string 225 string
96 other data types 96 other data types
35 IPv6 Address 35 IPv6 Address
skipping to change at page 44, line 32 skipping to change at page 43, line 38
4 Interface Id 4 Interface Id
3 IPv6 Prefix 3 IPv6 Prefix
4683 Total 4683 Total
The entries in the "Data Type" column are data types recommended by The entries in the "Data Type" column are data types recommended by
[RFC6158], along with "integer64". The "other data types" row [RFC6158], along with "integer64". The "other data types" row
encompasses all other data types, including complex data types and encompasses all other data types, including complex data types and
data types transporting opaque data. data types transporting opaque data.
We see that over half of the attributes encode less than 16 octets of We see that over half of the Attributes encode less than 16 octets of
data. It is therefore important to have an extension mechanism which data. It is therefore important to have an extension mechanism that
adds as little as possible to the size of these attributes. Another adds as little as possible to the size of these attributes. Another
result is that the overwhelming majority of attributes use simple result is that the overwhelming majority of attributes use simple
data types. data types.
Of the attributes defined above, 177 were declared as being inside of Of the Attributes defined above, 177 were declared as being inside of
a TLV. This is approximately 4% of the total. We did not a TLV. This is approximately 4% of the total. We did not
investigate whether additional attributes were defined in a flat name investigate whether additional attributes were defined in a flat
space, but could have been defined as being inside of a TLV. We namespace but could have been defined as being inside of a TLV. We
expect that the number could be as high as 10% of attributes. expect that the number could be as high as 10% of attributes.
Manual inspection of the dictionaries shows that approximately 20 (or Manual inspection of the dictionaries shows that approximately 20 (or
0.5%) attributes have the ability to transport more than 253 octets 0.5%) attributes have the ability to transport more than 253 octets
of data. These attributes are divided between VSAs, and a small of data. These attributes are divided between VSAs and a small
number of standard Attributes such as EAP-Message. number of standard Attributes such as EAP-Message.
The results of this audit and analysis is reflected in the design of The results of this audit and analysis are reflected in the design of
the extended attributes. The extended format has minimal overhead, the extended attributes. The extended format has minimal overhead,
it permits TLVs, and it has support for "long" attributes. permits TLVs, and has support for "long" attributes.
8. Diameter Considerations 8. Diameter Considerations
The attribute formats defined in this specification need to be The Attribute formats defined in this specification need to be
transported in Diameter. While Diameter supports attributes longer transported in Diameter. While Diameter supports attributes longer
than 253 octets and grouped attributes, we do not use that than 253 octets and grouped attributes, we do not use that
functionality here. Instead, we define the simplest possible functionality here. Instead, we define the simplest possible
encapsulation method. encapsulation method.
The new formats MUST be treated the same as traditional RADIUS The new formats MUST be treated the same as traditional RADIUS
attributes when converting from RADIUS to Diameter, or vice versa. attributes when converting from RADIUS to Diameter, or vice versa.
That is, the new attribute space is not converted to any "extended" That is, the new attribute space is not converted to any "extended"
Diameter attribute space. Fragmented attributes are not converted to Diameter attribute space. Fragmented attributes are not converted to
a single long Diameter attribute. The new EVS data types are not a single long Diameter attribute. The new EVS data types are not
converted to Diameter attributes with the "V" bit set. converted to Diameter attributes with the "V" bit set.
In short, this document mandates no changes for existing RADIUS to In short, this document mandates no changes for existing RADIUS-to-
Diameter, or Diameter to RADIUS gateways. Diameter or Diameter-to-RADIUS gateways.
9. Examples 9. Examples
A few examples are presented here in order to illustrate the encoding A few examples are presented here in order to illustrate the encoding
of the new attribute formats. These examples are not intended to be of the new Attribute formats. These examples are not intended to be
exhaustive, as many others are possible. For simplicity, we do not exhaustive, as many others are possible. For simplicity, we do not
show complete packets, only attributes. show complete packets, but only attributes.
The examples are given using a domain-specific language implemented The examples are given using a domain-specific language implemented
by the program given in Appendix A. The language is line oriented, by the program given in Appendix A of this document. The language is
and composed of a sequence of lines matching the grammar ([RFC5234]) line oriented and composed of a sequence of lines matching the ABNF
given below: grammar ([RFC5234]) given below:
Identifier = 1*DIGIT *( "." 1*DIGIT ) Identifier = 1*DIGIT *( "." 1*DIGIT )
HEXCHAR = HEXDIG HEXDIG HEXCHAR = HEXDIG HEXDIG
STRING = DQUOTE 1*CHAR DQUOTE STRING = DQUOTE 1*CHAR DQUOTE
TLV = "{" SP 1*DIGIT SP DATA SP "}" TLV = "{" SP 1*DIGIT SP DATA SP "}"
DATA = (HEXCHAR *(SP HEXCHAR)) / (TLV *(SP TLV)) / STRING DATA = (HEXCHAR *(SP HEXCHAR)) / (TLV *(SP TLV)) / STRING
LINE = Identifier SP DATA LINE = Identifier SP DATA
The program has additional restrictions on its input that are not The program has additional restrictions on its input that are not
reflected in the above grammar. For example, the portions of the reflected in the above grammar. For example, the portions of the
Identifier which refer to Type and Extended-Type are limited to identifier that refer to Type and Extended-Type are limited to values
values between 1 and 255. We trust that the source code in Appendix between 1 and 255. We trust that the source code in Appendix A is
A is clear, and that these restrictions do not negatively affect the clear and that these restrictions do not negatively affect the
comprehensibility of the examples. comprehensibility of the examples.
The program reads the input text, and interprets it as a set of The program reads the input text and interprets it as a set of
instructions to create RADIUS Attributes. It then prints the hex instructions to create RADIUS attributes. It then prints the hex
encoding of those attributes. It implements the minimum set of encoding of those attributes. It implements the minimum set of
functionality which achieves that goal. This minimalism means that functionality that achieves that goal. This minimalism means that it
it does not use attribute dictionaries; it does not implement support does not use attribute dictionaries; it does not implement support
for RADIUS data types; it can be used to encode attributes with for RADIUS data types; it can be used to encode attributes with
invalid data fields; and there is no requirement for consistency from invalid data fields; and there is no requirement for consistency from
one example to the next. For example, it can be used to encode a one example to the next. For example, it can be used to encode a
User-Name attribute which contains non-UTF8 data, or a Framed-IP- User-Name attribute that contains non-UTF8 data or a
Address which contains 253 octets of ASCII data. As a result, it Framed-IP-Address that contains 253 octets of ASCII data. As a
MUST NOT be used to create RADIUS Attributes for transport in a result, it MUST NOT be used to create RADIUS attributes for transport
RADIUS message. in a RADIUS message.
However, the program correctly encodes the RADIUS attribute fields of However, the program correctly encodes the RADIUS attribute fields of
"Type", "Length", "Extended-Type", "More", "Reserved", "Vendor-Id", "Type", "Length", "Extended-Type", "More", "Reserved", "Vendor-Id",
"Vendor-Type", and "Vendor-Length". It encodes RADIUS attribute data "Vendor-Type", and "Vendor-Length". It encodes RADIUS attribute data
types "evs" and TLV. It can therefore be used to encode example types "evs" and "tlv". It can therefore be used to encode example
attributes from inputs which are humanly readable. attributes from inputs that are human readable.
We do not give examples of "malformed" or "invalid attributes". We We do not give examples of "invalid attributes". We also note that
also note that the examples show format, rather than consistent the examples show format, rather than consistent meaning. A
meaning. A particular Attribute Type code may be used to demonstrate particular Attribute Type code may be used to demonstrate two
two different formats. In real specifications, attributes have a different formats. In real specifications, attributes have a static
static definitions based on their type code. definitions based on their type code.
The examples given below are strictly for demonstration purposes The examples given below are strictly for demonstration purposes only
only, and do not provide a standard of any kind. and do not provide a standard of any kind.
9.1. Extended Type 9.1. Extended Type
The following are a series of examples of the "Extended Type" format. The following is a series of examples of the "Extended Type" format.
Attribute encapsulating textual data. Attribute encapsulating textual data:
241.1 "bob" 241.1 "bob"
-> f1 06 01 62 6f 62 -> f1 06 01 62 6f 62
Attribute encapsulating a TLV with TLV-Type of one (1). Attribute encapsulating a TLV with TLV-Type of one (1):
241.2 { 1 23 45 } 241.2 { 1 23 45 }
-> f1 07 02 01 04 23 45 -> f1 07 02 01 04 23 45
Attribute encapsulating two TLVs, one after the other. Attribute encapsulating two TLVs, one after the other:
241.2 { 1 23 45 } { 2 67 89 } 241.2 { 1 23 45 } { 2 67 89 }
-> f1 0b 02 01 04 23 45 02 04 67 89 -> f1 0b 02 01 04 23 45 02 04 67 89
Attribute encapsulating two TLVs, where the second TLV is itself Attribute encapsulating two TLVs, where the second TLV is itself
encapsulating a TLV. encapsulating a TLV:
241.2 { 1 23 45 } { 3 { 1 ab cd } } 241.2 { 1 23 45 } { 3 { 1 ab cd } }
-> f1 0d 02 01 04 23 45 03 06 01 04 ab cd -> f1 0d 02 01 04 23 45 03 06 01 04 ab cd
Attribute encapsulating two TLVs, where the second TLV is itself Attribute encapsulating two TLVs, where the second TLV is itself
encapsulating two TLVs. encapsulating two TLVs:
241.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 241.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } }
-> f1 12 02 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f -> f1 12 02 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f
Attribute encapsulating a TLV, which in turn encapsulates a TLV, Attribute encapsulating a TLV, which in turn encapsulates a TLV, to a
to a depth of 5 nestings. depth of 5 nestings:
241.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 241.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } }
-> f1 0f 01 01 0c 02 0a 03 08 04 06 05 04 cd ef -> f1 0f 01 01 0c 02 0a 03 08 04 06 05 04 cd ef
Attribute encapsulating an extended Vendor Specific attribute, Attribute encapsulating an Extended-Vendor-Specific Attribute, with
with Vendor-Id of 1, and Vendor-Type of 4, which in turn Vendor-Id of 1 and Vendor-Type of 4, which in turn encapsulates
encapsulates textual data. textual data:
241.26.1.4 "test" 241.26.1.4 "test"
-> f1 0c 1a 00 00 00 01 04 74 65 73 74 -> f1 0c 1a 00 00 00 01 04 74 65 73 74
Attribute encapsulating an extended Vendor Specific attribute, with Attribute encapsulating an Extended-Vendor-Specific Attribute, with
Vendor-Id of 1, and Vendor-Type of 5, which in turn encapsulates Vendor-Id of 1 and Vendor-Type of 5, which in turn encapsulates a TLV
a TLV with TLV-Type of 3, which encapsulates textual data. with TLV-Type of 3, which encapsulates textual data:
241.26.1.5 { 3 "test" } 241.26.1.5 { 3 "test" }
-> f1 0e 1a 00 00 00 01 05 03 06 74 65 73 74 -> f1 0e 1a 00 00 00 01 05 03 06 74 65 73 74
9.2. Long Extended Type 9.2. Long Extended Type
The following are a series of examples of the "Long Extended Type" The following is a series of examples of the "Long Extended Type"
format. format.
Attribute encapsulating textual data. Attribute encapsulating textual data:
245.1 "bob" 245.1 "bob"
-> f5 07 01 00 62 6f 62 -> f5 07 01 00 62 6f 62
Attribute encapsulating a TLV with TLV-Type of one (1). Attribute encapsulating a TLV with TLV-Type of one (1):
245.2 { 1 23 45 } 245.2 { 1 23 45 }
-> f5 08 02 00 01 04 23 45 -> f5 08 02 00 01 04 23 45
Attribute encapsulating two TLVs, one after the other. Attribute encapsulating two TLVs, one after the other:
245.2 { 1 23 45 } { 2 67 89 } 245.2 { 1 23 45 } { 2 67 89 }
-> f5 0c 02 00 01 04 23 45 02 04 67 89 -> f5 0c 02 00 01 04 23 45 02 04 67 89
Attribute encapsulating two TLVs, where the second TLV is itself Attribute encapsulating two TLVs, where the second TLV is itself
encapsulating a TLV. encapsulating a TLV:
245.2 { 1 23 45 } { 3 { 1 ab cd } } 245.2 { 1 23 45 } { 3 { 1 ab cd } }
-> f5 0e 02 00 01 04 23 45 03 06 01 04 ab cd -> f5 0e 02 00 01 04 23 45 03 06 01 04 ab cd
Attribute encapsulating two TLVs, where the second TLV is itself Attribute encapsulating two TLVs, where the second TLV is itself
encapsulating two TLVs. encapsulating two TLVs:
245.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 245.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } }
-> f5 13 02 00 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f -> f5 13 02 00 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f
Attribute encapsulating a TLV, which in turn encapsulates a TLV, Attribute encapsulating a TLV, which in turn encapsulates a TLV, to a
to a depth of 5 nestings. depth of 5 nestings:
245.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 245.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } }
-> f5 10 01 00 01 0c 02 0a 03 08 04 06 05 04 cd ef -> f5 10 01 00 01 0c 02 0a 03 08 04 06 05 04 cd ef
Attribute encapsulating an extended Vendor Specific attribute, Attribute encapsulating an Extended-Vendor-Specific Attribute, with
with Vendor-Id of 1, and Vendor-Type of 4, which in turn Vendor-Id of 1 and Vendor-Type of 4, which in turn encapsulates
encapsulates textual data. textual data:
245.26.1.4 "test" 245.26.1.4 "test"
-> f5 0d 1a 00 00 00 00 01 04 74 65 73 74 -> f5 0d 1a 00 00 00 00 01 04 74 65 73 74
Attribute encapsulating an extended Vendor Specific attribute, Attribute encapsulating an Extended-Vendor-Specific Attribute, with
with Vendor-Id of 1, and Vendor-Type of 5, which in turn Vendor-Id of 1 and Vendor-Type of 5, which in turn encapsulates a TLV
encapsulates a TLV with TLV-Type of 3, which encapsulates with TLV-Type of 3, which encapsulates textual data:
textual data.
245.26.1.5 { 3 "test" } 245.26.1.5 { 3 "test" }
-> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74 -> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74
Attribute encapsulating more than 251 octets of data. The "Data" Attribute encapsulating more than 251 octets of data. The "Data"
portions are indented for readability. portions are indented for readability:
245.4 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 245.4 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb aaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc
ccccccccccc" ccccccccccc"
-> f5 ff 04 80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa -> f5 ff 04 80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb bb bb bb bb bb aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 13 04 00 cc bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 13 04 00 cc
cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
Attribute encapsulating an extended Vendor Specific attribute, Below is an example of an attribute encapsulating an Extended-Vendor-
with Vendor-Id of 1, and Vendor-Type of 6, which in turn Specific Attribute, with Vendor-Id of 1 and Vendor-Type of 6, which
encapsulates more than 251 octets of data. in turn encapsulates more than 251 octets of data.
As the VSA encapsulates more than 251 octets of data, it is As the VSA encapsulates more than 251 octets of data, it is split
split into two RADIUS attributes. The first attribute has the into two RADIUS attributes. The first attribute has the More field
More field set, and carries the Vendor-Id and Vendor-Type. set, and it carries the Vendor-Id and Vendor-Type. The second
The second attribute has the More field clear, and carries attribute has the More field clear and carries the rest of the data
the rest of the data portion of the VSA. Note that the second portion of the VSA. Note that the second attribute does not include
attribute does not include the Vendor-Id ad Vendor-Type fields. the Vendor-Id ad Vendor-Type fields.
The "Data" portions are indented for readability. The "Data" portions are indented for readability:
245.26.1.6 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 245.26.1.6 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc
ccccccccccccccccc" ccccccccccccccccc"
-> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa -> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 18 1a 00 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 18 1a 00 bb
bb bb bb bb cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc bb bb bb bb cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
10. IANA Considerations 10. IANA Considerations
This document updates [RFC3575] in that it adds new IANA This document updates [RFC3575] in that it adds new IANA
considerations for RADIUS Attributes. These considerations modify considerations for RADIUS attributes. These considerations modify
and extend the IANA considerations for RADIUS, rather than replacing and extend the IANA considerations for RADIUS, rather than replacing
them. them.
The IANA considerations of this document are limited to the "RADIUS The IANA considerations of this document are limited to the "RADIUS
Attribute Types" registry. Some Attribute Type values which were Attribute Types" registry. Some Attribute Type values that were
previously marked "Reserved" are now allocated, and the registry is previously marked "Reserved" are now allocated, and the registry is
extended from a simple 8-bit array to a tree-like structure, up to a extended from a simple 8-bit array to a tree-like structure, up to a
maximum depth of 125 nodes. Detailed instructions are given below. maximum depth of 125 nodes. Detailed instructions are given below.
10.1. Attribute Allocations 10.1. Attribute Allocations
IANA is requested to move the following Attribute Type values from IANA has moved the following Attribute Type values from "Reserved" to
"Reserved", to "Allocated", with the corresponding names: "Allocated" with the corresponding names:
* 241 Extended-Type-1 * 241 Extended-Type-1
* 242 Extended-Type-2 * 242 Extended-Type-2
* 243 Extended-Type-3 * 243 Extended-Type-3
* 244 Extended-Type-4 * 244 Extended-Type-4
* 245 Long-Extended-Type-1 * 245 Long-Extended-Type-1
* 246 Long-Extended-Type-2 * 246 Long-Extended-Type-2
These values serve as an encapsulation layer for the new RADIUS These values serve as an encapsulation layer for the new RADIUS
Attribute Type tree. Attribute Type tree.
10.2. RADIUS Attribute Type Tree 10.2. RADIUS Attribute Type Tree
Each of the Attribute Type values allocated above extends the "RADIUS Each of the Attribute Type values allocated above extends the "RADIUS
Attribute Types" to an N-ary tree, via a "dotted number" notation. Attribute Types" to an N-ary tree, via a "dotted number" notation.
Allocation of an Attribute Type value "TYPE" using the new Extended Allocation of an Attribute Type value "TYPE" using the new "Extended
type format results in allocation of 255 new Attribute Type values, Type" format results in allocation of 255 new Attribute Type values
of format "TYPE.1" through "TYPE.255". Value twenty-six (26) is of format "TYPE.1" through "TYPE.255". Value twenty-six (26) is
assigned as "Extended-Vendor-Specific-*". Values "TYPE.241" through assigned as "Extended-Vendor-Specific-*". Values "TYPE.241" through
"TYPE.255" are marked "Reserved". All other values are "Unassigned". "TYPE.255" are marked "Reserved". All other values are "Unassigned".
The initial set of Attribute Type values and names assigned by this The initial set of Attribute Type values and names assigned by this
document is given below. document is given below.
* 241 Extended-Attribute-1 * 241 Extended-Attribute-1
* 241.{1-25} Unassigned * 241.{1-25} Unassigned
* 241.26 Extended-Vendor-Specific-1 * 241.26 Extended-Vendor-Specific-1
* 241.{27-240} Unassigned * 241.{27-240} Unassigned
* 241.{241-255} Reserved * 241.{241-255} Reserved
* 242 Extended-Attribute-2 * 242 Extended-Attribute-2
* 242.{1-25} Unassigned * 242.{1-25} Unassigned
* 242.26 Extended-Vendor-Specific-2 * 242.26 Extended-Vendor-Specific-2
* 242.{27-240} Unassigned * 242.{27-240} Unassigned
* 243 Extended-Attribute-3 * 242.{241-255} Reserved
* 242.{241-255} Reserved * 243 Extended-Attribute-3
* 243.{1-25} Unassigned * 243.{1-25} Unassigned
* 243.26 Extended-Vendor-Specific-3 * 243.26 Extended-Vendor-Specific-3
* 243.{27-240} Unassigned * 243.{27-240} Unassigned
* 243.{241-255} Reserved * 243.{241-255} Reserved
* 244 Extended-Attribute-4 * 244 Extended-Attribute-4
* 244.{1-25} Unassigned * 244.{1-25} Unassigned
* 244.26 Extended-Vendor-Specific-4 * 244.26 Extended-Vendor-Specific-4
* 244.{27-240} Unassigned * 244.{27-240} Unassigned
* 244.{241-255} Reserved * 244.{241-255} Reserved
* 245 Extended-Attribute-5 * 245 Extended-Attribute-5
* 245.{1-25} Unassigned * 245.{1-25} Unassigned
* 245.26 Extended-Vendor-Specific-5 * 245.26 Extended-Vendor-Specific-5
* 245.{27-240} Unassigned * 245.{27-240} Unassigned
* 245.{241-255} Reserved * 245.{241-255} Reserved
* 246 Extended-Attribute-6 * 246 Extended-Attribute-6
* 246.{1-25} Unassigned * 246.{1-25} Unassigned
* 245.26 Extended-Vendor-Specific-6 * 246.26 Extended-Vendor-Specific-6
* 246.{27-240} Unassigned * 246.{27-240} Unassigned
* 246.{241-255} Reserved * 246.{241-255} Reserved
As per [RFC5226], the values marked "Unassigned" above are available As per [RFC5226], the values marked "Unassigned" above are available
via for assignment by IANA in future RADIUS specifications. The for assignment by IANA in future RADIUS specifications. The values
values marked "Reserved" are reserved for future use. marked "Reserved" are reserved for future use.
The Extended-Vendor-Specific spaces (TYPE.26) are for Private Use, The Extended-Vendor-Specific spaces (TYPE.26) are for Private Use,
and allocations are not managed by IANA. and allocations are not managed by IANA.
Allocation of Reserved entries in the extended space requires Allocation of Reserved entries in the extended space requires
Standards Action. Standards Action.
All other allocations in the extended space require IETF Review. All other allocations in the extended space require IETF Review.
10.3. Allocation Instructions 10.3. Allocation Instructions
This section defines what actions IANA needs to take when allocating This section defines what actions IANA needs to take when allocating
new attributes. Different actions are required when allocating new attributes. Different actions are required when allocating
attributes from the standard space, attributes of Extended Type attributes from the standard space, attributes of the "Extended Type"
format, attributes of the "Long Extended Type" format, preferential format, attributes of the "Long Extended Type" format, preferential
allocations, attributes of data type TLV, attributes within a TLV, allocations, attributes of data type TLV, attributes within a TLV,
and attributes of other data types. and attributes of other data types.
10.3.1. Requested Allocation from the Standard Space 10.3.1. Requested Allocation from the Standard Space
Specifications can request allocation of an Attribute from within the Specifications can request allocation of an Attribute from within the
standard space (e.g. Attribute Type Codes 1 through 255), subject to standard space (e.g., Attribute Type Codes 1 through 255), subject to
the considerations of [RFC3575] and this document. the considerations of [RFC3575] and this document.
10.3.2. Requested Allocation from the short extended space 10.3.2. Requested Allocation from the Short Extended Space
Specifications can request allocation of an Attribute which requires Specifications can request allocation of an Attribute that requires
the format Extended Type, by specifying the short extended space In the format "Extended Type", by specifying the short extended space.
that case, IANA should assign the lowest Unassigned number from the In that case, IANA should assign the lowest Unassigned number from
Attribute Type space with the relevant format. the Attribute Type space with the relevant format.
10.3.3. Requested Allocation from the long extended space 10.3.3. Requested Allocation from the Long Extended Space
Specifications can request allocation of an Attribute which requires Specifications can request allocation of an Attribute that requires
the format "Long Extended Type", by specifying the extended space the format "Long Extended Type", by specifying the extended space
(long). In that case, IANA should assign the lowest Unassigned (long). In that case, IANA should assign the lowest Unassigned
number from the Attribute Type space with the relevant format. number from the Attribute Type space with the relevant format.
10.3.4. Allocation Preferences 10.3.4. Allocation Preferences
Specifications which make no request for allocation from a specific Specifications that make no request for allocation from a specific
Type Space should have Attributes allocated using the following type space should have Attributes allocated using the following
criteria: criteria:
* when the standard space has no more Unassigned attributes, * When the standard space has no more Unassigned attributes, all
all allocations should be performed from the extended space. allocations should be performed from the extended space.
* specifications which allocate a small number of attributes * Specifications that allocate a small number of attributes (i.e.,
(i.e. less than ten) should have all allocations made from less than ten) should have all allocations made from the standard
the standard space. space.
* specifications which would allocate a more than twenty percent * Specifications that would allocate more than twenty percent of the
of remaining standard space attributes should have all allocations
the remaining standard space attributes should have all made from the extended space.
allocations made from the extended space.
* specifications which request allocation of an attribute of * Specifications that request allocation of an attribute of data type
data type TLV should have that attribute allocated from the TLV should have that attribute allocated from the extended space.
extended space.
* specifications which request allocation of an attribute * Specifications that request allocation of an attribute that can
which can transport 253 or more octets of data should have transport 253 or more octets of data should have that attribute
that attribute allocated from within the long extended space, allocated from within the long extended space. We note that
We note that Section 6.5, above requires specifications to Section 6.5 above makes recommendations related to this allocation.
request this allocation.
There is otherwise no requirement that all attributes within a There is otherwise no requirement that all attributes within a
specification be allocated from one type space or another. specification be allocated from one type space or another.
Specifications can simultaneously allocate attributes from both the Specifications can simultaneously allocate attributes from both the
standard space and the extended space. standard space and the extended space.
10.3.5. Extending the Type Space via TLV Data Type 10.3.5. Extending the Type Space via the TLV Data Type
When specifications request allocation of an attribute of data type When specifications request allocation of an attribute of data type
"tlv", that allocation extends the Attribute Type Tree by one more TLV, that allocation extends the Attribute Type tree by one more
level. Allocation of an Attribute Type value "TYPE.TLV", with Data level. Allocation of an Attribute Type value "TYPE.TLV", with data
Type TLV, results in allocation of 255 new Attribute Type values, of type TLV, results in allocation of 255 new Attribute Type values, of
format "TYPE.TLV.1" through "TYPE.TLV.255". Values 254-255 are format "TYPE.TLV.1" through "TYPE.TLV.255". Values 254-255 are
marked "Reserved". All other values are "Unassigned". Value 26 has marked "Reserved". All other values are "Unassigned". Value 26 has
no special meaning. no special meaning.
For example, if a new attribute "Example-TLV" of data type "tlv" is For example, if a new attribute "Example-TLV" of data type TLV is
assigned the identifier "245.1", then the extended tree will be assigned the identifier "245.1", then the extended tree will be
allocated as below: allocated as below:
* 245.1 Example-TLV * 245.1 Example-TLV
* 245.1.{1-253} Unassigned * 245.1.{1-253} Unassigned
* 245.1.{254-255} Reserved * 245.1.{254-255} Reserved
Note that this example does not define an "Example-TLV" attribute. Note that this example does not define an "Example-TLV" attribute.
The Attribute Type Tree can be extended multiple levels in one The Attribute Type tree can be extended multiple levels in one
specification when the specification requests allocation of nested specification when the specification requests allocation of nested
TLVs, as discussed below. TLVs, as discussed below.
10.3.6. Allocation within a TLV 10.3.6. Allocation within a TLV
Specifications can request allocation of Attribute Type values within Specifications can request allocation of Attribute Type values within
an Attribute of Data Type TLV. The encapsulating TLV can be an Attribute of data type TLV. The encapsulating TLV can be
allocated in the same specification, or it can have been previously allocated in the same specification, or it can have been previously
allocated. allocated.
Specifications need to request allocation within a specific Attribute Specifications need to request allocation within a specific Attribute
Type value (e.g. "TYPE.TLV.*"). Allocations are performed from the Type value (e.g., "TYPE.TLV.*"). Allocations are performed from the
smallest Unassigned value, proceeding to the largest Unassigned smallest Unassigned value, proceeding to the largest Unassigned
value. value.
Where the Attribute being allocated is of Data Type TLV, the Where the Attribute being allocated is of data type TLV, the
Attribute Type tree is extended by one level, as given in the Attribute Type tree is extended by one level, as given in the
previous section. Allocations can then be made within that level. previous section. Allocations can then be made within that level.
10.3.7. Allocation of Other Data Types 10.3.7. Allocation of Other Data Types
Attribute Type value allocations are otherwise allocated from the Attribute Type value allocations are otherwise allocated from the
smallest Unassigned value, proceeding to the largest Unassigned smallest Unassigned value, proceeding to the largest Unassigned
value. e.g. Starting from 241.1, proceeding through 241.255, then to value, e.g., starting from 241.1, proceeding through 241.255, then to
242.1, through 242.255, etc. 242.1, through 242.255, etc.
11. Security Considerations 11. Security Considerations
This document defines new formats for data carried inside of RADIUS, This document defines new formats for data carried inside of RADIUS
but otherwise makes no changes to the security of the RADIUS but otherwise makes no changes to the security of the RADIUS
protocol. protocol.
Attacks on cryptographic hashes are well known, and are getting Attacks on cryptographic hashes are well known and are getting better
better with time, as discussed in [RFC4270]. The security of the with time, as discussed in [RFC4270]. The security of the RADIUS
RADIUS protocol is dependent on MD5 [RFC1311], which has security protocol is dependent on MD5 [RFC1321], which has security issues as
issues as discussed in [RFC6151]. It is not known if the issues discussed in [RFC6151]. It is not known if the issues described in
described in [RFC6151] apply to RADIUS. For other issues, we [RFC6151] apply to RADIUS. For other issues, we incorporate by
incorporate by reference the security considerations of [RFC6158] reference the security considerations of [RFC6158] Section 5.
Section 5.
As with any protocol change, code changes are required in order to As with any protocol change, code changes are required in order to
implement the new features. These code changes have the potential to implement the new features. These code changes have the potential to
introduce new vulnerabilities in the software. Since the RADIUS introduce new vulnerabilities in the software. Since the RADIUS
server performs network authentication, it is an inviting target for server performs network authentication, it is an inviting target for
attackers. We RECOMMEND that access to RADIUS servers be kept to a attackers. We RECOMMEND that access to RADIUS servers be kept to a
minimum. minimum.
12. References 12. References
12.1. Normative references 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997.
[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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3575] Aboba, B, "IANA Considerations for RADIUS (Remote [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
Authentication Dial In User Service)", RFC 3575, July 2003. "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC5176] Chiba, M, et. al., "Dynamic Authorization Extensions to Remote [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
Authentication Dial In User Service (RADIUS)", RFC 5176,
January 2008.
[RFC5226] Narten, T. and Alvestrand, H, "Guidelines for Writing an IANA [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Considerations Section in RFCs", RFC 5226, May 2008. Authentication Dial In User Service)", RFC 3575,
July 2003.
[RFC6158] DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
6158, March 2011. IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[PEN] http://www.iana.org/assignments/enterprise-numbers [RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines",
BCP 158, RFC 6158, March 2011.
12.2. Informative references [PEN] IANA, "PRIVATE ENTERPRISE NUMBERS",
<http://www.iana.org/assignments/enterprise-numbers>.
[RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, 12.2. Informative References
April, 1992
[RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
Support", RFC 2868, June 2000. April 1992.
[RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
in Internet Protocols", RFC 4270, November 2005. M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000.
[RFC5234] Crocker, D. (Ed.), and Overell, P., "Augmented BNF for Syntax [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
Specifications: ABNF", RFC 5234, October 2005. Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC6151] Turner. S. and Chen, L., "Updated Security Considerations for [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, Syntax Specifications: ABNF", STD 68, RFC 5234,
March 2011. January 2008.
[EDUROAM] Internal Eduroam testing page, data retrieved 04 August 2010. [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, March 2011.
[ATTR] http://github.com/alandekok/freeradius- [ATTR] "alandekok/freeradius-server", available from GitHub, data
server/tree/master/share/, data retrieved September 2010. retrieved September 2010, <http://github.com/alandekok/
freeradius-server/tree/master/share/>.
Acknowledgments 13. Acknowledgments
This document is the result of long discussions in the IETF RADEXT This document is the result of long discussions in the IETF RADEXT
working group. The authors would like to thank all of the working group. The authors would like to thank all of the
participants who contributed various ideas over the years. Their participants who contributed various ideas over the years. Their
feedback has been invaluable, and has helped to make this feedback has been invaluable and has helped to make this
specification better. specification better.
Appendix A - Extended Attribute Generator Program Appendix A. Extended Attribute Generator Program
This section contains "C" program source which can be used for This section contains "C" program source code that can be used for
testing. It reads a line-oriented text file, parses it to create testing. It reads a line-oriented text file, parses it to create
RADIUS formatted attributes, and prints the hex version of those RADIUS formatted attributes, and prints the hex version of those
attributes to standard output. attributes to standard output.
The input accepts a grammar similar to that given in Section 9, with The input accepts grammar similar to that given in Section 9, with
some modifications for usability. For example, blank lines are some modifications for usability. For example, blank lines are
allowed, lines beginning with a '#' character are interpreted as allowed, lines beginning with a '#' character are interpreted as
comments, numbers (RADIUS Types, etc.) are checked for minimum / comments, numbers (RADIUS Types, etc.) are checked for minimum/
maximum values, and RADIUS Attribute lengths are enforced. maximum values, and RADIUS attribute lengths are enforced.
The program is included here for demonstration purposes only, and The program is included here for demonstration purposes only, and
does not define a standard of any kind. does not define a standard of any kind.
------------------------------------------------------------ ------------------------------------------------------------
/* /*
* Copyright (c) 2010 IETF Trust and the persons identified as * Copyright (c) 2013 IETF Trust and the persons identified as
* authors of the code. All rights reserved. * authors of the code. All rights reserved.
* *
* Redistribution and use in source and binary forms, with or without * Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions * modification, are permitted provided that the following conditions
* are met: * are met:
* *
* Redistributions of source code must retain the above copyright * - Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer. * notice, this list of conditions and the following disclaimer.
* *
* Redistributions in binary form must reproduce the above copyright * - Redistributions in binary form must reproduce the above
* notice, this list of conditions and the following disclaimer in * copyright notice, this list of conditions and the following
* the documentation and/or other materials provided with the * disclaimer in the documentation and/or other materials provided
* distribution. * with the distribution.
* *
* Neither the name of Internet Society, IETF or IETF Trust, nor the * - Neither the name of Internet Society, IETF or IETF Trust, nor
* names of specific contributors, may be used to endorse or promote * the names of specific contributors, may be used to endorse or
* products derived from this software without specific prior written * promote products derived from this software without specific
* permission. * prior written permission.
* *
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
* CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
* TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
* ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE. * SUCH DAMAGE.
* *
* Author: Alan DeKok <aland@networkradius.com> * Author: Alan DeKok <aland@networkradius.com>
skipping to change at page 67, line 28 skipping to change at page 68, line 13
} }
printf("\n"); printf("\n");
} }
if (fp != stdin) fclose(fp); if (fp != stdin) fclose(fp);
return 0; return 0;
} }
------------------------------------------------------------ ------------------------------------------------------------
Author's Address Authors' Addresses
Alan DeKok Alan DeKok
Network RADIUS SARL Network RADIUS SARL
57bis blvd des Alpes 57bis blvd des Alpes
38240 Meylan 38240 Meylan
France France
Email: aland@networkradius.com EMail: aland@networkradius.com
URI: http://networkradius.com URI: http://networkradius.com
Avi Lior Avi Lior
Email: avi.ietf@lior.org
EMail: avi.ietf@lior.org
 End of changes. 373 change blocks. 
936 lines changed or deleted 927 lines changed or added

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