idnits 2.17.1
draft-kwatsen-reverse-ssh-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but
does not include the phrase in its RFC 2119 key words list.
-- The document date (June 8, 2011) is 4707 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFCXXXX' is mentioned on line 179, but not defined
== Unused Reference: 'RFC2104' is defined on line 595, but no explicit
reference was found in the text
== Unused Reference: 'RFC3447' is defined on line 605, but no explicit
reference was found in the text
== Unused Reference: 'RFC4231' is defined on line 609, but no explicit
reference was found in the text
== Unused Reference: 'RFC4250' is defined on line 613, but no explicit
reference was found in the text
== Unused Reference: 'RFC4252' is defined on line 619, but no explicit
reference was found in the text
== Unused Reference: 'RFC6125' is defined on line 635, but no explicit
reference was found in the text
** Downref: Normative reference to an Informational RFC: RFC 2104
** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017)
** Obsolete normative reference: RFC 4741 (Obsoleted by RFC 6241)
** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525)
Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Secure Shell Working Group K. Watsen
3 Internet-Draft Juniper Networks
4 Expires: December 10, 2011 June 8, 2011
6 Reverse Secure Shell (Reverse SSH)
7 draft-kwatsen-reverse-ssh-01
9 Abstract
11 This memo presents a technique for a SSH (Secure Shell) server to
12 initiate the underlying TCP connection to the SSH client. This role
13 reversal is necessary in cases where the SSH client would otherwise
14 be unable to initiate an SSH connection to the SSH server, such as a
15 device "calling home" on its first boot.
17 Status of this Memo
19 This Internet-Draft is submitted in full conformance with the
20 provisions of BCP 78 and BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF). Note that other groups may also distribute
24 working documents as Internet-Drafts. The list of current Internet-
25 Drafts is at http://datatracker.ietf.org/drafts/current/.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 This Internet-Draft will expire on December 10, 2011.
34 Copyright Notice
36 Copyright (c) 2011 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (http://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Simplified BSD License text as described in Section 4.e of
46 the Trust Legal Provisions and are provided without warranty as
47 described in the Simplified BSD License.
49 1. Requirements Terminology
51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
53 document are to be interpreted as described in RFC 2119 [RFC2119].
55 2. Introduction
57 This memo presents a technique for a SSH (Secure Shell) [RFC4251]
58 server to initiate the underlying TCP connection to the SSH client.
59 This role reversal is necessary in cases where the SSH client would
60 otherwise be unable to initiate an SSH connection to the SSH server,
61 such as a device "calling home" on its first boot.
63 This document uses the terms "Reverse SSH client" and "Reverse SSH
64 server" in order to reflect the role of each peer. The Reverse SSH
65 client is the peer that initiates the TCP connection and then starts
66 the SSH server protocol. The Reverse SSH server is the peer that
67 listens for and accepts TCP connections and then starts the SSH
68 client protocol.
70 This RFC modifies the SSH protocol in two ways:
72 o Removes the restriction that the SSH Client must initiate the TCP
73 connection.
75 o Defines the "hmac-*" family of public key algorithms.
77 This RFC additionally defines a YANG [RFC6020] module for the
78 configuration of the Reverse SSH client running on a device.
80 3. Benefits to Device Management
82 The SSH protocol is nearly ubiquitous for device management, as it is
83 the transport for the command-line applications `ssh`, `scp`, and
84 `sftp` and the required transport for the NETCONF protocol [RFC4741].
85 However, in all these cases, the device expects to be the SSH server
86 so that it can authenticate the user, apply security credentials,
87 enable SSH channels to be opened, and so on. Reverse SSH allows the
88 device to always be the SSH server regardless of which peer initiates
89 the underlying TCP connection.
91 Reverse SSH is useful for both initial deployment and on-going device
92 management. Use of Reverse SSH for initial deployment is independent
93 of its use for on-going management.
95 For initial deployment, Reverse SSH may be used as a "call home"
96 mechanism, similar to that provided by Broadband Forum TR-069
97 [TR069], but with the benefit of not being bound to any particular
98 protocol (SOAP over HTTP).
100 For on-going management, Reverse SSH may be used to enable any of the
101 following scenarios:
103 o The device may be deployed behind a NAT-ing device that doesn't
104 provision an external address and port to connect to.
106 o The device may be deployed behind a firewall that doesn't allow
107 SSH access to the internal network.
109 o The device may be configured in "stealth mode" with no open ports
111 o The device may access the network in a way that dynamically
112 assigns it an IP address and is not configured to use a service to
113 register its dynamically-assigned IP address to a well-known
114 domain name.
116 o The operator prefers to have one open-port to secure in the data
117 center, rather than have an open port on each device in the
118 network.
120 One key benefit of using SSH as the transport protocol for Reverse
121 SSH is its ability to multiplex an unspecified number of
122 independently flow-controlled TCP sessions on top of a single
123 encrypted tunnel [RFC4254]. This feature is valuable as the device
124 only needs to be configured to initiate a single Reverse SSH
125 connection regardless the number the TCP-based protocols the
126 application wishes to support. For instance, the application may
127 "pin up" a channel for each distinct type of asynchronous
128 notification the device supports (logs, traps, backups, etc.) and
129 dynamically open/close channels as needed by its runtime. Lastly,
130 using SSH channels has been found to be more straightforward and
131 supported than using other multiplexing protocols such as Block
132 Extensible Exchange Protocol (BEEP) [RFC3080].
134 4. Protocol Overview
136 The Reverse SSH client's perspective
138 o The Reverse SSH client initiates a TCP connection to the Reverse
139 SSH server on the IANA-assigned SSH port (port 22)
141 o Immediately after the TCP session starts, the Reverse SSH client
142 starts the SSH server protocol using the accepted TCP connection.
143 That is, the Reverse SSH client sends it's SSH host key during the
144 SSH key exchange.
146 The Reverse SSH server's perspective
148 o The Reverse SSH server listens for TCP connections on the IANA-
149 assigned SSH port (port 22)
151 o The Reverse SSH server accepts an incoming TCP connection and
152 immeditately starts the SSH client protocol. That is, the Reverse
153 SSH server will need to authenticate its peer's SSH host key
154 during the SSH key exchange.
156 Note: in order to enable the Reverse SSH server to identify the
157 Reverse SSH client and automatically authenticate its SSH host key,
158 each peer SHOULD only advertise support for one of the following host
159 key algorithms:
161 +-----------------------+-----------+
162 | Algorithm | Reference |
163 +-----------------------+-----------+
164 | | |
165 | x509v3-ssh-dss | [RFC6187] |
166 | | |
167 | x509v3-ssh-rsa | [RFC6187] |
168 | | |
169 | x509v3-rsa2048-sha256 | [RFC6187] |
170 | | |
171 | x509v3-ecdsa-sha2-* | [RFC6187] |
172 | | |
173 | hmac-ssh-dss | [RFCXXXX] |
174 | | |
175 | hmac-ssh-rsa | [RFCXXXX] |
176 | | |
177 | hmac-rsa2048-sha256 | [RFCXXXX] |
178 | | |
179 | hmac-ecdsa-sha2-* | [RFCXXXX] |
180 | | |
181 +-----------------------+-----------+
183 5. The hmac-* Public Key Algorithms
185 This section defines a family of public host key algorithms that can
186 be used to both identify the SSH server and enable its host key to be
187 automaticaly authenticated.
189 The algorithms presented in this section rely on a symmetric HMAC key
190 to convey trust. This is in contrast to the PKI based authentication
191 model used by the x.509 based public key algorithms [[RFC6187]].
192 Using an HMAC key, which can be interactively provided to the SSH
193 Server, enables Reverse SSH to be used in deployments where it's not
194 possible for a x.509 Certificate Authority to sign the device's
195 certificate in time. For instance, when the device is "calling home"
196 the first time in order to receive its full configuration.
198 The HMAC-based host keys defined in this specification mirror those
199 defined in [RFC6187]. These host-keys are to be treated the same way
200 as in [RFC6187], except that the the peer authenticates the host key
201 via an HMAC, instead of PKIX.
203 Regardless of which underlying host key is used, the format of the
204 hmac-* based public key is as follows:
206 string server-id
207 string host-key
208 string hmac
210 The "server-id" field encodes a user-configured unique identifier for
211 the SSH Server. This field is necessary as the Reverse SSH client
212 MAY not be identifiable from its TCP session's source address. For
213 instance, the Reverse SSH client may be "calling home" for the first
214 time or have a dynamically assigned address (DHCP, NAT, etc.).
216 The "host-key" field is the SSH Server's corresponding SSH host key.
217 For instance, if the "hmac-ssh-rsa" public key was negotiated during
218 key exchange, this field would encode the "ssh-rsa" host key.
220 The "hmac" field is the value produced using the MAC algorithm
221 negotiated during key exchange over the selected host key and a user-
222 configured HMAC key [[RFC2104]]
224 6. Device Configuration
226 For devices supporting NETCONF [RFC4741], this section defines a YANG
227 [RFC6020] module to configure the Reverse SSH client on the device.
228 For devices that do not support NETCONF, this section illustrates
229 what its configuration data model SHOULD include.
231 This YANG module enables a NETCONF client to generically manage the
232 NETCONF server's Reverse SSH client configuration without needing to
233 understand a device-specific data-model. This is important as a
234 normalized configuration is necessary to bootstrap multi-vendor
235 devices for their "initial deployment". The definition of a YANG
236 module also ensures that key features are enabled such as supporting
237 more than one application, more than one server per application, and
238 the definition of a reconnection strategy.
240 This RFC does not attempt to define any strategy for how an initial
241 deployment might obtain its bootstrapping "call home" configuration
242 (address to connect to, signature algorithm to use, authentication
243 credentials to use, etc.). That said, implementations may consider
244 use of a DHCP server or a USB pen drive as viable options for these
245 kinds of deployments.
247 Configuration Example
249
250
251
252
253 config-mgr
254
255 This entry requests the device to periodically
256 connect to the Configuration Manager application
257
258 9876436534
259
260 5
261 20
262
263
264 hmac-sha1
265 secret
266
267
268
269 config-mgr1.acme.com
270 7022
271
272
273 config-mgr2.acme.com
274 7022
275
276
277
278 5
279 3
280
281
282 last-connected
283 10
284 4
285
286
287
288 log-monitor
289
290 This entry requests the device to mantain a
291 persistent connection to the Log Monitoring
292 application
293
294 device-23.53432
295
296
297 rsa-sha1
298 secret
299
300
301
302 log-mon1.acme.com
303 7514
304
305
306 log-monitor2.acme.com
307 7514
308
309
310
311 5
312 3
313
314
315 last-connected
316 10
317 4
318
319
321
322
323
324 The YANG Module
326 module ietf-reverse-ssh {
328 namespace "urn:ietf:params:xml:ns:yang:ietf-reverse-ssh";
330 prefix "rssh";
332 import ietf-inet-types { prefix inet; }
334 organization
335 "IETF NETCONF (Network Configuration Protocol) Working Group";
337 contact
338 "WG Web:
339 WG List:
341 WG Chair: Bert Wijnen
342
344 WG Chair: Mehmet Ersue
345
347 Editor: Kent Watsen
348 ";
350 revision 2011-04-26 {
351 description "Initial conception";
352 reference "RFC XXXX: Reverse SSH";
353 }
354 // RFC Ed.: replace XXXX with actual
355 // RFC number and remove this note
357 container reverse-ssh {
358 container applications {
359 description
360 "All the application that the device
361 initiates Reverse SSH connections to";
362 list application {
363 key name;
364 min-elements 1;
365 leaf name {
366 mandatory true;
367 type string {
368 length 1..32;
369 }
370 description
371 "The name of the specific application";
372 }
373 leaf description {
374 type string;
375 description
376 "An optional description for the application";
377 }
378 leaf device-id {
379 type string {
380 length 1..32;
381 }
382 description
383 "The identifier the device uses to
384 identify itself to this application. If
385 not specified, the device will use it's
386 serial-number (not recommneded)";
387 }
388 choice connection-type {
389 description "Indicates the application's
390 preference for how the device's
391 connection is maintained.";
392 default persistent-connection;
393 leaf persistent-connection {
394 type empty;
395 }
396 container periodic-connection {
397 leaf interval-mins {
398 type uint8;
399 default 5;
400 units minutes;
401 description
402 "The amount of unconnected time the
403 device will wait until establishing
404 a connection just in case the
405 application has some data pending
406 to send it. The device MAY
407 establish a connection before this
408 time if it has data is needs to
409 send to the device.";
410 }
411 leaf linger-secs {
412 type uint8;
413 default 30;
414 units seconds;
415 description
416 "The amount of time it should wait
417 after last receiving from or sending
418 data to the device before closing
419 the connection. This optimization
420 trades off the latency for
421 resources.";
422 }
423 }
424 }
425 choice authentication-strategy {
426 mandatory true;
427 container symmetric-authentication {
428 leaf algorithm {
429 default hmac-sha1;
430 type enumeration {
431 enum hmac-md5;
432 enum hmac-sha1;
433 enum hmac-sha256;
434 }
435 }
436 leaf hmac-key {
437 mandatory true;
438 type string; // secret
439 }
440 }
441 container assymmetric-authentication {
442 leaf algorithm {
443 default rsa-sha1;
444 type enumeration {
445 enum rsa-sha1;
446 }
447 }
448 leaf assymetric-key {
449 mandatory true;
450 type string; // secret
451 }
452 }
453 }
454 container servers {
455 description
456 "An ordered listing of the application's
457 servers that the device should attempt
458 connecting to.";
459 list server {
460 key host;
461 min-elements 1;
462 ordered-by user;
463 leaf host {
464 mandatory true;
465 type inet:host;
466 description
467 "IP address or domain-name for
468 the server";
469 }
470 leaf port {
471 type inet:port-number;
472 description
473 "The IP port for this server.
474 The device will use the
475 IANA-assigned port if not
476 specified.";
477 }
478 }
479 }
480 container keep-alive-strategy {
481 leaf interval-secs {
482 type uint8;
483 units seconds;
484 default 15;
485 description
486 "Sets a timeout interval in seconds after
487 which if no data has been received from
488 the client, a message will be sent to
489 request a response from the SSH client.
490 A value of '0' indicates that no messages
491 should be sent.";
492 }
493 leaf count-max {
494 type uint8;
495 default 3;
496 description
497 "Sets the number of keep alive messages
498 that may be sent without receiving any
499 response from the SSH client before
500 assuming the SSH client is no longer
501 alive. If this threshold is reached
502 the device will disconnect the SSH
503 session. The keep alive interval timer
504 is reset after each transmission. Thus,
505 an unresponsive SSH client will be
506 disconnected after approximately
507 'count-max * interval-secs' seconds.";
508 }
509 }
510 container reconnect-strategy {
511 leaf start-with {
512 default first-listed;
513 type enumeration {
514 enum first-listed;
515 enum last-connected;
516 }
517 }
518 leaf interval-secs {
519 type uint8;
520 units seconds;
521 default 5;
522 description
523 "time delay between connection attempts";
524 }
525 leaf count-max {
526 type uint8;
527 default 3;
528 description
529 "num times try to connect to a server";
530 }
531 }
532 }
533 }
535 }
536 }
538 7. Security Considerations
540 This RFC deviates from standard SSH protocol usage by allowing the
541 SSH server to initiate the TCP connection. This conflicts with
542 section 4 of the SSH Transport Layer Protocol RFC [RFC4253], which
543 states "The client initiates the connection". This role reversal,
544 however, does not alter the fundamentals for how SSH client and SSH
545 server authenticate eachother, and thus doesn't affect the security
546 of the solution.
548 This RFC defines new HMAC-based public key algorithms.
549 Implementations SHOULD use a MAC algorithm and an HMAC-key such that
550 the cryptographic strength of the HMAC is not less than the strength
551 of the host key it vouches for.
553 The HMAC-based public key algorithms specify a "server-id" field that
554 is passed in the clear. The server-id field SHOULD NOT contain a
555 value that might provide an observer any undue information about the
556 device. Specifically, it is NOT RECOMMENDED to use the device's
557 serial number for its "server-id", as it may reveal the device's
558 model-number and/or manufacturing date.
560 The hmac-* public key algorithms require the application consume the
561 server-id field without being able to first verify that it is the
562 value the device sent. The application must use the server-id value
563 to lookup the device's record in a local datastore in order to obtain
564 the HMAC-key needed to authenticate the HMAC. The application must
565 be sure to process the server-id carefully as it may have been
566 purposely encoded to illicit unexpected behaviour.
568 An attacker could DoS the application using valid "server-id" values,
569 forcing the application to perform computationally expensive
570 operations, only to deduce that the attacker doesn't posses a valid
571 key. This is no different than any secured service and all common
572 precautions apply (e.g. blacklisting the source address after a set
573 number of unsuccessful login attempts).
575 8. IANA Considerations
577 Consistent with Section 8 of [[RFC4251]] and Section 4.6 of
578 [[RFC4250]], this document makes the following registrations:
580 In the Public Key Algorithm Names registry:
582 o The SSH public key algorithm "hmac-ssh-dss".
584 o The SSH public key algorithm "hmac-ssh-rsa".
586 o The SSH public key algorithm "hmac-rsa2048-sha256".
588 o The family of SSH public key algorithm names beginning with "hmac-
589 ecdsa-sha2-" and not containing the at-sign ('@').
591 9. References
593 9.1. Normative References
595 [RFC2104] Krawczyk, H., Bellare, M., and R. Centti, "HMAC: Keyed-
596 Hashing for Message Authentication", RFC 2104,
597 February 1997.
599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
600 Requirement Levels", BCP 14, RFC 2119, March 1997.
602 [RFC3080] Rose, M., Ed., "The Blocks Extensible Exchange Protocol
603 Core", RFC 3080, March 2001.
605 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
606 Standards (PKCS) #1: RSA Cryptography Specifications
607 Version 2.1", RFC 3447, February 2003.
609 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
610 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
611 RFC 4231, December 2005.
613 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
614 Protocol Assigned Numbers", RFC 4250, December 2005.
616 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
617 Protocol Architecture", RFC 4251, January 2006.
619 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
620 Authentication Protocol", RFC 4252, January 2006.
622 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
623 Transport Layer Protocol", RFC 4253, January 2006.
625 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
626 Connection Protocol", RFC 4254, January 2006.
628 [RFC4741] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741,
629 December 2006.
631 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
632 the Network Configuration Protocol (NETCONF)", RFC 6020,
633 October 2010.
635 [RFC6125] Saint-Andre, PSA. and J. Hodges, "Representation and
636 Verification of Domain-Based Application Service Identity
637 within Internet Public Key Infrastructure Using X.509
638 (PKIX) Certificates in the Context of Transport Layer
639 Security (TLS)", RFC 6125, March 2011.
641 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
642 Shell Authentication", RFC 6187, March 2011.
644 9.2. Informative References
646 [TR069] The Broadband Forum, "TR-069 Amendemnt 3, CPE WAN
647 Management Protocol", November 2010.
649 Author's Address
651 Kent Watsen
652 Juniper Networks
654 Email: kwatsen@juniper.net