RFC 4014

Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option

📅 published February 2005, from ietf

Okay bestie, let's get into RFC 4014 💖✨

It's called Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option 🎀 It was written by R. Droms and J. Schnizlein from Cisco Systems. It's a Standards Track doc from the Network Working Group, dated February 2005. The header has no Obsoletes or Updates line, so it doesn't list any RFC it replaces or changes 🦋

Status of This Memo ✨

This is an Internet standards track protocol for the Internet community, and they're literally asking for discussion and suggestions for improvements 💅 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸

Copyright (C) The Internet Society (2005).

Abstract 💜

The RADIUS Attributes suboption lets a network element pass the identification and authorization attributes it got during RADIUS authentication over to a DHCP server 🎀 When the DHCP server gets a message from a relay agent that has a RADIUS Attributes suboption, it pulls out the contents and uses that info to pick configuration parameters for the client ✨

1. Introduction and Background 🌈

The RADIUS Attributes suboption for the DHCP Relay Agent option gives a NAS a way to pass attributes it got from a RADIUS server over to a DHCP server [1]. IEEE 802.1X [2] is an example of how a NAS, like a switch or a wireless LAN access point, can check who a device's user is before giving that device layer 2 network access. RADIUS is the Authentication Service there, as specified in RFC 3580 [8] 😭 In IEEE 802.1X authenticated access, the device has to swap some authentication credentials with the NAS first. The NAS then hands those credentials to a RADIUS server, which eventually sends back either an Access-Accept or an Access-Reject in response to an Access-Request. Based on that reply, the NAS either lets the device in or keeps it out 🔥

Figure 1 sums up who talks to who in IEEE 802.1X authentication 👑

                        +-----------------+
                        |Device requesting|
                        | network access  |
                        +-----------------+
                         |         ^
                         |         |
                        (1) Request for access
                         |         |
                         |        (4) Success/Failure
                         v         |
                        +-----------------+
                        |       NAS       |
                        |(IEEE 802.1X and |
                        |DHCP relay agent}|
                        +-----------------+
                           |     ^
                           |     |
                          (2) Request for authentication
                           |     |
                           |    (3) Access-Accept/Reject
                           v     |
                        +-----------------+
                        |     RADIUS      |
                        |     Server      |
                        +-----------------+

                             Figure 1

The access device acts as an IEEE 802.1X Authenticator and adds a DHCP relay agent option that includes a RADIUS Attributes suboption to DHCP messages 🦋 When IEEE 802.1X authentication wraps up successfully, a RADIUS Access-Accept gives the NAS attributes for service authorizations, and the NAS stores them locally. Later on, when the NAS relays DHCP messages from the network device, it adds those attributes in a RADIUS Attributes suboption. This suboption is another suboption of the Relay Agent Information option [5] 💖

The RADIUS Attributes suboption in this doc isn't limited to IEEE 802.1X, though 🌸 It can carry RADIUS attributes the relay agent got for any reason. The option isn't locked to 802.1X, but it is bound by RADIUS semantics (see Section 4) 💅

Here's the catch: robust interoperability is only guaranteed for RADIUS service implementations that live in the same scope as the DHCP service implementation, meaning within a single, localized administrative domain 🙈 Global interoperability across administrative domains is not required. Iykyk 🍓

2. Terminology 🎀

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 RFC 2119 [3] ✨

Within this spec, those same key words, "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", are about RADIUS clients and servers that implement the optional features of this specification 💜 Using them doesn't create any normative requirements outside of that scope, and it doesn't modify the base RADIUS specifications, like RFC 2865 [4] 🧚

2.1. DHCP Terminology 🌸

The following terms are used as defined in RFC 2131 and RFC 3046: DHCP relay agent, DHCP server, DHCP client 💅

2.2. RADIUS Terminology 🌈

These terms are used together with RADIUS:

  • RADIUS server: A RADIUS server is responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver service to the user 👑
  • Attribute: A Type-Length-Value tuple encapsulating data elements as defined in RFC 2865 [4] 🎀
  • NAS: A Network Access Server (NAS) provides access to the network and operates as a client of RADIUS. The client is responsible for passing user information to designated RADIUS servers and then acting on the response that is returned. Unlike a traditional dial NAS, the NAS considered here may not have a protocol such as PPP through which it can pass configuration information from the RADIUS attributes to the client 😭

2.3. IEEE 802.1X Terminology 🦋

These terms are used as defined in the IEEE 802.1X protocol: Authenticator, Supplicant 🫶

3. RADIUS Attributes Suboption Format 💎

The RADIUS Attributes suboption is a new suboption for the DHCP Relay Agent option ✨ Here's the layout:

        SubOpt   Len     RADIUS attributes
         code
       +-------+-----+------+------+------+------+--...-+------+
       |   7   |  N  |  o1  |  o2  |  o3  |  o4  |      |  oN  |
       +-------+-----+------+------+------+------+--...-+------+

The RADIUS attributes are encoded according to the encoding rules in RFC 2865, in octets o1...oN 🌸 The DHCP relay agent truncates the RADIUS attributes to fit in the RADIUS Attributes suboption 🙈

4. DHCP Relay Agent Behavior 🧚

When the DHCP relay agent gets a DHCP message from the client, it MAY append a DHCP Relay Agent Information option containing the RADIUS Attributes suboption, along with any other suboptions it's configured to supply 💖 The RADIUS Attributes suboption MUST only contain the attributes provided in the RADIUS Access/Accept message. The DHCP relay agent MUST NOT add more than one RADIUS Attributes suboption in a message 🔥

The relay agent MUST include the User-Name and Framed-Pool attributes in the RADIUS Attributes suboption, if they're available, and it MAY include other attributes 🫶

To avoid dependencies between the address allocation and other state information between the RADIUS server and the DHCP server, the DHCP relay agent SHOULD include only the attributes in the table below in an instance of the RADIUS Attributes suboption 🎀 The table, based on the analysis in RFC 3580 [8], lists attributes that MAY be included:

           #   Attribute
         ---   ---------
           1   User-Name (RFC 2865 [3])
           6   Service-Type (RFC 2865)
          26   Vendor-Specific (RFC 2865)
          27   Session-Timeout (RFC 2865)
          88   Framed-Pool (RFC 2869)
         100   Framed-IPv6-Pool (RFC 3162 [7])

Authors' Addresses ✨

Okay, meet the two people who wrote this, both at Cisco 💖 Here are their mailing addresses and emails:

Ralph Droms
Cisco Systems
1414 Massachusetts Avenue
Boxborough, MA  01719
USA

EMail: rdroms@cisco.com
John Schnizlein
Cisco Systems
9123 Loughran Road
Fort Washington, MD  20744
USA

EMail: jschnizl@cisco.com

So, the legal bit, but make it cute. Copyright (C) The Internet Society (2005). 🌸

This document is subject to the rights, licenses and restrictions contained in BCP 78. Outside of what BCP 78 says, the authors keep all their rights. 💅

The document and the info in it are provided on an "AS IS" basis, and the contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all say, in full:

THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Basically, nobody is promising it's perfect, and nobody is promising it won't step on anyone's toes. 🙈

Intellectual Property 🦋

The IETF doesn't take a side on whether any IP rights (patents, copyrights, that whole vibe) apply to the tech described here, or whether you can get a license to use it. It also doesn't claim it went looking for any of that. 🧚 For how the IETF handles rights in its documents, check out BCP 78 and BCP 79.

Copies of IPR disclosures sent to the IETF Secretariat, any promises of licenses, and the results of any attempt to get a general license or permission to use the proprietary rights are all available from the IETF's online IPR repository at http://www.ietf.org/ipr. 📚

The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 💜

Acknowledgement 🌈

Huge thanks to the Internet Society, which currently funds the RFC Editor function. Without them, these docs wouldn't be getting published! 🫶

📦 where this page comes from