doc/rfc/rfc3575.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                           B. Aboba
   8 Request for Comments: 3575                                     Microsoft
   9 Updates: 2865                                                  July 2003
  10 Category: Standard Track
  11
  12
  13                      IANA Considerations for RADIUS
  14               (Remote Authentication Dial In User Service)
  15
  16 Status of this Memo
  17
  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.
  23
  24 Copyright Notice
  25
  26    Copyright (C) The Internet Society (2003).  All Rights Reserved.
  27
  28 Abstract
  29
  30    This document describes the IANA considerations for the Remote
  31    Authentication Dial In User Service (RADIUS).
  32
  33    This document updates RFC 2865.
  34
  35 1.  Introduction
  36
  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.
  42
  43 1.1.  Specification of Requirements
  44
  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].
  50
  51
  52
  53
  54
  55
  56
  57
  58 Aboba                       Standards Track                     [Page 1]
  59 \f
  60 RFC 3575             IANA Considerations for RADIUS            July 2003
  61
  62
  63 1.2.  Terminology
  64
  65    The following terms are used here with the meanings defined in BCP
  66    26:  "name space", "assigned value", "registration".
  67
  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",
  71    "Standards Action".
  72
  73 2.  IANA Considerations
  74
  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].
  79
  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.
  83
  84 2.1.  Recommended Registration Policies
  85
  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.
 102
 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
 111
 112
 113
 114 Aboba                       Standards Track                     [Page 2]
 115 \f
 116 RFC 3575             IANA Considerations for RADIUS            July 2003
 117
 118
 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.
 125
 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.
 132
 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.
 139
 140    As noted in [RFC2865]:
 141
 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.
 145
 146    Therefore Attribute Type values 192-240 are considered Private Use,
 147    and values 241-255 require Standards Action.
 148
 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
 157    by a published RFC.
 158
 159 3.  References
 160
 161 3.1.  Normative References
 162
 163    [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
 164                   Requirement Levels", BCP 14, RFC 2119, March 1997.
 165
 166
 167
 168
 169
 170 Aboba                       Standards Track                     [Page 3]
 171 \f
 172 RFC 3575             IANA Considerations for RADIUS            July 2003
 173
 174
 175    [RFC2434]      Narten, T. and H. Alvestrand, "Guidelines for Writing
 176                   an IANA Considerations Section in RFCs", BCP 26, RFC
 177                   2434, October 1998.
 178
 179    [RFC2865]      Rigney, C., Willens, S., Rubens, A. and W. Simpson,
 180                   "Remote Authentication Dial In User Service (RADIUS)",
 181                   RFC 2865, June 2000.
 182
 183 3.2.  Informative References
 184
 185    [RFC2607]      Aboba, B. and J. Vollbrecht, "Proxy Chaining and
 186                   Policy Implementation in Roaming", RFC 2607, June
 187                   1999.
 188
 189    [RFC2866]      Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
 190
 191    [RFC2867]      Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
 192                   Modifications for Tunnel Protocol Support", RFC 2867,
 193                   June 2000.
 194
 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.
 198
 199    [RFC2869]      Rigney, C., Willats, W. and P. Calhoun, "RADIUS
 200                   Extensions", RFC 2869, June 2000.
 201
 202    [RFC2869bis]   Aboba, B. and P. Calhoun, "RADIUS Support for
 203                   Extensible Authentication Protocol (EAP)", Work in
 204                   Progress.
 205
 206    [RFC2882]      Mitton, D., "Network Access Servers Requirements:
 207                   Extended RADIUS Practices", RFC 2882, July 2000.
 208
 209    [RFC3162]      Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6",
 210                   RFC 3162, August 2001.
 211
 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
 215                   3576, July 2003.
 216
 217 4.  Security Considerations
 218
 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].
 223
 224
 225
 226 Aboba                       Standards Track                     [Page 4]
 227 \f
 228 RFC 3575             IANA Considerations for RADIUS            July 2003
 229
 230
 231 Appendix A - RADIUS Packet Types
 232
 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.
 239
 240    #        Message                      Reference
 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]
 264    28       Reserved
 265    29       Next-Passcode                [RFC2882]
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Aboba                       Standards Track                     [Page 5]
 283 \f
 284 RFC 3575             IANA Considerations for RADIUS            July 2003
 285
 286
 287    #        Message                      Reference
 288    ----     -------------------------    ---------
 289    30       New-Pin                      [RFC2882]
 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]
 298    44       CoA-ACK                      [DynAuth]
 299    45       CoA-NAK                      [DynAuth]
 300    50       IP-Address-Allocate          [RFC2882]
 301    51       IP-Address-Release           [RFC2882]
 302    250-253  Experimental Use
 303    254      Reserved
 304    255      Reserved                     [RFC2865]
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Aboba                       Standards Track                     [Page 6]
 339 \f
 340 RFC 3575             IANA Considerations for RADIUS            July 2003
 341
 342
 343 Intellectual Property Statement
 344
 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.
 358
 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
 363    Director.
 364
 365 Acknowledgments
 366
 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.
 370
 371 Authors' Addresses
 372
 373    Bernard Aboba
 374    Microsoft Corporation
 375    One Microsoft Way
 376    Redmond, WA 98052
 377
 378    EMail: bernarda@microsoft.com
 379    Phone: +1 425 706 6605
 380    Fax:   +1 425 936 7329
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Aboba                       Standards Track                     [Page 7]
 395 \f
 396 RFC 3575             IANA Considerations for RADIUS            July 2003
 397
 398
 399 Full Copyright Statement
 400
 401    Copyright (C) The Internet Society (2003).  All Rights Reserved.
 402
 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
 415    English.
 416
 417    The limited permissions granted above are perpetual and will not be
 418    revoked by the Internet Society or its successors or assignees.
 419
 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.
 426
 427 Acknowledgement
 428
 429    Funding for the RFC Editor function is currently provided by the
 430    Internet Society.
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Aboba                       Standards Track                     [Page 8]
 451 \f