draft-ietf-radext-radius-extensions-00.txt   draft-ietf-radext-radius-extensions-01.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, 5176 BWS Updates: 2865, 2866, 5176 BWS
<draft-ietf-radext-radius-extensions-00.txt> <draft-ietf-radext-radius-extensions-01.txt>
Expires: August 27, 2011 Expires: January 6, 2012
27 February 2011 6 June 2011
Remote Authentication Dial In User Service (RADIUS) Protocol Remote Authentication Dial In User Service (RADIUS) Protocol
Extensions Extensions
draft-ietf-radext-radius-extensions-00.txt draft-ietf-radext-radius-extensions-01.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 March 1, 2011. This Internet-Draft will expire on November January 6, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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. Terminology ......................................... 6 1.1. Terminology ......................................... 6
1.2. Requirements Language ............................... 6 1.2. Requirements Language ............................... 6
2. Extensions to RADIUS ..................................... 7 2. Extensions to RADIUS ..................................... 8
2.1. Extended Type ....................................... 7 2.1. Extended Type ....................................... 8
2.2. Extended Type with Flags ............................ 8 2.2. Extended Type with Flags ............................ 9
2.3. TLV Data Type ....................................... 10 2.3. TLV Data Type ....................................... 11
2.3.1. TLV Nesting .................................... 12 2.3.1. TLV Nesting .................................... 13
2.4. EVS Data Type ....................................... 12 2.4. EVS Data Type ....................................... 13
2.5. Attribute Naming and Type Identifiers ............... 14 2.5. Integer64 Data Type ................................. 15
2.5.1. Attribute and TLV Naming ....................... 14 2.6. Attribute Naming and Type Identifiers ............... 15
2.5.2. Attribute Type Identifiers ..................... 14 2.6.1. Attribute and TLV Naming ....................... 16
2.5.3. TLV Identifiers ................................ 15 2.6.2. Attribute Type Identifiers ..................... 16
2.5.4. VSA Identifiers ................................ 15 2.6.3. TLV Identifiers ................................ 16
3. Attribute Definitions .................................... 16 2.6.4. VSA Identifiers ................................ 17
3.1. Extended-Type-1 ..................................... 16 3. Attribute Definitions .................................... 18
3.2. Extended-Type-2 ..................................... 17 3.1. Extended-Type-1 ..................................... 18
3.3. Extended-Type-3 ..................................... 18 3.2. Extended-Type-2 ..................................... 19
3.4. Extended-Type-4 ..................................... 19 3.3. Extended-Type-3 ..................................... 20
3.5. Extended-Type-Flagged-1 ............................. 20 3.4. Extended-Type-4 ..................................... 21
3.6. Extended-Type-Flagged-2 ............................. 21 3.5. Extended-Type-Flagged-1 ............................. 21
4. Vendor Specific Attributes ............................... 22 3.6. Extended-Type-Flagged-2 ............................. 23
4.1. Extended-Vendor-Specific-1 .......................... 22 4. Vendor Specific Attributes ............................... 24
4.2. Extended-Vendor-Specific-2 .......................... 24 4.1. Extended-Vendor-Specific-1 .......................... 24
4.3. Extended-Vendor-Specific-3 .......................... 25 4.2. Extended-Vendor-Specific-2 .......................... 25
4.4. Extended-Vendor-Specific-4 .......................... 26 4.3. Extended-Vendor-Specific-3 .......................... 26
4.5. Extended-Vendor-Specific-5 .......................... 27 4.4. Extended-Vendor-Specific-4 .......................... 28
4.6. Extended-Vendor-Specific-6 .......................... 28 4.5. Extended-Vendor-Specific-5 .......................... 29
5. Compatibility with traditional RADIUS .................... 30 4.6. Extended-Vendor-Specific-6 .......................... 30
5.1. Attribute Allocation ................................ 30 5. Compatibility with traditional RADIUS .................... 32
5.2. Proxy Servers ....................................... 31 5.1. Attribute Allocation ................................ 32
6. Guidelines ............................................... 32 5.2. Proxy Servers ....................................... 33
6.1. Allocation Request Guidelines ....................... 32 6. Guidelines ............................................... 33
6.2. TLV Guidelines ...................................... 33 6.1. Updates to RFC 6158 ................................. 34
6.3. Implementation Guidelines ........................... 33 6.2. Guidelines For the New Types ........................ 34
6.4. Vendor Guidelines ................................... 34 6.3. Allocation Request Guidelines ....................... 34
7. Rationale ................................................ 34 6.4. TLV Guidelines ...................................... 35
7.1. Attribute Audit ..................................... 34 6.5. Implementation Guidelines ........................... 36
8. Examples ................................................. 35 6.6. Vendor Guidelines ................................... 36
8.1. Extended Type ....................................... 36 7. Rationale ................................................ 36
8.2. Extended Type with Flags ............................ 37 7.1. Attribute Audit ..................................... 36
9. IANA Considerations ...................................... 39 8. Examples ................................................. 37
9.1. Attribute Allocations ............................... 40 8.1. Extended Type ....................................... 38
9.2. RADIUS Attribute Type Tree .......................... 40 8.2. Extended Type with Flags ............................ 39
9.3. Assignment Policy ................................... 41 9. IANA Considerations ...................................... 42
9.4. Extending the Attribute Type Tree ................... 41 9.1. Attribute Allocations ............................... 42
9.5. Extending the RADIUS Attribute Type Space ........... 42 9.2. RADIUS Attribute Type Tree .......................... 42
10. Security Considerations ................................. 43 9.3. Assignment Policy ................................... 43
11. References .............................................. 43 9.4. Extending the Attribute Type Tree ................... 44
11.1. Normative references ............................... 43 9.5. Extending the RADIUS Attribute Type Space ........... 44
11.2. Informative references ............................. 43 10. Security Considerations ................................. 45
Appendix A - Extended Attribute Generator Program ............ 45 11. References .............................................. 45
11.1. Normative references ............................... 45
11.2. Informative references ............................. 46
Appendix A - Extended Attribute Generator Program ............ 47
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 6, line 9 skipping to change at page 6, line 9
* 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.
* defining a new "integer64" data type. The data type allows
counters which track more than 2^32 octets of data.
* 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 1500 values. over 1500 values.
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 implementation difficulty.
1.1. Terminology 1.1. Terminology
skipping to change at page 13, line 46 skipping to change at page 14, line 46
undistinguished octets. We recognise that Vendors have complete undistinguished octets. We recognise that Vendors have complete
control over the contents and format of the String field, while at control over the contents and format of the String 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 attribute encapsulating RADIUS Attribute, and subtracting the length of the
overhead (3, or 4 octets). attribute header including the 4 octets of Vendor-Id. i.e. For
"Extended Type" attributes, the length of the String field is seven
(7) less than the value of the Length field. For "Extended Type with
Flags" attributes, the length of the String field is eight (8) less
than the value of the Length field.
2.5. Attribute Naming and Type Identifiers 2.5. Integer64 Data Type
We define a new data type in RADIUS, called "integer64", which
carries a 64-bit unsigned integer in network byte order.
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
og this data type is within Accounting-Request packets, but this data
type SHOULD be used in any packet where 32-bit integers are expected
to be insufficient.
The "integer64" data type MAY be used in Attributes of any format,
standard space, extended attributes, TLVs, and VSAs.
A summary of the "integer64" data type format is shown below. The
fields are transmitted from left to right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attributes having data type "integer64" MUST have the relevant Length
field set to eight more than the length of the Attribute header. For
standard space Attributes and TLVs, this means that the Length field
MUST be set to ten (10). For "Extended Type" Attributes, the Length
field MUST be set to eleven (11). For "Extended Type with Flags"
Attributes, the Length field MUST be set to twelve (12).
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.
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.5.1. Attribute and TLV Naming 2.6.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 use 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 always used. For example, for VSA names, though this practice is not universal. For example,
the name "Vendor-My-Attribute" is preferred over the name "My- for a vendor named "Example", the name "Example-Attribute-Name"
Attribute". The second form can conflict with attributes from other SHOULD be used instead of "Attribute-Name". The second form can
vendors, whereas the first form cannot. conflict with attributes from other vendors, whereas the first form
cannot.
We therefore RECOMMEND that specifications give names to Attributes We therefore RECOMMEND that specifications give names to Attributes
which attempt to be globally unique across all RADIUS Attributes. We which attempt to be globally unique across all RADIUS Attributes. We
RECOMMEND that vendors use their name as a unique prefix for RECOMMEND that vendors use their name as a unique prefix for
attribute names. We recognise that these suggestion may sometimes be attribute names. We recognise that these suggestion may sometimes be
difficult to implement in practice. difficult to 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 named "Time-Zone",
"Time-Day", "Time-Hour", "Time-Minute", etc. "Time-Day", "Time-Hour", "Time-Minute", etc.
2.5.2. Attribute Type Identifiers 2.6.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, and attribute within the Type space of 241, having For example, and 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".
The algorithm used to create the Attribute Identifier is simply to The algorithm used to create the Attribute Identifier is simply to
concatenate all of the various identification fields (e.g. Type, concatenate all of the various identification fields (e.g. Type,
Extended-Type, etc.), starting from the encapsulating attribute, down Extended-Type, etc.), starting from the encapsulating attribute, down
to the final encapsulated TLV, separated by a '.' character. to the final encapsulated TLV, separated by a '.' character.
2.5.3. TLV Identifiers 2.6.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 replied in sequence for nested TLVs. TLV. This method can be replied 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, wth TLV-Type number four (4). another TLV, wth TLV-Type number four (4).
2.5.4. VSA Identifiers 2.6.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 number
26. It in turn carries a 24-bit Vendor-Id, and possibly additional 26. It in turn carries a 24-bit Vendor-Id, and possibly additional
skipping to change at page 17, line 17 skipping to change at page 19, line 5
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 by IANA, in the 241.{1-255} RADIUS Attribute field are specified by IANA, in the 241.{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.
String String
The String field is one or more octets. Implementations not The String 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 String field. of the String field.
skipping to change at page 18, line 4 skipping to change at page 19, line 38
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
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 by IANA, in the 242.{1-255} RADIUS Attribute field are specified by IANA, in the 242.{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.
String String
The String field is one or more octets. Implementations not The String 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 String field of the String field
skipping to change at page 19, line 5 skipping to change at page 20, line 40
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 by IANA, in the 243.{1-255} RADIUS Attribute field are specified by IANA, in the 243.{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.
String String
The String field is one or more octets. Implementations not The String 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 String field. of the String field.
skipping to change at page 19, line 46 skipping to change at page 21, line 34
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 by IANA, in the 244.{1-255} RADIUS Attribute field are specified by IANA, in the 244.{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.
String String
The String field is one or more octets. Implementations not The String 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 String Field. of the String Field.
skipping to change at page 20, line 41 skipping to change at page 22, line 29
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 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 Flag 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 Flags
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.
String String
The String field is one or more octets. Implementations not The String 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.
skipping to change at page 21, line 50 skipping to change at page 23, line 36
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 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 Flag 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 Flags
This field is 7 bits long, and is reserved for future use. This field is 7 bits long, and is reserved for future use.
skipping to change at page 23, line 48 skipping to change at page 25, line 32
String String
The String field is one or more octets. The actual format of the The String 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 String field is eight (8) less then the value 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 String field. determine the interpretation of the String 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.
skipping to change at page 25, line 5 skipping to change at page 26, line 39
String String
The String field is one or more octets. The actual format of the The String 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 String field is eight (8) less then the value 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 String field. determine the interpretation of the String 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.
skipping to change at page 26, line 8 skipping to change at page 27, line 46
String String
The String field is one or more octets. The actual format of the The String 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 String field is eight (8) less then the value 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 String field. determine the interpretation of the String 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.
skipping to change at page 27, line 4 skipping to change at page 28, line 45
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.
String String
The String field is one or more octets. The actual format of the The String 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 String field is eight (8) less then the value 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 String field. determine the interpretation of the String 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.
skipping to change at page 30, line 21 skipping to change at page 32, line 15
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. This section describes them. RADIUS. This section describes 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, as Vendor Specific Attributes. This practice is considered space, as Vendor Specific Attributes. This practice is considered
anti-social behavior, as noted in [GUIDELINES]. These vendor anti-social behavior, as noted in [RFC6158]. These vendor
definitions conflict with the attributes in the RADIUS Attribute Type definitions conflict with the attributes in the RADIUS Attribute Type
space. The conflicting definitions may make it difficult for space. The conflicting definitions may make it difficult for
implementations to support both those Vendor Attributes, and the new implementations to support both those Vendor Attributes, and the new
Extended Attribute formats. Extended Attribute 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 which indicates which type of attributes are being
sent from the client. If the flag is set one way, the conflicting sent from the client. If the flag is set one way, the conflicting
skipping to change at page 31, line 23 skipping to change at page 33, line 20
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 which they do not understand (i.e.
attributes which have no "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 ones which they do not understand, or which are not
in a local dictionary. When forwarded, these attributes SHOULD be in a local dictionary. When forwarded, these attributes SHOULD be
sent verbatim, with no modifications or changes. The only exception sent verbatim, with no modifications or changes. The only exception
to this recommendation is when local site policy dictates that to this recommendation is when local site policy dictates that
filtering of attributes has to occur. For example, a filter at a filtering of attributes has to occur. For example, a filter at a
visited network may require removal of certain authorization rules visited network may require removal of certain authorization rules
which apply to the home network, but not to the visited network. which apply to the home network, but not to the visited network.
This filtering can sometimes be done even when the contents of the This filtering can sometimes be done even when the contents of the
skipping to change at page 32, line 7 skipping to change at page 33, line 51
conformant proxies are fixed. We therefore RECOMMEND that all conformant proxies are fixed. We therefore RECOMMEND that all
proxies which do not support the Extended Attributes (241 through proxies which do not support the Extended Attributes (241 through
246) define them as being of data type "string", and delete all other 246) define them as being of data type "string", and delete all other
local definitions for those attributes. 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
therefore requires a set of guidelines, as has been done in
[RFC6158].
6.1. Updates to RFC 6158
This specification updates [RFC6158] by adding the data types "evs",
"tlv" and "integer64"; defining them to be "basic" data types; and
permitting their use subject to the restrictions outlined below.
All other recommendations given in [RFC6158] are unchanged. New
recommendations for the use of the new data types and attribute
formats are given below.
6.2. Guidelines For the New Types
We recommend the following guidelines when designing attributes using We recommend the following guidelines when designing attributes using
the new format. The items listed below are not exhaustive. As the new format. The items listed below are not exhaustive. As
experience is gained with the new formats, later specifications may experience is gained with the new formats, later specifications may
define additional guidelines. define additional guidelines.
* Unless otherwise specified, the guidelines in [GUIDELINES] MUST * The data type "evs" MUST NOT be used for standard RADIUS
be followed.
* The data type "esv" 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. While its use is NOT RECOMMENDED by [GUIDELINES], this attributes. While its use is NOT RECOMMENDED by [RFC6158], this
specification updates [GUIDELINES] to permit the "tlv" data type in specification updates [RFC6158] to permit the "tlv" data type in
attributes using the Extended-Type format. attributes using the Extended-Type format.
* [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 to Extended-Type space. The "tlv" data type should be used instead to
group attributes group attributes.
6.1. Allocation Request Guidelines * The "integer64" data type MAY be used in any RADIUS attribute.
The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but
their utility is now evident.
* For all other circumstances, the guidelines in [RFC6158] MUST
be followed.
6.3. 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.
* When the Type spaces of 241.*, 242.*, 243.*, or 244.* are nearing * When the Type spaces of 241.*, 242.*, 243.*, or 244.* are nearing
exhaustion, a new specification SHOULD be written which requests exhaustion, a new specification SHOULD be written which requests
skipping to change at page 33, line 19 skipping to change at page 35, line 37
* 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 and totals less than 247 octets of data, they SHOULD change, and and totals less than 247 octets of data, they SHOULD
request allocation from the Type spaces of 241.*, 242.*, 243.*, or request allocation from the Type spaces of 241.*, 242.*, 243.*, or
244.*. 244.*.
* 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 Type spaces of 245.* or they SHOULD request allocation from the Type spaces of 245.* or
246.*. 246.*.
6.2. TLV Guidelines 6.4. 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.
* Specifications SHOULD that the interpretation of an attribute * Specifications SHOULD that the interpretation of an attribute
depends only on its OID, and not on its encoding in the RADIUS depends only on its OID, and not on its encoding in the RADIUS
packet. packet.
6.3. Implementation Guidelines 6.5. Implementation Guidelines
* 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.
* Any attribute which is allocated from the Type spaces of 245.* or * Any attribute which is allocated from the Type spaces of 245.* or
246.*, of data type "text", "string", or "tlv" can end up carrying 246.*, of data type "text", "string", or "tlv" can end up carrying
more than 251 octets of data, up to the maximum RADIUS packet more than 251 octets of data, up to the maximum RADIUS packet
length (~4096 octets). Specifications defining such attributes length (~4096 octets). Specifications defining such attributes
SHOULD define a maximum length. SHOULD define a maximum length.
6.4. Vendor Guidelines 6.6. 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 be widely attributes, as this specification may take time to be widely
deployed. deployed.
7. Rationale 7. Rationale
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
skipping to change at page 34, line 33 skipping to change at page 36, line 49
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
----- --------- ----- ---------
2257 integer 2257 integer
1762 text 1762 text
273 IPv4 Address 273 IPv4 Address
235 string 235 string
96 other data types 96 other data types
35 IPv6 Address 35 IPv6 Address
18 date 18 date
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
[GUIDELINES]. The "other data types" row encompasses data types not [RFC6158]. The "other data types" row encompasses data types not
recommended by that document. recommended by that document.
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. The "Extended Type with Flags" number of standard Attributes. The "Extended Type with Flags"
formats is therefore important, but "long" attributes have had formats is therefore important, but "long" attributes have had
limited deployment. limited deployment.
8. Examples 8. Examples
skipping to change at page 40, line 36 skipping to change at page 43, line 5
These attributes serve as an encapsulation layer for the new RADIUS These attributes serve as an encapsulation layer for the new RADIUS
Attribute Type tree. Attribute Type tree.
9.2. RADIUS Attribute Type Tree 9.2. RADIUS Attribute Type Tree
Each of the attributes allocated above extends the "RADIUS Attribute Each of the attributes allocated above extends the "RADIUS Attribute
Types" to an N-ary tree, via a "dotted number" notation. Each number Types" to an N-ary tree, via a "dotted number" notation. Each number
in the tree is an 8-bit value (1 to 255). The value zero (0) MUST in the tree is an 8-bit value (1 to 255). The value zero (0) MUST
NOT be used. Currently, only one level of the tree is defined: NOT be used. Currently, only one level of the tree is defined:
* 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 * 243 Extended-Attribute-3
* 242.{241-255} Reserved * 242.{241-255} Reserved
* 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 * 245.26 Extended-Vendor-Specific-6
* 246.{27-240} Unassigned * 246.{27-240} Unassigned
* 246.{241-255} Reserved * 246.{241-255} Reserved
The values marked "Unassigned" above are available for assignment by The values marked "Unassigned" above are available for assignment by
IANA in future RADIUS specifications. The values marked "Reserved" IANA in future RADIUS specifications. The values marked "Reserved"
are reserved for future use. are reserved for future use.
9.3. Assignment Policy 9.3. Assignment Policy
skipping to change at page 43, line 28 skipping to change at page 45, line 42
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 11. References
11.1. Normative references 11.1. Normative references
[RFC1321]
Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, April,
1992
[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.
11.2. Informative references 11.2. Informative references
[RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321,
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.
[RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes [RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes
in Internet Protocols", RFC 4270, November 2005. in Internet Protocols", RFC 4270, November 2005.
[RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176,
January 2008.
[RFC5234] Crocker, D. (Ed.), and Overell, P., "Augmented BNF for Syntax [RFC5234] Crocker, D. (Ed.), and Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, October 2005. Specifications: ABNF", RFC 5234, October 2005.
[GUIDELINES] [RFC6158] DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC
DeKok, A., and Weber, G., "RADIUS Design Guidelines", draft- 6158, March 2011.
ietf-radext-design-18.txt, work in progress.
[EDUROAM] Internal Eduroam testing page, data retrieved 04 August 2010. [EDUROAM] Internal Eduroam testing page, data retrieved 04 August 2010.
[ATTR] http://github.com/alandekok/freeradius- [ATTR] http://github.com/alandekok/freeradius-
server/tree/master/share/, data retrieved September 2010. server/tree/master/share/, data retrieved September 2010.
Acknowledgments 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
 End of changes. 48 change blocks. 
113 lines changed or deleted 186 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/