Secure Shell Working Group K. Watsen
Internet-Draft Juniper Networks
Expires: November 13, 2011 May 12, 2011
Reverse Secure Shell (Reverse SSH)
draft-kwatsen-reverse-ssh-00
Abstract
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.
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 November 13, 2011.
Copyright Notice
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.
Watsen Expires November 13, 2011 [Page 1]
Internet-Draft Reverse Secure Shell (Reverse SSH) May 2011
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 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:
o The device may be deployed behind a NAT-ing device that doesn't
provision an external address and port to connect to.
o The device may be deployed behind a firewall that doesn't allow
SSH access to the internal network.
Watsen Expires November 13, 2011 [Page 2]
Internet-Draft Reverse Secure Shell (Reverse SSH) May 2011
o The device may be configured in "stealth mode" with no open ports
o The device may access the network in a way that dynamically
assigns it an IP address and is not configured to use a service to
register its dynamically-assigned IP address to a well-known
domain name.
o The operator prefers to have one open-port to secure in the data
center, rather than have an open port on each device in the
network.
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.
Watsen Expires November 13, 2011 [Page 3]
Internet-Draft Reverse Secure Shell (Reverse SSH) May 2011
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.
3. Protocol Overview
The Device's perspective
o The device initiates a TCP connection to the application on the
IANA-assigned Reverse SSH port [TBD]
o Immediately after the TCP session starts, the device MUST send a
REVERSE-SSH-CONN-INFO message to the remote application and then
start the SSH server using the accepted TCP connection.
o The REVERSE-SSH-CONN-INFO message contains information necessary
for the application to identify the device and authenticate it's
SSH host-key
The Application's Perspective
o The application listens for TCP connections on the IANA-assigned
Reverse SSH port
o The application accepts an incoming TCP connection and waits to
receive the REVERSE-SSH-CONN-INFO message
o The application processes the REVERSE-SSH-CONN-INFO message by
first asserting that its message header fields are as expected
o The application then uses the DEVICE-ID field to lookup the device
in some internal persistent datastore
o The application uses a device-specific key found in its datastore
to authenticate the device's SSH host key contained in the message
o The application initiates the SSH client protocol using the
accepted TCP connection
o The application authenticates the device's SSH host key using one
of the ones it just authenticated from the REVERSE-SSH-CONN-INFO
message
o The application authenticates itself to the device using
previously configured authentication credentials
Watsen Expires November 13, 2011 [Page 4]
Internet-Draft Reverse Secure Shell (Reverse SSH) May 2011
4. Protocol
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.
Watsen Expires November 13, 2011 [Page 5]
Internet-Draft Reverse Secure Shell (Reverse SSH) May 2011
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.
5. Device Configuration
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
Watsen Expires November 13, 2011 [Page 6]
Internet-Draft Reverse Secure Shell (Reverse SSH) May 2011
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
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<reverse-ssh xmlns="urn:ietf:params:xml:ns:yang:ietf-reverse-ssh">
<applications>
<application>
<name>config-mgr</name>
<description>
This entry requests the device to periodically
connect to the Configuration Manager application
</description>
<device-id>9876436534</device-id>
<periodic-connection>
<interval-mins>5</interval-mins>
<linger-secs>20</linger-secs>
</periodic-connection>
<symmetric-authentication>
<algorithm>hmac-sha1</algorithm>
<hmac-key>secret</hmac-key>
</symmetric-authentication>
<servers>
<server>
<host>config-mgr1.acme.com</host>
<port>7022</port>
</server>
<server>
<host>config-mgr2.acme.com</host>
<port>7022</port>
</server>
</servers>
<keep-alive-strategy>
<interval-secs>5</interval-secs>
<count-max>3</count-max>
</keep-alive-strategy>
<reconnect-strategy>
<start-with>last-connected</start-with>
<interval-secs>10</interval-secs>
<count-max>4</count-max>
</reconnect-strategy>
</application>
Watsen Expires November 13, 2011 [Page 7]
Internet-Draft Reverse Secure Shell (Reverse SSH) May 2011
<application>
<name>log-monitor</name>
<description>
This entry requests the device to mantain a
persistent connection to the Log Monitoring
application
</description>
<device-id>device-23.53432</device-id>
<persistent-connection/>
<assymmetric-authentication>
<algorithm>rsa-sha1</algorithm>
<assymetric-key>secret</assymetric-key>
</assymmetric-authentication>
<servers>
<server>
<host>log-mon1.acme.com</host>
<port>7514</port>
</server>
<server>
<host>log-monitor2.acme.com</host>
<port>7514</port>
</server>
</servers>
<keep-alive-strategy>
<interval-secs>5</interval-secs>
<count-max>3</count-max>
</keep-alive-strategy>
<reconnect-strategy>
<start-with>last-connected</start-with>
<interval-secs>10</interval-secs>
<count-max>4</count-max>
</reconnect-strategy>
</application>
</applications>
</reverse-ssh>
</config>
Watsen Expires November 13, 2011 [Page 8]
Internet-Draft Reverse Secure Shell (Reverse SSH) May 2011
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: <http://tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
WG Chair: Bert Wijnen
<mailto:bertietf@bwijnen.net>
WG Chair: Mehmet Ersue
<mailto:mehmet.ersue@nsn.com>
Editor: Kent Watsen
<mailto:kwatsen@juniper.net>";
revision 2011-04-26 {
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;
}
Watsen Expires November 13, 2011 [Page 9]
Internet-Draft Reverse Secure Shell (Reverse SSH) May 2011
description
"The name of the specific application";
}
leaf description {
type string;
description
"An optional description for the application";
}
leaf device-id {
type string {
length 1..32;
}
description
"The identifier the device uses to
identify itself to this application. If
not specified, the device will use it's
serial-number (not recommneded)";
}
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 interval-mins {
type uint8;
default 5;
units minutes;
description
"The amount of unconnected time the
device will wait until establishing
a connection just in case the
application has some data pending
to send it. The device MAY
establish a connection before this
time if it has data is needs to
send to the device.";
}
leaf linger-secs {
type uint8;
default 30;
units seconds;
description
"The amount of time it should wait
after last receiving from or sending
Watsen Expires November 13, 2011 [Page 10]
Internet-Draft Reverse Secure Shell (Reverse SSH) May 2011
data to the device before closing
the connection. This optimization
trades off the latency for
resources.";
}
}
}
choice authentication-strategy {
mandatory true;
container symmetric-authentication {
leaf algorithm {
default hmac-sha1;
type enumeration {
enum hmac-md5;
enum hmac-sha1;
enum hmac-sha256;
}
}
leaf hmac-key {
mandatory true;
type string; // secret
}
}
container assymmetric-authentication {
leaf algorithm {
default rsa-sha1;
type enumeration {
enum rsa-sha1;
}
}
leaf assymetric-key {
mandatory true;
type string; // secret
}
}
}
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;
leaf host {
mandatory true;
type inet:host;
Watsen Expires November 13, 2011 [Page 11]
Internet-Draft Reverse Secure Shell (Reverse SSH) May 2011
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.";
}
}
}
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
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 {
Watsen Expires November 13, 2011 [Page 12]
Internet-Draft Reverse Secure Shell (Reverse SSH) May 2011
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 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
Watsen Expires November 13, 2011 [Page 13]
Internet-Draft Reverse Secure Shell (Reverse SSH) May 2011
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).
7. IANA Considerations
IANA is requested to assign a TCP port number which will be the
Watsen Expires November 13, 2011 [Page 14]
Internet-Draft Reverse Secure Shell (Reverse SSH) May 2011
default port for Reverse SSH connections as defined in this document.
8. References
8.1. 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.
[RFC3080] Rose, M., Ed., "The Blocks Extensible Exchange Protocol
Core", RFC 3080, March 2001.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
RFC 4231, December 2005.
[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.
[RFC4741] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
Watsen Expires November 13, 2011 [Page 15]
Internet-Draft Reverse Secure Shell (Reverse SSH) May 2011
Shell Authentication", RFC 6187, March 2011.
8.2. Informative References
[TR069] The Broadband Forum, "TR-069 Amendemnt 3, CPE WAN
Management Protocol", November 2010.
Author's Address
Kent Watsen
Juniper Networks
Email: kwatsen@juniper.net
Watsen Expires November 13, 2011 [Page 16]