NETCONF Working Group K. Watsen Internet-Draft Juniper Networks Updates: 4253 (if approved) June 19, 2013 Intended status: Standards Track Expires: December 21, 2013 Reverse Secure Shell (Reverse SSH) draft-ietf-netconf-reverse-ssh-01 Abstract 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". Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 21, 2013. Copyright Notice Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) 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 Watsen Expires December 21, 2013 [Page 1] Internet-Draft Reverse Secure Shell (Reverse SSH) June 2013 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Requirements Terminology . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Benefits to Device Management . . . . . . . . . . . . . . . . 2 4. The Reverse SSH Protocol . . . . . . . . . . . . . . . . . . 3 5. Device Configuration . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Normative References . . . . . . . . . . . . . . . . . . . . 12 1. Requirements Terminology 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 [RFC2119]. 2. Introduction This memo presents a technique for a NETCONF [RFC6241] server to initiate a Secure Shell (SSH) [RFC4251] 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" [RFC6242]. While the motivation for this work is for the NETCONF protocol, the solution is not specific to NETCONF and is applicable any time it is desired for a SSH server to initiate a connection to a SSH client. For this reason, the solution is given the generic name "Reverse SSH" and the port the remote peer listens on is the Reverse SSH port. 3. Benefits to Device Management 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 [RFC6241]. However, all these SSH-based protocols expect the managed device to be the SSH server. Reverse SSH enables the managed device to consistently be the SSH server regardless of which peer initiates the underlying TCP Watsen Expires December 21, 2013 [Page 2] Internet-Draft Reverse Secure Shell (Reverse SSH) June 2013 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 conviently 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: o The device may proactively "call home" after being powered on for the first time to register itself with its management system. o The managed device 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. o The managed device may be configured in "stealth mode" and thus doesn't have any open ports. o The managed device may be deployed behind a firewall that doesn't allow SSH access to the internal network. o The managed device may be deployed behind a firewall that implements network address translation (NAT) for all internal network IP addresses. o The operator may prefer to have managed devices initiate management connections believing it is easier to secure one open- port in the data center than to have an open port on each managed device 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 [RFC4254]. This is valuable as the managed device only needs to be configured to initiate a single Reverse SSH connection regardless the number of TCP-based protocols the application wishes to support. For instance, the application may "pin up" a channel for each distinct type of asynchronous notification the managed device supports (logs, traps, backups, etc.) and dynamically open/close channels as needed by its runtime. 4. The Reverse SSH Protocol The NETCONF server's perspective o The NETCONF server initiates a TCP connection to the NETCONF client on the IANA-assigned Reverse SSH port YYYY. Watsen Expires December 21, 2013 [Page 3] Internet-Draft Reverse Secure Shell (Reverse SSH) June 2013 o Immediately after the TCP session starts, the NETCONF server starts the SSH server protocol using the accepted TCP connection. That is, the NETCONF Server sends its SSH host key during the SSH key exchange. The NETCONF client's perspective o The NETCONF client listens for TCP connections on the IANA- assigned SSH port YYYY. o The NETCONF client accepts an incoming TCP connection and immediately starts the SSH client protocol. That is, the NETCONF client will need to authenticate its peer's SSH host key during the SSH key exchange. This document updates the SSH Transport Layer Protocol [RFC4253] only by removing the restriction in Section 4 (Connection Setup) of [RFC4252] that the SSH Client must initiate the transport connection. Security implications related to this change are discussed in the Security Considerations (Section 6) section. For first-time connections, in order for the NETCONF client to authenticate the NETCONF server, a public host key algorithm that certifies the the NETCONF server's identity and host-key SHOULD be used. Examples of suitable public host key algorithms are the x509v3-* algorithms defined in [RFC6187]. 5. Device Configuration For devices supporting NETCONF, this section defines a YANG [RFC6020] module to configure Reverse SSH on the device. For devices that do not support NETCONF, this section illustrates what its configuration data model SHOULD include. 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 does not attempt to define any strategy for how an initial deployment might obtain its bootstrapping "call home" configuration, as defined by this YANG module. That said, implementations may consider fetching configuration from a server identified via the DHCP protocol or loading it off a USB drive plugged into the device before being powered on. Configuration Example Watsen Expires December 21, 2013 [Page 4] Internet-Draft Reverse Secure Shell (Reverse SSH) June 2013 config-mgr This entry requests the device to periodically connect to the Configuration Manager application config-mgr1.acme.com 7022 config-mgr2.acme.com 7022 5 20 ssh_host_key_cert ssh_host_key_cert2 5 3 last-connected 10 4 log-monitor This entry requests the device to mantain a persistent connection to the Log Monitoring application Watsen Expires December 21, 2013 [Page 5] Internet-Draft Reverse Secure Shell (Reverse SSH) June 2013 log-mon1.acme.com 7514 log-monitor2.acme.com 7514 ssh_host_key_hmac 5 3 last-connected 10 4 The YANG Module module ietf-reverse-ssh { namespace "urn:ietf:params:xml:ns:yang:ietf-reverse-ssh"; prefix "rssh"; import ietf-inet-types { prefix inet; } organization "IETF NETCONF (Network Configuration Protocol) Working Group"; contact "WG Web: WG List: WG Chair: Bert Wijnen Watsen Expires December 21, 2013 [Page 6] Internet-Draft Reverse Secure Shell (Reverse SSH) June 2013 WG Chair: Mehmet Ersue Editor: Kent Watsen "; revision 2013-06-18 { description "Initial conception"; reference "RFC XXXX: Reverse SSH"; } // RFC Ed.: replace XXXX with actual // RFC number and remove this note container reverse-ssh { container applications { description "All the application that the device initiates Reverse SSH connections to"; list application { key name; min-elements 1; leaf name { mandatory true; type string { length 1..32; } description "The name of the application the device is connecting to"; } leaf description { type string; description "An optional description for the application"; } container servers { description "An ordered listing of the application's servers that the device should attempt connecting to."; list server { key host; min-elements 1; ordered-by user; Watsen Expires December 21, 2013 [Page 7] Internet-Draft Reverse Secure Shell (Reverse SSH) June 2013 leaf host { mandatory true; type inet:host; description "IP address or domain-name for the server"; } leaf port { type inet:port-number; description "The IP port for this server. The device will use the IANA-assigned port if not specified."; } } } choice connection-type { description "Indicates the application's preference for how the device's connection is maintained."; default persistent-connection; leaf persistent-connection { type empty; } container periodic-connection { leaf timeout-mins { type uint8; default 5; units minutes; description "The maximum amount of unconnected time the device will wait until establishing a connection to the applications again to send it. The device may establish a connection before this time if it has data it needs to send to the device."; } leaf linger-secs { type uint8; default 30; units seconds; description "The amount of time the device should wait after last receiving data from Watsen Expires December 21, 2013 [Page 8] Internet-Draft Reverse Secure Shell (Reverse SSH) June 2013 or sending data to the device before closing its connection to the app."; } } } container host-keys { description "An ordered listing of the SSH host keys the device should advertise to the application."; list host-key { key name; min-elements 1; ordered-by user; leaf name { mandatory true; type string { length 1..64; } description "The name of a host key the device should advertise during the SSH key exchange."; } } } container keep-alive-strategy { leaf interval-secs { type uint8; units seconds; default 15; description "Sets a timeout interval in seconds after which if no data has been received from the client, a message will be sent to request a response from the SSH client. A value of '0' indicates that no messages should be sent."; } leaf count-max { type uint8; default 3; description "Sets the number of keep alive messages that may be sent without receiving any response from the SSH client before assuming the SSH client is no longer alive. If this threshold is reached the device will disconnect the SSH Watsen Expires December 21, 2013 [Page 9] Internet-Draft Reverse Secure Shell (Reverse SSH) June 2013 session. The keep alive interval timer is reset after each transmission. Thus, an unresponsive SSH client will be disconnected after approximately 'count-max * interval-secs' seconds."; } } container reconnect-strategy { leaf start-with { default first-listed; type enumeration { enum first-listed; enum last-connected; } } leaf interval-secs { type uint8; units seconds; default 5; description "time delay between connection attempts"; } leaf count-max { type uint8; default 3; description "num times try to connect to a server"; } } } } } } 6. Security Considerations 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 [RFC4253], 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 the 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 Watsen Expires December 21, 2013 [Page 10] Internet-Draft Reverse Secure Shell (Reverse SSH) June 2013 (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 [RFC4251]). 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 (Algortihm Negotition) in [RFC4253]). 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. It is RECOMMENDED that the SSH client orders 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 to perform computationally expensive operations, before deducing that the attacker doesn't posses a valid key. This is no different than any Watsen Expires December 21, 2013 [Page 11] Internet-Draft Reverse Secure Shell (Reverse SSH) June 2013 secured service and all common precautions apply (e.g. blacklisting the source address after a set number of unsuccessful login attempts). 7. IANA Considerations 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 [RFC6335]. Service Name: reverse-ssh Transport Protocol(s): TCP Assignee: IESG Contact: IETF Chair Description: Reverse SSH (call home) Reference: RFC XXXX Port Number: YYYY 8. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Centti, "HMAC: Keyed- Hashing for Message Authentication ", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels ", BCP 14, RFC 2119, March 1997. [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers ", RFC 4250, December 2005. [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture ", RFC 4251, January 2006. [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol ", RFC 4252, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol ", RFC 4253, January 2006. [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol ", RFC 4254, January 2006. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) ", RFC 6020, October 2010. Watsen Expires December 21, 2013 [Page 12] Internet-Draft Reverse Secure Shell (Reverse SSH) June 2013 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure Shell Authentication ", RFC 6187, March 2011. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "NETCONF Configuration Protocol", RFC 6241, June 2011. [RFC6242] Wasserman, M., Ed., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, June 2011. [RFC6335] Cotton, M., Ed., Eggert, L., Ed., Touch, J., Ed., Westerlund, M., Ed., and S. Cheshire, Ed., "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", RFC 6335, August 2011. Author's Address Kent Watsen Juniper Networks EMail: kwatsen@juniper.net Watsen Expires December 21, 2013 [Page 13]