NETCONF over Transport Layer Security (TLS)
obsoleted by
- rfc-7589 — Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication
Extracted elements (20)
The client is always the NETCONF manager and the server is always the NETCONF agent when NETCONF runs over TLS, because TLS is application-protocol-independent and this mapping provides a clean, consistent binding between the transport and protocol roles.
Third-party authentication (e.g., AAA backend) is not supported because TLS does not specify that authentication model and NETCONF depends on its transport protocol for authentication services. BEEP or SSH transports should be used when AAA is needed.
The ']]>]]>' message delimiter defined in RFC 4742 (NETCONF over SSH) is reused verbatim for NETCONF over TLS. Since this sequence can legally appear in XML attribute values, comments, and processing instructions, implementations must actively sanitize outbound NETCONF messages.
A TLS client (NETCONF manager) MUST send a TLS close_notify alert before closing the connection if no further NETCONF RPC commands are expected.
All NETCONF messages MUST be sent as TLS 'application data'. A single TLS record may contain multiple NETCONF messages, or one NETCONF message may span multiple TLS records.
Both client and server MUST send the delimiter sequence ']]>]]>' after each XML document in the NETCONF exchange, and implementations MUST ensure this sequence never appears within a NETCONF message itself.
Clients MUST verify the binding between the identity of servers and the public keys presented; they SHOULD implement the certificate validation algorithm from RFC 5280 Section 6.
During TLS negotiation, the client MUST check the server hostname against the server's identity in the certificate to prevent man-in-the-middle attacks.
If a subjectAltName extension of type dNSName is present in the server certificate, it MUST be used as the source of the server's identity for hostname matching.
If hostname matching fails, the client MUST either ask for explicit user confirmation or terminate the connection and indicate the server's identity is suspect.
Implementations MUST support TLS 1.2 and are REQUIRED to support the mandatory cipher suite TLS_RSA_WITH_AES_128_CBC_SHA. The server MUST support certificate-based client authentication.
Once the TLS server receives a close_notify from the TLS client, it MUST reply with a close_notify unless it has already detected the connection was closed (e.g., via TCP).
The client MUST use the hostname it used to open the connection (or the TLS server_name extension) for comparison and MUST NOT use any form of the server hostname derived from an insecure remote source such as insecure DNS lookup.
The NETCONF manager MUST act as the TLS client and MUST connect to TCP port 6513, sending the TLS ClientHello to begin the TLS handshake.
The server MUST verify the identity of the client with certificate-based authentication according to local policy before any configuration or state data is sent to or received from the client.
NETCONF over TLS maps the NETCONF manager to the TLS client role and the NETCONF agent to the TLS server role. The client opens the connection and issues <rpc> elements; the server responds with <rpc-reply> elements.
IANA assigned TCP port 6513 in the Registered Port Numbers range with the name 'netconf-tls' and service name 'netconf' for use as the default port for NETCONF over TLS.
An attacker may inject arbitrary NETCONF messages via an application that does not check message content, or deliberately insert the ']]>]]>' delimiter to cause a DoS. Applications and NETCONF APIs MUST ensure the delimiter never appears in messages; receivers MUST silently discard and terminate the session if it is found inside a message.
The security considerations of both TLS (RFC 5246) and NETCONF (RFC 4741) apply. This document does not introduce new security considerations beyond RFC 4742, but it relies on TLS mutual certificate-based authentication as the sole authentication mechanism.
The delimiter sequence ']]>]]>' (6 ASCII characters) MUST be appended after each XML document exchanged over NETCONF/TLS. This sequence was inherited from RFC 4742 (NETCONF over SSH) to frame message boundaries within the TLS stream.