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