draft-ietf-radext-radius-extensions-11.txt   draft-ietf-radext-radius-extensions-12.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 Updates: 2865, 2866, 3575, 5176, 6158
<draft-ietf-radext-radius-extensions-11.txt> <draft-ietf-radext-radius-extensions-12.txt>
Expires: August 1, 2013 Expires: August 18, 2013
1 February 2013 18 February 2013
Remote Authentication Dial In User Service (RADIUS) Protocol Remote Authentication Dial In User Service (RADIUS) Protocol
Extensions Extensions
draft-ietf-radext-radius-extensions-11.txt draft-ietf-radext-radius-extensions-12.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 3, line 28 skipping to change at page 3, line 28
2.4. EVS Data Type ....................................... 16 2.4. EVS Data Type ....................................... 16
2.5. Integer64 Data Type ................................. 18 2.5. Integer64 Data Type ................................. 18
2.6. Vendor-ID Field ..................................... 18 2.6. Vendor-ID Field ..................................... 18
2.7. Attribute Naming and Type Identifiers ............... 19 2.7. Attribute Naming and Type Identifiers ............... 19
2.7.1. Attribute and TLV Naming ....................... 19 2.7.1. Attribute and TLV Naming ....................... 19
2.7.2. Attribute Type Identifiers ..................... 20 2.7.2. Attribute Type Identifiers ..................... 20
2.7.3. TLV Identifiers ................................ 20 2.7.3. TLV Identifiers ................................ 20
2.7.4. VSA Identifiers ................................ 20 2.7.4. VSA Identifiers ................................ 20
2.8. Invalid Attributes .................................. 21 2.8. Invalid Attributes .................................. 21
3. Attribute Definitions .................................... 22 3. Attribute Definitions .................................... 22
3.1. Extended-Type-1 ..................................... 22 3.1. Extended-Type-1 ..................................... 23
3.2. Extended-Type-2 ..................................... 23 3.2. Extended-Type-2 ..................................... 23
3.3. Extended-Type-3 ..................................... 24 3.3. Extended-Type-3 ..................................... 24
3.4. Extended-Type-4 ..................................... 25 3.4. Extended-Type-4 ..................................... 25
3.5. Long-Extended-Type-1 ................................ 26 3.5. Long-Extended-Type-1 ................................ 26
3.6. Long-Extended-Type-2 ................................ 27 3.6. Long-Extended-Type-2 ................................ 27
4. Vendor Specific Attributes ............................... 28 4. Vendor Specific Attributes ............................... 28
4.1. Extended-Vendor-Specific-1 .......................... 29 4.1. Extended-Vendor-Specific-1 .......................... 29
4.2. Extended-Vendor-Specific-2 .......................... 30 4.2. Extended-Vendor-Specific-2 .......................... 30
4.3. Extended-Vendor-Specific-3 .......................... 31 4.3. Extended-Vendor-Specific-3 .......................... 31
4.4. Extended-Vendor-Specific-4 .......................... 32 4.4. Extended-Vendor-Specific-4 .......................... 32
4.5. Extended-Vendor-Specific-5 .......................... 33 4.5. Extended-Vendor-Specific-5 .......................... 33
4.6. Extended-Vendor-Specific-6 .......................... 35 4.6. Extended-Vendor-Specific-6 .......................... 35
5. Compatibility with traditional RADIUS .................... 36 5. Compatibility with traditional RADIUS .................... 36
5.1. Attribute Allocation ................................ 36 5.1. Attribute Allocation ................................ 36
5.2. Proxy Servers ....................................... 37 5.2. Proxy Servers ....................................... 37
6. Guidelines ............................................... 38 6. Guidelines ............................................... 38
6.1. Updates to RFC 6158 ................................. 38 6.1. Updates to RFC 6158 ................................. 39
6.2. Guidelines for Simple Data Types .................... 38 6.2. Guidelines for Simple Data Types .................... 39
6.3. Guidelines for Complex Data Types ................... 39 6.3. Guidelines for Complex Data Types ................... 39
6.4. Design Guidelines For the New Types ................. 40 6.4. Design Guidelines For the New Types ................. 40
6.5. TLV Guidelines ...................................... 40 6.5. TLV Guidelines ...................................... 41
6.6. Allocation Request Guidelines ....................... 41 6.6. Allocation Request Guidelines ....................... 41
6.7. Allocation Requests Guidelines for TLVs ............. 42 6.7. Allocation Requests Guidelines for TLVs ............. 43
6.8. Implementation Guidelines ........................... 43 6.8. Implementation Guidelines ........................... 43
6.9. Vendor Guidelines ................................... 43 6.9. Vendor Guidelines ................................... 43
7. Rationale for This Design ................................ 43 7. Rationale for This Design ................................ 43
7.1. Attribute Audit ..................................... 43 7.1. Attribute Audit ..................................... 44
8. Diameter Considerations .................................. 44 8. Diameter Considerations .................................. 45
9. Examples ................................................. 45 9. Examples ................................................. 45
9.1. Extended Type ....................................... 46 9.1. Extended Type ....................................... 46
9.2. Long Extended Type .................................. 47 9.2. Long Extended Type .................................. 47
10. IANA Considerations ..................................... 50 10. IANA Considerations ..................................... 50
10.1. Attribute Allocations .............................. 50 10.1. Attribute Allocations .............................. 50
10.2. RADIUS Attribute Type Tree ......................... 50 10.2. RADIUS Attribute Type Tree ......................... 51
10.3. Allocation Instructions ............................ 51 10.3. Allocation Instructions ............................ 52
10.3.1. Requested Allocation from the Standard Space .. 52 10.3.1. Requested Allocation from the Standard Space .. 52
10.3.2. Requested Allocation from the short extended sp 52 10.3.2. Requested Allocation from the short extended sp 52
10.3.3. Requested Allocation from the long extended spa 52 10.3.3. Requested Allocation from the long extended spa 52
10.3.4. Allocation Preferences ........................ 52 10.3.4. Allocation Preferences ........................ 52
10.3.5. Extending the Type Space via TLV Data Type .... 53 10.3.5. Extending the Type Space via TLV Data Type .... 53
10.3.6. Allocation within a TLV ....................... 53 10.3.6. Allocation within a TLV ....................... 54
10.3.7. Allocation of Other Data Types ................ 54 10.3.7. Allocation of Other Data Types ................ 54
11. Security Considerations ................................. 54 11. Security Considerations ................................. 54
12. References .............................................. 54 12. References .............................................. 54
12.1. Normative references ............................... 54 12.1. Normative references ............................... 55
12.2. Informative references ............................. 55 12.2. Informative references ............................. 55
Appendix A - Extended Attribute Generator Program ............ 56 Appendix A - Extended Attribute Generator Program ............ 57
1. Introduction 1. Introduction
Under current allocation pressure, we expect that the RADIUS Under current allocation pressure, we expect that the RADIUS
Attribute Type space will be exhausted by 2014 or 2015. We therefore Attribute Type space will be exhausted by 2014 or 2015. We therefore
need a way to extend the type space, so that new specifications may need a way to extend the type space, so that new specifications may
continue to be developed. Other issues have also been shown with continue to be developed. Other issues have also been shown with
RADIUS. The attribute grouping method defined in [RFC2868] has been RADIUS. The attribute grouping method defined in [RFC2868] has been
shown to be impractical, and a more powerful mechanism is needed. shown to be impractical, and a more powerful mechanism is needed.
Multiple attributes have been defined which transport more than the Multiple attributes have been defined 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 40 skipping to change at page 6, line 40
deployments, and implementation difficulty. deployments, and implementation difficulty.
1.1. Caveats and Limitations 1.1. Caveats and Limitations
This section describes some caveats and limitations with the This section describes some caveats and limitations with the
proposal. proposal.
1.1.1. Failure to Meet Certain Goals 1.1.1. Failure to Meet Certain Goals
One goal which was not met by the above modifications is to have an One goal which was not met by the above modifications is to have an
incentive for standards to use the new space. That incenctive is incentive for standards to use the new space. That incentive is
being provided by the exhaustion of the standard space. being provided by the exhaustion of the standard space.
1.1.2. Implementation Recommendations 1.1.2. Implementation Recommendations
It is RECOMMENDED that implementations support this specification. It is RECOMMENDED that implementations support this specification.
It is RECOMMENDED that new specifications use the formats defined in It is RECOMMENDED that new specifications use the formats defined in
this specification. this specification.
The alternative to the above recommendations is a circular argument The alternative to the above recommendations is a circular argument
of not implementing this specification because no other standards of not implementing this specification because no other standards
skipping to change at page 9, line 19 skipping to change at page 9, line 19
type, an Extended-Vendor-Specific (EVS) data type, and an Integer64 type, an Extended-Vendor-Specific (EVS) data type, and an Integer64
data type. It defines a new method for naming attributes and data type. It defines a new method for naming attributes and
identifying Attributes using the new attribute formats. It finally identifying Attributes using the new attribute formats. It finally
defines the new term "invalid attribute", and describes how it defines the new term "invalid attribute", and describes how it
affects implementations. affects implementations.
The new attribute formats are designed to be compatible with the The new attribute formats are designed to be compatible with the
attribute format given in [RFC2865] Section 5. The meaning and attribute format given in [RFC2865] Section 5. The meaning and
interpretation of the Type and Length fields is unchanged from that interpretation of the Type and Length fields is unchanged from that
specification. This reuse allows the new formats to be compatible specification. This reuse allows the new formats to be compatible
RADIUS implementations which do not implement this specification. with RADIUS implementations which do not implement this
Those implementations can simply ignore the Value field of an specification. Those implementations can simply ignore the Value
attribute, or forward it verbatim. field of an attribute, or forward it verbatim.
The changes to the attribute format come about by "stealing" one or The changes to the attribute format come about by "stealing" one or
more octets from the Value field. This change has the effect that more octets from the Value field. This change has the effect that
the Value field of [RFC2865] Section 5 contains both the new octets the Value field of [RFC2865] Section 5 contains both the new octets
given here, and any attribute-specific Value. The result is that given here, and any attribute-specific Value. The result is that
Values in this specification are limited to less than 253 octets in Values in this specification are limited to less than 253 octets in
size. This limitation is overcome through the use of the "Long size. This limitation is overcome through the use of the "Long
Extended Type" format. Extended Type" format.
We reiterate that the formats given in this document do not insert We reiterate that the formats given in this document do not insert
skipping to change at page 13, line 34 skipping to change at page 13, line 34
taken as the sum of the lengths of the fragments (i.e. Value taken as the sum of the lengths of the fragments (i.e. Value
fields) from which it is constructed. The format of the data fields) from which it is constructed. The format of the data
SHOULD be a valid RADIUS data type. If the reassembled data does SHOULD be a valid RADIUS data type. If the reassembled data does
not match the expected format, all fragments MUST be treated as not match the expected format, all fragments MUST be treated as
"invalid attributes", and the reassembled data MUST be discarded. "invalid attributes", and the reassembled data MUST be discarded.
We note that the maximum size of a fragmented attribute is limited We note that the maximum size of a fragmented attribute is limited
only by the RADIUS packet length limitation (i.e. 4096 octets, not only by the RADIUS packet length limitation (i.e. 4096 octets, not
counting various headers and overhead). Implementations MUST be counting various headers and overhead). Implementations MUST be
able to handle the case where one fragmented attribute completely able to handle the case where one fragmented attribute completely
fill the packet. fills the packet.
This definition increases the RADIUS Attribute Type space as above, This definition increases the RADIUS Attribute Type space as above,
but also provides for transport of Attributes which could contain but also provides for transport of Attributes which could contain
more than 253 octets of data. more than 253 octets of data.
Note that [RFC2865] Section 5 says: Note that [RFC2865] Section 5 says:
If multiple Attributes with the same Type are present, the order If multiple Attributes with the same Type are present, the order
of Attributes with the same Type MUST be preserved by any proxies. of Attributes with the same Type MUST be preserved by any proxies.
The order of Attributes of different Types is not required to be The order of Attributes of different Types is not required to be
skipping to change at page 15, line 16 skipping to change at page 15, line 16
receives a TLV with an invalid TLV-Length, then the attribute receives a TLV with an invalid TLV-Length, then the attribute
which encapsulates that TLV MUST be considered to be an "invalid which encapsulates that TLV MUST be considered to be an "invalid
attribute", and handled as per Section 2.8, below. attribute", and handled as per Section 2.8, below.
TLV-Value TLV-Value
The TLV-Value field is one or more octets and contains information The TLV-Value field is one or more octets and contains information
specific to the Attribute. The format and length of the TLV-Value specific to the Attribute. The format and length of the TLV-Value
field is determined by the TLV-Type and TLV-Length fields. field is determined by the TLV-Type and TLV-Length fields.
The TLV-Value field SHOULD encapsulate a previously defined RADIUS The TLV-Value field SHOULD encapsulate a standard RADIUS data
data type. Use of non-standard data types SHOULD NOT be done. We type. Non-standard data types SHOULD NOT be used withing TLV-
note that the TLV-Value field MAY also contain one or more Value fields. We note that the TLV-Value field MAY also contain
attributes of data type "tlv", which allows for simple grouping one or more attributes of data type "tlv", which allows for simple
and multiple layers of nesting. grouping and multiple layers of nesting.
The TLV-Value field is limited to containing 253 or fewer octets The TLV-Value field is limited to containing 253 or fewer octets
of data. Specifications which require a TLV to contain more than of data. Specifications which require a TLV to contain more than
253 octets of data are incompatible with RADIUS, and need to be 253 octets of data are incompatible with RADIUS, and need to be
redesigned. Specifications which require the transport of empty redesigned. Specifications which require the transport of empty
Values (i.e. Length = 2) are incompatible with RADIUS, and need to Values (i.e. Length = 2) are incompatible with RADIUS, and need to
be redesigned. be redesigned.
The TLV-Value field MUST NOT contain data using the "Extended The TLV-Value field MUST NOT contain data using the "Extended
Type" formats defined in this document. The base Extended Type" formats defined in this document. The base Extended
skipping to change at page 16, line 4 skipping to change at page 16, line 4
If multiple TLVs with the same TLV-Type are present, the order of If multiple TLVs with the same TLV-Type are present, the order of
TLVs with the same TLV-Type MUST be preserved by any proxies. The TLVs with the same TLV-Type MUST be preserved by any proxies. The
order of TLVs of different TLV-Types is not required to be preserved. order of TLVs of different TLV-Types is not required to be preserved.
A RADIUS server or client MUST NOT have any dependencies on the order A RADIUS server or client MUST NOT have any dependencies on the order
of TLVs of different TLV-Types. A RADIUS server or client MUST NOT of TLVs of different TLV-Types. A RADIUS server or client MUST NOT
require TLVs of the same TLV-type to be contiguous. require TLVs of the same TLV-type to be contiguous.
The interpretation of multiple TLVs of the same TLV-Type MUST be that The interpretation of multiple TLVs of the same TLV-Type MUST be that
of a logical "and", unless otherwise specified. That is, multiple of a logical "and", unless otherwise specified. That is, multiple
TLVs are interpreted as specifying a set or a list of values. TLVs are interpreted as specifying an unordered set of values.
Specifications SHOULD NOT define TLVs to be interpreted as a logical Specifications SHOULD NOT define TLVs to be interpreted as a logical
"or". Doing so would mean that a RADIUS client or server would make "or". Doing so would mean that a RADIUS client or server would make
an arbitrary, and non-deterministic choice among the values. an arbitrary, and non-deterministic choice among the values.
2.3.1. TLV Nesting 2.3.1. TLV Nesting
TLVs may contain other TLVs. When this occurs, the "container" TLV TLVs may contain other TLVs. When this occurs, the "container" TLV
MUST be completely filled by the "contained" TLVs. That is, the MUST be completely filled by the "contained" TLVs. That is, the
"container" TLV-Length field MUST be exactly two (2) more than the "container" TLV-Length field MUST be exactly two (2) more than the
sum of the "contained" TLV-Length fields. If the "contained" TLVs sum of the "contained" TLV-Length fields. If the "contained" TLVs
skipping to change at page 17, line 16 skipping to change at page 17, line 16
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 | Vendor-Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id Vendor-Id
The 4 octets are the Network Management Private Enterprise Code The 4 octets are the Network Management Private Enterprise Code
[PEN] of the Vendor in network byte order. [PEN] of the Vendor in network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the Vendor.
String Vendor-Value
The String field is one or more octets. It SHOULD encapsulate a The Vendor-Value field is one or more octets. It SHOULD
previously defined RADIUS data type. Using non-standard data encapsulate a standard RADIUS data type. Using non-standard data
types is NOT RECOMMENDED. We note that the Value field may be of types is NOT RECOMMENDED. We note that the Value field may be of
data type "tlv". However, it MUST NOT be of data type "evs", as data type "tlv". However, it MUST NOT be of data type "evs", as
the use cases are unclear for one vendor delegating Attribute Type the use cases are unclear for one vendor delegating Attribute Type
space to another vendor. space to another vendor.
The actual format of the information is site or application The actual format of the information is site or application
specific, and a robust implementation SHOULD support the field as specific, and a robust implementation SHOULD support the field as
undistinguished octets. We recognise that Vendors have complete undistinguished octets. We recognise that Vendors have complete
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 Vendor-
field is implicit, and is determined by taking the "Length" of the Value field is implicit, and is determined by taking the "Length" of
encapsulating RADIUS Attribute, and subtracting the length of the the encapsulating RADIUS Attribute, and subtracting the length of the
attribute header (2 octets), the extended type (1 octet), the Vendor- attribute header (2 octets), the extended type (1 octet), the Vendor-
Id (4 octets), and the Vendor-type (1 octet). i.e. For "Extended Id (4 octets), and the Vendor-type (1 octet). i.e. For "Extended
Type" attributes, the length of the String field is eight (8) less Type" attributes, the length of the Vendor-Value field is eight (8)
than the value of the Length field. For "Long Extended Type" less than the value of the Length field. For "Long Extended Type"
attributes, the length of the String field is nine (9) less than the attributes, the length of the Vendor-Value field is nine (9) less
value of the Length field. than the value of the Length field.
2.5. Integer64 Data Type 2.5. Integer64 Data Type
We define a new data type in RADIUS, called "integer64", which We define a new data type in RADIUS, called "integer64", which
carries a 64-bit unsigned integer in network byte order. carries a 64-bit unsigned integer in network byte order.
This data type is intended to be used in any situation where there is This data type is intended to be used in any situation where there is
a need to have counters which can count past 2^32. The expected use a need to have counters 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 22, line 24 skipping to change at page 22, line 24
For Attributes of type "TLV", an Attribute is considered to be an For Attributes of type "TLV", an Attribute is considered to be an
"invalid attribute" when the TLV-Length field allows the "invalid attribute" when the TLV-Length field allows the
encapsulating Attribute to be parsed, but the TLV-Value field does encapsulating Attribute to be parsed, but the TLV-Value field does
not match the criteria for that TLV. Implementations SHOULD NOT not match the criteria for that TLV. Implementations SHOULD NOT
treat the "invalid attribute" property as being transitive. That is, treat the "invalid attribute" property as being transitive. That is,
the Attribute encapsulating the "invalid attribute" SHOULD NOT be the Attribute encapsulating the "invalid attribute" SHOULD NOT be
treated as an "invalid attribute". That encapsulating Attribute treated as an "invalid attribute". That encapsulating Attribute
might contain multiple TLVs, only one of which is an "invalid might contain multiple TLVs, only one of which is an "invalid
attribute". attribute".
However, a TLV definition may require particular sub-TLVs to be
present, and/or to have specific values. If a sub-TLV is missing, or
contains incorrect value(s), or is an "invalid attribute", then the
encapsulating TLV SHOULD be treated as an "invalid attribute". This
requirement ensures that strongly connected TLVs are handled either
as a coherent whole, or are ignored entirely.
3. Attribute Definitions 3. Attribute Definitions
We define four (4) attributes of "Extended Type", which are allocated We define four (4) attributes of "Extended Type", which are allocated
from the "Reserved" Attribute Type codes of 241, 242, 243, and 244. from the "Reserved" Attribute Type codes of 241, 242, 243, and 244.
We also define two (2) attributes of "Long Extended Type", which are We also define two (2) attributes of "Long Extended Type", which are
allocated from the "Reserved" Attribute Type codes of 245 and 246. allocated from the "Reserved" Attribute Type codes of 245 and 246.
Type Name Type Name
---- ---- ---- ----
241 Extended-Type-1 241 Extended-Type-1
skipping to change at page 54, line 19 skipping to change at page 54, line 35
value. e.g. Starting from 241.1, proceeding through 241.255, then to value. e.g. Starting from 241.1, proceeding through 241.255, then to
242.1, through 242.255, etc. 242.1, through 242.255, etc.
11. Security Considerations 11. Security Considerations
This document defines new formats for data carried inside of RADIUS, This document defines new formats for data carried inside of RADIUS,
but otherwise makes no changes to the security of the RADIUS but otherwise makes no changes to the security of the RADIUS
protocol. protocol.
Attacks on cryptographic hashes are well known, and are getting Attacks on cryptographic hashes are well known, and are getting
better with time, as discussed in[RFC4270]. RADIUS uses the MD5 hash better with time, as discussed in [RFC4270]. The security of the
[RFC1321] for packet authentication and attribute obfuscation. There RADIUS protocol is dependent on MD5 [RFC1311], which has security
are ongoing efforts in the IETF to analyze and address these issues issues as discussed in [RFC6151]. It is not known if the issues
for the RADIUS protocol. described in [RFC6151] apply to RADIUS. For other issues, we
incorporate by reference the security considerations of [RFC6158]
Section 5.
As with any protocol change, code changes are required in order to As with any protocol change, code changes are required in order to
implement the new features. These code changes have the potential to implement the new features. These code changes have the potential to
introduce new vulnerabilities in the software. Since the RADIUS introduce new vulnerabilities in the software. Since the RADIUS
server performs network authentication, it is an inviting target for server performs network authentication, it is an inviting target for
attackers. We RECOMMEND that access to RADIUS servers be kept to a attackers. We RECOMMEND that access to RADIUS servers be kept to a
minimum. minimum.
12. References 12. References
12.1. Normative references 12.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [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.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
skipping to change at page 55, line 24 skipping to change at page 55, line 44
[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.
[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.
[RFC6151] Turner. S. and Chen, L., "Updated Security Considerations for
the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151,
March 2011.
[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
participants who contributed various ideas over the years. Their participants who contributed various ideas over the years. Their
 End of changes. 25 change blocks. 
43 lines changed or deleted 55 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/