sn3rd

sean@sn3rd.com

Vigil Security, LLC

516 Dranesville Road Herndon VA 20170 United States of America housley@vigilsec.com

OPS netconf NETCONF TLS 1.3 TLS 1.2 Early Data RFC 7589 defines how to protect Network Configuration Protocol (NETCONF) messages with TLS 1.2. This document updates RFC 7589 to update support requirements for TLS 1.2 and add TLS 1.3 support requirements, including restrictions on the use of TLS 1.3's early data.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2026 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 () 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

• .  Introduction
• .  Conventions
• .  Early Data
• .  Cipher Suites
• .  Security Considerations
• .  IANA Considerations
• .  Normative References
• Acknowledgments
• Authors' Addresses

Introduction defines how to protect NETCONF messages with TLS 1.2 . This document updates to update support requirements for TLS 1.2 and add TLS 1.3 support requirements, including restrictions on the use of TLS 1.3's early data, which is also known as 0-RTT data. It also updates "netconf‑tls", the IANA-registered port number entry, to refer to this document. All other provisions set forth in are unchanged, including connection initiation, message framing, connection closure, certificate validation, server identity, and client identity.

Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Early Data Early data (aka 0-RTT data) is a mechanism defined in TLS 1.3 that allows a client to send data ("early data") as part of the first flight of messages to a server. Note that TLS 1.3 can be used without early data as per . In fact, early data is permitted by TLS 1.3 only when the client and server share a Pre-Shared Key (PSK), either obtained externally or via a previous handshake. The client uses the PSK to authenticate the server and to encrypt the early data. As noted in , the security properties for early data are weaker than those for subsequent TLS-protected data. In particular, early data is not forward secret, and there is no protection against the replay of early data between connections. requires applications not use early data without a profile that defines its use. This document specifies that NETCONF implementations that support TLS 1.3 or later MUST NOT use early data.

Cipher Suites Implementations MUST support mutually authenticated TLS 1.2 , and they are, as specified in , recommended to support the cipher suites found in . Implementations MAY implement additional TLS 1.2 cipher suites that provide mutual authentication and confidentiality, as required by NETCONF . Implementations SHOULD support mutually authenticated TLS 1.3 and, if implemented, MUST prefer to negotiate TLS 1.3 over earlier versions of TLS. Implementations that support TLS 1.3 are REQUIRED to support the mandatory-to-implement cipher suites listed in . Implementations that support TLS 1.3 MAY implement additional TLS cipher suites that provide mutual authentication and confidentiality, which are required for NETCONF .

Security Considerations The security considerations of , , and apply here as well. NETCONF implementations SHOULD follow the TLS recommendations given in . For implementations that support TLS 1.3, the security considerations of TLS 1.3 apply. As specified in , NETCONF over TLS requires mutual authentication. For implementations that support TLS 1.3 : TLS 1.3 mutual authentication is used to ensure that only authorized users and systems are able to view the NETCONF server's configuration and state or to modify the NETCONF server's configuration. To this end, neither the client nor the server should establish a NETCONF over TLS 1.3 connection with an unknown, unexpected, or incorrectly identified peer; see . If deployments make use of a trusted list of Certification Authority (CA) certificates , then the listed CAs should only issue certificates to parties that are authorized to access the NETCONF servers. Doing otherwise will allow certificates that were issued for other purposes to be inappropriately accepted by a NETCONF server. The security considerations of apply to all implementations when the client checks the identity of the server, as is required in .

IANA Considerations IANA has added a reference to this document in the "netconf-tls" entry in the "Service Name and Transport Protocol Port Number Registry". The updated registry entry appears as follows:

Service Name:

netconf-tls

Port Number:

6513

Transport Protocol:

tcp

Description:

NETCONF over TLS

Assignee:

IESG <iesg@ietf.org>

Contact:

IETF Chair <chair@ietf.org>

Reference:

RFC 7589, RFC 9918

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol with mutual X.509 authentication to secure the exchange of NETCONF messages. This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations.

Acknowledgments We would like to thank , , , , and for their reviews.

Authors' Addresses sn3rd

sean@sn3rd.com

Vigil Security, LLC

516 Dranesville Road Herndon VA 20170 United States of America housley@vigilsec.com