< draft-aboba-radius-iana   rfc3575.txt 
Network Working Group B. Aboba Network Working Group B. Aboba
INTERNET-DRAFT Microsoft Request for Comments: 3575 Microsoft
Category: Standards Track Updates: 2865 July 2003
<draft-aboba-radius-iana-06.txt> Category: Standard Track
17 April 2003
Updates: RFC 2865
IANA Considerations for RADIUS IANA Considerations for RADIUS
(Remote Authentication Dial In User Service)
This document is an Internet-Draft and is in full conformance with all Status of this Memo
provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet- Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document describes the IANA considerations for the Remote This document describes the IANA considerations for the Remote
Authentication Dial In User Service (RADIUS). Authentication Dial In User Service (RADIUS).
This document updates RFC 2865. This document updates RFC 2865.
1. Introduction 1. Introduction
This document provides guidance to the Internet Assigned Numbers This document provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the Remote Authority (IANA) regarding registration of values related to the
Authentication Dial In User Service (RADIUS), defined in [RFC2865], in Remote Authentication Dial In User Service (RADIUS), defined in
accordance with BCP 26, [RFC2434]. It also reserves Packet Type Codes [RFC2865], in accordance with BCP 26, [RFC2434]. It also reserves
that are or have been in use on the Internet. Packet Type Codes that are or have been in use on the Internet.
1.1. Specification of Requirements 1.1. Specification of Requirements
In this document, several words are used to signify the requirements of In this document, several words are used to signify the requirements
the specification. These words are often capitalized. The key words of the specification. These words are often capitalized. The key
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
interpreted as described in [RFC2119]. are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
The following terms are used here with the meanings defined in BCP 26: The following terms are used here with the meanings defined in BCP
"name space", "assigned value", "registration". 26: "name space", "assigned value", "registration".
The following policies are used here with the meanings defined in BCP The following policies are used here with the meanings defined in BCP
26: "Private Use", "First Come First Served", "Expert Review", 26: "Private Use", "First Come First Served", "Expert Review",
"Specification Required", "IETF Consensus", "Standards Action". "Specification Required", "IESG Approval", "IETF Consensus",
"Standards Action".
2. IANA Considerations 2. IANA Considerations
There are three name spaces in RADIUS that require registration: Packet There are three name spaces in RADIUS that require registration:
Type Codes, Attribute Types, and Attribute Values (for certain Packet Type Codes, Attribute Types, and Attribute Values (for certain
Attributes). This draft creates no new IANA registries, since a RADIUS Attributes). This document creates no new IANA registries, since a
registry was created by [RFC2865]. RADIUS registry was created by [RFC2865].
RADIUS is not intended as a general-purpose protocol, and allocations RADIUS is not intended as a general-purpose protocol, and allocations
SHOULD NOT be made for purposes unrelated to Authentication, SHOULD NOT be made for purposes unrelated to Authentication,
Authorization or Accounting. Authorization or Accounting.
2.1. Recommended Registration Policies 2.1. Recommended Registration Policies
For registration requests where a Designated Expert should be consulted, For registration requests where a Designated Expert should be
the responsible IESG area director should appoint the Designated Expert. consulted, the responsible IESG area director should appoint the
The intention is that any allocation will be accompanied by a published Designated Expert. The intention is that any allocation will be
RFC. But in order to allow for the allocation of values prior to the accompanied by a published RFC. However, the Designated Expert can
RFC being approved for publication, the Designated Expert can approve approve allocations once it seems clear that an RFC will be
allocations once it seems clear that an RFC will be published. The published, allowing for the allocation of values prior to the
Designated expert will post a request to the AAA WG mailing list (or a document being approved for publication as an RFC. The Designated
successor designated by the Area Director) for comment and review, Expert will post a request to the AAA WG mailing list (or a successor
including an Internet-Draft. Before a period of 30 days has passed, The designated by the Area Director) for comment and review, including an
Designated Expert will either approve or deny the registration request Internet-Draft. Before a period of 30 days has passed, the
and publish a notice of the decision to the AAA WG mailing list or its Designated Expert will either approve or deny the registration
successor, as well as informing IANA. A denial notice must be justified request, publish a notice of the decision to the AAA WG mailing list
by an explanation and, in the cases where it is possible, concrete or its successor, and inform IANA of its decision. A denial notice
suggestions on how the request can be modified so as to become must be justified by an explanation and, in the cases where it is
acceptable. possible, concrete suggestions on how the request can be modified so
as to become acceptable.
Packet Type Codes have a range from 1 to 253. RADIUS Type Codes 1-5 and Packet Type Codes have a range from 1 to 253. RADIUS Type Codes 1-5
11-13 were allocated in [RFC2865], while Type Codes 40-45, 250-253 are and 11-13 were allocated in [RFC2865], while Type Codes 40-45,
allocated by this document. Type Codes 250-253 are allocated for 250-253 are allocated by this document. Type Codes 250-253 are
Experimental Uses, and 254-255 are reserved. Packet Type Codes 6-10, allocated for Experimental Uses, and 254-255 are reserved. Packet
12-13, 21-34, 50-51 have no meaning defined by an IETF RFC, but are Type Codes 6-10, 12-13, 21-34, 50-51 have no meaning defined by an
reserved until a specification is provided for them. This is being done IETF RFC, but are reserved until a specification is provided for
to avoid interoperability problems with software that implements non- them. This is being done to avoid interoperability problems with
standard RADIUS extensions that are or have been in use on the Internet. software that implements non-standard RADIUS extensions that are or
Because a new Packet Type has considerable impact on interoperability, a have been in use on the Internet. Because a new Packet Type has
new Packet Type Code requires Standards Action. Type Codes 52-249 considerable impact on interoperability, a new Packet Type Code
should be allocated first; when these are exhausted, Type Codes 14-20, requires IESG Approval. The intention is that any allocation will be
35-39, 46-49 may be allocated. For a list of Type Codes, see Appendix accompanied by a published RFC. Type Codes 52-249 should be
A. allocated first; when these are exhausted, Type Codes 14-20, 35-39,
46-49 may be allocated. For a list of Type Codes, see Appendix A.
Attribute Types have a range from 1 to 255, and are the scarcest Attribute Types have a range from 1 to 255, and are the scarcest
resource in RADIUS, thus must be allocated with care. Attributes resource in RADIUS, thus must be allocated with care. Attributes
1-53,55,60-88,90-91,94-100 have been allocated, with 17 and 21 available 1-53,55,60-88,90-91,94-100 have been allocated, with 17 and 21
for re-use. Attributes 17, 21, 54, 56-59, 89, 101-191 may be allocated available for re-use. Attributes 17, 21, 54, 56-59, 89, 101-191 may
by IETF Consensus. It is recommended that attributes 17 and 21 be used be allocated by IETF Consensus. It is recommended that attributes 17
only after all others are exhausted. and 21 be used only after all others are exhausted.
Note that RADIUS defines a mechanism for Vendor-Specific extensions Note that RADIUS defines a mechanism for Vendor-Specific extensions
(Attribute 26) and the use of that should be encouraged instead of (Attribute 26) for functions specific only to one vendor's
allocation of global attribute types, for functions specific only to one implementation of RADIUS, where no interoperability is deemed useful.
vendor's implementation of RADIUS, where no interoperability is deemed For functions specific only to one vendor's implementation of RADIUS,
useful. the use of that should be encouraged instead of the allocation of
global attribute types.
As noted in [RFC2865]: As noted in [RFC2865]:
Attribute Type Values 192-223 are reserved for experimental Attribute Type Values 192-223 are reserved for experimental use,
use, values 224-240 are reserved for implementation-specific use, values 224-240 are reserved for implementation-specific use, and
and values 241-255 are reserved and should not be used. values 241-255 are reserved and should not be used.
Therefore Attribute Type values 192-240 are considered Private Use, and Therefore Attribute Type values 192-240 are considered Private Use,
values 241-255 require Standards Action. and values 241-255 require Standards Action.
Certain attributes (for example, NAS-Port-Type) in RADIUS define a list Certain attributes (for example, NAS-Port-Type) in RADIUS define a
of values to correspond with various meanings. There can be 4 billion list of values to correspond with various meanings. There can be 4
(2^32) values for each attribute. Additional values can be allocated by billion (2^32) values for each attribute. Additional values can be
Designated Expert. The exception to this policy is the Service-Type allocated by the Designated Expert. The exception to this policy is
attribute (6), whose values define new modes of operation for RADIUS. the Service-Type attribute (6), whose values define new modes of
Values 1-16 of the Service-Type attribute have been allocated. operation for RADIUS. Values 1-16 of the Service-Type attribute have
been allocated. Allocation of new Service-Type values are by IETF
Consensus. The intention is that any allocation will be accompanied
by a published RFC.
Allocation of new Service-Type values are by IETF Consensus. 3. References
3. Normative references 3.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", BCP 14, RFC 2119, March 1997.
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", BCP 26, RFC 2434, an IANA Considerations Section in RFCs", BCP 26, RFC
October 1998. 2434, October 1998.
[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
4. Informative references 3.2. Informative References
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and
Implementation in Roaming", RFC 2607, June 1999. Policy Implementation in Roaming", RFC 2607, June
1999.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2867] Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting [RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867, Modifications for Tunnel Protocol Support", RFC 2867,
June 2000. June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Holdrege, M. and I. Goyret, "RADIUS Attributes for
Support", RFC 2868, June 2000. Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS
Extensions", RFC 2869, June 2000. Extensions", RFC 2869, June 2000.
[RFC2869bis] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible [RFC2869bis] Aboba, B. and P. Calhoun, "RADIUS Support for
Authentication Protocol (EAP)", draft-aboba-radius- Extensible Authentication Protocol (EAP)", Work in
rfc2869bis-18.txt, Internet draft (work in progress), Progress.
April 2003.
[RFC2882] Mitton, D., "Network Access Servers Requirements: [RFC2882] Mitton, D., "Network Access Servers Requirements:
Extended RADIUS Practices", RFC 2882, July 2000. Extended RADIUS Practices", RFC 2882, July 2000.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6",
3162, August 2001. RFC 3162, August 2001.
[DynAuth] Chiba, M., et al., "Dynamic Authorization Extensions to [DynAuth] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
Remote Authentication Dial In User Service (RADIUS)", Aboba, "Dynamic Authorization Extensions to Remote
Internet draft (work in progress), draft-chiba-radius- Authentication Dial In User Service (RADIUS)", RFC
dynamic-authorization-16.txt, April 2003. 3576, July 2003.
5. Security Considerations 4. Security Considerations
The security considerations detailed in [RFC2434] are generally The security considerations detailed in [RFC2434] are generally
applicable to this document. Security considerations relating to the applicable to this document. Security considerations relating to the
RADIUS protocol are discussed in [RFC2607], [RFC2865], [RFC3162], RADIUS protocol are discussed in [RFC2607], [RFC2865], [RFC3162],
[DynAuth], and [RFC2869bis]. [DynAuth], and [RFC2869bis].
Appendix A - RADIUS Packet Types Appendix A - RADIUS Packet Types
A list of RADIUS Packet Type Codes is given below. This document A list of RADIUS Packet Type Codes is given below. This document
instructs IANA to list them in the registry of Packet Type Codes. Note instructs IANA to list them in the registry of Packet Type Codes.
that Type Codes 40-45, which are defined in [DynAuth] are being formally Note that Type Codes 40-45, defined in [DynAuth], are being formally
allocated here. Codes 40-45 were listed in [RFC2882] and have been allocated here. Codes 40-45 were listed in [RFC2882] and have been
implemented and used. Given their widespread current usage, these implemented and used. Given their current widespread usage, these
assignments are not reclaimable in practice. assignments are not reclaimable in practice.
# Message Reference # Message Reference
1 Access-Request [RFC2865] ---- ------------------------- ---------
2 Access-Accept [RFC2865] 1 Access-Request [RFC2865]
3 Access-Reject [RFC2865] 2 Access-Accept [RFC2865]
4 Accounting-Request [RFC2865] 3 Access-Reject [RFC2865]
5 Accounting-Response [RFC2865] 4 Accounting-Request [RFC2865]
6 Accounting-Status [RFC2882] 5 Accounting-Response [RFC2865]
(now Interim Accounting) 6 Accounting-Status [RFC2882]
7 Password-Request [RFC2882] (now Interim Accounting)
8 Password-Ack [RFC2882] 7 Password-Request [RFC2882]
9 Password-Reject [RFC2882] 8 Password-Ack [RFC2882]
10 Accounting-Message [RFC2882] 9 Password-Reject [RFC2882]
11 Access-Challenge [RFC2865] 10 Accounting-Message [RFC2882]
12 Status-Server (experimental) [RFC2865] 11 Access-Challenge [RFC2865]
13 Status-Client (experimental) [RFC2865] 12 Status-Server (experimental) [RFC2865]
21 Resource-Free-Request [RFC2882] 13 Status-Client (experimental) [RFC2865]
22 Resource-Free-Response [RFC2882] 21 Resource-Free-Request [RFC2882]
23 Resource-Query-Request [RFC2882] 22 Resource-Free-Response [RFC2882]
24 Resource-Query-Response [RFC2882] 23 Resource-Query-Request [RFC2882]
25 Alternate-Resource- 24 Resource-Query-Response [RFC2882]
Reclaim-Request [RFC2882] 25 Alternate-Resource-
26 NAS-Reboot-Request [RFC2882] Reclaim-Request [RFC2882]
27 NAS-Reboot-Response [RFC2882] 26 NAS-Reboot-Request [RFC2882]
28 Reserved 27 NAS-Reboot-Response [RFC2882]
29 Next-Passcode [RFC2882] 28 Reserved
30 New-Pin [RFC2882] 29 Next-Passcode [RFC2882]
31 Terminate-Session [RFC2882] # Message Reference
32 Password-Expired [RFC2882] ---- ------------------------- ---------
33 Event-Request [RFC2882] 30 New-Pin [RFC2882]
34 Event-Response [RFC2882] 31 Terminate-Session [RFC2882]
# Message Reference 32 Password-Expired [RFC2882]
40 Disconnect-Request [DynAuth] 33 Event-Request [RFC2882]
41 Disconnect-ACK [DynAuth] 34 Event-Response [RFC2882]
42 Disconnect-NAK [DynAuth] 40 Disconnect-Request [DynAuth]
43 CoA-Request [DynAuth] 41 Disconnect-ACK [DynAuth]
44 CoA-ACK [DynAuth] 42 Disconnect-NAK [DynAuth]
45 CoA-NAK [DynAuth] 43 CoA-Request [DynAuth]
50 IP-Address-Allocate [RFC2882] 44 CoA-ACK [DynAuth]
51 IP-Address-Release [RFC2882] 45 CoA-NAK [DynAuth]
250-253 Experimental Use 50 IP-Address-Allocate [RFC2882]
254 Reserved 51 IP-Address-Release [RFC2882]
255 Reserved [RFC2865] 250-253 Experimental Use
254 Reserved
255 Reserved [RFC2865]
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards- related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Acknowledgments Acknowledgments
Thanks to Ignacio Goyret of Lucent, Allison Mankin of Lucent Bell Labs, Thanks to Ignacio Goyret of Lucent, Allison Mankin of Lucent Bell
Thomas Narten of IBM, Glen Zorn and Harald Alvestrand of Cisco for Labs, Thomas Narten of IBM, Glen Zorn and Harald Alvestrand of Cisco
discussions relating to this document. for discussions relating to this document.
Authors' Addresses Authors' Addresses
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
EMail: [email protected] EMail: [email protected]
Phone: +1 425 706 6605 Phone: +1 425 706 6605
Fax: +1 425 936 7329 Fax: +1 425 936 7329
Intellectual Property Statement Full Copyright Statement
The IETF takes no position regarding the validity or scope of any Copyright (C) The Internet Society (2003). All Rights Reserved.
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementers or users of this specification can be obtained from the
IETF Secretariat.
The IETF invites any interested party to bring to its attention any This document and translations of it may be copied and furnished to
copyrights, patents or patent applications, or other proprietary rights others, and derivative works that comment on or otherwise explain it
which may cover technology that may be required to practice this or assist in its implementation may be prepared, copied, published
standard. Please address the information to the IETF Executive and distributed, in whole or in part, without restriction of any
Director. kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
Full Copyright Statement The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
Copyright (C) The Internet Society (2003). All Rights Reserved. This document and the information contained herein is provided on an
This document and translations of it may be copied and furnished to "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
others, and derivative works that comment on or otherwise explain it or TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
assist in its implementation may be prepared, copied, published and BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
distributed, in whole or in part, without restriction of any kind, HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
provided that the above copyright notice and this paragraph are included MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English. The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expiration Date Acknowledgement
This memo is filed as <draft-aboba-radius-iana-06.txt>, and expires Funding for the RFC Editor function is currently provided by the
November 19, 2003. Internet Society.
 End of changes. 50 change blocks. 
236 lines changed or deleted 239 lines changed or added

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