Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication
obsoletes
- rfc-5539 — NETCONF over Transport Layer Security (TLS)
Extracted elements (24)
CommonName-based username mapping ('common-name') is deprecated in favor of subjectAltName-based methods. Users are encouraged to use SAN mapping types instead to align with modern certificate practices.
The certificate-to-username mapping algorithm is intentionally identical to the one in the SNMP-TLS-TM-MIB (RFC 6353) and the ietf-x509-cert-to-name YANG module (RFC 7407), promoting consistency across management protocols that use TLS with X.509 certificates.
The document retains the EOM sequence ]]>]]> for the initial <hello> message despite the known XML injection risk in order to maintain backward compatibility with existing RFC 5539 implementations. Chunked framing is adopted for subsequent messages when :base:1.1 is mutually advertised.
This document updates the framing from RFC 5539 (which used RFC 4742 EOM framing) to align with RFC 6242 framing. When both peers advertise :base:1.1, chunked framing is used; otherwise, legacy EOM framing is used for backward compatibility.
All NETCONF messages MUST be sent as TLS 'application data'. Multiple NETCONF messages may be contained in one TLS record, or a NETCONF message may be transferred across multiple TLS records.
Both peers MUST use X.509 certificate path validation (RFC 5280) to verify the integrity of the peer's certificate. If path validation fails and the certificate does not match a locally trusted copy, the connection MUST be terminated.
For the 'san-any' map type, the first matching subjectAltName value (rfc822Name, dNSName, or iPAddress) found in the certificate MUST be used when deriving the username.
If no username can be determined from a list entry or the derived username does not comply with NETCONF username requirements, additional list entries MUST be searched. If no further entries exist, the TLS session MUST be terminated.
Implementations MAY implement additional TLS cipher suites that provide mutual authentication and confidentiality as required by NETCONF.
Implementations MUST support mutual TLS certificate-based authentication. The NETCONF client MUST act as the TLS client and the TLS server MUST send a CertificateRequest to obtain a certificate from the client.
Implementations MUST support TLS 1.2 (RFC 5246) and are REQUIRED to support the mandatory-to-implement cipher suite. Implementations SHOULD follow the recommendations in RFC 7525.
The NETCONF client MUST act as the TLS client, actively opening the TLS connection. The well-known TCP port 6513 is used by NETCONF servers to listen for incoming TLS connections.
The NETCONF client MUST check the identity of the server according to Section 6 of RFC 6125.
The NETCONF server MUST verify the identity of the NETCONF client before the NETCONF session is started, deriving a NETCONF username from the presented certificate using an ordered list of certificate-to-username mappings.
The TLS client MUST send the TLS ClientHello message to begin the TLS handshake. Client and server identity verification MUST be done before the NETCONF <hello> message is sent.
When the NETCONF server processes a <close-session> operation, the server SHALL respond and close the TLS session as described in Section 7.2.1 of RFC 5246.
Six map types are defined for deriving a NETCONF username from a certificate: 'specified' (explicit auxiliary data), 'san-rfc822-name' (subjectAltName rfc822Name), 'san-dns-name' (subjectAltName dNSName), 'san-ip-address' (subjectAltName iPAddress), 'san-any' (first matching SAN), and 'common-name' (certificate CommonName, deprecated).
The NETCONF <hello> message MUST be followed by the character sequence ]]>]]>. After inspecting capabilities, if both peers advertise :base:1.1, the chunked framing mechanism (RFC 6242 Section 4.2) is used; otherwise the end-of-message-based mechanism (RFC 6242 Section 4.3) is used.
The server maintains an ordered list of certificate-to-username mappings. Each entry contains a certificate fingerprint, a map type, and optional auxiliary data (an explicit username). Entries are evaluated in order to find the first match.
IANA assigned TCP port 6513 with service name 'netconf-tls' in the Registered Port Numbers range. This is the default port for NETCONF over TLS as defined in Section 2.
NETCONF configuration and state data may include sensitive information such as usernames or security keys, requiring strong encryption for data privacy. The security considerations of both TLS (RFC 5246) and NETCONF (RFC 6241) apply.
NETCONF over TLS requires mutual authentication; neither side should establish a connection with an unknown, unexpected, or incorrect identity. If a white-listed CA certificate is used for client acceptance, it should issue only certificates for NETCONF access, not general-purpose certificates.
The EOM sequence ]]>]]> can appear in well-formed XML and could be used for injection attacks. This document retains EOM for the initial <hello> for backward compatibility, then switches to chunked framing (RFC 6242) when both peers support :base:1.1 to mitigate injection risk.
Third-party AAA authentication is not supported because TLS does not define that authentication model and NETCONF depends on the transport for authentication. SSH transport (RFC 6242) should be used if third-party authentication is needed.