RADIUS Extensions for DHCP Configured Services

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

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."¶

This Internet-Draft will expire on 27 September 2023.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

3. DHCP Options RADIUS Attributes

This section specifies two new RADIUS attributes for RADIUS clients and servers to exchange DHCP-encoded data. This data is then used to feed the DHCP procedure between a DHCP client and a DHCP server.¶

Both DHCPv4-Options and DHCPv6-Options Attributes use the "Long Extended Type" format (Section 2.2 of [RFC6929]). The description of the fields is provided in Sections 3.1 and 3.2.¶

These attributes use the "Long Extended Type" format in order to permit the transport of attributes encapsulating more than 253 octets of data. DHCP options that can be included in the DHCP*-Options RADIUS attributes are limited by the maximum packet size of 4096 bytes (Section 3 of [RFC2865]). In order to accommodate deployments with large DHCP options, RADIUS implementations are RECOMMENDED to support a packet size up to 65535 bytes. Such a recommendation can be met if RADIUS implementations support a mechanism that relaxes the 4096 bytes limit (e.g., [RFC7499] or [RFC7930]).¶

The value fields of DHCP*-Options Attributes are encoded in clear and not encrypted as, for example, Tunnel-Password Attribute [RFC2868].¶

RADIUS implementations may support a configuration parameter to control the DHCP options that can be included in a DHCP*-Options RADIUS attribute. Likewise, DHCP server implementations may support a configuration parameter to control the permitted DHCP options in a DHCP*-Options RADIUS attribute. Absent explicit configuration, RADIUS implementations and DHCP server implementations SHOULD ignore non-permitted DHCP options received in a DHCP*-Options RADIUS attribute.¶

RADIUS supplied data is specific configuration data that is returned as a function of authentication and authorization checks. As such, absent any explicit configuration on the DHCP server, RADIUS supplied data by means of DHCP*-Options Attributes take precedence over any local configuration.¶

These attributes are defined with globally unique names. The naming of the attributes follows the guidelines in Section 2.7.1 of [RFC6929]. Invalid attributes are handled as per Section 2.8 of [RFC6929].¶

4. Passing DHCP Options RADIUS Attributes by DHCP Relay Agents to DHCP Servers

5. An Example: Applicability to Encrypted DNS Provisioning

Typical deployment scenarios are similar to those described, for instance, in Section 2 of [RFC6911]. For illustration purposes, Figure 1 shows an example where a Customer Premises Equipment (CPE) is provided with an encrypted DNS resolver. This example assumes that the Network Access Server (NAS) embeds both RADIUS client and DHCPv6 server capabilities.¶

+-------------+           +-------------+             +-------+
|     CPE     |           |     NAS     |             |  AAA  |
|DHCPv6 client|           |DHCPv6 server|             |Server |
|             |           |RADIUS client|             |       |
+------+------+           +------+------+             +---+---+
       |                         |                        |
       o-----DHCPv6 Solicit----->|                        |
       |                         o----Access-Request ---->|
       |                         |                        |
       |                         |<----Access-Accept------o
       |                         |     DHCPv6-Options     |
       |<----DHCPv6 Advertise----o    (OPTION_V6_DNR)     |
       |     (OPTION_V6_DNR)     |                        |
       |                         |                        |
       o-----DHCPv6 Request----->|                        |
       |                         |                        |
       |<------DHCPv6 Reply------o                        |
       |     (OPTION_V6_DNR)     |                        |
       |                         |                        |

                DHCPv6                     RADIUS

Upon receipt of the DHCPv6 Solicit message from a CPE, the NAS sends a RADIUS Access-Request message to the Authentication, Authorization, and Accounting (AAA) server. Once the AAA server receives the request, it replies with an Access-Accept message (possibly after having sent a RADIUS Access-Challenge message and assuming the CPE is entitled to connect to the network) that carries a list of parameters to be used for this session, and which include the encrypted DNS information. Such an information is encoded as OPTION_V6_DNR (144) instances ([I-D.ietf-add-dnr]) in the DHCPv6-Options RADIUS attribute. These instances are then used by the NAS to complete the DHCPv6 procedure that the CPE initiated to retrieve information about the encrypted DNS service to use. The Discovery of Network-designated Resolvers (DNR) procedure defined in [I-D.ietf-add-dnr] is then followed between the DHCPv6 client and the DHCPv6 server.¶

Should any encrypted DNS-related information (e.g., Authentication Domain Name (ADN), IPv6 address) change, the RADIUS server sends a RADIUS Change-of-Authorization (CoA) message [RFC5176] that carries the DHCPv6-Options Attribute with the updated OPTION_V6_DNR information to the NAS. Once that message is received and validated by the NAS, it replies with a RADIUS CoA ACK message. The NAS replaces the old encrypted DNS resolver information with the new one and sends a DHCPv6 Reconfigure message which leads the DHCPv6 client to initiate a Renew/Reply message exchange with the DHCPv6 server.¶

In deployments where the NAS behaves as a DHCPv6 relay agent, the procedure discussed in Section 3 of [RFC7037] can be followed. To that aim, Section 8.2 updates the "RADIUS Attributes Permitted in DHCPv6 RADIUS Option" registry ([DHCP-RADIUS]). CoA-Requests can be used following the procedure specified in [RFC6977].¶

Figure 2 shows another example where a CPE is provided with an encrypted DNS resolver, but the CPE uses DHCPv4 to retrieve its encrypted DNS resolver.¶

+-------------+           +-------------+             +-------+
|     CPE     |           |     NAS     |             |  AAA  |
|DHCPv4 client|           |DHCPv4 server|             |Server |
|             |           |RADIUS client|             |       |
+------+------+           +------+------+             +---+---+
       |                         |                        |
       o------DHCPDISCOVER------>|                        |
       |                         o----Access-Request ---->|
       |                         |                        |
       |                         |<----Access-Accept------o
       |                         |     DHCPv4_Options     |
       |<-----DHCPOFFER----------o    (OPTION_V4_DNR)     |
       |     (OPTION_V4_DNR)     |                        |
       |                         |                        |
       o-----DHCPREQUEST-------->|                        |
       |     (OPTION_V4_DNR)     |                        |
       |                         |                        |
       |<-------DHCPACK----------o                        |
       |     (OPTION_V4_DNR)     |                        |
       |                         |                        |

               DHCPv4                      RADIUS

Other deployment scenarios can be envisaged, such as returning customized service parameters (e.g., different DoH URI Templates) as a function of the service/policies/preferences that are set by a network administrator. How an administrator indicates its service/policies/preferences to an AAA server is out of scope.¶

6. Security Considerations

RADIUS-related security considerations are discussed in [RFC2865].¶

DHCPv6-related security issues are discussed in Section 22 of [RFC8415], while DHCPv4-related security issues are discussed in Section 7 of [RFC2131]. Security considerations specific to the DHCP options that are carried in RADIUS are discussed in relevant documents that specify these options. For example, security considerations (including traffic theft) are discussed in Section 7 of [I-D.ietf-add-dnr].¶

RADIUS servers have conventionally tolerated the input of arbitrary data via the "string" data type (Section 3.5 of [RFC8044]). This practice allows RADIUS servers to support newer standards without software upgrades, by allowing administrators to manually create complex attribute content and, then, to pass that content to a RADIUS server as opaque strings. While this practice is useful, it is RECOMMENDED that RADIUS servers that implement the present specification are updated to understand the format and encoding of DHCP options. Administrators can, thus, enter the DHCP options as options instead of manually-encoded opaque strings. This recommendation increases security and interoperability by ensuring that the options are encoded correctly. It also increases usability for administrators.¶

The considerations discussed in Section 7 of [RFC4014] and Section 8 of [RFC7037] should be taken into account in deployments where DHCP relay agents pass the DHCP*-Options Attributes to DHCP servers. Additional considerations specific to the use of Reconfigure messages are discussed in Section 9 of [RFC6977].¶

8. IANA Considerations

9. Acknowledgements

Thanks to Christian Jacquenet, Neil Cook, Joe Clarke, Qin Wu, Dirk von-Hugo, Tom Petch, and Chongfeng Xie for the review and suggestions.¶

Thanks to Ben Schwartz and Bernie Volz for the comments.¶

Thanks to Rob Wilton for the careful AD review.¶

Thanks to Ralf Weber for the dnsdir reviews, Robert Sparks for genart review, and Tatuya Jinmei for the int-dir review.¶

Thanks to Eric Vyncke, Paul Wouters, and Warren Kumari for the IESG review.¶

Authors' Addresses