]> Cisco Systems, Inc.

Richtistrasse 7 Wallisellen 8304 Switzerland +41 44 878 9200 lear@cisco.com

InkBridge Networks

alan.dekok@inkbridge.io

Security EMU Working Group TEAP TLV DHCP Authentication This document defines a new Tunneled Extensible Authentication Protocol (TEAP) Type-Length-Value (TLV) to encapsulate DHCPv6 (Dynamic Host Configuration Protocol Version 6) options within TEAP authentication exchanges. This enhancement enables exchange of network configuration parameters after the authentication phase. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the EMU WG Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction TEAP (Tunneled Extensible Authentication Protocol), defined in , supports the use of Type-Length-Value (TLV) structures to exchange additional data during the authentication process. DHCPv6 is widely used for configuration of network parameters. This document introduces a new TLV to encapsulate DHCPv6 options within TEAP messages. specifies a way to communicate DHCPv6 options to a RADIUS client. This memo specifies a means to communicate options end-to-end between the authentication server and the peer. Not all DHCP communications will necessarily make sense in this context. For instance, an AAA server may only wish to send non-topological options, such as a definitions for a print server, or next hop configuration URL. It might not send next-hop router or IP address binding information. Sending options in a protected and authenticated TLS tunnel also authenticates the options, and allows them to be transmitted securely from the authentication server to the peer. While provides for authentication of DHCP messages, this feature is not always used. Even if the DHCP messages are authenticated, there are still benefits to sending options inside of a protected TEAP session.

Use of both DHCPv6 and TEAP protocols Because DHCPv6 is widely deployed, peers implementing this specification can expect to receive information via both TEAP and DHCPv6. Therefore, the possibility of a conflict arises. Clients are not in a good position to determine on their own which information is correct. Therefore, the following strategy is RECOMMENDED:

1. Peers receiving information only via DHCP will use that information.
2. Peers receiving DHCP information only via TEAP will use that information.
3. Peers receiving overlapping DHCPv6 options SHOULD select TEAP information since it is likely to be better authenticated and unchanged.
4. If conflicting information is received by the peer it SHOULD log the conflict as an error and MAY produce an exception.

In practice, these rules can be applied by a peer initializing a result option list by using the options which are received from TEAP, and then selectively adding options from DHCP. Before adding a DHCP option, the peer checks (by number) if the option already exists in the result option list. If no matching option exists, it is added. If a matching option exists, the values are compared, and a log message can be generated. It is RECOMMENDED that conflict be avoided by having the DHCP server send options which control network behavior (address assignment, routes, etc). The TEAP server can then send options which require the peer to follow a particular policy. The detailed list of which options fall into which category is site-specific, and out of scope of this specification.

TEAP TLV for DHCPv6 Options DHCPv6 options are carried within the DHCPv6-Options TLV. The TLV format is defined below. Both the TEAP server and TEAP client MAY transmit this TLV during Phase 2, and it MAY be included in a Request Action frame. The Mandatory bit MUST not be set. If either side sends this TLV prior to Phase 2, an error TLV of 2002 (Unexpected TLVs Exchanged) be returned with a Result of Status=Failure. That is, the table in Section 4.3.1 of remains unchanged. Thus this TLV MAY be used as follows: When is this TLV Allowed

Request	Response	Success	Failure	TLV
0-1	0-1	0-1	0	DHCPv6-Options

A TEAP peer or server receiving this TLV SHOULD NOT act on it until the other side has been sufficiently authenticated, but it is not an error to send this TLV in advance of such authentication. In this way, the TLV can be conveniently piggybacked as part of the authentication prior to a result or intermediate result being generated.

TLV Format The DHCPv6-Options TLV follows the TEAP TLV format from , and is defined below:

DHCP options TLV format

=2 octets DHCPv6 options This field MUST contain DHCPv6 options, as defined in {{RFC8415, Section 21.1}}. ]]>

DHCPv6 Option Encapsulation The TLV Value field encapsulates DHCPv6 options exactly as they appear in DHCPv6 messages. There MUST NOT be more than one DHCPv6-Options TLV in a TEAP exchange. The TEAP TLV format is sufficient to carry any number of DHCPv6 options which may be needed. A party which receives multiple DHCPv6-Options TLVs during a TEAP exchange SHOULD process only the first such option, and then ignore all remaining ones. The format adheres to the standard DHCPv6 option encoding, ensuring compatibility with existing DHCPv6 implementations. Encapsulating this option in the TLV would look as follows (in hexadecimal): Where:

• Type = 0xXXXX (TBD assigned by IANA)
• Length = 0x0014 (20 bytes for the "Recursive DNS Servers" option, including addresses)
• Value = 0x00170010FE8000000000000000000000000001 (DHCPv6 Option 23 with an IPv6 address of FE80::1).

Security Considerations Encapsulating DHCPv6 options within TEAP messages inherits the security guarantees of the TEAP protocol. Further details on mitigation strategies are discussed in . Sending DHCPv6 options withing a protected and authenticated TLS tunnel provides for additional authentication of those options, and for exchanging the options in a secure manner. While DHCPv6 provides for message authentication, that functionality is not always available. This feature also enables better separation of responsibilities. A DHCPv6 server can simply manage address assignment and network configuration. The TEAP authentication server can then manage higher level network policies.

Additional Policy Decisions DHCP clients can send options which indicate their desired network posture. An authentication server can then make policy decisions based on the options, such as placing the device into a different VLAN.

Captive Portals and Provisioning TEAP provides for unauthenticated access for provisioning. The DHCPv6-Options TLV can be used within a provisioning network without issue.

IANA Considerations IANA is requested to assign a new TEAP TLV type value for the DHCPv6 Options TLV from the TEAP TLV Type registry defined in .

Acknowledgements The authors hope to thank the members of the IETF EMU Working Group for their valuable input and contributions.

References Normative References This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. This document obsoletes RFC 7170 and updates RFC 9427 by moving all TEAP specifications from those documents to this one. This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550. Informative References This document specifies two new Remote Authentication Dial-In User Service (RADIUS) attributes that carry DHCP options. The specification is generic and can be applicable to any service that relies upon DHCP. Both DHCPv4- and DHCPv6-configured services are covered. Also, this document updates RFC 4014 by relaxing a constraint on permitted RADIUS attributes in the RADIUS Attributes DHCP suboption.

Acknowledgments TODO acknowledge.