idnits 2.17.1 draft-ietf-netconf-reverse-ssh-06.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4253, but the abstract doesn't seem to mention this, which it should. 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. (Using the creation date from RFC4253, updated by this document, for RFC5378 checks: 1997-03-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2014) is 3573 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) == Unused Reference: 'RFC4250' is defined on line 374, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Updates: 4253 (if approved) July 2014 5 Intended status: Standards Track 6 Expires: January 02, 2015 8 NETCONF Call Home using SSH 9 draft-ietf-netconf-reverse-ssh-06 11 Abstract 13 This document presents a technique for a NETCONF server to request 14 that a NETCONF client initiates a SSH connection to the NETCONF 15 server, a technique referred to as 'call home'. Call home is needed 16 to support deployments where the NETCONF client is otherwise unable 17 to initiate a SSH connection to the NETCONF server directly. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 02, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Requirements Terminology . . . . . . . . . . . . . . . . . . 2 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2.1. Applicability Statement . . . . . . . . . . . . . . . . . 3 56 2.2. Update to RFC 4253 . . . . . . . . . . . . . . . . . . . 3 57 2.3. Draft Naming . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Benefits to Device Management . . . . . . . . . . . . . . . . 3 59 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. SSH Server Identification and Verification . . . . . . . . . 5 61 6. Device Configuration . . . . . . . . . . . . . . . . . . . . 6 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 10.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 69 A.1. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 9 70 A.2. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 10 71 A.3. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 10 72 A.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 11 73 A.5. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 11 74 A.6. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Requirements Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [RFC2119]. 82 2. Introduction 83 This document presents a technique for a NETCONF server to request 84 that a NETCONF [RFC6241] client initiates a SSH [RFC4251] connection 85 to the NETCONF server, a technique referred to as 'call home'. Call 86 home is needed to support deployments where the NETCONF client is 87 otherwise unable to initiate a SSH connection to the NETCONF server 88 directly. 90 2.1. Applicability Statement 92 The techniques described in this document are suitable for network 93 management scenarios such as the ones described in section 3. 94 However, these techniques SHOULD only be used for a NETCONF server to 95 initiate a connection to a NETCONF client, as described in this 96 document. 98 The reason for this restriction is that different protocols have 99 different security assumptions. The NETCONF over SSH specification 100 requires NETCONF clients and servers to verify the identity of the 101 other party before starting the NETCONF protocol (section 6 of 102 [RFC6242]). This contrasts with the base SSH protocol, which does 103 not require programmatic verification of the other party (section 104 9.3.4 of [RFC4251] and section 4 of [RFC4252]). In such 105 circumstances, allowing the SSH server to contact the SSH client 106 would open new vulnerabilities. Therefore, any use of call home with 107 SSH for purposes other than NETCONF will need a thorough, contextual 108 security analysis. 110 2.2. Update to RFC 4253 112 This document updates the SSH Transport Layer Protocol [RFC4253] only 113 by removing the restriction in Section 4 (Connection Setup) of 114 [RFC4252] that the SSH Client must initiate the transport connection. 115 Security implications related to this change are discussed in 116 Security Considerations (Section 7). 118 2.3. Draft Naming 120 (this section should be removed if this draft becomes an RFC) 122 This draft's name includes the string "reverse-ssh", and yet 123 currently nowhere in this draft is there any reference to reversing 124 SSH. This appearant ommision comes from the -05 edit of this draft, 125 where "Reverse SSH" was changed to "Call Home" throughout. If this 126 draft becomes an RFC, its name would no longer contain the obsolete 127 "reverse-ssh" reference, thus self-correcting this inconsistency. 129 3. Benefits to Device Management 130 The SSH protocol is nearly ubiquitous for device management, as it is 131 the transport for the command-line applications `ssh`, `scp`, and 132 `sftp` and is the required transport for the NETCONF protocol 133 [RFC6241]. However, all these SSH-based protocols expect the network 134 element to be the SSH server. 136 NETCONF over SSH Call Home enables the network element to 137 consistently be the SSH server regardless of which peer initiates the 138 underlying TCP connection. Maintaining the role of SSH server is 139 both necessary and desirable. It is necessary because SSH channels 140 and subsystems can only be opened on the SSH server. It is desirable 141 because it conveniently leverages infrastructure that may be deployed 142 for host-key verification and user authentication. 144 Call home is useful for both initial deployment and on-going device 145 management and may be used to enable any of the following scenarios: 147 o The network element may proactively call home after being powered 148 on for the first time to register itself with its management 149 system. 151 o The network element may access the network in a way that 152 dynamically assigns it an IP address and it doesn't register its 153 assigned IP addressed to a mapping service. 155 o The network element may be configured in "stealth mode" and thus 156 doesn't have any open ports for the management system to connect 157 to. 159 o The network element may be deployed behind a firewall that doesn't 160 allow SSH access to the internal network. 162 o The network element may be deployed behind a firewall that 163 implements network address translation (NAT) for all internal 164 network IP addresses, thus complicating the ability for a 165 management system to connect to it. 167 o The operator may prefer to have network elements initiate 168 management connections believing it is easier to secure one open- 169 port in the data center than to have an open port on each network 170 element in the network. 172 One key benefit of using SSH as the transport protocol is its ability 173 to multiplex an unspecified number of independently flow-controlled 174 TCP sessions [RFC4254]. This is valuable as the network element only 175 needs to be configured to initiate a single call home connection to a 176 management system, regardless the number of NETCONF channels the 177 management system wants to open. 179 4. Protocol 181 The NETCONF server's perspective (e.g., the network element) 183 o The NETCONF server initiates a TCP connection to the NETCONF 184 client on the IANA-assigned SSH for NETCONF Call Home port YYYY. 186 o The TCP connection is accepted and a TCP session is established. 188 o Using this TCP connection, the NETCONF server immediately starts 189 the SSH server protocol. That is, the next message sent on the 190 TCP stream is SSH's Protocol Version Exchange message (section 191 4.2, [RFC4253]). 193 o The SSH connection is established. 195 The NETCONF client's perspective (e.g., the management system) 197 o The NETCONF client listens for TCP connections on the IANA- 198 assigned NETCONF over SSH Call Home port YYYY. 200 o The NETCONF client accepts an incoming TCP connection and a TCP 201 session is established. 203 o Using this TCP connection, the NETCONF client immediately starts 204 the SSH Client protocol, starting with sending the SSH's Protocol 205 Version Exchange message (section 4.2, [RFC4253]). 207 o The SSH connection is established. 209 5. SSH Server Identification and Verification 211 When the management system accepts a new incoming TCP connection on 212 the NETCONF over SSH Call Home port, it starts the SSH client 213 protocol. As the SSH client, it MUST authenticate the SSH server, by 214 both identifying the network element and verifying its SSH host key. 216 Due to call home having the network element initiate the TCP 217 connection, the management system MAY identify the remote peer using 218 the source IP address of the TCP connection. However, identifying 219 the remote peer using the source IP address of the TCP connection is 220 NOT RECOMMENDED as it can only work in networks that use known static 221 addresses. 223 To support network elements having dynamically-assigned IP addresses, 224 or deployed behind gateways that translate their IP addresses (e.g., 225 NAT), the management system MAY identify the device using its SSH 226 host key. For instance, a fingerprint of the network element's host 227 key could itself be used as an identifier since each device has a 228 statistically unique host key. However, identifying the remote peer 229 using its host key directly is NOT RECOMMENDED as it requires the 230 host key to be manually verified the first time the network element 231 connects and anytime its host key changes thereafter. 233 Yet another option for identifying the network element is for its 234 host key to encode the network element's identity, such as if the 235 host key were a certificate. This option enables the host key to 236 change over time, so long as it continues to encode the same 237 identity, but brings the next issue of how the management system can 238 verify the network element's host key is authentic. 240 The security of SSH is anchored in the ability for the SSH client to 241 verify the SSH server's host key. Typically this is done by 242 comparing the host key presented by the SSH server with one that was 243 previously configured on the SSH client, looking it up in a local 244 database using the identity of the SSH client as the lookup key. 245 Nothing changes regarding this requirement due to the direction 246 reversal of the underlying TCP connection. To ensure security, the 247 management system MUST verify the network element's SSH host key each 248 time a SSH session is established. 250 However, configuring distinct host keys on the management system 251 doesn't scale well, which is an important consideration to a network 252 management system. A more scalable strategy for the management 253 system is for the network element's manufacturer to sign the network- 254 element's host key with a common trusted key, such as a certificate 255 authority. Then, when the network-element is deployed, the 256 management system only needs to trust a single certificate, which 257 vouches for the authenticity of the various network element host 258 keys. 260 Since both the identification and verification issues are addressed 261 using certificates, this draft RECOMMENDS network elements use a host 262 key that can encode a unique identifier (e.g., its serial number) and 263 be signed by a common trust anchor (e.g., a certificate authority). 264 Examples of suitable public host keys are the X.509v3 keys defined in 265 defined in [RFC6187] and the PGP keys defined in [RFC4253]. 267 6. Device Configuration 269 How to configure a device to initiate a NETCONF over SSH Call Home 270 connection is outside the scope of this document, as implementations 271 can support this protocol using a proprietary configuration data 272 model. That said, a YANG [RFC6020] model to configure NETCONF over 273 SSH Call Home is specified in [draft-ietf-netconf-server-model]. 275 7. Security Considerations 277 This RFC deviates from standard SSH protocol usage by allowing the 278 SSH server to initiate the TCP connection. This conflicts with 279 section 4 of the SSH Transport Layer Protocol RFC [RFC4253], which 280 states "The client initiates the connection". However this statement 281 is made without rationalization and it's not clear how it impacts the 282 security of the protocol, so this section analyzes the security 283 offered by having the client initiate the connection. 285 First, assuming the SSH server is not using a public host key 286 algorithm that certifies its identity, the security of the protocol 287 doesn't seem to be sensitive to which peer initiates the connection. 288 That is, it is still the case that reliable distribution of host keys 289 (or their fingerprints) should occur prior to first connection and 290 that verification for subsequent connections happens by comparing the 291 host keys in a locally cached database. It does not seem to matter 292 if the SSH server's host name is derived from user-input or extracted 293 from the TCP layer, potentially via a reverse-DNS lookup. Once the 294 host name-to-key association is stored in a local database, no man- 295 in-the-middle attack is possible due to the attacker being unable to 296 guess the real SSH server's private key (Section 9.3.4 (Man-in-the- 297 middle) of [RFC4251]). 299 That said, this RFC recommends implementations use a public host key 300 algorithm that certifies the SSH server's identity. The identity can 301 be any unique identifier, such as a device's serial number or a 302 deployment-specific value. If this recommendation is followed, then 303 no information from the TCP layer would be needed to lookup the 304 device in a local database and therefore the directionality of the 305 TCP layer is clearly inconsequential. 307 The SSH protocol negotiates which algorithms it will use during key 308 exchange (Section 7.1 (Algorithm Negotiation) in [RFC4253]). The 309 algorithm selected is essentially the first compatible algorithm 310 listed by the SSH client that is also listed by the SSH server. For 311 a network management application, there may be a need to advertise a 312 large number of algorithms to be compatible with the various devices 313 it manages. The SSH client SHOULD order its list of public host key 314 algorithms such that all the certifiable public host key algorithms 315 are listed first. Additionally, when possible, SSH servers SHOULD 316 only list certifiable public host key algorithms. Note that since 317 the SSH server would have to be configured to know which IP address 318 it is to connect to, it is expected that it will also be configured 319 to know which host key algorithm to use for the particular 320 application, and hence only needs to list just that one public host 321 key algorithm. 323 This RFC suggests implementations can use a device's serial number as 324 a form of identity. A potential concern with using a serial number 325 is that the SSH protocol passes the SSH server's host-key in the 326 clear and many times serial numbers encode revealing information 327 about the device, such as what kind of device it is and when it was 328 manufactured. While there is little security in trying to hide this 329 information from an attacker, it is understood that some deployments 330 may want to keep this information private. If this is a concern, 331 deployments SHOULD use an alternate unique identifier, if even just 332 the hash of the device's serial number. 334 An attacker could DoS the application by having it perform 335 computationally expensive operations, before deducing that the 336 attacker doesn't posses a valid key. This is no different than any 337 secured service and all common precautions apply (e.g., blacklisting 338 the source address after a set number of unsuccessful login 339 attempts). 341 8. IANA Considerations 343 This document requests that IANA assigns a TCP port number in the 344 "Registered Port Numbers" range with the service name "netconf-ssh- 345 ch". This port will be the default port for NETCONF over SSH Call 346 Home protocol and will be used when the NETCONF server is to initiate 347 a connection to a NETCONF client using SSH. Below is the 348 registration template following the rules in [RFC6335]. 350 Service Name: netconf-ssh-ch 351 Transport Protocol(s): TCP 352 Assignee: IESG 353 Contact: IETF Chair 354 Description: NETCONF over SSH Call Home 355 Reference: RFC XXXX 356 Port Number: YYYY 358 9. Acknowledgements 360 The author would like to thank for following for lively discussions 361 on list and in the halls (ordered by last name): Andy Bierman, Martin 362 Bjorklund, Mehmet Ersue, Wes Hardaker, Stephen Hanna, David 363 Harrington, Jeffrey Hutzelman, Radek Krejci, Alan Luchuk, Mouse, Russ 364 Mundy, Tom Petch, Peter Saint-Andre, Joe Touch, Sean Turner, Bert 365 Wijnen. 367 10. References 369 10.1. Normative References 371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels ", BCP 14, RFC 2119, March 1997. 374 [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) 375 Protocol Assigned Numbers ", RFC 4250, December 2005. 377 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 378 Protocol Architecture ", RFC 4251, January 2006. 380 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 381 Authentication Protocol ", RFC 4252, January 2006. 383 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 384 Transport Layer Protocol ", RFC 4253, January 2006. 386 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 387 Connection Protocol ", RFC 4254, January 2006. 389 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 390 Network Configuration Protocol (NETCONF) ", RFC 6020, 391 October 2010. 393 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 394 Shell Authentication ", RFC 6187, March 2011. 396 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 397 Bierman, "NETCONF Configuration Protocol", RFC 6241, June 398 2011. 400 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 401 Shell (SSH)", RFC 6242, June 2011. 403 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 404 Cheshire, "Internet Assigned Numbers Authority (IANA) 405 Procedures for the Management of the Service Name and 406 Transport Protocol Port Number Registry", RFC 6335, August 407 2011. 409 10.2. Informative References 411 [draft-ietf-netconf-server-model] 412 Watsen, K. and J. Schoenwaelder, "A YANG Data Model for 413 NETCONF Server Configuration", RFC 6242, June 2011. 415 Appendix A. Change Log 417 A.1. 05 to 06 418 Changed title to "NETCONF Call Home using SSH" 420 Revised the Abstract and Introduction to better explain what the 421 document regards. 423 Changed "MUST" to "SHOULD" in the Applicability Statement. 425 Added a "Draft Naming" section explaining why, despite its name, 426 reversing SSH is nowhere in the text 428 Added PGP keys as another kind of SSH host key encoding identity 429 and signed by a trust anchor. 431 Revised the Device Considerations section to more clearly explain 432 why a device configuration data model is out of scope, and hence 433 an Informative reference. 435 Clarified Security Considerations section on use of serial 436 numbers. 438 A.2. 04 to 05 440 Changed "Reverse SSH" to "Call Home" 442 Added references to Applicability Statement 444 A.3. 03 to 04 446 Changed title to "Reverse SSH for NETCONF Call Home" (changed 447 again in -05) 449 Removed statement on how other SSH channels might be used for 450 other protocols 452 Improved language on how the management system, as the SSH client, 453 MUST authenticate the SSH server 455 Clarified that identifying the network element using source IP 456 address is NOT RECOMMENDED 458 Clarified that identifying the NE using simple certificate 459 comparison is NOT RECOMMENDED 461 Device Configuration section now more clearly states that the YANG 462 model is out of scope 464 Change requested port name to "netconf-ssh-ch" 465 General edits for grammer, capitalization, and spellings 467 A.4. 02 to 03 469 Updated Device Configuration section to reference 470 [draft-ietf-netconf-server-model] 472 A.5. 01 to 02 474 Added Applicability Statement 476 Removed references to ZeroConf / ZeroTouch 478 Clarified the protocol section 480 Added a section for identification and verification 482 A.6. 00 to 01 484 Removed the hmac-* family of algorithms 486 Author's Address 488 Kent Watsen 489 Juniper Networks 491 EMail: kwatsen@juniper.net