idnits 2.17.1 draft-ietf-netconf-call-home-00.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 document seems to lack an Introduction section. -- 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 (August 19, 2014) is 3538 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: 3 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) August 19, 2014 5 Intended status: Standards Track 6 Expires: February 20, 2015 8 NETCONF Call Home 9 draft-ietf-netconf-call-home-00 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 February 20, 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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3 55 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 56 4. Update to RFC 4253 . . . . . . . . . . . . . . . . . . . . . 3 57 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 7. NETCONF Server Identification and Verification . . . . . . . 5 60 8. Configuration Data Model . . . . . . . . . . . . . . . . . . 6 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 64 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 12.2. Informative References . . . . . . . . . . . . . . . . . 8 68 1. Motivation 70 Call home is generally useful for both the initial deployment and on- 71 going management of networking elements. Here are some scenarios 72 enabled by call home: 74 o The network element may proactively call home after being powered 75 on for the first time to register itself with its management 76 system. 78 o The network element may access the network in a way that 79 dynamically assigns it an IP address and it doesn't register its 80 assigned IP addressed to a mapping service. 82 o The network element may be configured in "stealth mode" and thus 83 doesn't have any open ports for the management system to connect 84 to. 86 o The network element may be deployed behind a firewall that doesn't 87 allow management access to the internal network. 89 o The network element may be deployed behind a firewall that 90 implements network address translation (NAT) for all internal 91 network IP addresses, thus complicating the ability for a 92 management system to connect to it. 94 o The operator may prefer to have network elements initiate 95 management connections believing it is easier to secure one open- 96 port in the data center than to have an open port on each network 97 element in the network. 99 Having call home for NETCONF is particularly useful as NETCONF is the 100 recommended protocol for configuration [iesg-statement], which is 101 needed for provisioning workflows. 103 2. Requirements Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 3. Applicability Statement 111 The techniques described in this document are suitable for network 112 management scenarios such as the ones described in section 3. 113 However, these techniques SHOULD only be used for a NETCONF server to 114 initiate a connection to a NETCONF client, as described in this 115 document. 117 The reason for this restriction is that different protocols have 118 different security assumptions. The NETCONF transport specifications 119 require NETCONF clients and servers to verify the identity of the 120 other party before starting the NETCONF protocol (section 6 of 121 [RFC6242]). 123 This contrasts with the base SSH and TLS protocols, which do not 124 require programmatic verification of the other party (e.g., section 125 9.3.4 of [RFC4251] and section 4 of [RFC4252]). In such 126 circumstances, allowing the SSH/TLS server to contact the SSH/TLS 127 client would open new vulnerabilities. Any use of call home with 128 SSH/TLS for purposes other than NETCONF will need a thorough, 129 contextual security analysis. 131 4. Update to RFC 4253 133 This document updates the SSH Transport Layer Protocol [RFC4253] only 134 by removing the restriction in Section 4 (Connection Setup) of 135 [RFC4253] that the SSH client initiates the connection. Security 136 implications related to this change are discussed in Security 137 Considerations (Section 9). 139 5. Overview 141 The same technique is used to enabled call home for both the SSH and 142 TLS transports. The technique is to have the network element 143 initiate a TCP connection to its remote peer. The remote peer then 144 uses the established TCP connection to initiate either the SSH or TLS 145 protocols. In this way, the network element is always the SSH or TLS 146 server, regardless if call home is used or not. 148 Enabling the network element to maintain the role of SSH or TLS 149 server is both necessary and desirable. It is necessary for the SSH 150 protocol, as SSH channels and subsystems can only be opened on the 151 SSH server. It is desirable for both the SSH and TLS protocols as it 152 conveniently leverages infrastructure that may be deployed for host- 153 key or certificate verification and user authentication. 155 6. Operation 157 The NETCONF server's perspective (e.g., the network element) 159 o The NETCONF server initiates a TCP connection to the NETCONF 160 client on one of the IANA-assigned ports for NETCONF Call Home 161 (YYYY or ZZZZ). 163 o The TCP connection is accepted and a TCP session is established. 165 o Using this TCP connection, the NETCONF server immediately starts 166 either the SSH-server or TLS-server protocol. That is, the next 167 message sent on the TCP stream is the initial message defined for 168 these protocols, per [RFC4253] or [RFC5246]. 170 o The NETCONF protocol proceeds normally for SSH and TLS, as defined 171 in [RFC4253] and [RFC5539] respectively. 173 The NETCONF client's perspective (e.g., the management system) 175 o The NETCONF client listens for TCP connections on one or both of 176 the IANA-assigned ports for NETCONF Call Home port (YYYY and/or 177 ZZZZ). 179 o The NETCONF client accepts an incoming TCP connection and a TCP 180 session is established. 182 o Using this TCP connection, the NETCONF client immediately starts 183 either the SSH-server or TLS-server protocol. That is, the next 184 message sent on the TCP stream is the initial message defined for 185 these protocols, per xref target="RFC4253"/> or [RFC5246]. 187 o The NETCONF protocol proceeds normally for SSH and TLS, as defined 188 in [RFC4253] and [RFC5539] respectively. 190 7. NETCONF Server Identification and Verification 192 Under normal circumstances, a management system initiates the NETCONF 193 connection to the network element. This action provides essential 194 input to verify the network element's identity. For instance, when 195 using TLS, the input can be compared to the domain names and IP 196 addresses encoded in X.509 certificates. Similarly, when using SSH, 197 the input can be compared to information persisted previously. 199 However, when receiving a NETCONF Call Home connection, the 200 management system does not have an expectation for the connection to 201 be from a specific network element, and thus must derived the network 202 element's identity using information provided by the network and the 203 network element itself. This section describes strategies a 204 management system can use to identify a network element. 206 In addition to identifying a network element, a management system 207 must also be able to verify the network element's credentials. 208 Verifying a network element's credentials is of course necessary 209 under normal circumstances, but due to call home being commonly used 210 for newly deployed network elements, how to verify its credentials 211 the very first time becomes a critical concern. Therefore, this 212 section also describes strategies a management system can use to 213 verify a network element's credentials. 215 The first information a management system learns from a NETCONF Call 216 Home connection is the IP address of the remote peer, as provided as 217 the source address of the TCP connection. This IP address could be 218 used as an identifier, but it can only work in networks that use 219 known static addresses, in which case having the management system 220 initiate the NETCONF connection to the network element would have 221 worked just as well. Due to its limited use, it is not recommended 222 to identify a network element based on its source IP address. 224 The next information a management system learns is provided by the 225 network element in the form of a host-key or a certificate, for the 226 SSH and TLS protocols respectively. Without examining the contents 227 of the host-key or certificate, it is possible to form an identity 228 for the network element using it (e.g., a fingerprint), since each 229 network element is assumed to have a statistically unique public key, 230 even in virtualized environments. This strategy also provides a 231 mechanism to verify the network element, in that a secure connection 232 can only be established with the network element having the matching 233 private key. This strategy is commonly implemented by SSH clients, 234 but could be used equally well by TLS-based clients, such as may be 235 required when the network elements have self-signed certificates. 236 This strategy is viable and useful when the network elements call 237 home using either SSH with standard RSA/DSA host-keys, or using TLS 238 with self-signed certificates. 240 Yet another option for identifying a network element is for its host 241 key or certificate to encode its identity directly (e.g., within the 242 "Subject" field). However, in order to trust the content encoded 243 within a host-key or certificate, it must be signed by a trust anchor 244 known to the management application. This strategy enables a 245 management application to transparently authenticate network 246 elements, thus eliminating the need for manual authentication, as 247 required by the previously discussed strategy. Elimination of manual 248 steps is needed to achieve scalable solutions, however one can claim 249 that this merely pushes equivalent work to provisioning the network 250 elements with signed credentials. This assessment is accurate in 251 general, but not in the case where the manufacturer itself provisions 252 the credentials, such as is described by [Std-802.1AR-2009]. When 253 network elements are pre-provisioned this way, management 254 applications can transparently authenticate network elements using 255 just the manufacturer's trust anchor and a list of expected network 256 element identifiers, which could be provided along with shipping 257 information. 259 TLS uses X.509 certificates by default. To use X.509 certificates 260 with SSH, implementations should reference [RFC6187]. 262 8. Configuration Data Model 264 How to configure a network element to initiate a NETCONF Call Home 265 connection is outside the scope of this document, as implementations 266 can support this protocol using proprietary configuration data 267 models. That said, a YANG [RFC6020] model configuring NETCONF Call 268 Home is provided in [draft-ietf-netconf-server-model]. 270 9. Security Considerations 272 The security considerations described throughout [RFC6242] and 273 [RFC5539], and by extension [RFC4253] and [RFC5246], apply here as 274 well. 276 This RFC deviates from standard SSH and TLS usage by having the SSH/ 277 TLS server initiate the underlying TCP connection. For SSH, 278 [RFC4253] says "the client initiates the connection", whereas for 279 TLS, [RFC5246] says it is layered on top of "some reliable transport 280 protocol" without further attribution. 282 For SSH, not having the SSH client initiate the TCP connection means 283 that it does not have a preconceived notion of the SSH server's 284 identity, and therefore must dynamically derive one from information 285 provided by the network or the SSH server itself. Security 286 Considerations for strategies for this are described in Section 7. 288 An attacker could DoS the management application by having it perform 289 computationally expensive operations, before deducing that the 290 attacker doesn't posses a valid key. This is no different than any 291 secured service and all common precautions apply (e.g., blacklisting 292 the source address after a set number of unsuccessful login 293 attempts). 295 10. IANA Considerations 297 This document requests that IANA assigns two TCP port numbers in the 298 "Registered Port Numbers" range with the service names "netconf-ch- 299 ssh" and "netconf-ch-tls". These ports will be the default ports for 300 NETCONF Call Home protocol when using SSH and TLS respectively. 301 Below is the registration template following the rules in [RFC6335]. 303 Service Name: netconf-ch-ssh 304 Transport Protocol(s): TCP 305 Assignee: IESG 306 Contact: IETF Chair 307 Description: NETCONF Call Home (SSH) 308 Reference: RFC XXXX 309 Port Number: YYYY 311 Service Name: netconf-ch-tls 312 Transport Protocol(s): TCP 313 Assignee: IESG 314 Contact: IETF Chair 315 Description: NETCONF Call Home (TLS) 316 Reference: RFC XXXX 317 Port Number: ZZZZ 319 11. Acknowledgements 321 The author would like to thank for following for lively discussions 322 on list and in the halls (ordered by last name): Andy Bierman, Martin 323 Bjorklund, Mehmet Ersue, Wes Hardaker, Stephen Hanna, David 324 Harrington, Jeffrey Hutzelman, Radek Krejci, Alan Luchuk, Mouse, Russ 325 Mundy, Tom Petch, Peter Saint-Andre, Joe Touch, Sean Turner, Bert 326 Wijnen. 328 12. References 329 12.1. Normative References 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, March 1997. 334 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 335 Protocol Architecture", RFC 4251, January 2006. 337 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 338 Authentication Protocol", RFC 4252, January 2006. 340 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 341 Transport Layer Protocol", RFC 4253, January 2006. 343 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 344 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 346 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", 347 RFC 5539, May 2009. 349 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 350 Network Configuration Protocol (NETCONF)", RFC 6020, 351 October 2010. 353 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 354 Shell Authentication", RFC 6187, March 2011. 356 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 357 Shell (SSH)", RFC 6242, June 2011. 359 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 360 Cheshire, "Internet Assigned Numbers Authority (IANA) 361 Procedures for the Management of the Service Name and 362 Transport Protocol Port Number Registry", BCP 165, RFC 363 6335, August 2011. 365 12.2. Informative References 367 [Std-802.1AR-2009] 368 IEEE SA-Standards Board, "IEEE Standard for Local and 369 metropolitan area networks - Secure Device Identity", 370 December 2009, . 373 [draft-ietf-netconf-server-model] 374 Watsen, K. and J. Schoenwaelder, "NETCONF Server 375 Configuration Model", 2014, . 378 [iesg-statement] 379 "Writable MIB Module IESG Statement", March 2014, 380 . 383 Author's Address 385 Kent Watsen 386 Juniper Networks 388 EMail: kwatsen@juniper.net