RFC 5539

NETCONF over Transport Layer Security (TLS)

📅 published May 2009, from ietf

NETCONF over Transport Layer Security (TLS) 🎀

Okay bestie, RFC 5539 is all about locking down how you configure network devices 🔐💅. Before we dive in, here's the title block ✨. It's from the Network Working Group, written by M. Badra of the CNRS/LIMOS Laboratory. It's a Standards Track document dated May 2009 🦋. The title block doesn't list anything it obsoletes or updates, so it isn't replacing or patching any older RFC 🙈.

Status of This Memo ✨

This is an Internet standards track protocol for the Internet community, and the authors are literally asking for discussion and suggestions for improvements 💬. To check where it stands in standardization, look at the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.

Copyright (c) 2009 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, which you can find at http://trustee.ietf.org/license-info. Please read those carefully, because they describe your rights and restrictions for this document 👀.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸.

Abstract 🦋

NETCONF gives you mechanisms to install, manipulate, and delete the configuration of network devices 🛠️. This document explains how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges 🔐.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
  1.1.  Conventions Used in This Document . . . . . . . . . . . . . 2
2.  NETCONF over TLS  . . . . . . . . . . . . . . . . . . . . . . . 3
  2.1.  Connection Initiation . . . . . . . . . . . . . . . . . . . 3
  2.2.  Connection Closure  . . . . . . . . . . . . . . . . . . . . 4
3.  Endpoint Authentication and Identification  . . . . . . . . . . 4
  3.1.  Server Identity . . . . . . . . . . . . . . . . . . . . . . 4
  3.2.  Client Identity . . . . . . . . . . . . . . . . . . . . . . 5
4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
7.  Contributor's Address . . . . . . . . . . . . . . . . . . . . . 7
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
  8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
  8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7

1. Introduction 💖

The NETCONF protocol [RFC4741] defines a way to manage a network device 🧚. NETCONF is connection-oriented, so it needs a persistent connection between peers. That connection must provide integrity, confidentiality, peer authentication, and reliable, sequenced data delivery 💜.

This document defines "NETCONF over TLS", which supports certificate-based mutual authentication and key derivation. It borrows the protected ciphersuite negotiation, mutual authentication, and key management capabilities of the TLS (Transport Layer Security) protocol, which is described in [RFC5246] 🦋.

Throughout the document, "client" and "server" refer to the two ends of the TLS connection. The client actively opens the TLS connection, and the server passively listens for incoming TLS connections 👑. "Manager" and "agent" refer to the two ends of the NETCONF protocol session. The manager issues NETCONF remote procedure call (RPC) commands, and the agent replies to them 🍓. When NETCONF runs over TLS using the mapping in this document, the client is always the manager and the server is always the agent ✨.

1.1. Conventions Used in This Document 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💅.

2. NETCONF over TLS 🌸

Since TLS is application-protocol-independent, NETCONF can sit on top of TLS transparently 🫶. This document explains how NETCONF gets used inside a TLS session.

2.1. Connection Initiation 🚀

The peer acting as the NETCONF manager MUST also act as the TLS client. It MUST connect to the server, which passively listens for the incoming TLS connection on TCP port 6513. It MUST therefore send the TLS ClientHello message to begin the TLS handshake 🤝.

Once the TLS handshake has finished, the client and the server MAY begin to exchange NETCONF data. Specifically, the client sends complete XML documents to the server containing <rpc> elements, and the server responds with complete XML documents containing <rpc-reply> elements 💖. The client MAY indicate interest in receiving event notifications from a server by creating a subscription to receive them [RFC5277]. In that case, the server replies to say whether the subscription request worked. If it did, the server starts sending event notifications to the client as events happen within the system 🔔.

All NETCONF messages MUST be sent as TLS "application data". One TLS record might carry multiple NETCONF messages, or a single NETCONF message might be spread across multiple TLS records 📦.

This document uses the same delimiter sequence (]]>]]>) defined in [RFC4742], and both the client and the server MUST send it after each XML document in the NETCONF exchange. This character sequence can legally show up in plain XML inside attribute values, comments, and processing instructions, so implementations of this document MUST ensure that this character sequence is never part of a NETCONF message 🙈.

Implementations of the protocol in this document MAY implement any TLS cipher suite that provides certificate-based mutual authentication [RFC5246]. The server MUST support certificate-based client authentication 🔑.

Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to support the mandatory-to-implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to future versions of TLS. In that case, the mandatory-to-implement cipher suite for the implemented version MUST be supported 🌈.

2.2. Connection Closure 👋

A TLS client (NETCONF manager) MUST close the associated TLS connection if the connection is not expected to issue any NETCONF RPC commands later. It MUST send a TLS close_notify alert before closing the connection. The TLS client MAY choose to not wait for the TLS server (NETCONF agent) close_notify alert and simply close the connection, which creates an incomplete close on the TLS server side 😬. Once the TLS server gets a close_notify from the TLS client, it MUST reply with a close_notify, unless it already knows the connection has been closed by the TLS client (for example, because TCP indicated the closure) 💌.

When no data has been received from a connection for a long time (the application decides what "long" means), a NETCONF peer MAY close the connection. Before closing, the NETCONF peer MUST attempt to start an exchange of close_notify alerts with the other NETCONF peer. A close_notify sender that isn't ready to receive any more data MAY close the connection after sending its close_notify alert, which creates an incomplete close on the close_notify receiver's side 🧊.

3. Endpoint Authentication and Identification 🕵️‍♀️

3.1. Server Identity 🪪

During the TLS negotiation, the client MUST carefully examine the certificate the server presents, to check whether it meets the client's expectations. In particular, the client MUST compare its understanding of the server hostname with the server's identity as presented in the server Certificate message. That's how you prevent man-in-the-middle attacks 🚨.

Matching follows the rules below (copying the example of [RFC4642]) 💅:

  • The client MUST use the server hostname it used to open the connection (or the hostname specified in the TLS "server_name" extension [RFC5246]) as the value to compare against the server name in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (for example, an insecure DNS lookup). CNAME canonicalization is not done.
  • If a subjectAltName extension of type dNSName is present in the certificate, it MUST be used as the source of the server's identity.
  • Matching is case-insensitive.
  • A "*" wildcard character MAY be used as the leftmost name component in the certificate. For example, *.example.com would match a.example.com and foo.example.com, etc., but would not match example.com.
  • If the certificate contains multiple names (for example, more than one dNSName field), then a match with any one of the fields is considered acceptable.

If the match fails, the client MUST either ask for explicit user confirmation or terminate the connection and indicate that the server's identity is suspect 😱.

Clients MUST also verify the binding between the identity of the servers they connect to and the public keys those servers present 🔍. Clients SHOULD implement the algorithm in Section 6 of [RFC5280] for general certificate validation. They MAY supplement that algorithm with other validation methods that achieve equivalent levels of verification, such as comparing the server certificate against a local store of already-verified certificates and identity bindings ✅.

If the client has external information about the expected identity of the server, the hostname check MAY be omitted 🧠.

3.2. Client Identity 🎫

The server MUST verify the identity of the client with certificate-based authentication according to local policy. That makes sure the incoming client request is legitimate before any configuration or state data is sent to or received from the client 👑💖.

4. Security Considerations ✨

okay bestie, this section is SERIOUS, so let's gooo 💅 the security stuff from [RFC5246] and [RFC4741] applies here too, no cap 🔐

this doc doesn't do third-party authentication (like backend AAA servers) 🙈 TLS doesn't define that way of authenticating, and NETCONF leans on the transport for its auth service. so if you need third-party auth, you can use BEEP or the SSH transport instead 🦋

⚠️ the big one: an attacker might try to inject NETCONF messages through an app that doesn't check what it's sending, or sneak the delimiter sequence into a message to cause a DoS 💀 so applications and NETCONF APIs MUST make sure the delimiter sequence from Section 2.1 NEVER shows up in NETCONF messages. otherwise those messages can get dropped, garbled, or misread 😭

if the sender spots the delimiter sequence in a message, a robust implementation of this doc SHOULD warn the user that illegal characters were found 🫶

if the receiver spots it (this includes XML attribute values, XML comments, and processing instructions 👀), a robust implementation of this doc MUST silently discard the message without processing it further, and then stop the NETCONF session 🛑

finally, this doc doesn't introduce any new security considerations compared to [RFC4742] ✨🎀

5. IANA Considerations 🌸

IANA assigned TCP port number 6513 in the "Registered Port Numbers" range with the name "netconf-tls" 🦋 this is the default port for NETCONF over TLS, as defined in this doc ✨

Registration Contact: Mohamad Badra, badra@isima.fr. Transport Protocol: TCP. Port Number: 6513 Broadcast, Multicast or Anycast: No. Port Name: netconf-tls. Service Name: netconf. Reference: RFC 5539

6. Acknowledgements 🫶

a big chunk of the text in Section 3 was lifted from [RFC4642] 📚

the author wants to thank David Harrington, Miao Fuyou, Eric Rescorla, Juergen Schoenwaelder, Simon Josefsson, Olivier Coupelon, Alfred Hoenes, and the NETCONF mailing list members for their comments 💜 they also appreciate Bert Wijnen, Mehmet Ersue, and Dan Romascanu for working through the issues 🙌 and Charlie Kaufman, Pasi Eronen, and Tim Polk for the thorough review 👑

7. Contributor's Address 🧚

Ibrahim Hajjeh Ineovation France

EMail: ibrahim.hajjeh@ineovation.fr

8. References 📚

8.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4741]  Enns, R., "NETCONF Configuration Protocol", RFC 4741,
           December 2006.

[RFC4742]  Wasserman, M. and T. Goddard, "Using the NETCONF
           Configuration Protocol over Secure SHell (SSH)", RFC 4742,
           December 2006.

[RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
           (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
           Housley, R., and W. Polk, "Internet X.509 Public Key
           Infrastructure Certificate and Certificate Revocation List
           (CRL) Profile", RFC 5280, May 2008.

8.2. Informative References

[RFC4642]  Murchison, K., Vinocur, J., and C. Newman, "Using
           Transport Layer Security (TLS) with Network News Transfer
           Protocol (NNTP)", RFC 4642, October 2006.

[RFC5277]  Chisholm, S. and H. Trevino, "NETCONF Event
           Notifications", RFC 5277, July 2008.

Author's Address 💖

Mohamad Badra
CNRS/LIMOS Laboratory
Campus de cezeaux, Bat. ISIMA
Aubiere  63170
France

EMail: badra@isima.fr
📦 where this page comes from