One document matched: draft-kwatsen-reverse-ssh-00.xml
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc symrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc ipr="trust200902" docName="draft-kwatsen-reverse-ssh-00">
<front>
<title>Reverse Secure Shell (Reverse SSH)</title>
<author initials="K.W." surname="Watsen" fullname="Kent Watsen">
<organization>Juniper Networks</organization>
<address>
<email>kwatsen@juniper.net</email>
</address>
</author>
<date month="May" year="2011"/>
<area>Security</area>
<workgroup>Secure Shell Working Group</workgroup>
<keyword>reverse-ssh</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Requirements Terminology">
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section title="Introduction">
<t>This memo presents a technique for a SSH (Secure Shell)
<xref target="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.</t>
<t>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.</t>
<t>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 <xref target="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.</t>
<t>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.</t>
<t>For initial deployment, Reverse SSH may be used as a
"call home" mechanism, similar to that provided by Broadband
Forum TR-069 <xref target="TR069"/>, but with the benefit of
not being bound to any particular protocol (SOAP over HTTP).</t>
<t>For on-going management, Reverse SSH may be used to
enable any of the following scenarios:
<list style="symbols">
<t>The device may be deployed behind a NAT-ing
device that doesn't provision an external address
and port to connect to.</t>
<t>The device may be deployed behind a firewall
that doesn't allow SSH access to the internal
network.</t>
<t>The device may be configured in
"stealth mode" with no open ports</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
<t>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 <xref target="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) <xref target="RFC3080"/>.</t>
<t>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.</t>
<t>This RFC additionally defines a YANG <xref target="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.</t>
<t>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.</t>
</section>
<section title="Protocol Overview">
<t>The Device's perspective
<list style="symbols">
<t>The device initiates a TCP connection to the application
on the IANA-assigned Reverse SSH port [TBD]</t>
<t>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.</t>
<t>The REVERSE-SSH-CONN-INFO message contains information
necessary for the application to identify the device and
authenticate it's SSH host-key</t>
</list>
</t>
<t>The Application's Perspective
<list style="symbols">
<t>The application listens for TCP connections on the
IANA-assigned Reverse SSH port</t>
<t>The application accepts an incoming TCP connection and
waits to receive the REVERSE-SSH-CONN-INFO message</t>
<t>The application processes the REVERSE-SSH-CONN-INFO message
by first asserting that its message header fields are
as expected</t>
<t>The application then uses the DEVICE-ID field to lookup the
device in some internal persistent datastore</t>
<t>The application uses a device-specific key found in its
datastore to authenticate the device's SSH host key contained
in the message</t>
<t>The application initiates the SSH client protocol using
the accepted TCP connection</t>
<t>The application authenticates the device's SSH host key
using one of the ones it just authenticated from the
REVERSE-SSH-CONN-INFO message</t>
<t>The application authenticates itself to the device using
previously configured authentication credentials</t>
</list>
</t>
</section>
<section title="Protocol">
<t>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:</t>
<figure>
<artwork>
string "REVERSE-SSH-CONN-INFO (v1)"
string device-id
uint32 host-key-info-count
string host-key-info[1..host-key-info-count]
</artwork>
</figure>
<t>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.</t>
<t>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
<xref target="RFC4253"/>).</t>
<t>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
<xref target="RFC4253"/> or x.509 from <xref target="RFC6187"/>
only need to list their name, whereas others will need to be
signed.</t>
<t>Format for the 'host-key-info' field:</t>
<figure>
<artwork>
string server-host-key-algorithm
..... algorithm-specific-data follow
</artwork>
</figure>
<t>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 <xref target="RFC4253"/>).</t>
<t>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.</t>
<t>Non certificate-based host key algorithms MUST encode
their algorithm-specific data as follows:</t>
<figure>
<artwork>
string host-key
string signature-algorithm
string signature
</artwork>
</figure>
<t>The "host-key" field is the algorithm-specific host key
(e.g. the ssh-rsa key) on the device.</t>
<t>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
<xref target="RFC4250"/>.</t>
<figure>
<preamble>Signature Algorithms (extensible)</preamble>
<artwork>
hmac-md5 [RFC2104]
hmac-sha1 [RFC2104]
rsa-sha1 [RFC3447] (Section 8.2)
hmac-sha256 [RFC4231]
</artwork>
</figure>
<t>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.</t>
<t>The "signature" field contains the "result" of the signature
algorithm applied to the host-key field.</t>
</section>
<section title="Device Configuration">
<t>For devices that support NETCONF, this section defines a
YANG <xref target="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.</t>
<t>While it's expected that NETCONF <xref target="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.</t>
<figure>
<preamble>Configuration Example</preamble>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(config.xml)
]]></artwork>
</figure>
<t><vspace blankLines='10'/></t>
<figure>
<preamble>The YANG Module</preamble>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(ietf-reverse-ssh@2011-04-26.yang)
]]></artwork>
</figure>
</section>
<section title="Security Considerations">
<t>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.</t>
<t>Despite section 4 of the SSH Transport Layer Protocol RFC
<xref target="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.</t>
<t>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".</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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).</t>
</section>
<section title="IANA Considerations">
<t>IANA is requested to assign a TCP port number which will be
the default port for Reverse SSH connections as defined in this
document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2104">
<front>
<title>
HMAC: Keyed-Hashing for Message Authentication
</title>
<author initials="H.K." surname="Krawczyk"
fullname="Hugo Krawczyk">
</author>
<author initials="M.B." surname="Bellare"
fullname="Mihir Bellare">
</author>
<author initials="R.C." surname="Centti"
fullname="Ran Centti">
</author>
<date month="February" year="1997"/>
</front>
<seriesInfo name="RFC" value="2104"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>
Key words for use in RFCs to Indicate Requirement Levels
</title>
<author initials="S.B." surname="Bradner"
fullname="Scott Bradner">
<organization>Harvard University</organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
</reference>
<reference anchor="RFC3080">
<front>
<title>The Blocks Extensible Exchange Protocol Core</title>
<author initials="M.R." surname="Rose"
fullname="Marshall Rose" role="editor">
</author>
<date month="March" year="2001" />
</front>
<seriesInfo name="RFC" value="3080" />
</reference>
<reference anchor="RFC3447">
<front>
<title>
Public-Key Cryptography Standards (PKCS) #1:
RSA Cryptography Specifications Version 2.1
</title>
<author initials="J.J." surname="Jonsson"
fullname="Jakob Jonsson">
<organization>
Philipps-Universitaet Marburg
</organization>
</author>
<author initials="B.K." surname="Kaliski"
fullname="Burt Kaliski">
<organization>RSA Laboratories</organization>
</author>
<date month="February" year="2003" />
</front>
<seriesInfo name="RFC" value="3447" />
</reference>
<reference anchor="RFC4231">
<front>
<title>
Identifiers and Test Vectors for HMAC-SHA-224,
HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512
</title>
<author initials="M.N." surname="Nystrom"
fullname="Magnus Nystrom">
<organization>RSA Security</organization>
</author>
<date month="December" year="2005" />
</front>
<seriesInfo name="RFC" value="4231" />
</reference>
<reference anchor="RFC4250">
<front>
<title>
The Secure Shell (SSH) Protocol Assigned Numbers
</title>
<author initials="S.L." surname="Lehtinen"
fullname="Sami Lehtinen">
<organization>
SSH Communications Security Corp
</organization>
</author>
<author initials="C.L." surname="Lonvick"
fullname="Chris Lonvick" role="editor">
<organization>
Cisco Systems, Inc.
</organization>
</author>
<date month="December" year="2005" />
</front>
<seriesInfo name="RFC" value="4250" />
</reference>
<reference anchor="RFC4251">
<front>
<title>
The Secure Shell (SSH) Protocol Architecture
</title>
<author initials="T.Y." surname="Ylonen"
fullname="Tatu Ylonen">
<organization>
SSH Communications Security Corp
</organization>
</author>
<author initials="C.L." surname="Lonvick"
fullname="Chris Lonvick" role="editor">
<organization>
Cisco Systems, Inc.
</organization>
</author>
<date month="January" year="2006" />
</front>
<seriesInfo name="RFC" value="4251" />
</reference>
<reference anchor="RFC4252">
<front>
<title>
The Secure Shell (SSH) Authentication Protocol
</title>
<author initials="T.Y." surname="Ylonen"
fullname="Tatu Ylonen">
<organization>
SSH Communications Security Corp
</organization>
</author>
<author initials="C.L." surname="Lonvick"
fullname="Chris Lonvick" role="editor">
<organization>
Cisco Systems, Inc.
</organization>
</author>
<date month="January" year="2006" />
</front>
<seriesInfo name="RFC" value="4252" />
</reference>
<reference anchor="RFC4253">
<front>
<title>
The Secure Shell (SSH) Transport Layer Protocol
</title>
<author initials="T.Y." surname="Ylonen"
fullname="Tatu Ylonen">
<organization>
SSH Communications Security Corp
</organization>
</author>
<author initials="C.L." surname="Lonvick"
fullname="Chris Lonvick" role="editor">
<organization>
Cisco Systems, Inc.
</organization>
</author>
<date month="January" year="2006" />
</front>
<seriesInfo name="RFC" value="4253" />
</reference>
<reference anchor="RFC4254">
<front>
<title>
The Secure Shell (SSH) Connection Protocol
</title>
<author initials="T.Y." surname="Ylonen"
fullname="Tatu Ylonen">
<organization>
SSH Communications Security Corp
</organization>
</author>
<author initials="C.L." surname="Lonvick"
fullname="Chris Lonvick" role="editor">
<organization>
Cisco Systems, Inc.
</organization>
</author>
<date month="January" year="2006" />
</front>
<seriesInfo name="RFC" value="4254" />
</reference>
<reference anchor="RFC4741">
<front>
<title>NETCONF Configuration Protocol</title>
<author initials="R.E." surname="Enns"
fullname="Rob Enns" role="editor">
<organization>Juniper Networks</organization>
</author>
<date month="December" year="2006" />
</front>
<seriesInfo name="RFC" value="4741" />
</reference>
<reference anchor="RFC6020">
<front>
<title>
YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)
</title>
<author initials="M.B." surname="Bjorklund"
fullname="Martin Bjorklund" role="editor">
<organization>Tail-f Systems</organization>
</author>
<date month="October" year="2010" />
</front>
<seriesInfo name="RFC" value="6020" />
</reference>
<reference anchor="RFC6187">
<front>
<title>
X.509v3 Certificates for Secure Shell Authentication
</title>
<author initials="K.I." surname="Igoe"
fullname="Kevin Igoe">
<organization>National Security Agency</organization>
</author>
<author initials="D.S." surname="Stebila"
fullname="Douglas Stebila">
<organization>
Queensland University of Technology
</organization>
</author>
<date month="March" year="2011" />
</front>
<seriesInfo name="RFC" value="6187" />
</reference>
</references>
<references title="Informative References">
<reference anchor="TR069">
<front>
<title>
TR-069 Amendemnt 3, CPE WAN Management Protocol
</title>
<author surname="The Broadband Forum"
fullname="The Broadband Forum"/>
<date month="November" year="2010" />
</front>
<format type="PDF" target="http://www.broadband-forum.org/technical/download/TR-069_Amendment-3.pdf"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:00:12 |