Reverse SSH for NETCONF Call HomeJuniper Networkskwatsen@juniper.net
Operations
NETCONF Working Groupreverse-sshThis document 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 document 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 NETCONF channels the management
system wants to open.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
TCP connection on the Reverse SSH port, it starts the
SSH client protocol. As the SSH client, it MUST
authenticate the SSH server, by both identifying the
network element and verifying its SSH host key.Due to Reverse SSH having the network element
initiate the TCP connection, the management system
MAY identify the remote peer using the source IP
address of the TCP connection. However, identifying
the remote peer using the source IP address of the
TCP connection is NOT RECOMMENDED as it can only
work in networks that use known static addresses.To support network elements having dynamically-assigned
IP addresses, or deployed behind gateways that translate
their IP addresses (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 itself
be used as an identifier since each device has a statistically
unique host key. However, identifying the remote peer
using its host key directly is NOT RECOMMENDED as it
requires the host key to be manually verified the first
time the network element connects and anytime its host
key changes thereafter.Yet another option for identifying the network element
is for its host key to encode the network element's
identity, such as if the host key were a certificate.
This option enables the host key to change over time,
so long as it continues to encode the same identity,
but brings the next issue of how the management system
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 host key. 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 for the management system is for the
network element's manufacturer to sign the network-element's
host key with a common trusted key, such as a certificate
authority. Then, when the network-element is deployed,
the management system only needs to trust a single certificate,
which vouches for the authenticity of the various
network element host 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
is outside the scope of this document, but entails setting
what IP address a device should connect to and what SSH
host-key it should present. A complete YANG
model to configure Reverse SSH
is specified in 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 a 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-the-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
is 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
"netconf-ssh-ch". This port will be the default port for the
Reverse SSH for NETCONF Call Home protocol and will be used when the NETCONF server
is to initiate a connection to a NETCONF client using SSH.
Below is the registration template following the rules in
.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,
Radek Krejci, Alan Luchuk, Mouse, Russ Mundy, Tom Petch,
Peter Saint-Andre, Joe Touch, Sean Turner, Bert Wijnen.
Key words for use in RFCs to Indicate Requirement Levels
Harvard University
The Secure Shell (SSH) Protocol Assigned Numbers
SSH Communications Security Corp
Cisco Systems, Inc.
The Secure Shell (SSH) Protocol Architecture
SSH Communications Security Corp
Cisco Systems, Inc.
The Secure Shell (SSH) Authentication Protocol
SSH Communications Security Corp
Cisco Systems, Inc.
The Secure Shell (SSH) Transport Layer Protocol
SSH Communications Security Corp
Cisco Systems, Inc.
The Secure Shell (SSH) Connection Protocol
SSH Communications Security Corp
Cisco Systems, Inc.
YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)
Tail-f Systems
X.509v3 Certificates for Secure Shell Authentication
National Security Agency
Queensland University of Technology
NETCONF Configuration ProtocolJuniper NetworksTail-f SystemsJacobs UniversityBrocadeUsing the NETCONF Protocol over Secure Shell (SSH)Painless Security, LLCInternet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name
and Transport Protocol Port Number RegistryInternet Corporation for Assigned Names and NumbersNokia Research CenterUSC/ISIEricssonApple Inc.A YANG Data Model for NETCONF Server ConfigurationJuniper NetworksJacobs UniversityChanged title to "Reverse SSH for NETCONF Call Home"Removed statement on how other SSH channels might be used for other protocolsImproved language on how the management system, as the SSH client, MUST authenticate the SSH serverClarified that identifying the network element using source IP address is NOT RECOMMENDEDClarified that identifying the NE using simple certificate comparison is NOT RECOMMENDEDDevice Configuration section now more clearly states that the YANG model is out of scopeChange requested port name to "netconf-ssh-ch"General edits for grammer, capitalization, and spellingsUpdated Device Configuration section to reference
Added Applicability StatementRemoved references to ZeroConf / ZeroTouchClarified the protocol sectionAdded a section for identification and verificationRemoved the hmac-* family of algorithms