RFC 3575

IANA Considerations for RADIUS (Remote Authentication Dial In User Service)

📅 published July 2003, from ietf

IANA Considerations for RADIUS (Remote Authentication Dial In User Service) 🎀

Okay so this is the title block, bestie, and it has the important facts 💅

  • Network Working Group 🌸
  • Request for Comments: 3575 ✨
  • Author: B. Aboba, from Microsoft 💖
  • Date: July 2003 🦋
  • Category: Standard Track (an Internet standards track protocol) 👑
  • Updates: 2865, which is RFC 2865 🫶

Status of This Memo 📜

This doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🔥 For the current standardization state and status, check the latest edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (2003). All Rights Reserved. 💜

Abstract 🧚

This doc explains the IANA considerations for the Remote Authentication Dial In User Service (RADIUS), which is giving main character energy 👑

It also updates RFC 2865 🍓

1. Introduction ✨

Okay so this section is basically IANA's guidebook 📖 It tells IANA how to register values related to RADIUS, which is defined in [RFC2865], and it follows BCP 26 and [RFC2434] while doing it 💅 It also reserves the Packet Type Codes that are or have been in use on the Internet, so nobody's stepping on anyone's toes 🫶

1.1. Specification of Requirements 🎀

Bestie, this part explains the vibe words. The document uses a bunch of words to signal how strict a requirement is, and they're usually capitalized 💖 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🔥

1.2. Terminology 🌸

These terms mean what BCP 26 says they mean: "name space", "assigned value", and "registration" 🦋

These policies also mean what BCP 26 says: "Private Use", "First Come First Served", "Expert Review", "Specification Required", "IESG Approval", "IETF Consensus", and "Standards Action" 💅

2. IANA Considerations 🌈

Okay so there are three name spaces in RADIUS that need registration: Packet Type Codes, Attribute Types, and Attribute Values (for certain Attributes) 👑 This doc doesn't create any new IANA registries, since [RFC2865] already made a RADIUS registry ✨

RADIUS is not meant to be a general-purpose protocol, so allocations SHOULD NOT be made for purposes that have nothing to do with Authentication, Authorization or Accounting 🙈 Bestie, keep it on theme 💅

When a registration request needs a Designated Expert, the responsible IESG area director should appoint that Designated Expert 💖 The goal is that every allocation comes with a published RFC 🫶 The Designated Expert can still approve allocations once it's clear an RFC will be published, so values can be allocated before the document gets approved for publication as an RFC ✨

The Designated Expert will post the request to the AAA WG mailing list (or a successor the Area Director designates) for comment and review, including an Internet-Draft 📨 Before 30 days have passed, the Designated Expert will either approve or deny the request, post a notice of the decision to the AAA WG mailing list or its successor, and tell IANA what they decided 🔥 A denial notice must come with an explanation and, where it's possible, concrete suggestions for how the request can be changed so it becomes acceptable 💅

Packet Type Codes range from 1 to 253 🌸 RADIUS Type Codes 1-5 and 11-13 were allocated in [RFC2865], while Type Codes 40-45 and 250-253 are allocated by this document 🦋 Type Codes 250-253 are for Experimental Uses, and 254-255 are reserved 💜 Packet Type Codes 6-10, 12-13, 21-34, and 50-51 have no meaning defined by an IETF RFC, but they're reserved until someone provides a specification for them 🧚 This is so there aren't interoperability problems with software that uses non-standard RADIUS extensions that are or have been in use on the Internet 🫶

A new Packet Type has a big impact on interoperability, so a new Packet Type Code requires IESG Approval 👑 The goal is that every allocation comes with a published RFC ✨ Type Codes 52-249 should be allocated first; once those run out, Type Codes 14-20, 35-39, and 46-49 may be allocated 🌈 For a list of Type Codes, see Appendix A 📖

Attribute Types range from 1 to 255, and they're the scarcest resource in RADIUS, so they must be allocated with care 💀 Attributes 1-53,55,60-88,90-91,94-100 have already been allocated, with 17 and 21 available for re-use 🍓 Attributes 17, 21, 54, 56-59, 89, and 101-191 may be allocated by IETF Consensus 💖 It is recommended that attributes 17 and 21 be used only after all the others are used up 🙈

Also, RADIUS defines a mechanism for Vendor-Specific extensions (Attribute 26) 🎀 That's for functions specific to one vendor's implementation of RADIUS, where interoperability isn't deemed useful 🦋 For functions that only one vendor's implementation of RADIUS needs, that mechanism should be encouraged instead of allocating global attribute types 💅

As noted in [RFC2865]:

   Attribute Type Values 192-223 are reserved for experimental use,
   values 224-240 are reserved for implementation-specific use, and
   values 241-255 are reserved and should not be used.

So Attribute Type values 192-240 are considered Private Use, and values 241-255 require Standards Action 🌸

Certain attributes (for example, NAS-Port-Type) in RADIUS define a list of values that correspond to different meanings 🧚 There can be 4 billion (2^32) values for each attribute 🤯 Additional values can be allocated by the Designated Expert 🫶 The exception is the Service-Type attribute (6), whose values define new modes of operation for RADIUS 👑 Values 1-16 of Service-Type have been allocated, and new Service-Type values are allocated by IETF Consensus ✨ The goal is that every allocation comes with a published RFC 💖

3. References 📚

3.1. Normative References 🔥

[RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2434]      Narten, T. and H. Alvestrand, "Guidelines for Writing
               an IANA Considerations Section in RFCs", BCP 26, RFC
               2434, October 1998.

[RFC2865]      Rigney, C., Willens, S., Rubens, A. and W. Simpson,
               "Remote Authentication Dial In User Service (RADIUS)",
               RFC 2865, June 2000.

3.2. Informative References 🦋

[RFC2607]      Aboba, B. and J. Vollbrecht, "Proxy Chaining and
               Policy Implementation in Roaming", RFC 2607, June
               1999.

[RFC2866]      Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

[RFC2867]      Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
               Modifications for Tunnel Protocol Support", RFC 2867,
               June 2000.

[RFC2868]      Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
               Holdrege, M. and I. Goyret, "RADIUS Attributes for
               Tunnel Protocol Support", RFC 2868, June 2000.

[RFC2869]      Rigney, C., Willats, W. and P. Calhoun, "RADIUS
               Extensions", RFC 2869, June 2000.

[RFC2869bis]   Aboba, B. and P. Calhoun, "RADIUS Support for
               Extensible Authentication Protocol (EAP)", Work in
               Progress.

[RFC2882]      Mitton, D., "Network Access Servers Requirements:
               Extended RADIUS Practices", RFC 2882, July 2000.

[RFC3162]      Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6",
               RFC 3162, August 2001.

[DynAuth]      Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
               Aboba, "Dynamic Authorization Extensions to Remote
               Authentication Dial In User Service (RADIUS)", RFC
               3576, July 2003.

Intellectual Property Statement ✨

Okay bestie, let's talk legal stuff, but make it cute 🎀. The IETF is not saying whether any IP rights floating around are valid or how far they reach, and it's not saying it went hunting for them either 🫣. If you want the details on how the IETF handles rights for standards-track and standards-related docs, check out BCP-11 📚. Copies of any claimed rights that were submitted for publication, plus any promises of licenses, or the results of trying to get a general license for implementers or users to use those proprietary rights, can all be requested from the IETF Secretariat 💌.

The IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to practice this standard to tell them 🦋. Send that info to the IETF Executive Director. Yes, it's giving transparency 💅.

Acknowledgments

Huge thanks to Ignacio Goyret of Lucent, Allison Mankin of Lucent Bell Labs, Thomas Narten of IBM, and Glen Zorn and Harald Alvestrand of Cisco 🫶. They all chatted with the author about this document, and honestly, the group chat energy here is immaculate ✨.

Authors' Addresses

Meet the author, Bernard Aboba, from Microsoft Corporation 💜. Here's where to reach him:

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax:   +1 425 936 7329

Copyright (C) The Internet Society (2003). All Rights Reserved. 🌈

Okay, so this part is the rules for sharing. You're allowed to copy this document and pass it around to other people, and you can even make derivative works that comment on or explain it, or help people implement it 🌸. You can publish and distribute those too, in whole or in part, with zero restrictions of any kind 🙌. The one big catch: the copyright notice and this paragraph have to stay on every single copy and derivative work 🔥.

The actual document can't be modified in any way. You can't remove the copyright notice or references to the Internet Society or other Internet orgs 🙅‍♀️. The exceptions are if you need it to develop Internet standards, in which case you have to follow the copyright procedures in the Internet Standards process, or if you're translating it into a language other than English 🌍.

These permissions are perpetual, and the Internet Society and its successors or assignees can't revoke them 💎. Forever and ever, bestie 🧚.

Now, the disclaimer part, which is a little less fun 💀. This document and everything in it is provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED 🙈. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose 😭.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society 🍓. Thank you for the support, Internet Society, you're iconic 👑.

📦 where this page comes from