| Secure Shell Working Group | K.W. Watsen |
| Internet-Draft | Juniper Networks |
| Expires: November 14, 2011 | May 13, 2011 |
Reverse Secure Shell (Reverse SSH)
draft-kwatsen-reverse-ssh-00
This memo presents a technique for a SSH (Secure Shell) server to initiate the underlying TCP connection to the SSH client. This role reversal is necessary in cases where the SSH client would otherwise be unable to initiate an SSH connection to the SSH server, such as a device "calling home" on its first boot.
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 November 14, 2011.
Copyright (c) 2011 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 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.
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].
This memo presents a technique for a SSH (Secure Shell) [RFC4251] server to initiate the underlying TCP connection to the SSH client. This role reversal is necessary in cases where the SSH client would otherwise be unable to initiate an SSH connection to the SSH server, such as a device "calling home" on its first boot.
The need for Reverse SSH is primarily for device management, as no other circumstance seems to need it. As such, and so as to reduce confusion, this document uses the terms "device" and "application" to refer to the TCP-client/SSH-server and TCP-server/SSH-client, respectively.
The SSH protocol is nearly ubiquitous for device management, as it is the transport for the command-line applications `ssh`, `scp`, and `sftp` and the required transport for the NETCONF protocol [RFC4741]. However, in all these cases, the device expects to be the SSH server so that it can authenticate the application, apply security credentials, enable SSH channels to be opened, and so on. Reverse SSH allows the device to always be the SSH server regardless of which peer initiates the underlying TCP connection.
Reverse SSH is useful for both initial and on-going device management. Use of Reverse SSH for initial deployment is independent of its use for on-going management.
For initial deployment, Reverse SSH may be used as a "call home" mechanism, similar to that provided by Broadband Forum TR-069 [TR069], but with the benefit of not being bound to any particular protocol (SOAP over HTTP).
For on-going management, Reverse SSH may be used to enable any of the following scenarios:
One key benefit of using SSH as the transport protocol for Reverse SSH is its ability to multiplex an unspecified number of independently flow-controlled TCP sessions on top of a single encrypted tunnel [RFC4254]. This feature is valuable as the device only needs to be configured to initiate a single Reverse SSH connection regardless the number the 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 device supports (logs, traps, backups, etc.) and dynamically open/close channels as needed by its runtime. Lastly, using SSH channels has been found to be more straightforward and supported than using other multiplexing protocols such as Block Extensible Exchange Protocol (BEEP) [RFC3080].
Reverse SSH has been designed to be fully transparent to the SSH protocol and, specifically, not affect the ability for an SSH server to reset its host keys. This strategy ensures that Reverse SSH is easy to both implement and deploy. As a testament to it's ease of implementation, all the SSH libraries tested in a number of programming languages, both the client and server side API supported using an already accepted TCP file descriptor, which doesn't retain any state as to which peer initiated the TCP connection. Further, on systems supporting OpenSSL, the `sshd -i` parameter does the same on the command-line, in order for `inetd` to pass accepted connections on to it.
This RFC additionally defines a YANG [RFC6020] module for the configuration of the Reverse SSH agent running on a device. While wholly distinct from the Reverse SSH protocol, the definition of a YANG module enables a management application to generically manage the IETF-namespaced configuration without needing to understand any device-specific data-model. This is important as helps to normalize the configuration necessary to bootstrap multi-vendor devices for their "initial deployment". The definition of a YANG module also ensures that key features are enabled such as supporting more than one application, more than one server per application, and the definition of a reconnection strategy.
This RFC does not attempt to define any strategy for how an initial deployment might obtain its bootstrapping "call home" configuration (address to connect to, signature algorithm to use, authentication credentials to use, etc.). That said, implementations may consider use of a DHCP server or a USB pen drive as viable options.
The Device's perspective
The Application's Perspective
As mentioned in in the overview, the "protocol" is really just a single message, the 'REVERSE-SSH-CONN-INFO' message, which is described as follows:
string "REVERSE-SSH-CONN-INFO (v1)"
string device-id
uint32 host-key-info-count
string host-key-info[1..host-key-info-count]
The "device-id" field encodes an application-configured identifier. This field is necessary as the device MAY not be identifiable from its TCP session's source address due to it "calling home" for the first time or having a dynamically assigned address. The device-id MAY be the device's serial-number though, for security reasons, it is NOT RECOMMENDED. The device-id SHOULD be a random value meaningful only to the application.
The "host-key-info-count" field indicates the number of "host-key-info" blocks that follow. This value MUST be a positive value less than or equal to the number of host-keys the device has. This is to say, the value cannot exceed the number of "server_host_key_algorithms" the device would present in its "SSH_KEY_INIT" message (section 7.1 of [RFC4253]).
The "host-key-info" field, one for each host key the device has, provides information needed for the application to authenticate the host-key at the time of the SSH key-exchange. Certificate based hosts keys, such as those using PGP from [RFC4253] or x.509 from [RFC6187] only need to list their name, whereas others will need to be signed.
Format for the 'host-key-info' field:
string server-host-key-algorithm
..... algorithm-specific-data follow
The "server-host-key-algorithm" field identifies the format of the host-key (e.g. "ssh-rsa"). It's value MUST be one of the "server_host_key_algorithms" values the device would present in its "SSH_KEY_INIT" message (section 7.1 of [RFC4253]).
No algorithm-specific data needs to follow any of the certificate-based host key algorithms; the name alone is sufficient since the host-key presented at the time of the SSH key exchange will carry with it all the information needed for the application to authenticate it.
Non certificate-based host key algorithms MUST encode their algorithm-specific data as follows:
string host-key
string signature-algorithm
string signature
The "host-key" field is the algorithm-specific host key (e.g. the ssh-rsa key) on the device.
The "signature-algorithm" field identifies the signature algorithm used to sign the host key. Which algorithm is used is an application-configured value selected among options supported by the device. The following options are identified here, but vendor-specific options MAY be specified using the extensibility mechanism defined in [RFC4250].
Signature Algorithms (extensible)
hmac-md5 [RFC2104]
hmac-sha1 [RFC2104]
rsa-sha1 [RFC3447] (Section 8.2)
hmac-sha256 [RFC4231]
All of these signature algorithms require a key to be provided. The HMAC-based algorithms require a symmetric-key (both peers know the same value) and the RSA-based algorithm requires an asymmetric key (device has the private key). The YANG module presented in the "Device Configuration" section below defines the necessary configuration nodes for these key values.
The "signature" field contains the "result" of the signature algorithm applied to the host-key field.
For devices that support NETCONF, this section defines a YANG [RFC6020] module that can be used to enable management applications to configure the Reverse SSH service on the device. This section is also useful for devices that do not support NETCONF, as it highlights what a configuration data model SHOULD include.
While it's expected that NETCONF [RFC4741] will be used to configure the device, it's not entirely clear how that can be done for "initial-deployments", especially when needing to support a zero-touch "call home" mechanism, where the device is set to its factory defaults. Though out of scope for this RFC, it's helpful to consider that many of these values can be provided either from the DHCP server or a USB-based drive that device bootstraps itself from. Further, for devices having a secure crypto processor, it's expected that its "factory default" includes a unique private key (stored in crypto processor) and a public certificate signed by the device's vendor, providing the needed "chain of trust" for the PGP and/or x.509 host key algorithms.
Configuration Example
INSERT_TEXT_FROM_FILE(config.xml)
The YANG Module
INSERT_TEXT_FROM_FILE(ietf-reverse-ssh@2011-04-26.yang)
This protocol deviates from standard SSH protocol usage in two ways: 1) the device initiates the underlying TCP connection and 2) the device sends the REVERSE-SSH-CONN-INFO message to the application. The SSH client/server protocol itself is unchanged. Thus all security considerations are limited to these two differences.
Despite section 4 of the SSH Transport Layer Protocol RFC [RFC4253] stating "The client initiates the connection", having the device initiate the underlying TCP connection is in itself not a primary concern. This can be seen by assuming the device has a stable IP address, such that the application can discover it from the TCP connection's state, thus enabling it to lookup of the corresponding record for the device's host-key in its local datastore and proceed as usual. Ultimately, the fundamentals for how the application trusts the device's host key are unchanged. This is true even for first-time authentications.
However, Reverse SSH is designed to support cases where the device's IP address may be NAT-ed or dynamically-assigned. Compounding the issue further, Reverse SSH is designed to support scenarios where its not possible to have any prior information about the device's host key. This is clear since SSH keys are typically generated after a device boots its "factory default".
Thus there are two issues - establishing the identity of the device and trusting its host key. Resolving these two issues is the purpose of the REVERSE-SSH-CONN-INFO message.
The REVERSE-SSH-CONN-INFO message itself is neither signed nor encrypted. Care must be taken regarding the data the device sends and how it is precessed by the application.
Since the REVERSE-SSH-CONN-INFO message is not encrypted, it should not contain any value that might give an observer any undue information about the device. Of primary concern are the "device-id" field and information embedded in any certificates sent. Specifically, using the device's serial number for its "device-id" is NOT RECOMMENDED as it may reveal the device's model-number and/or manufacturing date.
Likewise, many fields in the REVERSE-SSH-CONN-INFO message must be consumed without being able to verifying that they are the values the device sent. For instance, the "device-id" value must to used to lookup the device's record in a local datastore in order to obtain the keys needed to process the rest of the message. The application must be sure to validate all inputs carefully as they may be purposely encoded to illicit unexpected behaviour.
The REVERSE-SSH-CONN-INFO message enables the application to authenticate the device's SSH host key. This authentication occurs prior to the start of the SSH protocol in order to remain entirely transparent to it. The device's host keys are authenticated by it being signed by another key that the application does trust. Thus the trust in the host key is conveyed by the other key vouching for it. In order for this solution to not lose any cryptographic strength, the strength of the signing key MUST be greater or equal to SSH host key it it vouching for.
An attacker could DoS the application using valid "device-id" values, forcing the application to perform computationally expensive operations, only to deduce 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).
IANA is requested to assign a TCP port number which will be the default port for Reverse SSH connections as defined in this document.
| [TR069] | The Broadband Forum, , "TR-069 Amendemnt 3, CPE WAN Management Protocol ", November 2010. |