7 Network Working Group B. Aboba
8 Request for Comments: 3575 Microsoft
9 Updates: 2865 July 2003
10 Category: Standard Track
13 IANA Considerations for RADIUS
14 (Remote Authentication Dial In User Service)
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
26 Copyright (C) The Internet Society (2003). All Rights Reserved.
30 This document describes the IANA considerations for the Remote
31 Authentication Dial In User Service (RADIUS).
33 This document updates RFC 2865.
37 This document provides guidance to the Internet Assigned Numbers
38 Authority (IANA) regarding registration of values related to the
39 Remote Authentication Dial In User Service (RADIUS), defined in
40 [RFC2865], in accordance with BCP 26, [RFC2434]. It also reserves
41 Packet Type Codes that are or have been in use on the Internet.
43 1.1. Specification of Requirements
45 In this document, several words are used to signify the requirements
46 of the specification. These words are often capitalized. The key
47 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
48 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
49 are to be interpreted as described in [RFC2119].
58 Aboba Standards Track [Page 1]
60 RFC 3575 IANA Considerations for RADIUS July 2003
65 The following terms are used here with the meanings defined in BCP
66 26: "name space", "assigned value", "registration".
68 The following policies are used here with the meanings defined in BCP
69 26: "Private Use", "First Come First Served", "Expert Review",
70 "Specification Required", "IESG Approval", "IETF Consensus",
73 2. IANA Considerations
75 There are three name spaces in RADIUS that require registration:
76 Packet Type Codes, Attribute Types, and Attribute Values (for certain
77 Attributes). This document creates no new IANA registries, since a
78 RADIUS registry was created by [RFC2865].
80 RADIUS is not intended as a general-purpose protocol, and allocations
81 SHOULD NOT be made for purposes unrelated to Authentication,
82 Authorization or Accounting.
84 2.1. Recommended Registration Policies
86 For registration requests where a Designated Expert should be
87 consulted, the responsible IESG area director should appoint the
88 Designated Expert. The intention is that any allocation will be
89 accompanied by a published RFC. However, the Designated Expert can
90 approve allocations once it seems clear that an RFC will be
91 published, allowing for the allocation of values prior to the
92 document being approved for publication as an RFC. The Designated
93 Expert will post a request to the AAA WG mailing list (or a successor
94 designated by the Area Director) for comment and review, including an
95 Internet-Draft. Before a period of 30 days has passed, the
96 Designated Expert will either approve or deny the registration
97 request, publish a notice of the decision to the AAA WG mailing list
98 or its successor, and inform IANA of its decision. A denial notice
99 must be justified by an explanation and, in the cases where it is
100 possible, concrete suggestions on how the request can be modified so
101 as to become acceptable.
103 Packet Type Codes have a range from 1 to 253. RADIUS Type Codes 1-5
104 and 11-13 were allocated in [RFC2865], while Type Codes 40-45,
105 250-253 are allocated by this document. Type Codes 250-253 are
106 allocated for Experimental Uses, and 254-255 are reserved. Packet
107 Type Codes 6-10, 12-13, 21-34, 50-51 have no meaning defined by an
108 IETF RFC, but are reserved until a specification is provided for
109 them. This is being done to avoid interoperability problems with
110 software that implements non-standard RADIUS extensions that are or
114 Aboba Standards Track [Page 2]
116 RFC 3575 IANA Considerations for RADIUS July 2003
119 have been in use on the Internet. Because a new Packet Type has
120 considerable impact on interoperability, a new Packet Type Code
121 requires IESG Approval. The intention is that any allocation will be
122 accompanied by a published RFC. Type Codes 52-249 should be
123 allocated first; when these are exhausted, Type Codes 14-20, 35-39,
124 46-49 may be allocated. For a list of Type Codes, see Appendix A.
126 Attribute Types have a range from 1 to 255, and are the scarcest
127 resource in RADIUS, thus must be allocated with care. Attributes
128 1-53,55,60-88,90-91,94-100 have been allocated, with 17 and 21
129 available for re-use. Attributes 17, 21, 54, 56-59, 89, 101-191 may
130 be allocated by IETF Consensus. It is recommended that attributes 17
131 and 21 be used only after all others are exhausted.
133 Note that RADIUS defines a mechanism for Vendor-Specific extensions
134 (Attribute 26) for functions specific only to one vendor's
135 implementation of RADIUS, where no interoperability is deemed useful.
136 For functions specific only to one vendor's implementation of RADIUS,
137 the use of that should be encouraged instead of the allocation of
138 global attribute types.
140 As noted in [RFC2865]:
142 Attribute Type Values 192-223 are reserved for experimental use,
143 values 224-240 are reserved for implementation-specific use, and
144 values 241-255 are reserved and should not be used.
146 Therefore Attribute Type values 192-240 are considered Private Use,
147 and values 241-255 require Standards Action.
149 Certain attributes (for example, NAS-Port-Type) in RADIUS define a
150 list of values to correspond with various meanings. There can be 4
151 billion (2^32) values for each attribute. Additional values can be
152 allocated by the Designated Expert. The exception to this policy is
153 the Service-Type attribute (6), whose values define new modes of
154 operation for RADIUS. Values 1-16 of the Service-Type attribute have
155 been allocated. Allocation of new Service-Type values are by IETF
156 Consensus. The intention is that any allocation will be accompanied
161 3.1. Normative References
163 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
164 Requirement Levels", BCP 14, RFC 2119, March 1997.
170 Aboba Standards Track [Page 3]
172 RFC 3575 IANA Considerations for RADIUS July 2003
175 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
176 an IANA Considerations Section in RFCs", BCP 26, RFC
179 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
180 "Remote Authentication Dial In User Service (RADIUS)",
183 3.2. Informative References
185 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and
186 Policy Implementation in Roaming", RFC 2607, June
189 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
191 [RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
192 Modifications for Tunnel Protocol Support", RFC 2867,
195 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
196 Holdrege, M. and I. Goyret, "RADIUS Attributes for
197 Tunnel Protocol Support", RFC 2868, June 2000.
199 [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS
200 Extensions", RFC 2869, June 2000.
202 [RFC2869bis] Aboba, B. and P. Calhoun, "RADIUS Support for
203 Extensible Authentication Protocol (EAP)", Work in
206 [RFC2882] Mitton, D., "Network Access Servers Requirements:
207 Extended RADIUS Practices", RFC 2882, July 2000.
209 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6",
210 RFC 3162, August 2001.
212 [DynAuth] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
213 Aboba, "Dynamic Authorization Extensions to Remote
214 Authentication Dial In User Service (RADIUS)", RFC
217 4. Security Considerations
219 The security considerations detailed in [RFC2434] are generally
220 applicable to this document. Security considerations relating to the
221 RADIUS protocol are discussed in [RFC2607], [RFC2865], [RFC3162],
222 [DynAuth], and [RFC2869bis].
226 Aboba Standards Track [Page 4]
228 RFC 3575 IANA Considerations for RADIUS July 2003
231 Appendix A - RADIUS Packet Types
233 A list of RADIUS Packet Type Codes is given below. This document
234 instructs IANA to list them in the registry of Packet Type Codes.
235 Note that Type Codes 40-45, defined in [DynAuth], are being formally
236 allocated here. Codes 40-45 were listed in [RFC2882] and have been
237 implemented and used. Given their current widespread usage, these
238 assignments are not reclaimable in practice.
241 ---- ------------------------- ---------
242 1 Access-Request [RFC2865]
243 2 Access-Accept [RFC2865]
244 3 Access-Reject [RFC2865]
245 4 Accounting-Request [RFC2865]
246 5 Accounting-Response [RFC2865]
247 6 Accounting-Status [RFC2882]
248 (now Interim Accounting)
249 7 Password-Request [RFC2882]
250 8 Password-Ack [RFC2882]
251 9 Password-Reject [RFC2882]
252 10 Accounting-Message [RFC2882]
253 11 Access-Challenge [RFC2865]
254 12 Status-Server (experimental) [RFC2865]
255 13 Status-Client (experimental) [RFC2865]
256 21 Resource-Free-Request [RFC2882]
257 22 Resource-Free-Response [RFC2882]
258 23 Resource-Query-Request [RFC2882]
259 24 Resource-Query-Response [RFC2882]
260 25 Alternate-Resource-
261 Reclaim-Request [RFC2882]
262 26 NAS-Reboot-Request [RFC2882]
263 27 NAS-Reboot-Response [RFC2882]
265 29 Next-Passcode [RFC2882]
282 Aboba Standards Track [Page 5]
284 RFC 3575 IANA Considerations for RADIUS July 2003
288 ---- ------------------------- ---------
290 31 Terminate-Session [RFC2882]
291 32 Password-Expired [RFC2882]
292 33 Event-Request [RFC2882]
293 34 Event-Response [RFC2882]
294 40 Disconnect-Request [DynAuth]
295 41 Disconnect-ACK [DynAuth]
296 42 Disconnect-NAK [DynAuth]
297 43 CoA-Request [DynAuth]
300 50 IP-Address-Allocate [RFC2882]
301 51 IP-Address-Release [RFC2882]
302 250-253 Experimental Use
304 255 Reserved [RFC2865]
338 Aboba Standards Track [Page 6]
340 RFC 3575 IANA Considerations for RADIUS July 2003
343 Intellectual Property Statement
345 The IETF takes no position regarding the validity or scope of any
346 intellectual property or other rights that might be claimed to
347 pertain to the implementation or use of the technology described in
348 this document or the extent to which any license under such rights
349 might or might not be available; neither does it represent that it
350 has made any effort to identify any such rights. Information on the
351 IETF's procedures with respect to rights in standards-track and
352 standards- related documentation can be found in BCP-11. Copies of
353 claims of rights made available for publication and any assurances of
354 licenses to be made available, or the result of an attempt made to
355 obtain a general license or permission for the use of such
356 proprietary rights by implementers or users of this specification can
357 be obtained from the IETF Secretariat.
359 The IETF invites any interested party to bring to its attention any
360 copyrights, patents or patent applications, or other proprietary
361 rights which may cover technology that may be required to practice
362 this standard. Please address the information to the IETF Executive
367 Thanks to Ignacio Goyret of Lucent, Allison Mankin of Lucent Bell
368 Labs, Thomas Narten of IBM, Glen Zorn and Harald Alvestrand of Cisco
369 for discussions relating to this document.
374 Microsoft Corporation
378 EMail: bernarda@microsoft.com
379 Phone: +1 425 706 6605
394 Aboba Standards Track [Page 7]
396 RFC 3575 IANA Considerations for RADIUS July 2003
399 Full Copyright Statement
401 Copyright (C) The Internet Society (2003). All Rights Reserved.
403 This document and translations of it may be copied and furnished to
404 others, and derivative works that comment on or otherwise explain it
405 or assist in its implementation may be prepared, copied, published
406 and distributed, in whole or in part, without restriction of any
407 kind, provided that the above copyright notice and this paragraph are
408 included on all such copies and derivative works. However, this
409 document itself may not be modified in any way, such as by removing
410 the copyright notice or references to the Internet Society or other
411 Internet organizations, except as needed for the purpose of
412 developing Internet standards in which case the procedures for
413 copyrights defined in the Internet Standards process must be
414 followed, or as required to translate it into languages other than
417 The limited permissions granted above are perpetual and will not be
418 revoked by the Internet Society or its successors or assignees.
420 This document and the information contained herein is provided on an
421 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
422 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
423 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
424 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
425 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
429 Funding for the RFC Editor function is currently provided by the
450 Aboba Standards Track [Page 8]