draft-ietf-radext-radius-extensions-04.txt   draft-ietf-radext-radius-extensions-05.txt 
Network Working Group Alan DeKok Network Working Group Alan DeKok
INTERNET-DRAFT Network RADIUS INTERNET-DRAFT Network RADIUS
Category: Proposed Standard Avi Lior Category: Proposed Standard Avi Lior
Updates: 2865, 2866, 3575, 5176, 6158 BWS Updates: 2865, 2866, 3575, 5176, 6158 BWS
<draft-ietf-radext-radius-extensions-04.txt> <draft-ietf-radext-radius-extensions-05.txt>
Expires: July 2, 2012 Expires: October 26, 2012
2 January 2012 26 April 2012
Remote Authentication Dial In User Service (RADIUS) Protocol Remote Authentication Dial In User Service (RADIUS) Protocol
Extensions Extensions
draft-ietf-radext-radius-extensions-04.txt draft-ietf-radext-radius-extensions-05.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 which 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 which address all of the above
problems. problems.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 2, 2012. This Internet-Draft will expire on October 26, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 ............................................. 5
1.1. Unmet Requirements .................................. 6 1.1. Unmet Requirements .................................. 6
1.2. Terminology ......................................... 6 1.2. Terminology ......................................... 6
1.3. Requirements Language ............................... 7 1.3. Requirements Language ............................... 7
2. Extensions to RADIUS ..................................... 9 2. Extensions to RADIUS ..................................... 9
2.1. Extended Type ....................................... 9 2.1. Extended Type ....................................... 9
2.2. Extended Type with Flags ............................ 10 2.2. Long Extended Type .................................. 10
2.3. TLV Data Type ....................................... 12 2.3. TLV Data Type ....................................... 12
2.3.1. TLV Nesting .................................... 14 2.3.1. TLV Nesting .................................... 14
2.4. EVS Data Type ....................................... 14 2.4. EVS Data Type ....................................... 14
2.5. Integer64 Data Type ................................. 15 2.5. Integer64 Data Type ................................. 16
2.6. Attribute Naming and Type Identifiers ............... 16 2.6. Attribute Naming and Type Identifiers ............... 16
2.6.1. Attribute and TLV Naming ....................... 16 2.6.1. Attribute and TLV Naming ....................... 17
2.6.2. Attribute Type Identifiers ..................... 17 2.6.2. Attribute Type Identifiers ..................... 17
2.6.3. TLV Identifiers ................................ 17 2.6.3. TLV Identifiers ................................ 17
2.6.4. VSA Identifiers ................................ 18 2.6.4. VSA Identifiers ................................ 18
2.7. Invalid Attributes .................................. 18 2.7. Invalid Attributes .................................. 19
3. Attribute Definitions .................................... 19 3. Attribute Definitions .................................... 19
3.1. Extended-Type-1 ..................................... 20 3.1. Extended-Type-1 ..................................... 20
3.2. Extended-Type-2 ..................................... 21 3.2. Extended-Type-2 ..................................... 21
3.3. Extended-Type-3 ..................................... 21 3.3. Extended-Type-3 ..................................... 22
3.4. Extended-Type-4 ..................................... 22 3.4. Extended-Type-4 ..................................... 22
3.5. Extended-Type-Flagged-1 ............................. 23 3.5. Long-Extended-Type-1 ................................ 23
3.6. Extended-Type-Flagged-2 ............................. 24 3.6. Long-Extended-Type-2 ................................ 24
4. Vendor Specific Attributes ............................... 25 4. Vendor Specific Attributes ............................... 26
4.1. Extended-Vendor-Specific-1 .......................... 26 4.1. Extended-Vendor-Specific-1 .......................... 26
4.2. Extended-Vendor-Specific-2 .......................... 27 4.2. Extended-Vendor-Specific-2 .......................... 27
4.3. Extended-Vendor-Specific-3 .......................... 28 4.3. Extended-Vendor-Specific-3 .......................... 28
4.4. Extended-Vendor-Specific-4 .......................... 29 4.4. Extended-Vendor-Specific-4 .......................... 30
4.5. Extended-Vendor-Specific-5 .......................... 31 4.5. Extended-Vendor-Specific-5 .......................... 31
4.6. Extended-Vendor-Specific-6 .......................... 32 4.6. Extended-Vendor-Specific-6 .......................... 32
5. Compatibility with traditional RADIUS .................... 33 5. Compatibility with traditional RADIUS .................... 34
5.1. Attribute Allocation ................................ 34 5.1. Attribute Allocation ................................ 34
5.2. Proxy Servers ....................................... 35 5.2. Proxy Servers ....................................... 35
6. Guidelines ............................................... 35 6. Guidelines ............................................... 36
6.1. Updates to RFC 6158 ................................. 36 6.1. Updates to RFC 6158 ................................. 36
6.2. Guidelines for Simple Data Types .................... 36 6.2. Guidelines for Simple Data Types .................... 36
6.3. Guidelines for Complex Data Types ................... 36 6.3. Guidelines for Complex Data Types ................... 37
6.4. Guidelines For the New Types ........................ 37 6.4. Guidelines For the New Types ........................ 37
6.5. Allocation Request Guidelines ....................... 38 6.5. Allocation Request Guidelines ....................... 38
6.6. TLV Guidelines ...................................... 39 6.6. TLV Guidelines ...................................... 39
6.7. Implementation Guidelines ........................... 39 6.7. Implementation Guidelines ........................... 39
6.8. Vendor Guidelines ................................... 40 6.8. Vendor Guidelines ................................... 40
7. Rationale ................................................ 40 7. Rationale ................................................ 40
7.1. Attribute Audit ..................................... 40 7.1. Attribute Audit ..................................... 40
8. Examples ................................................. 41 8. Diameter Considerations .................................. 41
8.1. Extended Type ....................................... 42 9. Examples ................................................. 42
8.2. Extended Type with Flags ............................ 43 9.1. Extended Type ....................................... 43
9. IANA Considerations ...................................... 46 9.2. Long Extended Type .................................. 44
9.1. Attribute Allocations ............................... 46 10. IANA Considerations ..................................... 46
9.2. RADIUS Attribute Type Tree .......................... 47 10.1. Attribute Allocations .............................. 47
9.3. Allocation Instructions ............................. 48 10.2. RADIUS Attribute Type Tree ......................... 47
9.3.1. Requested Allocation from the Standard Space ... 48 10.3. Allocation Instructions ............................ 48
9.3.2. Requested Allocation from the short extended spa 48 10.3.1. Requested Allocation from the Standard Space .. 48
9.3.3. Requested Allocation from the long extended spac 48 10.3.2. Requested Allocation from the short extended sp 48
9.3.4. Allocation Preferences ......................... 48 10.3.3. Requested Allocation from the long extended spa 49
9.3.5. Extending the Type Space via TLV Data Type ..... 49 10.3.4. Allocation Preferences ........................ 49
9.3.6. Allocation within a TLV ........................ 50 10.3.5. Extending the Type Space via TLV Data Type .... 49
9.3.7. Allocation of Other Data Types ................. 50 10.3.6. Allocation within a TLV ....................... 50
10. Security Considerations ................................. 50 10.3.7. Allocation of Other Data Types ................ 50
11. References .............................................. 50 11. Security Considerations ................................. 50
11.1. Normative references ............................... 50 12. References .............................................. 51
11.2. Informative references ............................. 51 12.1. Normative references ............................... 51
Appendix A - Extended Attribute Generator Program ............ 52 12.2. Informative references ............................. 51
Appendix A - Extended Attribute Generator Program ............ 53
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 imnpractical, and a more powerful mechanism is needed. shown to be imnpractical, and a more powerful mechanism is needed.
Multiple attributes have been defined which transport more than the Multiple attributes have been defined which 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
skipping to change at page 5, line 34 skipping to change at page 5, line 34
* 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 Attribute Type Space. the Attribute Type Space.
* 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. approximately 1000 values.
* defining an "Extended Type with Flags" format, which inserts * defining a "Long Extended Type" format, which inserts
an additional "Flags" octet between the "Extended Type" octet, an additional octet between the "Extended Type" octet,
and the "Value" field. This method gives us a general way of and the "Value" field. This method gives us a general way of
adding additional functionality to the protocol. adding additional functionality to the protocol.
* defining a method which uses the "Flags" field to indicate data * defining a method which uses the additional octet to indicate data
fragmentation across multiple Attributes. This method provides a fragmentation across multiple Attributes. This method provides a
standard way for an Attribute to carry more than 253 octets of standard way for an Attribute to carry more than 253 octets of
data. data.
* allocating 2 attributes as using the format of "Extended Type with * allocating 2 attributes as using the format "Long Extended Type".
Flags". This allocation extends the RADIUS Attribute Type Space This allocation extends the RADIUS Attribute Type Space
by an additional 500 values. by an additional 500 values.
* defining a new "Type Length Value" (TLV) data type. The data type * defining a new "Type Length Value" (TLV) data type. The 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. creates a standard way to group a set of Attributes.
* defining a new "extended Vendor-Specific" (EVS) data type. The * defining a new "extended Vendor-Specific" (EVS) data type. The
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. (VSAs) inside of the new attribute formats.
skipping to change at page 7, line 24 skipping to change at page 7, line 24
Extended space Extended space
Codes in the RADIUS Attribute Type Space that require the Codes in the RADIUS Attribute Type Space that require the
extensions defined in this document, and are an extension of the extensions defined in this document, and are an extension of the
standard space, but which cannot be represented within the standard standard space, but which cannot be represented within the standard
space. space.
Short extended space Short extended space
Codes in the extended space which use the "Extended Type" format. Codes in the extended space which use the "Extended Type" format.
Long extended space Long extended space
Codes in the extended space which use the "Extended Type with Codes in the extended space which use the "Long Extended Type"
Flags" format. format.
The following terms are used here with the meanings defined in BCP The following terms are used here with the meanings defined in BCP
26: "name space", "assigned value", "registration". 26: "name space", "assigned value", "registration".
The following terms are used here with the meanings defined in BCP The following terms are used here with the meanings defined in BCP
26: "Private Use", "Reserved", "Unassigned". 26: "Private Use", "Reserved", "Unassigned".
The following policies are used here with the meanings defined in The following policies are used here with the meanings defined in
BCP 26: "Private Use", "IETF Review", "Standards Action". BCP 26: "Private Use", "IETF Review", "Standards Action".
skipping to change at page 9, line 8 skipping to change at page 9, line 8
of the must or must not requirements for the protocols it implements. of the must or must not requirements for the protocols it implements.
An implementation that satisfies all the MUST, MUST NOT, SHOULD, and An implementation that satisfies all the MUST, MUST NOT, SHOULD, and
SHOULD NOT requirements for its protocols is said to be SHOULD NOT requirements for its protocols is said to be
"unconditionally compliant"; one that satisfies all the MUST and MUST "unconditionally compliant"; one that satisfies all the MUST and MUST
NOT requirements but not all the SHOULD or SHOULD NOT requirements NOT requirements but not all the SHOULD or SHOULD NOT requirements
for its protocols is said to be "conditionally compliant". for its protocols is said to be "conditionally compliant".
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
"Extended Type with Flags". It defines a new Type-Length-Value (TLV) "Long Extended Type". It defines a new Type-Length-Value (TLV) data
data type, an Extended-Vendor-Specific (EVS) data type, and an type, an Extended-Vendor-Specific (EVS) data type, and an Integer64
Integer64 data type. It defines a new method for naming attributes data type. It defines a new method for naming attributes and
and identifying Attributes using the new attribute formats. It identifying Attributes using the new attribute formats. It finally
finally defines the new term "invalid attribute", and describes how defines the new term "invalid attribute", and describes how it
it affects implementations. affects implementations.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 39 skipping to change at page 9, line 39
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
This field is identical to the Length field of the Attribute This field is identical to the Length field of the Attribute
format defined in [RFC2865] Section 5. Permitted values are format defined in [RFC2865] Section 5. Permitted values are
between 4 and 255. If a client or server receives an Extended between 4 and 255. If a client or server receives an Extended
Attribute with a Length of 2 or 3, then that Attribute MUST be Attribute with a Length of 2 or 3, then that Attribute MUST be
deemed to be an "invalid attribute", and handled as per Section deemed to be an "invalid attribute", and handled as per Section
XXX, below. 2.7, 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 by IANA. Unlike the Type field defined in field are specified by IANA. Unlike the Type field defined in
[RFC2865] Section 5, no values are allocated for experimental or [RFC2865] Section 5, no values are allocated for experimental or
implementation-specific use. Values 241-255 are reserved and implementation-specific use. Values 241-255 are reserved and
SHOULD NOT be used. SHOULD 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
skipping to change at page 10, line 20 skipping to change at page 10, line 20
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 SHOULD be defined in [RFC2865] Section 5. The format of the data SHOULD be
a valid RADIUS data type. a valid RADIUS data type.
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 252
octets. Where an Attribute needs to carry more than 252 octets of octets. Where an Attribute needs to carry more than 252 octets of
data, the "Extended Type with flags" format should be used. data, the "Long Extended Type" format should 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. Extended Type with Flags 2.2. Long Extended Type
This section defines a new attribute format, called "Extended Type This section defines a new attribute format, called "Long Extended
with Flags". It leverages the "Extended Type" format in order to Type". It leverages the "Extended Type" format in order to permit
permit the transport of attributes encapsulating more than 253 octets the transport of attributes encapsulating more than 253 octets of
of data. A summary of the Attribute format is shown below. The data. A summary of the Attribute format is shown below. The fields
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| Flags | | 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
This field is identical to the Length field of the Attribute This field is identical to the Length field of the Attribute
format defined in [RFC2865] Section 5. Permitted values are format defined in [RFC2865] Section 5. Permitted values are
between 5 and 255. If a client or server receives an "Extended between 5 and 255. If a client or server receives a "Long
Attribute with Flags" with a Length of 2, 3, or 4, then that Extended Attribute" with a Length of 2, 3, or 4, then that
Attribute MUST be deemed to be an "invalid attribute", and be Attribute MUST be deemed to be an "invalid attribute", and be
handled as per Section 2.7, below. handled as per Section 2.7, below.
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 Flag 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 flag MUST be clear (0) if the Length field has value less The More field MUST be clear (0) if the Length field has value
than 255. The More flag MAY be set (1) if the Length field has less than 255. The More field MAY be set (1) if the Length field
value of 255. has value of 255.
If the More flag is set (1), it indicates that the Value field has If the More field is set (1), it indicates that the Value field
been fragmented across multiple RADIUS attributes. When the More has been fragmented across multiple RADIUS attributes. When the
flag is set (1), the attribute SHOULD have a Length field of value More field is set (1), the attribute SHOULD have a Length field of
255; it MUST NOT have a length Field of value 4; there MUST be an value 255; it MUST NOT have a length Field of value 4; there MUST
attribute following this one; and the next attribute MUST have be an attribute following this one; and the next attribute MUST
both the same Type and Extended Type. That is, multiple fragments have both the same Type and Extended Type. That is, multiple
of the same value MUST be in order and MUST be consecutive fragments of the same value MUST be in order and MUST be
attributes in the packet, and the last attribute in a packet MUST consecutive attributes in the packet, and the last attribute in a
NOT have the More flag set (1). packet MUST NOT have the More field set (1).
When the Length field of an attribute has value less than 255, the When the Length field of an attribute has value less than 255, the
More flag SHOULD be clear (0). More field SHOULD be clear (0).
If a client or server receives an attribute fragment with the If a client or server receives an attribute fragment with the
"More" flag 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 deemed to be an "invalid found, then the fragmented attribute is deemed to be an "invalid
attribute", and handled as per Section 2.7, below. attribute", and handled as per Section 2.7, below.
Flags 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.
skipping to change at page 14, line 13 skipping to change at page 14, line 13
any other format. any other format.
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 over-fill 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
XXX, below. 2.7, 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. NOT RECOMMENDED.
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
which which permits the "Value" field of an Attribute to contain a which permits the "Value" field of an Attribute to contain a Vendor-
Vendor-Id, followed by a Vendor-Type, and then vendor-defined data. Id, followed by a Vendor-Type, and then vendor-defined data. This
This data can in turn contain valid RADIUS data types, or any other data can in turn contain valid RADIUS data types, or any other data
data as determined by the vendor. as determined by the vendor.
This data type is intended use in attributes which carry Vendor- This data type is intended use in attributes which 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 (26). It is RECOMMENDED that this data type be used by a vendor only
when the Vendor-Specific Attribute Type space has been fully when the Vendor-Specific Attribute Type space has been fully
allocated. 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 "Extended Type with Flags". It MUST NOT be used "Extended Type" or "Long Extended Type". It MUST NOT be used in any
in any other Attribute definition, including standard RADIUS other Attribute definition, including standard RADIUS Attributes,
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 | String .... | Vendor-Type | String ....
skipping to change at page 15, line 42 skipping to change at page 15, line 42
control over the contents and format of the Value field, while at control over the contents and format of the Value field, while at
the same time recommending that good practices be followed. the same time recommending 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 "String" data type has no "Vendor length" field. The length of the "String"
field is implicit, and is determined by taking the "Length" of the field is implicit, and is determined by taking the "Length" of the
encapsulating RADIUS Attribute, and subtracting the length of the encapsulating RADIUS Attribute, and subtracting the length of the
attribute header including the 4 octets of Vendor-Id. i.e. For attribute header (2 octets), the extended type (1 octet), the Vendor-
"Extended Type" attributes, the length of the String field is seven Id (4 octets), and the Vendor-type (1 octet). i.e. For "Extended
(7) less than the value of the Length field. For "Extended Type with Type" attributes, the length of the String field is eight (8) less
Flags" attributes, the length of the String field is eight (8) less than the value of the Length field. For "Long Extended Type"
than the value of the Length field. attributes, the length of the String field is nine (9) less 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 which 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
skipping to change at page 16, line 29 skipping to change at page 16, line 34
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 "Extended Type with Flags" 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. Attribute Naming and Type Identifiers 2.6. 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 named "User-Name" has been
allocated number one (1). This scheme needs to be extended in order allocated number one (1). This scheme needs to be extended in order
to be able to refer to attributes of Extended Type, and to TLVs. It to be able to refer to attributes of Extended Type, and to TLVs. It
will also be used by IANA for allocating RADIUS Attribute Type will also be used by IANA for allocating RADIUS Attribute Type
values. values.
skipping to change at page 19, line 22 skipping to change at page 19, line 30
packet, or treating the packet as a negative acknowledgement. packet, or treating the packet as a negative acknowledgement.
Instead, only the "invalid attribute" is treated differently. Instead, only the "invalid attribute" is treated differently.
When an implementation receives an "invalid attribute", it SHOULD be When an implementation receives an "invalid attribute", it SHOULD be
silently discarded. If it is not discarded, it MUST NOT be handled silently discarded. If it is not discarded, it MUST NOT be handled
in the same manner as a well-formed attribute. For example, in the same manner as a well-formed attribute. For example,
receiving an Attribute of data type "address" containing more than receiving an Attribute of data type "address" containing more than
four, or less than four octets of data means that the Attribute MUST four, or less than four octets of data means that the Attribute MUST
NOT be treated as being of data type "address". NOT be treated as being of data type "address".
For Attributes of type "Extended Type with Flags", an Attribute is For Attributes of type "Long Extended Type", an Attribute is deemed
deemed to be an "invalid attribute" when does not match the criteria to be an "invalid attribute" when does not match the criteria set out
set out in Section 2.2, above. in Section 2.2, above.
For Attributes of type "TLV", an Attribute is deemed to be an For Attributes of type "TLV", an Attribute is deemed to be an
"invalid attribute" when the TLV-Length field is valid, but the TLV- "invalid attribute" when the TLV-Length field is valid, but the TLV-
Value field does not match the criteria for that Attribute. Value field does not match the criteria for that Attribute.
Implementations SHOULD NOT treat the "invalid attribute" property as Implementations SHOULD NOT treat the "invalid attribute" property as
being transitive. That is, the encapsulating Attribute SHOULD NOT be being transitive. That is, the encapsulating Attribute SHOULD NOT be
treated as being an "invalid attribute" if it encapsulates an treated as being an "invalid attribute" if it encapsulates an
"invalid attribute". "invalid attribute".
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 "Extended Type with Flags", We also define two (2) attributes of "Long Extended Type", which are
which are allocated from the "Reserved" Attribute Type codes of 245 allocated from the "Reserved" Attribute Type codes of 245 and 246.
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 Extended-Type-Flagged-1 245 Long-Extended-Type-1
246 Extended-Type-Flagged-2 246 Long-Extended-Type-2
The rest of this section gives a detailed definition for each The rest of this section gives a detailed definition 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}.
skipping to change at page 23, line 32 skipping to change at page 23, line 39
Value Value
The Value field is one or more octets. Implementations not The Value field is one or more octets. Implementations not
supporting this specification SHOULD support the field as supporting this specification SHOULD support the field as
undistinguished octets. undistinguished 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. Extended-Type-Flagged-1 3.5. Long-Extended-Type-1
Description Description
This attribute encapsulates attributes of the "Extended Type with This attribute encapsulates attributes of the "Long Extended Type"
Flags" 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 Extended-Type-Flagged-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| Flags | | Type | Length | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
245 for Extended-Type-Flagged-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 by IANA, in the 245.{1-255} RADIUS Attribute field are specified by IANA, in the 245.{1-255} RADIUS Attribute
Type Space. Further definition of this field is given in Section Type Space. Further definition of this field is given in Section
2.1, above. 2.1, above.
M (More) M (More)
The More Flag 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.
Flags 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. Implementations not The Value field is one or more octets. Implementations not
supporting this specification SHOULD support the field as supporting this specification SHOULD support the field as
undistinguished octets. undistinguished 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. Extended-Type-Flagged-2 3.6. Long-Extended-Type-2
Description Description
This attribute encapsulates attributes of the "Extended Type with This attribute encapsulates attributes of the "Long Extended Type"
Flags" 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 Extended-Type-Flagged-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| Flags | | Type | Length | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
246 for Extended-Type-Flagged-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 by IANA, in the 246.{1-255} RADIUS Attribute field are specified by IANA, in the 246.{1-255} RADIUS Attribute
Type Space. Further definition of this field is given in Section Type Space. Further definition of this field is given in Section
2.1, above. 2.1, above.
M (More) M (More)
The More Flag 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.
Flags 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. Implementations not The Value field is one or more octets. Implementations not
supporting this specification SHOULD support the field as supporting this specification SHOULD support the field as
skipping to change at page 26, line 5 skipping to change at page 26, line 12
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 which 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 of "Extended Type "evs" data type. We also define two (2) attributes using "Long
with Flags" format, with Type codes (245.26, 246.26), using the "evs" Extended Type" format, with Type codes (245.26, 246.26), which are of
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
skipping to change at page 31, line 18 skipping to change at page 31, line 25
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.
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| Flags | | Type | Length | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id | | Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Value .... | Vendor-Type | Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type.Extended-Type Type.Extended-Type
245.26 for Extended-Vendor-Specific-5 245.26 for Extended-Vendor-Specific-5
skipping to change at page 31, line 40 skipping to change at page 31, line 47
>= 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 Flag 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.
Flags 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 high-order octet is 0 and the low-order 3 octets are the SMI The high-order octet is 0 and the low-order 3 octets are the SMI
Network Management Private Enterprise Code of the Vendor in Network Management Private Enterprise Code of the Vendor in
network byte order. 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
skipping to change at page 32, line 39 skipping to change at page 32, line 46
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.
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| Flags | | Type | Length | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id | | Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Value .... | Vendor-Type | Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type.Extended-Type Type.Extended-Type
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 Flag 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.
Flags 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 high-order octet is 0 and the low-order 3 octets are the SMI The high-order octet is 0 and the low-order 3 octets are the SMI
Network Management Private Enterprise Code of the Vendor in Network Management Private Enterprise Code of the Vendor in
skipping to change at page 39, line 9 skipping to change at page 39, line 14
extended space. The standard space, or the short extended space extended space. The standard space, or the short extended space
MUST be used instead. MUST be used instead.
* Specifications of an attribute which encodes 253 octets or more of * Specifications of an attribute which 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
SHOULD be written which requests allocation of one or more RADIUS SHOULD be written which requests allocation of one or more RADIUS
Attributes from the "Reserved" portion of the standard space, Attributes from the "Reserved" portion of the standard space,
values 247-255, using an appropriate format ("Extended Type", or values 247-255, using an appropriate format ("Extended Type", or
"Extended Type with Flags") "Long Extended Type")
6.6. TLV Guidelines 6.6. TLV Guidelines
The following items give guidelines for specifications using TLVs. The following items give guidelines for specifications using 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.
skipping to change at page 39, line 48 skipping to change at page 40, line 6
* RADIUS server implementations SHOULD support this specification * RADIUS server implementations SHOULD support this specification
as soon as possible. as soon as possible.
* RADIUS proxy servers SHOULD forward all attributes, even ones * RADIUS proxy servers SHOULD forward all attributes, even ones
which they do not understand, or which are not in a local which they do not understand, or which are not in a local
dictionary. These attributes SHOULD be forwarded verbatim, with dictionary. These attributes SHOULD be forwarded verbatim, with
no modifications or changes. no modifications or changes.
* When forwarding attributes, RADIUS proxy servers SHOULD forward * When forwarding attributes, RADIUS proxy servers SHOULD forward
the "Flag" field unchanged. That is, they SHOULD NOT assume that the "Reserved" field unchanged. That is, they SHOULD NOT assume
the "Flag" field is always set to zero on transmission. that the "Reserved" field can always be set to zero.
6.8. Vendor Guidelines 6.8. 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, as this specification may take time to become widely attributes, as this specification may take time to become widely
deployed. deployed.
* Vendors SHOULD implement this specification as soon as * Vendors SHOULD implement this specification as soon as
possible. The changes to RADIUS are relatively small, and are possible. The changes to RADIUS are relatively small, and are
skipping to change at page 40, line 27 skipping to change at page 40, line 31
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 to be unworkable in practice. We
do not otherwise explain here why earlier proposals did not obtain do not otherwise explain here why earlier proposals did not obtain
working group consensus. working 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 "Extended Type with Attribute format. The downside is that the "Long Extended Type"
Flags" format is awkward, and the 7 bits of Flags will likey never be format is awkward, and the 7 Reserved bits will likey never be used
used for anything. for anything.
7.1. Attribute Audit 7.1. Attribute Audit
An audit of almost five thousand publicly available attributes An audit of almost five thousand publicly available attributes
[ATTR], shows the statistics summarized below. The attributes include [ATTR], 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
----- --------- ----- ---------
skipping to change at page 41, line 31 skipping to change at page 41, line 34
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 is 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. it permits TLVs, and it has support for "long" attributes.
8. Examples 8. Diameter Considerations
The attribute formats defined in this specification need to be
transported in Diameter. While Diameter supports attributes longer
than 253 octets and grouped attributes, we do not use that
functionality here. Instead, we define the simplest possible
encapsulation method.
The new formats MUST be treated the same as traditional RADIUS
attributes when converting from RADIUS to Diameter, or vice versa.
That is, the new attribute space is not converted to any "extended"
Diameter attribute space. Fragmented attributes are not converted to
a single long Diameter attribute. The new EVS data types are not
converted to Diameter attributes with the "V" bit set.
In short, this document mandates no changes for existing RADIUS to
Diameter, or Diameter to RADIUS gateways.
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, 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. The language is line oriented,
and composed of a sequence of lines matching the grammar ([RFC5234]) and composed of a sequence of lines matching the grammar ([RFC5234])
given below: given below:
skipping to change at page 42, line 27 skipping to change at page 42, line 50
it does not use attribute dictionaries; it does not implement support it 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 which contains non-UTF8 data, or a Framed-IP-
Address which contains 253 octets of ASCII data. As a result, it Address which contains 253 octets of ASCII data. As a result, it
MUST NOT be used to create RADIUS Attributes for transport in a MUST NOT be used to create RADIUS Attributes for transport in a
RADIUS message. 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", "Flags", "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 which are humanly readable.
We do not give examples of "malformed" or "invalid attributes". We We do not give examples of "malformed" or "invalid attributes". We
also note that the examples show format, rather than consistent also note that the examples show format, rather than consistent
meaning. A particular Attribute Type code may be used to demonstrate meaning. A particular Attribute Type code may be used to demonstrate
two different formats. In real specifications, attributes have a two different formats. In real specifications, attributes have a
static definitions based on their type code. static 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, and do not provide a standard of any kind. only, and do not provide a standard of any kind.
8.1. Extended Type 9.1. Extended Type
The following are a series of examples of the "Extended Type" format. The following are 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).
skipping to change at page 43, line 45 skipping to change at page 44, line 19
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 with TLV-Type of 3, which encapsulates textual data. a TLV 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
8.2. Extended Type with Flags 9.2. Long Extended Type
The following are a series of examples of the "Extended Type with The following are a series of examples of the "Long Extended Type"
flags" 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
skipping to change at page 45, line 36 skipping to change at page 46, line 11
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 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, Attribute encapsulating an extended Vendor Specific attribute,
with Vendor-Id of 1, and Vendor-Type of 6, which in turn with Vendor-Id of 1, and Vendor-Type of 6, which in turn
encapsulates more than 251 octets of data. 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 into two RADIUS attributes. The first attribute has the split into two RADIUS attributes. The first attribute has the
More flag set, and carries the Vendor-Id and Vendor-Type. More field set, and carries the Vendor-Id and Vendor-Type.
The second attribute has the More flag clear, and carries The second attribute has the More field clear, and carries
the rest of the data portion of the VSA. Note that the second the rest of the data portion of the VSA. Note that the second
attribute does not include the Vendor-Id ad Vendor-Type fields. attribute does not include 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 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 245.26.1.6 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
skipping to change at page 46, line 20 skipping to change at page 46, line 43
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 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 17 1a 00 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 17 1a 00 bb
bb bb bb bb cc cc cc cc cc cc cc cc cc cc 13 45 67 89 bb bb bb bb cc cc cc cc cc cc cc cc cc cc 13 45 67 89
9. 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 which 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.
9.1. Attribute Allocations 10.1. Attribute Allocations
IANA is requested to move the following Attribute Type values from IANA is requested to move the following Attribute Type values from
"Reserved", to "Allocated", with the corresponding names: "Reserved", to "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 Extended-Type-Flagged-1 * 245 Long-Extended-Type-1
* 246 Extended-Type-Flagged-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.
9.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". The value zero "TYPE.0" is not of format "TYPE.1" through "TYPE.255". The value zero "TYPE.0" is not
used. Value twenty-six (26) is assigned as "Extended-Vendor- used. Value twenty-six (26) is assigned as "Extended-Vendor-
Specific-*". Values "TYPE.241" through "TYPE.255" are marked Specific-*". Values "TYPE.241" through "TYPE.255" are marked
"Reserved". All other values are "Unassigned". "Reserved". All other values are "Unassigned".
skipping to change at page 48, line 13 skipping to change at page 48, line 33
values marked "Reserved" are reserved for future use. values 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.
9.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 Extended Type
format, attributes of Extended Type with Flags format, perferential format, attributes of the "Long Extended Type" format, perferential
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.
9.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.
9.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 which requires
the format Extended Type, by specifying the short extended space In the format Extended Type, by specifying the short extended space In
that case, IANA should assign the lowest Unassigned number from the that case, IANA should assign the lowest Unassigned number from the
Attribute Type space with the relevant format. Attribute Type space with the relevant format.
9.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 which requires
the format Extended Type with Flags, 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.
9.3.4. Allocation Preferences 10.3.4. Allocation Preferences
Specifications which make no request for allocation from a specific Specifications which 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 allocations should be performed from the extended space. all allocations should be performed from the extended space.
* specifications which allocate a small number of attributes * specifications which allocate a small number of attributes
(i.e. less than ten) should have all allocations made from (i.e. less than ten) should have all allocations made from
skipping to change at page 49, line 16 skipping to change at page 49, line 37
* specifications which allocate a large number of attributes * specifications which allocate a large number of attributes
(i.e. ten or more) should have all allocations made from the (i.e. ten or more) should have all allocations made from the
extended space. extended space.
* specifications which request allocation of an Attribute of * specifications which request allocation of an Attribute of
data type TLV should have that attribute allocated from the data type TLV should have that attribute allocated from the
extended space. extended space.
* specifications which request allocation of an attribute * specifications which request allocation of an attribute
which can transport 253 or more octets of data should have which can transport 253 or more octets of data should have
that attribute allocated from within the long extended space, that attribute allocated from within the long extended space,
We note that Section 6.5, above requires specifications to We note that Section 6.5, above requires specifications to
request 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.
9.3.5. Extending the Type Space via TLV Data Type 10.3.5. Extending the Type Space via 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". The value zero "VALUE.0" format "TYPE.TLV.1" through "TYPE.TLV.255". The value zero "VALUE.0"
is not used. Values 254-255 are marked "Reserved". All other values is not used. Values 254-255 are marked "Reserved". All other values
are "Unassigned". Value 26 has no special meaning. are "Unassigned". Value 26 has 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
skipping to change at page 50, line 5 skipping to change at page 50, line 23
* 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.
9.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.
9.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.
10. 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 with time, as discussed in[RFC4270]. RADIUS uses the MD5 hash better with time, as discussed in[RFC4270]. RADIUS uses the MD5 hash
[RFC1321] for packet authentication and attribute obfuscation. There [RFC1321] for packet authentication and attribute obfuscation. There
are ongoing efforts in the IETF to analyze and address these issues are ongoing efforts in the IETF to analyze and address these issues
for the RADIUS protocol. for the RADIUS protocol.
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.
11. References 12. References
11.1. Normative references 12.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997. Requirement Levels", RFC 2119, March, 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000. 2000.
[RFC5226] Narten, T. and Alvestrand, H, "Guidelines for Writing an IANA [RFC5226] Narten, T. and Alvestrand, H, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 5226, May 2008. Considerations Section in RFCs", RFC 5226, May 2008.
11.2. Informative references 12.2. Informative references
[RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321,
April, 1992 April, 1992
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol [RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000. Support", RFC 2868, June 2000.
[RFC3575] Aboba, B, "IANA Considerations for RADIUS (Remote [RFC3575] Aboba, B, "IANA Considerations for RADIUS (Remote
 End of changes. 93 change blocks. 
161 lines changed or deleted 180 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/