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