idnits 2.17.1 draft-ietf-netconf-call-home-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 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 (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 (October 10, 2014) is 3485 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5539 (Obsoleted by RFC 7589) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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) October 10, 2014 5 Intended status: Standards Track 6 Expires: April 13, 2015 8 NETCONF Call Home 9 draft-ietf-netconf-call-home-01 11 Abstract 13 This document presents NETCONF Call Home, which enables a NETCONF 14 server to initiate a secure connection to the NETCONF client. 15 NETCONF Call Home supports both the SSH and TLS transports, and does 16 so in a way that preserves the SSH and TLS roles when compared to 17 standard NETCONF over SSH or TLS connections. 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 April 13, 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Requirements Terminology . . . . . . . . . . . . . . . . 3 56 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 3 57 1.4. Update to RFC 4253 . . . . . . . . . . . . . . . . . . . 4 58 2. The NETCONF Server . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 4 60 2.2. Configuration Data Model . . . . . . . . . . . . . . . . 5 61 3. The NETCONF Client . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 5 63 3.2. Server Identification and Verification . . . . . . . . . 5 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 7.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 71 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 This document presents NETCONF Call Home, which enables a NETCONF 76 server to initiate a secure connection to the NETCONF client. 77 NETCONF Call Home supports both the SSH and TLS transports, and does 78 so in a way that preserves the SSH and TLS roles when compared to 79 standard NETCONF over SSH or TLS connections. 81 The same technique is used to enabled call home for both the SSH and 82 TLS transports. The technique is to have the NETCONF server initiate 83 a TCP connection to the intended NETCONF client. The NETCONF client 84 then uses the established TCP connection to initiate either the SSH 85 or TLS protocols. In this way, the NETCONF server is always the SSH 86 or TLS server, regardless if call home is used or not. 88 Enabling the NETCONF server to maintain the role of SSH or TLS server 89 is both necessary and desirable. It is necessary for the SSH 90 protocol, as SSH channels and subsystems can only be opened on the 91 SSH server. It is desirable for both the SSH and TLS protocols as it 92 conveniently leverages infrastructure that may be deployed for host- 93 key or certificate verification and user authentication. 95 1.1. Motivation 97 Call home is generally useful for both the initial deployment and on- 98 going management of networking elements. Here are some scenarios 99 enabled by call home: 101 o The network element may proactively call home after being powered 102 on for the first time in order to register itself with its 103 management system. 105 o The network element may access the network in a way that 106 dynamically assigns it an IP address and it doesn't register its 107 assigned IP addressed to a mapping service. 109 o The network element may be configured in "stealth mode" and thus 110 doesn't have any open ports for the management system to connect 111 to. 113 o The network element may be deployed behind a firewall that doesn't 114 allow management access to the internal network. 116 o The network element may be deployed behind a firewall that 117 implements network address translation (NAT) for all internal 118 network IP addresses, thus complicating the ability for a 119 management system to connect to it. 121 o The operator may prefer to have network elements initiate 122 management connections believing it is easier to secure one open- 123 port in the data center than to have an open port on each network 124 element in the network. 126 Having call home for NETCONF is particularly useful as NETCONF is the 127 recommended protocol for configuration [iesg-statement], which is 128 needed for provisioning workflows. 130 1.2. Requirements Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 1.3. Applicability Statement 138 The techniques described in this document are suitable for network 139 management scenarios such as the ones described in Section 1.1. 140 However, these techniques SHOULD only be used for a NETCONF server to 141 initiate a connection to a NETCONF client, as described in this 142 document. 144 The reason for this restriction is that different protocols have 145 different security assumptions. The NETCONF transport specifications 146 require NETCONF clients and servers to verify the identity of the 147 other party before starting the NETCONF protocol (section 2.2 of 148 [RFC6241]. 150 This contrasts with the base SSH and TLS protocols, which do not 151 require programmatic verification of the other party (e.g., section 152 9.3.4 of [RFC4251] and section 4 of [RFC4252]). In such 153 circumstances, allowing the SSH/TLS server to contact the SSH/TLS 154 client would open new vulnerabilities. Any use of call home with 155 SSH/TLS for purposes other than NETCONF will need a thorough, 156 contextual security analysis. 158 1.4. Update to RFC 4253 160 This document updates the SSH Transport Layer Protocol [RFC4253] only 161 by removing the "The client initiates the connection" statement made 162 in Section 4 (Connection Setup). This document assumes that the 163 reference to "connection" refers to the underlying transport 164 connection (e.g., TCP). Security implications related to this change 165 are discussed in Security Considerations (Section 4). 167 2. The NETCONF Server 169 2.1. Protocol Operation 171 o The NETCONF server initiates a TCP connection to the NETCONF 172 client on one of the IANA-assigned ports for NETCONF Call Home 173 (YYYY for netconf-ch-ssh and ZZZZ for netconf-ch-tls). 175 o The TCP connection is accepted and a TCP session is established. 177 o Using this TCP session, the NETCONF server immediately starts 178 either the SSH-server or the TLS-server protocol, depending on 179 which port is connected. The NETCONF server MUST start the SSH- 180 server protocol when port YYYY is connected and the TLS-server 181 protocol when port ZZZZ is connected. The SSH-server and TLS- 182 server protocols are described by [RFC4253] and [RFC5246] 183 respectively. 185 o The NETCONF protocol proceeds normally for SSH and TLS, as defined 186 in [RFC6242] and [RFC5539] respectively. 188 2.2. Configuration Data Model 190 How to configure a NETCONF server to initiate a NETCONF Call Home 191 connection is outside the scope of this document, as implementations 192 can support this protocol using proprietary configuration data 193 models. That said, a YANG [RFC6020] model for configuring NETCONF 194 Call Home is provided in [draft-ietf-netconf-server-model]. 196 3. The NETCONF Client 198 3.1. Protocol Operation 200 o The NETCONF client listens for TCP connections on one or both of 201 the IANA-assigned ports for NETCONF Call Home (YYYY for netconf- 202 ch-ssh and ZZZZ for netconf-ch-tls). 204 o The NETCONF client accepts an incoming TCP connection and a TCP 205 session is established. 207 o Using this TCP session, the NETCONF client immediately starts 208 either the SSH-client or the TLS-client protocol, depending on 209 which port is connected. The NETCONF client MUST start the SSH- 210 client protocol when port YYYY is connected and the TLS-client 211 protocol when port ZZZZ is connected. The SSH-client and TLS- 212 client protocols are described by [RFC4253] and [RFC5246] 213 respectively. 215 o The NETCONF protocol proceeds normally for SSH and TLS, as is 216 defined in [RFC6242] and [RFC5539] respectively. 218 3.2. Server Identification and Verification 220 Under normal circumstances, a NETCONF client initiates the NETCONF 221 connection to the NETCONF server. This action provides essential 222 input to verify the NETCONF server's identity. For instance, when 223 using TLS, the input can be compared to the domain names and IP 224 addresses encoded in X.509 certificates. Similarly, when using SSH, 225 the input can be compared to information persisted previously. 227 However, when receiving a NETCONF Call Home connection, the NETCONF 228 client does not have any context leading it to know the connection is 229 from a particular NETCONF server. Thus the NETCONF client must 230 derive the NETCONF server's identity using information provided by 231 the network and the NETCONF server itself. This section describes 232 strategies a NETCONF client can use to identify a NETCONF server. 234 In addition to identifying a NETCONF server, a NETCONF client must 235 also be able to verify the NETCONF server's credentials. Verifying a 236 NETCONF server's credentials is necessary under normal circumstances 237 but, due to call home being commonly used for newly deployed NETCONF 238 servers, how to verify its credentials the very first time becomes a 239 prominent concern. Therefore, this section also describes strategies 240 a NETCONF client can use to verify a NETCONF server's credentials. 242 The first information a NETCONF client learns from a NETCONF Call 243 Home connection is the IP address of the NETCONF server, as provided 244 by the source address of the TCP connection. This IP address could 245 be used as an identifier directly, but doing so would only work in 246 networks that use known static addresses, in which case a standard 247 NETCONF connection would have worked just as well. Due to this 248 limited use, it is not recommended to identify a NETCONF server based 249 on its source IP address. 251 The next information a NETCONF client learns is provided by the 252 NETCONF server in the form of a host-key or a certificate, for the 253 SSH and TLS protocols respectively. Without examining the contents 254 of the host-key or certificate, it is possible to form an identity 255 for the NETCONF server using it (e.g., a fingerprint), since each 256 NETCONF server is assumed to have a statistically unique public key, 257 even in virtualized environments. This strategy also provides a 258 mechanism to verify the NETCONF server, in that a secure connection 259 can only be established with the NETCONF server having the matching 260 private key. This strategy is commonly implemented by SSH clients, 261 and could be used equally well by TLS-based clients, such as may be 262 required when the NETCONF servers have self-signed certificates. 263 This strategy is viable and useful when the NETCONF servers call home 264 using either SSH with standard RSA/DSA host-keys, or using TLS with 265 self-signed certificates. 267 Yet another option for identifying a NETCONF server is for its host 268 key or certificate to encode its identity directly (e.g., within the 269 "Subject" field). However, in order to trust the content encoded 270 within a host-key or certificate, it must be signed by a certificate 271 authority trusted by the NETCONF client. This strategy's use of PKI 272 enables a NETCONF client to transparently authenticate NETCONF 273 servers, thus eliminating the need for manual authentication, as 274 required by the previously discussed strategies. Elimination of 275 manual steps is needed to achieve scalable solutions, however one can 276 claim that this merely pushes equivalent work to provisioning the 277 NETCONF servers with signed credentials. This assessment is accurate 278 in general, but not in the case where the manufacturer itself 279 provisions the credentials, such as is described by 280 [Std-802.1AR-2009]. When NETCONF servers are pre-provisioned this 281 way, NETCONF clients can transparently authenticate NETCONF servers 282 using just the manufacturer's trust anchor and a list of expected 283 NETCONF server identifiers, which could be provided along with 284 shipping information. This strategy is recommended for all 285 deployment scenarios. 287 In discussing the use of certificates, it is worth noting that TLS 288 uses X.509 certificates by default. However, to use X.509 289 certificates with SSH, both the NETCONF client and server must 290 support [RFC6187]. 292 4. Security Considerations 294 The security considerations described throughout [RFC6242] and 295 [RFC5539], and by extension [RFC4253] and [RFC5246], apply here as 296 well. 298 This RFC deviates from standard SSH and TLS usage by having the SSH/ 299 TLS server initiate the underlying TCP connection. For SSH, 300 [RFC4253] says "the client initiates the connection", whereas for 301 TLS, [RFC5246] says it is layered on top of "some reliable transport 302 protocol" without further attribution. 304 For SSH, not having the SSH client initiate the TCP connection means 305 that it does not have a preconceived notion of the SSH server's 306 identity, and therefore must dynamically derive one from information 307 provided by the network or the SSH server itself. Security 308 Considerations for strategies for this are described in Section 3.2. 310 An attacker could DoS the NETCONF client by having it perform 311 computationally expensive operations, before deducing that the 312 attacker doesn't posses a valid key. This is no different than any 313 secured service and all common precautions apply (e.g., blacklisting 314 the source address after a set number of unsuccessful login 315 attempts). 317 5. IANA Considerations 319 This document requests that IANA assigns two TCP port numbers in the 320 "Registered Port Numbers" range with the service names "netconf-ch- 321 ssh" and "netconf-ch-tls". These ports will be the default ports for 322 NETCONF Call Home protocol when using SSH and TLS respectively. 323 Below is the registration template following the rules in [RFC6335]. 325 Service Name: netconf-ch-ssh 326 Transport Protocol(s): TCP 327 Assignee: IESG 328 Contact: IETF Chair 329 Description: NETCONF Call Home (SSH) 330 Reference: RFC XXXX 331 Port Number: YYYY 333 Service Name: netconf-ch-tls 334 Transport Protocol(s): TCP 335 Assignee: IESG 336 Contact: IETF Chair 337 Description: NETCONF Call Home (TLS) 338 Reference: RFC XXXX 339 Port Number: ZZZZ 341 6. Acknowledgements 343 The author would like to thank for following for lively discussions 344 on list and in the halls (ordered by last name): Andy Bierman, Martin 345 Bjorklund, Mehmet Ersue, Wes Hardaker, Stephen Hanna, David 346 Harrington, Jeffrey Hutzelman, Radek Krejci, Alan Luchuk, Mouse, Russ 347 Mundy, Tom Petch, Peter Saint-Andre, Joe Touch, Sean Turner, Bert 348 Wijnen. 350 7. References 352 7.1. Normative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, March 1997. 357 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 358 Protocol Architecture", RFC 4251, January 2006. 360 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 361 Authentication Protocol", RFC 4252, January 2006. 363 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 364 Transport Layer Protocol", RFC 4253, January 2006. 366 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 367 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 369 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", 370 RFC 5539, May 2009. 372 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 373 Network Configuration Protocol (NETCONF)", RFC 6020, 374 October 2010. 376 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 377 Shell Authentication", RFC 6187, March 2011. 379 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 380 Bierman, "Network Configuration Protocol (NETCONF)", RFC 381 6241, June 2011. 383 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 384 Shell (SSH)", RFC 6242, June 2011. 386 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 387 Cheshire, "Internet Assigned Numbers Authority (IANA) 388 Procedures for the Management of the Service Name and 389 Transport Protocol Port Number Registry", BCP 165, RFC 390 6335, August 2011. 392 7.2. Informative References 394 [Std-802.1AR-2009] 395 IEEE SA-Standards Board, "IEEE Standard for Local and 396 metropolitan area networks - Secure Device Identity", 397 December 2009, . 400 [draft-ietf-netconf-server-model] 401 Watsen, K. and J. Schoenwaelder, "NETCONF Server 402 Configuration Model", 2014, . 405 [iesg-statement] 406 "Writable MIB Module IESG Statement", March 2014, 407 . 410 Appendix A. Change Log 412 A.1. 00 to 01 414 o The term "TCP connection" is now used throughout. 416 o The terms "network element" and "management system" are now only 417 used in the Motivation section. 419 o Restructured doc a little to create an Introduction section. 421 o Fixed reference in Applicability Statement so it would work 422 equally well for SSH and TLS. 424 o Fixed reported odd wording and three references. 426 Author's Address 428 Kent Watsen 429 Juniper Networks 431 EMail: kwatsen@juniper.net