draft-ietf-netconf-reverse-ssh-00.txt   draft-ietf-netconf-reverse-ssh-01.txt 
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Updates: 4253 (if approved) June 18, 2013 Updates: 4253 (if approved) June 19, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: December 20, 2013 Expires: December 21, 2013
Reverse Secure Shell (Reverse SSH) Reverse Secure Shell (Reverse SSH)
draft-ietf-netconf-reverse-ssh-00 draft-ietf-netconf-reverse-ssh-01
Abstract Abstract
This memo presents a technique for a NETCONF server to initiate a SSH This memo presents a technique for a NETCONF server to initiate a SSH
connection to a NETCONF client. This is accomplished by the NETCONF connection to a NETCONF client. This is accomplished by the NETCONF
client listening on IANA-assigned TCP port XXX and starting the SSH client listening on IANA-assigned TCP port YYYY and starting the SSH
client protocol immediately after accepting a TCP connection on it. client protocol immediately after accepting a TCP connection on it.
This role-reversal is necessary as the NETCONF server must also be 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- the SSH Server, in order for the NETCONF client to open the IANA-
assigned SSH subsystem "netconf". assigned SSH subsystem "netconf".
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 20, 2013. This Internet-Draft will expire on December 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements Terminology . . . . . . . . . . . . . . . . . . 2 1. Requirements Terminology . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Benefits to Device Management . . . . . . . . . . . . . . . . 2 3. Benefits to Device Management . . . . . . . . . . . . . . . . 2
4. The Reverse SSH Protocol . . . . . . . . . . . . . . . . . . 4 4. The Reverse SSH Protocol . . . . . . . . . . . . . . . . . . 3
5. The hmac-* Public Key Algorithms . . . . . . . . . . . . . . 4 5. Device Configuration . . . . . . . . . . . . . . . . . . . . 4
6. Device Configuration . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Normative References . . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . 14
1. Requirements Terminology 1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introduction 2. Introduction
This memo presents a technique for a NETCONF [RFC6241] server to This memo presents a technique for a NETCONF [RFC6241] server to
initiate a Secure Shell (SSH) [RFC4251] connection to a NETCONF initiate a Secure Shell (SSH) [RFC4251] connection to a NETCONF
client. This is accomplished by the NETCONF client listening on client. This is accomplished by the NETCONF client listening on
IANA-assigned TCP port XXX and starting the SSH client protocol IANA-assigned TCP port YYYY and starting the SSH client protocol
immediately after accepting a TCP connection on it. This role- immediately after accepting a TCP connection on it. This role-
reversal is necessary as the NETCONF server must also be the SSH 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 Server, in order for the NETCONF client to open the IANA-assigned SSH
subsystem "netconf" [RFC6242]. subsystem "netconf" [RFC6242].
While the motivation for this work is for the NETCONF protocol, the 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 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. 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" 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. and the port the remote peer listens on is the Reverse SSH port.
skipping to change at page 4, line 10 skipping to change at page 3, line 50
to support. For instance, the application may "pin up" a channel for to support. For instance, the application may "pin up" a channel for
each distinct type of asynchronous notification the managed device each distinct type of asynchronous notification the managed device
supports (logs, traps, backups, etc.) and dynamically open/close supports (logs, traps, backups, etc.) and dynamically open/close
channels as needed by its runtime. channels as needed by its runtime.
4. The Reverse SSH Protocol 4. The Reverse SSH Protocol
The NETCONF server's perspective The NETCONF server's perspective
o The NETCONF server initiates a TCP connection to the NETCONF o The NETCONF server initiates a TCP connection to the NETCONF
client on the IANA-assigned Reverse SSH port XXX. client on the IANA-assigned Reverse SSH port YYYY.
o Immediately after the TCP session starts, the NETCONF server o Immediately after the TCP session starts, the NETCONF server
starts the SSH server protocol using the accepted TCP connection. starts the SSH server protocol using the accepted TCP connection.
That is, the NETCONF Server sends its SSH host key during the SSH That is, the NETCONF Server sends its SSH host key during the SSH
key exchange. key exchange.
The NETCONF client's perspective The NETCONF client's perspective
o The NETCONF client listens for TCP connections on the IANA- o The NETCONF client listens for TCP connections on the IANA-
assigned SSH port XXX. assigned SSH port YYYY.
o The NETCONF client accepts an incoming TCP connection and o The NETCONF client accepts an incoming TCP connection and
immediately starts the SSH client protocol. That is, the NETCONF immediately starts the SSH client protocol. That is, the NETCONF
client will need to authenticate its peer's SSH host key during client will need to authenticate its peer's SSH host key during
the SSH key exchange. the SSH key exchange.
This document updates the SSH Transport Layer Protocol [RFC4253] only This document updates the SSH Transport Layer Protocol [RFC4253] only
by removing the restriction in Section 4 (Connection Setup) of by removing the restriction in Section 4 (Connection Setup) of
[RFC4252] that the SSH Client must initiate the transport connection. [RFC4252] that the SSH Client must initiate the transport connection.
Security implications related to this change are discussed in the Security implications related to this change are discussed in the
Security Considerations (Section 7) section. Security Considerations (Section 6) section.
For first-time connections, in order for the NETCONF client to For first-time connections, in order for the NETCONF client to
authenticate the NETCONF server, a public host key algorithm that authenticate the NETCONF server, a public host key algorithm that
certifies the the NETCONF server's identity and host-key SHOULD be certifies the the NETCONF server's identity and host-key SHOULD be
used. Examples of suitable public host key algorithms are the used. Examples of suitable public host key algorithms are the
x509v3-* algorithms defined in [RFC6187] and the the hmac-* x509v3-* algorithms defined in [RFC6187].
algorithms defined in the The hmac-* Public Key Algorithms
(Section 5) section below.
5. The hmac-* Public Key Algorithms
This section defines a family of public host key algorithms that can
be used to both identify the SSH server and enable its host key to be
automatically authenticated.
The algorithms presented in this section rely on a symmetric HMAC key
to convey trust. This is in contrast to the PKI based authentication
model used by the x.509 based public host key algorithms ([RFC6187]).
An HMAC key enables Reverse SSH to be used in deployments where it's
not possible for a x.509 Certificate Authority to sign the managed
device's certificate in time, as it only requires a password to be
provided.
The HMAC-based public host key algorithms defined in this
specification mirror those defined in [RFC6187]. These host-keys are
to be treated the same way as in [RFC6187], except that the peer
authenticates the host key via an HMAC, instead of PKIX. The
algorithms defined by this specification are:
+-----------------------+
| Algorithm |
+-----------------------+
| hmac-ssh-dss |
| hmac-ssh-rsa |
| hmac-rsa2048-sha256 |
| hmac-ecdsa-sha2-* |
+-----------------------+
Regardless of which underlying host key is used, the format of the
hmac-* based public key is as follows:
+---------------------+
| string server-id |
| string host-key |
| string hmac |
+---------------------+
The "server-id" field encodes a user-configured unique identifier for
the SSH Server, or its Serial Number if none provided. This field is
necessary as the SSH client MAY not otherwise be identifiable. For
instance, the SSH server may be "calling home" for the first time or
have a dynamically assigned address (DHCP, NAT, etc.).
The "host-key" field is the SSH Server's corresponding SSH host key.
For instance, if the "hmac-ssh-rsa" public key was negotiated during
key exchange, this field would encode the "ssh-rsa" host key.
The "hmac" field is the value produced using the MAC algorithm
negotiated during key exchange over the selected host key and a user-
configured HMAC key. [[RFC2104]]
6. Device Configuration 5. Device Configuration
For devices supporting NETCONF, this section defines a YANG [RFC6020] For devices supporting NETCONF, this section defines a YANG [RFC6020]
module to configure Reverse SSH on the device. For devices that do module to configure Reverse SSH on the device. For devices that do
not support NETCONF, this section illustrates what its configuration not support NETCONF, this section illustrates what its configuration
data model SHOULD include. data model SHOULD include.
This YANG module enables a NETCONF client to generically manage a This YANG module enables a NETCONF client to generically manage a
NETCONF server's Reverse SSH configuration. Key aspects of this YANG NETCONF server's Reverse SSH configuration. Key aspects of this YANG
module include support for more than one application, more than one module include support for more than one application, more than one
server per application, and a reconnection strategy. server per application, and a reconnection strategy.
skipping to change at page 12, line 4 skipping to change at page 10, line 31
units seconds; units seconds;
default 5; default 5;
description description
"time delay between connection attempts"; "time delay between connection attempts";
} }
leaf count-max { leaf count-max {
type uint8; type uint8;
default 3; default 3;
description description
"num times try to connect to a server"; "num times try to connect to a server";
} }
} }
} }
} }
} }
} }
7. Security Considerations 6. Security Considerations
This RFC deviates from standard SSH protocol usage by allowing the This RFC deviates from standard SSH protocol usage by allowing the
SSH server to initiate the TCP connection. This conflicts with SSH server to initiate the TCP connection. This conflicts with
section 4 of the SSH Transport Layer Protocol RFC [RFC4253], which section 4 of the SSH Transport Layer Protocol RFC [RFC4253], which
states "The client initiates the connection". However this statement states "The client initiates the connection". However this statement
is made without rationalization and it's not clear how it impacts the is made without rationalization and it's not clear how it impacts the
security of the protocol, so this section analyzes the security security of the protocol, so this section analyzes the security
offered by the having the client initiate the connection. offered by the having the client initiate the connection.
First, assuming the SSH server is not using a public host key First, assuming the SSH server is not using a public host key
skipping to change at page 13, line 22 skipping to change at page 11, line 49
a form of identity. A potential concern with using a serial number 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 is that the SSH protocol passes the SSH server's host-key in the
clear and many times serial numbers encode revealing information clear and many times serial numbers encode revealing information
about the device, such as what kind of device it is and when it was 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 manufactured. While there is little security in trying to hide this
information from an attacker, it is understood that some deployments information from an attacker, it is understood that some deployments
may want to keep this information private. If this is a concern, may want to keep this information private. If this is a concern,
deployments MAY consider using instead a hash of the device's serial deployments MAY consider using instead a hash of the device's serial
number or an application-specified unique identifier. number or an application-specified unique identifier.
The HMAC-* family of public host key algorithms defined in this RFC An attacker could DoS the application by having it to perform
take a hmac-key. The length of the hmac-key SHOULD NOT be less than computationally expensive operations, before deducing that the
the output length of the associated hash function, as discussed in attacker doesn't posses a valid key. This is no different than any
Section 3 (Keys) in [RFC2104]. The associated hash function for each secured service and all common precautions apply (e.g. blacklisting
public host key algorithm is as follows: the source address after a set number of unsuccessful login
attempts).
+-----------------------+------------------------------+
| Algorithm | Hash Function(s) |
+-----------------------+------------------------------+
| hmac-ssh-dss | SHA-1 |
| hmac-ssh-rsa | SHA-1 |
| hmac-rsa2048-sha256 | SHA-256 |
| hmac-ecdsa-sha2-* | SHA-256, SHA-384, or SHA-512 |
+-----------------------+------------------------------+
Note: for the Elliptical Curve algorithms, the hash function
selection is defined by Section 6.2.1 in [RFC5656].
The output length for each of these hash functions is as follows:
+---------------+-----------------------+
| Hash Function | Output Length (bytes) |
+---------------+-----------------------+
| SHA-1 | 20 |
| SHA-256 | 32 |
| SHA-384 | 48 |
| SHA-512 | 64 |
+---------------+-----------------------+
The hmac-* public host key algorithms require the application consume
the <server-id> field without being able to first verify that it is
the value the managed device sent. The application must use the
server-id value to lookup the managed device's record in a local
datastore in order to obtain the HMAC-key needed to authenticate the
HMAC. The application must be sure to process the server-id
carefully as it may have been purposely encoded to illicit unexpected
behaviour.
An attacker could DoS the application using valid "server-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).
8. IANA Considerations
Consistent with Section 8 of [[RFC4251]] and Section 4.6 of
[[RFC4250]], this document makes the following registrations in the
Public Key Algorithm Names registry:
o The SSH public key algorithm "hmac-ssh-dss".
o The SSH public key algorithm "hmac-ssh-rsa".
o The SSH public key algorithm "hmac-rsa2048-sha256".
o The family of SSH public key algorithm names beginning with "hmac- 7. IANA Considerations
ecdsa-sha2-" and not containing the at-sign ('@').
This document requests that IANA assigns a TCP port number in the This document requests that IANA assigns a TCP port number in the
"Registered Port Numbers" range with the service name "reverse-ssh". "Registered Port Numbers" range with the service name "reverse-ssh".
This port will be the default port for the Reverse SSH protocol and 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 will be used when the NETCONF server needs to initiate a connection
to a NETCONF client using SSH. Below is the registration template to a NETCONF client using SSH. Below is the registration template
following the rules in [RFC6335]. following the rules in [RFC6335].
Service Name: reverse-ssh Service Name: reverse-ssh
Transport Protocol(s): TCP Transport Protocol(s): TCP
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org> Contact: IETF Chair <chair@ietf.org>
Description: Reverse SSH (call home) Description: Reverse SSH (call home)
Reference: RFC XXXX Reference: RFC XXXX
Port Number: YYYY Port Number: YYYY
9. Normative References 8. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Centti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Centti, "HMAC: Keyed-
Hashing for Message Authentication ", RFC 2104, February Hashing for Message Authentication ", RFC 2104, February
1997. 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels ", BCP 14, RFC 2119, March 1997. Requirement Levels ", BCP 14, RFC 2119, March 1997.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers ", RFC 4250, December 2005. Protocol Assigned Numbers ", RFC 4250, December 2005.
skipping to change at page 15, line 27 skipping to change at page 12, line 49
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol ", RFC 4252, January 2006. Authentication Protocol ", RFC 4252, January 2006.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol ", RFC 4253, January 2006. Transport Layer Protocol ", RFC 4253, January 2006.
[RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Connection Protocol ", RFC 4254, January 2006. Connection Protocol ", RFC 4254, January 2006.
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm
Integration in the Secure Shell Transport Layer ", RFC
5656, December 2009.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF) ", RFC 6020, the Network Configuration Protocol (NETCONF) ", RFC 6020,
October 2010. October 2010.
[RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
Shell Authentication ", RFC 6187, March 2011. Shell Authentication ", RFC 6187, March 2011.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "NETCONF Configuration Protocol", RFC and A. Bierman, Ed., "NETCONF Configuration Protocol", RFC
6241, June 2011. 6241, June 2011.
 End of changes. 18 change blocks. 
136 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/