rfc-6440

The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option

G. Zorn, Q. Wu, Y. Wang

date2011-12 streamIETF areasec wghokey statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc6440 doi10.17487/RFC6440

In order to derive a Domain-Specific Root Key (DSRK) from the Extended Master Session Key (EMSK) generated as a side effect of an Extensible Authentication Protocol (EAP) method, the EAP peer must discover the name of the domain to which it is attached. This document specifies a Dynamic Host Configuration Protocol Version 6 (DHCPv6) option designed to allow a DHCPv6 server to inform clients using the EAP Re-authentication Protocol (ERP) EAP method of the name of the local domain for ERP. [STANDARDS-TRACK]

Extracted elements (11)

design-rationale §3

The contents of the ERP Local Domain Name option are explicitly scoped to ERP use and do not represent the name of a local domain for any other purposes, preventing misuse or ambiguity with other domain-name DHCPv6 options.

security

design-rationale §1

The local domain name (LDN) is required to derive the Domain-Specific Root Key (DSRK) from the EMSK; without LDN discovery, ERP re-authentication cannot proceed. No lower-layer mechanism for LDN discovery had previously been defined, motivating this DHCPv6 option.

security

interoperability-note §3.1

Internationalized domain names are permitted in the erp-local-domain-name field but only as A-labels (ASCII-compatible encoding) as defined in RFC 5890; U-labels are not supported by the RFC 3315 encoding.

security

normative-requirement §4 MUST

A DHCPv6 client that does not know the ERP LDN and requires the server to provide it MUST include an Option Request option requesting OPTION_ERP_LOCAL_DOMAIN_NAME, as described in RFC 3315 Section 22.7.

security

normative-requirement §5 SHOULD

A DHCPv6 relay agent that has pre-existing knowledge of the ERP local domain name for a client (e.g., from a prior AAA exchange) SHOULD include it in an instance of the ERP Local Domain Name option forwarded to the DHCPv6 server as a suboption of the Relay-Supplied Options option (RFC 6422).

security, diameter

normative-requirement §3.1 MUST

The erp-local-domain-name field MUST be encoded as specified in Section 8 of RFC 3315; internationalized domain names are supported only as A-labels per RFC 5890.

security

normative-requirement §4 MUST

When a DHCPv6 client receives an ERP Local Domain Name option, it MUST verify that the option length is no more than 256 octets and that the local domain name is a properly encoded single FQDN per RFC 3315 Section 8.

security

protocol-element §3.1

The DHCPv6 ERP Local Domain Name option (OPTION_ERP_LOCAL_DOMAIN_NAME, code 65) allows a DHCPv6 server to inform ERP clients of the local domain name. The option carries the erp-local-domain-name field encoded as a DNS name per RFC 3315 Section 8.

security, registry

registry §7

IANA assigned option code 65 to OPTION_ERP_LOCAL_DOMAIN_NAME in the 'DHCP Option Codes' registry, and added the option name to the 'Options Permitted in the Relay-Supplied Options Option' registry.

registry, security

security-consideration §6

The DHCPv6 exchange conveying the local domain name is security sensitive and requires server authentication and integrity protection. DHCPv6 security as described in RFC 3315 SHOULD be used to protect this exchange.

security, crypto

wire-format §3.1

The option consists of a 2-octet option code (65), a 2-octet option-length indicating the length of the erp-local-domain-name field in octets, followed by the variable-length erp-local-domain-name field encoded per RFC 3315 Section 8.

security