Juniper Networks

kwatsen@juniper.net

Operations NETCONF Working Group reverse-ssh This memo presents a technique for a NETCONF server to initiate a SSH connection to a NETCONF client. This is accomplished by the NETCONF client listening on IANA-assigned TCP port YYYY and starting the SSH client protocol immediately after accepting a TCP connection on it. This role-reversal is necessary as the NETCONF server must also be the SSH Server, in order for the NETCONF client to open the IANA-assigned SSH subsystem "netconf".

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 RFC 2119 .

This memo presents a technique for a NETCONF server to initiate a Secure Shell (SSH) connection to a NETCONF client. This is accomplished by the NETCONF client listening on IANA-assigned TCP port YYYY and starting the SSH client protocol immediately after accepting a TCP connection on it. This role-reversal is necessary as the NETCONF server must also be the SSH Server, in order for the NETCONF client to open the IANA-assigned SSH subsystem "netconf" .

The techniques described in this document are suitable for network management scenarios such as the ones described in section 3. However, these techniques MUST only be used for a NETCONF server to initiate a connection to a NETCONF client, as described in this document. The reason for this restriction is that different protocols have different security assumptions. The NETCONF over SSH specification requires NETCONF clients and servers to verify the identity of the other party before starting the NETCONF protocol. This contrasts with the base SSH protocol, which does not require programmatic verification of the other party. In such circumstances, allowing the SSH server to contact the SSH client would open new vulnerabilities. Therefore, any use of Reverse SSH for purposes other than NETCONF will need a thorough, contextual security analysis.

This document updates the SSH Transport Layer Protocol only by removing the restriction in Section 4 (Connection Setup) of that the SSH Client must initiate the transport connection. Security implications related to this change are discussed in Security Considerations ().

The SSH protocol is nearly ubiquitous for device management, as it is the transport for the command-line applications `ssh`, `scp`, and `sftp` and is the required transport for the NETCONF protocol . However, all these SSH-based protocols expect the network element to be the SSH server. Reverse SSH enables the network element to consistently be the SSH server regardless of which peer initiates the underlying TCP connection. Maintaining the role of SSH Server is both necessary and desirable. It is necessary because SSH channels and subsystems can only be opened on the SSH Server. It is desirable because it conveniently leverages infrastructure that may be deployed for host-key verification and user authentication. Reverse SSH is useful for both initial deployment and on-going device management and may be used to enable any of the following scenarios: The network element may proactively "call home" after being powered on for the first time to register itself with its management system. The network element may access the network in a way that dynamically assigns it an IP address and it doesn't register its assigned IP addressed to a mapping service. The network element may be configured in "stealth mode" and thus doesn't have any open ports for the management system to connect to. The network element may be deployed behind a firewall that doesn't allow SSH access to the internal network. The network element may be deployed behind a firewall that implements network address translation (NAT) for all internal network IP addresses, thus complicating the ability for a management system to connect to it. The operator may prefer to have network elements initiate management connections believing it is easier to secure one open-port in the data center than to have an open port on each network element in the network. One key benefit of using SSH as the transport protocol is its ability to multiplex an unspecified number of independently flow-controlled TCP sessions . This is valuable as the network element only needs to be configured to initiate a single Reverse SSH connection to the management system, regardless the number of TCP-based protocols the management system wishes to support. For instance, in addition to having a SSH channel for NETCONF, the management system may "pin up" channels for Syslog, SNMP, or file-transfers.

The NETCONF server's perspective (e.g., the network element) The NETCONF server initiates a TCP connection to the NETCONF client on the IANA-assigned Reverse SSH port YYYY. The TCP connection is accepted and a TCP session is established. Using this TCP connection, the NETCONF server immediately starts the SSH Server protocol. That is, the next message sent on the TCP stream is SSH's Protocol Version Exchange message (section 4.2, ). The SSH connection is established. The NETCONF client's perspective (e.g., the management system) The NETCONF client listens for TCP connections on the IANA-assigned SSH port YYYY. The NETCONF client accepts an incoming TCP connection and a TCP session is established. Using this TCP connection, the NETCONF client immediately starts the SSH Client protocol, starting with sending the SSH's Protocol Version Exchange message (section 4.2, ). The SSH connection is established.

When the management system accepts a new incoming connection, it needs to authenticate the remote peer. Ultimately, this entails identifying the peer and verifying its SSH host key. Due to Reverse SSH having the network element initiate the TCP connection, the first data the management system has to identify it with is the source IP address of the TCP connection. But this approach is limited as it only works in networks that use known static addresses. To support network-elements having dynamically-assigned IP addresses or deployed behind gateways that translate their IP address (e.g., NAT), the management system MAY identify the device using its SSH host key. For instance, a fingerprint of the network element's host key could be used as an identifier since the probability of collision is acceptably low. But this solution requires the management system to be configured with each device's host key each time it changes. Yet another option for identifying the network element is for its host key to encode its identity, such as if it were a certificate. This option enables the host key to change over time, but brings the next issue of how the mangement element can verify the network element's host key is authentic. The security of SSH is anchored in the ability for the SSH client to verify the SSH server's hostkey. Typically this is done by comparing the host key presented by the SSH server with one that was previously configured on the SSH client, looking it up in a local database using the identity of the SSH client as the lookup key. Nothing changes regarding this requirement due to the direction reversal of the underlying TCP connection. To ensure security, the management system MUST verify the network element's SSH host key each time a SSH session is established. However, configuring distinct host keys on the management system doesn't scale well, which is an important consideration to a network management system. A more scalable strategy is to have the network element's host key signed by a common trusted key, such as a certificate authority. Thus, the mangement system only needs to trust a single public key, which vouches for the authenticity of the various network element public keys. Since both the identification and verification issues are addressed using certificates, this draft RECOMMENDS network elements use a host key that can encode a unique (e.g., its serial number) and be signed by a common trust anchor (e.g., a certificate authority). Examples of suitable public host keys are the X.509v3 keys defined in defined in .

Configuring a device to initiate a Reverse SSH connection entails it knowing what IP address it should connect to and what SSH host-key it should present. A complete YANG module to configure Reverse SSH is defined in . This YANG module enables a NETCONF client to generically manage a NETCONF server's Reverse SSH configuration. Key aspects of this YANG module include support for more than one application, more than one server per application, and a reconnection strategy.

This RFC deviates from standard SSH protocol usage by allowing the SSH server to initiate the TCP connection. This conflicts with section 4 of the SSH Transport Layer Protocol RFC , which states "The client initiates the connection". However this statement is made without rationalization and it's not clear how it impacts the security of the protocol, so this section analyzes the security offered by having the client initiate the connection. First, assuming the SSH server is not using a public host key algorithm that certifies its identity, the security of the protocol doesn't seem to be sensitive to which peer initiates the connection. That is, it is still the case that reliable distribution of host keys (or their fingerprints) should occur prior to first connection and that verification for subsequent connections happens by comparing the host keys in locally cached database. It does not seem to matter if the SSH Server's host name is derived from user-input or extracted from the TCP layer, potentially via a reverse-DNS lookup. Once the host name-to-key association is stored in a local database, no man-in-the-middle attack is possible due to the attacker being unable to guess the real SSH server's private key (Section 9.3.4 (Man-in-th-middle) of ). That said, this RFC recommends implementations use a public host key algorithm that certifies the SSH server's identity. The identity can be any unique identifier, such as a device's serial number or a deployment-specific value. If this recommendation is followed, then no information from the TCP layer would be needed to lookup the device in a local database and therefore the directionality of the TCP layer is clearly inconsequential. The SSH protocol negotiates which algorithms it will use during key exchange (Section 7.1 (Algorithm Negotiation) in ). The algorithm selected is essentially the first compatible algorithm listed by the SSH client that is also listed by the SSH server. For a network management application, there may be a need to advertise a large number of algorithms to be compatible with the various devices it manages. The SSH client SHOULD order its list of public host key algorithms such that all the certifiable public host key algorithms are listed first. Additionally, when possible, SSH servers SHOULD only list certifiable public host key algorithms. Note that since the SSH server would have to be configured to know which IP address it needs to connect to, it is expected that it will also be configured to know which host key algorithm to use for the particular application, and hence only needs to list just that one public host key algorithm. This RFC suggests implementations can use a device's serial number as a form of identity. A potential concern with using a serial number is that the SSH protocol passes the SSH server's host-key in the clear and many times serial numbers encode revealing information about the device, such as what kind of device it is and when it was manufactured. While there is little security in trying to hide this information from an attacker, it is understood that some deployments may want to keep this information private. If this is a concern, deployments MAY consider using instead a hash of the device's serial number or an application-specified unique identifier. An attacker could DoS the application by having it perform computationally expensive operations, before deducing that the attacker doesn't posses a valid key. This is no different than any secured service and all common precautions apply (e.g., blacklisting the source address after a set number of unsuccessful login attempts).

This document requests that IANA assigns a TCP port number in the "Registered Port Numbers" range with the service name "reverse-ssh". This port will be the default port for the Reverse SSH protocol and will be used when the NETCONF server needs to initiate a connection to a NETCONF client using SSH. Below is the registration template following the rules in .

Contact: IETF Chair Description: Reverse SSH (call home) Reference: RFC XXXX Port Number: YYYY ]]>

The author would like to thank for following for lively discussions on list and in the halls (ordered by last name): Andy Bierman, Martin Bjorklund, Mehmet Ersue, Wes Hardaker, Stephen Hanna, David Harrington, Jeffrey Hutzelman, Mouse, Russ Mundy, Tom Petch, Peter Saint-Andre, Joe Touch, Sean Turner, Bert Wijnen.

Harvard University SSH Communications Security Corp Cisco Systems, Inc. SSH Communications Security Corp Cisco Systems, Inc. SSH Communications Security Corp Cisco Systems, Inc. SSH Communications Security Corp Cisco Systems, Inc. SSH Communications Security Corp Cisco Systems, Inc. Tail-f Systems National Security Agency Queensland University of Technology Juniper Networks Tail-f Systems Jacobs University Brocade Painless Security, LLC Internet Corporation for Assigned Names and Numbers Nokia Research Center USC/ISI Ericsson Apple Inc. Juniper Networks Jacobs University

Updated Device Configuration section to reference

Added Applicability Statement Removed references to ZeroConf / ZeroTouch Clarified the protocol section Added a section for identification and verification

Removed the hmac-* family of algorithms