draft-ietf-radext-radius-extensions-07.txt   draft-ietf-radext-radius-extensions-08.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-07.txt> <draft-ietf-radext-radius-extensions-08.txt>
Expires: June 26, 2013 Expires: July 8, 2013
26 December 2012 8 January 2013
Remote Authentication Dial In User Service (RADIUS) Protocol Remote Authentication Dial In User Service (RADIUS) Protocol
Extensions Extensions
draft-ietf-radext-radius-extensions-07.txt draft-ietf-radext-radius-extensions-08.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 2, line 4 skipping to change at page 2, line 4
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 June 26, 2013. This Internet-Draft will expire on June 26, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of (http://trustee.ietf.org/license-info/) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 16, line 45 skipping to change at page 16, line 45
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 ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id Vendor-Id
The 4 octets are the SMI Network Management Private Enterprise The 4 octets are the Network Management Private Enterprise Code
Code [SMI] 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.
Value Value
The Value field is one or more octets. It SHOULD encapsulate a The Value field is one or more octets. It SHOULD encapsulate a
previously defined RADIUS data type. Using non-standard data previously defined RADIUS data type. Using non-standard data
skipping to change at page 29, line 8 skipping to change at page 29, line 8
Type.Extended-Type Type.Extended-Type
241.26 for Extended-Vendor-Specific-1 241.26 for Extended-Vendor-Specific-1
Length Length
>= 9 >= 9
Vendor-Id Vendor-Id
The 4 octets are the SMI Network Management Private Enterprise The 4 octets are the Network Management Private Enterprise Code
Code [SMI] 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.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 30, line 14 skipping to change at page 30, line 14
Type.Extended-Type Type.Extended-Type
242.26 for Extended-Vendor-Specific-2 242.26 for Extended-Vendor-Specific-2
Length Length
>= 9 >= 9
Vendor-Id Vendor-Id
The 4 octets are the SMI Network Management Private Enterprise The 4 octets are the Network Management Private Enterprise Code
Code [SMI] 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.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 31, line 21 skipping to change at page 31, line 21
Type.Extended-Type Type.Extended-Type
243.26 for Extended-Vendor-Specific-3 243.26 for Extended-Vendor-Specific-3
Length Length
>= 9 >= 9
Vendor-Id Vendor-Id
The 4 octets are the SMI Network Management Private Enterprise The 4 octets are the Network Management Private Enterprise Code
Code [SMI] 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.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 32, line 26 skipping to change at page 32, line 26
Type.Extended-Type Type.Extended-Type
244.26 for Extended-Vendor-Specific-4 244.26 for Extended-Vendor-Specific-4
Length Length
>= 9 >= 9
Vendor-Id Vendor-Id
The 4 octets are the SMI Network Management Private Enterprise The 4 octets are the Network Management Private Enterprise Code
Code [SMI] 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.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 34, line 4 skipping to change at page 34, line 4
Further definition of this field is given in Section 2.2, above. Further definition of this field is given in Section 2.2, above.
Reserved Reserved
This field is 7 bits long, and is reserved for future use. This field is 7 bits long, and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an attribute Implementations MUST set it to zero (0) when encoding an attribute
for sending in a packet. The contents SHOULD be ignored on for sending in a packet. The contents SHOULD be ignored on
reception. reception.
Vendor-Id Vendor-Id
The 4 octets are the SMI Network Management Private Enterprise The 4 octets are the Network Management Private Enterprise Code
Code [SMI] 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.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 35, line 25 skipping to change at page 35, line 25
Reserved Reserved
This field is 7 bits long, and is reserved for future use. This field is 7 bits long, and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an attribute Implementations MUST set it to zero (0) when encoding an attribute
for sending in a packet. The contents SHOULD be ignored on for sending in a packet. The contents SHOULD be ignored on
reception. reception.
Vendor-Id Vendor-Id
The 4 octets are the SMI Network Management Private Enterprise The 4 octets are the Network Management Private Enterprise Code
Code [SMI] 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.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 40, line 40 skipping to change at page 40, line 40
infinite. infinite.
* Specifications which allocate many attributes MUST NOT request that * Specifications which allocate many attributes MUST NOT request that
allocation be made from from the standard space. That space is allocation be made from from the standard space. That space is
under allocation pressure, and the extended space is more suitable under allocation pressure, and the extended space is more suitable
for large allocations. for large allocations.
* Specifications which allocate many related attributes SHOULD define * Specifications which allocate many related attributes SHOULD define
one or more TLVs to contain related attributes. one or more TLVs to contain related attributes.
* New specifications SHOULD NOT request allocation from the standard * Specifications should not request allocation from a specific space.
Attribute Type Space (i.e. Attributes 1 through 255). That space The IANA considerations given in Section 9, below, should be
is deprecated. sufficient for attribute allocation.
* It is RECOMMENDED that specifications do not request allocation
from a specific space. The IANA considerations given in
Section 9, below, should be sufficient for attribute allocation.
* Specifications of an attribute which encodes 252 octets or less * Specifications of an attribute which encodes 252 octets or less
of data MAY request allocation from the exended space, using of data MAY request allocation from the exended space, using
format "Extended Type" format "Extended Type"
* Specifications of an attribute which always encode less than 253 * Specifications of an attribute which always encode less than 253
octets of data MUST NOT request allocation from the long extended octets of data MUST NOT request allocation from the long extended
space. The standard space, or the short extended space MUST be space. The standard space, or the short extended space MUST be
used instead. used instead.
skipping to change at page 51, line 25 skipping to change at page 51, line 25
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
the standard space. the standard space.
* specifications which allocate a large number of attributes * specifications which would allocate a large percentage of the
(i.e. ten or more) should have all allocations made from the remaining standard space attributes should have all allocations
extended space. made from the 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.
skipping to change at page 53, line 25 skipping to change at page 53, line 25
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.
[RFC3575] Aboba, B, "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575, July 2003.
[RFC5176] Chiba, M, et. al., "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176,
January 2008.
[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.
[SMI] http://www.iana.org/assignments/enterprise-numbers [RFC6158] DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC
6158, March 2011.
[PEN] http://www.iana.org/assignments/enterprise-numbers
12.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.
[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
Authentication Dial In User Service)", RFC 3575, July 2003.
[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.
[RFC6158] DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC
6158, 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. 17 change blocks. 
38 lines changed or deleted 38 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/