idnits 2.17.1 draft-ietf-netconf-call-home-12.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 : ---------------------------------------------------------------------------- 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 date (November 23, 2015) is 3076 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 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 Intended status: Standards Track November 23, 2015 5 Expires: May 26, 2016 7 NETCONF Call Home and RESTCONF Call Home 8 draft-ietf-netconf-call-home-12 10 Abstract 12 This RFC presents NETCONF Call Home and RESTCONF Call Home, which 13 enable a NETCONF or RESTCONF server to initiate a secure connection 14 to a NETCONF or RESTCONF client respectively. 16 Editorial Note (To be removed by RFC Editor) 18 This draft contains many placeholder values that need to be replaced 19 with finalized values at the time of publication. This note 20 summarizes all of the substitutions that are needed. Please note 21 that no other RFC Editor instructions are specified anywhere else in 22 this document. 24 Artwork in this document contains placeholder references for this 25 draft. Please apply the following replacement: 27 o "XXXX" --> the assigned RFC value for this draft 29 This document contains references to another draft in progress, both 30 in the Normative References section, as well as in body text 31 throughout. Please update the following reference to reflect its 32 final RFC assignment: 34 o draft-ietf-netconf-restconf 36 Artwork in this document contains placeholder values for ports 37 pending IANA assignment from "draft-ietf-netconf-call-home". Please 38 apply the following replacements: 40 o "PORT-X" --> the assigned port value for "netconf-ch-ssh" 42 o "PORT-Y" --> the assigned port value for "netconf-ch-tls" 44 o "PORT-Z" --> the assigned port value for "restconf-ch-tls" 46 The following two Appendix sections are to be removed prior to 47 publication: 49 o Appendix A. Change Log 51 o Appendix B. Open Issues 53 Status of This Memo 55 This Internet-Draft is submitted in full conformance with the 56 provisions of BCP 78 and BCP 79. 58 Internet-Drafts are working documents of the Internet Engineering 59 Task Force (IETF). Note that other groups may also distribute 60 working documents as Internet-Drafts. The list of current Internet- 61 Drafts is at http://datatracker.ietf.org/drafts/current/. 63 Internet-Drafts are draft documents valid for a maximum of six months 64 and may be updated, replaced, or obsoleted by other documents at any 65 time. It is inappropriate to use Internet-Drafts as reference 66 material or to cite them other than as "work in progress." 68 This Internet-Draft will expire on May 26, 2016. 70 Copyright Notice 72 Copyright (c) 2015 IETF Trust and the persons identified as the 73 document authors. All rights reserved. 75 This document is subject to BCP 78 and the IETF Trust's Legal 76 Provisions Relating to IETF Documents 77 (http://trustee.ietf.org/license-info) in effect on the date of 78 publication of this document. Please review these documents 79 carefully, as they describe your rights and restrictions with respect 80 to this document. Code Components extracted from this document must 81 include Simplified BSD License text as described in Section 4.e of 82 the Trust Legal Provisions and are provided without warranty as 83 described in the Simplified BSD License. 85 Table of Contents 87 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 88 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 89 1.2. Requirements Terminology . . . . . . . . . . . . . . . . 5 90 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 5 91 1.4. Relation to RFC 4253 . . . . . . . . . . . . . . . . . . 5 92 1.5. The NETCONF/RESTCONF Convention . . . . . . . . . . . . . 5 93 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 94 3. The NETCONF or RESTCONF Client . . . . . . . . . . . . . . . 6 95 3.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 6 96 3.2. Configuration Data Model . . . . . . . . . . . . . . . . 8 98 4. The NETCONF or RESTCONF Server . . . . . . . . . . . . . . . 8 99 4.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 8 100 4.2. Configuration Data Model . . . . . . . . . . . . . . . . 9 101 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 102 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 103 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 104 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 105 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 106 8.2. Informative References . . . . . . . . . . . . . . . . . 13 107 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 108 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 15 109 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 15 110 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 15 111 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 15 112 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 15 113 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 16 114 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 16 115 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 16 116 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 16 117 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 16 118 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 16 119 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 16 120 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 17 121 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 123 1. Introduction 125 This RFC presents NETCONF Call Home and RESTCONF Call Home, which 126 enable a NETCONF or RESTCONF server to initiate a secure connection 127 to a NETCONF or RESTCONF client respectively. 129 NETCONF Call Home supports both of the secure transports used by the 130 NETCONF protocol [RFC6241], SSH and TLS. The NETCONF protocol's 131 binding to SSH is defined in [RFC6242]. The NETCONF protocol's 132 binding to TLS is defined in [RFC7589]. 134 RESTCONF Call Home only supports TLS, the same as the RESTCONF 135 protocol [draft-ietf-netconf-restconf]. The RESTCONF protocol's 136 binding to TLS is defined in [draft-ietf-netconf-restconf]. 138 The SSH protocol is defined in [RFC4253]. The TLS protocol is 139 defined in [RFC5246]. Both the SSH and TLS protocols are layered on 140 top of the TCP protocol, which is defined in [RFC793]. 142 Both NETCONF Call Home and RESTCONF Call Home preserve all but one of 143 the client/server roles in their respective protocol stacks, as 144 compared to client-initiated NETCONF and RESTCONF connections. The 145 one and only role reversal that occurs is at the TCP layer; that is, 146 which peer is the TCP-client and which is the TCP-server. 148 For example, a network element is traditionally the TCP-server. 149 However, when calling home, the network element becomes the TCP- 150 client. The network element's secure transport layer roles (SSH- 151 server, TLS-server) and its application layer roles (NETCONF-server, 152 RESTCONF-server) both remain the same. 154 Having consistency in both the secure transport layer (SSH, TLS) and 155 application layer (NETCONF, RESTCONF) roles conveniently enables 156 deployed network management infrastructure to support call home also. 157 For instance, existing certificate chains and user authentication 158 mechanisms are unaffected by call home. 160 1.1. Motivation 162 Call home is generally useful for both the initial deployment and on- 163 going management of networking elements. Here are some scenarios 164 enabled by call home: 166 o The network element may proactively call home after being powered 167 on for the first time in order to register itself with its 168 management system. 170 o The network element may access the network in a way that 171 dynamically assigns it an IP address, but does not register its 172 assigned IP address to a mapping service (e.g., dynamic DNS). 174 o The network element may be deployed behind a firewall that 175 implements network address translation (NAT) for all internal 176 network IP addresses. 178 o The network element may be deployed behind a firewall that doesn't 179 allow any management access to the internal network. 181 o The network element may be configured in "stealth mode" and thus 182 doesn't have any open ports for the management system to connect 183 to. 185 o The operator may prefer to have network elements initiate 186 management connections, believing it is easier to secure one open 187 port in the data center than to have an open port on each network 188 element in the network. 190 1.2. Requirements Terminology 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in RFC 2119 [RFC2119]. 196 1.3. Applicability Statement 198 The techniques described in this document are suitable for network 199 management scenarios such as the ones described in Section 1.1. 200 However, these techniques are only defined for NETCONF Call Home and 201 RESTCONF Call Home, as described in this document. 203 The reason for this restriction is that different protocols have 204 different security assumptions. The NETCONF and RESTCONF protocols 205 require clients and servers to verify the identity of the other 206 party. This requirement is specified for the NETCONF protocol in 207 Section 2.2 of [RFC6241], and is specified for the RESTCONF protocol 208 in Sections 2.4 and 2.5 of [draft-ietf-netconf-restconf]). 210 This contrasts with the base SSH and TLS protocols, which do not 211 require programmatic verification of the other party (section 9.3.4 212 of [RFC4251], section 4 of [RFC4252], and section 7.3 of [RFC5246]). 213 In such circumstances, allowing the SSH/TLS server to contact the 214 SSH/TLS client would open new vulnerabilities. Any use of call home 215 with SSH/TLS for purposes other than NETCONF or RESTCONF will need a 216 thorough, contextual security analysis, similar to that performed in 217 the process of publishing this document. 219 1.4. Relation to RFC 4253 221 This document uses the SSH Transport Layer Protocol [RFC4253] with 222 the exception that the statement "The client initiates the 223 connection" made in Section 4 (Connection Setup) does not apply. 224 Assuming the reference to client means "SSH client" and the reference 225 to connection means "TCP connection", this statement doesn't hold 226 true in call home, where the network element is the SSH server and 227 yet still initiates the TCP connection. Security implications 228 related to this change are discussed in Security Considerations 229 (Section 5). 231 1.5. The NETCONF/RESTCONF Convention 233 Throughout the remainder of this document, the term "NETCONF/ 234 RESTCONF" is used as an abbreviation in place of the text "the 235 NETCONF or the RESTCONF". The NETCONF/RESTCONF abbreviation is not 236 intended to require or to imply that a client or server must 237 implement both the NETCONF standard and the RESTCONF standard. 239 2. Solution Overview 241 The diagram below illustrates call home from a protocol layering 242 perspective: 244 NETCONF/RESTCONF NETCONF/RESTCONF 245 Server Client 246 | | 247 | 1. TCP | 248 |----------------------------------->| 249 | | 250 | | 251 | 2. SSH/TLS | 252 |<-----------------------------------| 253 | | 254 | | 255 | 3. NETCONF/RESTCONF | 256 |<-----------------------------------| 257 | | 259 Note: arrows point from the "client" to 260 the "server" at each protocol layer 262 This diagram makes the following points: 264 1. The NETCONF/RESTCONF server begins by initiating a TCP connection 265 to the NETCONF/RESTCONF client. 267 2. Using this TCP connection, the NETCONF/RESTCONF client initiates 268 a SSH/TLS session to the NETCONF/RESTCONF server. 270 3. Using this SSH/TLS session, the NETCONF/RESTCONF client intiates 271 a NETCONF/RESTCONF session to the NETCONF/RESTCONF server. 273 3. The NETCONF or RESTCONF Client 275 The term "client" is defined in [RFC6241], Section 1.1 "client". In 276 the context of network management, the NETCONF/RESTCONF client might 277 be a network management system. 279 3.1. Protocol Operation 281 C1 The NETCONF/RESTCONF client listens for TCP connection requests 282 from NETCONF/RESTCONF servers. The client MUST support accepting 283 TCP connections on the IANA-assigned ports defined in Section 6, 284 but MAY be configured to listen a defferent port. 286 C2 The NETCONF/RESTCONF client accepts an incoming TCP connection 287 request and a TCP connection is established. 289 C3 Using this TCP connection, the NETCONF/RESTCONF client starts 290 either the SSH-client [RFC4253] or the TLS-client [RFC5246] 291 protocol. For example, assuming the use of the IANA-assigned 292 ports, the SSH-client protocol is started when the connection is 293 accepted on port PORT-X and the TLS-client protocol is started 294 when the connection is accepted on either port PORT-Y or PORT-Z. 296 C4 If using TLS, the NETCONF/RESTCONF client MUST advertise 297 "peer_allowed_to_send", as defined by [RFC6520]. This is 298 required so NETCONF/RESTCONF servers can depend on it being there 299 for call home connections, when keep-alives are needed the most. 301 C5 As part of establishing an SSH or TLS connection, the NETCONF/ 302 RESTCONF client MUST validate the server's presented host key or 303 certificate. This validation MAY be accomplished by certificate 304 path validation or by comparing the host key or certificate to a 305 previously trusted or "pinned" value. If a certificate is 306 presented and it contains revocation checking information, the 307 NETCONF/RESTCONF client SHOULD check the revocation status of the 308 certificate. If it is determined that a certificate has been 309 revoked, the client MUST immediately close the connection. 311 C6 If certificate path validation is used, the NETCONF/RESTCONF 312 client MUST ensure that the presented certificate has a valid 313 chain of trust to a preconfigured Issuer and that the presented 314 certificate encodes an "identifier" [RFC6125] that the client had 315 awareness of prior to the connection attempt. Clients SHOULD 316 ensure that the Issuer used to authenticate the presented 317 certificate defines the namespace for the identifiers of 318 interest. How identifiers are encoded in certificates MAY be 319 determined by a policy associated with the certificate's Issuer. 320 For instance, a given Issuer may be known to only sign IDevID 321 certificates [Std-802.1AR-2009] having a unique identifier (e.g., 322 serial number) in the X.509 certificate's "CommonName" field. 324 C7 After the server's host key or certificate is validated, the SSH 325 or TLS protocol proceeds as normal to establish a SSH or TLS 326 connection. When performing client-authentcation with the 327 NETCONF/RESTCONF server, the NETCONF/RESTCONF client MUST ensure 328 to only use credentials that it had previously associated for the 329 NETCONF/RESTCONF server's presented host key or server 330 certificate. 332 C8 Once the SSH or TLS connection is established, the NETCONF/ 333 RESTCONF client starts either the NETCONF-client [RFC6241] or 334 RESTCONF-client [draft-ietf-netconf-restconf] protocol. Assuming 335 the use of the IANA-assigned ports, the NETCONF-client protocol 336 is started when the connection is accepted on either port PORT-X 337 or PORT-Y and the RESTCONF-client protocol is started when the 338 connection is accepted on port PORT-Z. 340 3.2. Configuration Data Model 342 How a NETCONF or RESTCONF client is configured is outside the scope 343 of this document. For instance, such configuration might be used to 344 enable listening for call home connections, configuring trust 345 anchors, or configuring identifiers for expected connections. 347 4. The NETCONF or RESTCONF Server 349 The term "server" is defined in [RFC6241], Section 1.1 "server". In 350 the context of network management, the NETCONF/RESTCONF server might 351 be a network element or a device. 353 4.1. Protocol Operation 355 S1 The NETCONF/RESTCONF server initiates a TCP connection request to 356 the NETCONF/RESTCONF client. The server MUST support connecting 357 to one of the IANA-assigned ports defined in Section 6, but MAY 358 be configured to connect to a different port. Using the IANA- 359 assigned ports, the server connects to port PORT-X for NETCONF 360 over SSH, port PORT-Y for NETCONF over TLS, and port PORT-Z for 361 RESTCONF over TLS. 363 S2 The TCP connection request is accepted and a TCP connection is 364 established. 366 S3 Using this TCP connection, the NETCONF/RESTCONF server starts 367 either the SSH-server [RFC4253] or the TLS-server [RFC5246] 368 protocol, depending on how it is configured. For example, 369 assuming the use of the IANA-assigned ports, the SSH-server 370 protocol is used after connecting to the remote port PORT-X and 371 the TLS-server protocol is used after connecting to one of the 372 remote ports PORT-Y or PORT-Z. 374 S4 As part of establishing the SSH or TLS connection, the NETCONF/ 375 RESTCONF server will send its host key or certificate to the 376 client. If a certificate is sent, the server MUST also send all 377 intermediate certificates leading up to the certificate's trust 378 anchor. How to send a list of certificates is defined for SSH in 379 [RFC6187] Section 2.1, and for TLS in [RFC5246] Section 7.4.2. 381 S5 Establishing an SSH or TLS session requires server authentication 382 of client credentials in all cases except with RESTCONF, where 383 some client authentication schemes occur after the secure 384 transport connection (TLS) has been established. If transport 385 (SSH or TLS) level client authentication is required, and the 386 client is unable to successfully authenticate itself to the 387 server in an amount of time defined by local policy, the server 388 MUST close the connection. 390 S6 Once the SSH or TLS connection is established, the NETCONF/ 391 RESTCONF server starts either the NETCONF-server [RFC6241] or 392 RESTCONF-server [draft-ietf-netconf-restconf] protocol, depending 393 on how it is configured. Assuming the use of the IANA-assigned 394 ports, the NETCONF-server protocol is used after connecting to 395 remote port PORT-X or PORT-Y, and the RESTCONF-server protocol is 396 used after connecting to remote port PORT-Z. 398 S7 If a persistent connection is desired, the NETCONF/RESTCONF 399 server, as the connection initiator, SHOULD actively test the 400 aliveness of the connection using a keep-alive mechanism. For 401 TLS based connections, the NETCONF/RESTCONF server SHOULD send 402 HeartbeatRequest messages, as defined by [RFC6520]. For SSH 403 based connections, per section 4 of [RFC4254], the NETCONF/ 404 RESTCONF server SHOULD send a SSH_MSG_GLOBAL_REQUEST message with 405 the purposely nonexistent "request name" value 406 "keepalive@ietf.org" and the "want reply" value set to '1'. 408 4.2. Configuration Data Model 410 How a NETCONF or RESTCONF server is configured is outside the scope 411 of this document. This includes configuration that might be used to 412 specify hostnames, IP addresses, ports, algorithms, or other relevant 413 parameters. That said, a YANG [RFC6020] model for configuring 414 NETCONF and RESTCONF servers, including call home, is provided in 415 [draft-ietf-netconf-server-model]. 417 5. Security Considerations 419 The security considerations described in [RFC6242] and [RFC7589], and 420 by extension [RFC4253], [RFC5246], and [draft-ietf-netconf-restconf] 421 apply here as well. 423 This RFC deviates from standard SSH and TLS usage by having the SSH/ 424 TLS server initiate the underlying TCP connection. This reversal is 425 incongruous with [RFC4253], which says "the client initiates the 426 connection" and also [RFC6125], which says "the client MUST construct 427 a list of acceptable reference identifiers, and MUST do so 428 independently of the identifiers presented by the service." To 429 account for these variances, this RFC requires that the NETCONF/ 430 RESTCONF client validate the SSH host key or certificate via 431 certificate path validation to a preconfigured Issuer certificate or 432 by comparing the host key or certificate to a previously trusted or 433 "pinned" value. Furthermore, if certificate path validation is used, 434 this RFC requires that the client be able to match a presented 435 identifier encoded in the certificate with an identifier the client 436 was preconfigured to expect. 438 Internet facing hosts running NETCONF or RESTCONF call home will be 439 fingerprinted via scanning tools such as `zmap` [zmap]. Both SSH and 440 TLS provide many ways in which a device can be fingerprinted. SSH 441 and TLS servers are fairly mature and able to withstand an attack, 442 but SSH and clients may not be as robust. Implementers and 443 deployments needs to ensure that software update mechanisms are 444 provided so that vulnerabilities can be fixed in a timely fashion. 446 An attacker could launch a denial of service (DoS) attack on the 447 NETCONF/RESTCONF client by having it perform computationally 448 expensive operations, before deducing that the attacker doesn't 449 posses a valid key. For instance, in TLS 1.3 [draft-ietf-tls-tls13], 450 the ClientHello message contains a Key Share value based on an 451 asymmetric key operation. This is similar to any other secured 452 service and all common precautions apply (e.g., temporarily 453 blacklisting the source address after a set number of unsuccessful 454 login attempts). 456 For cases when the NETCONF/RESTCONF server presents an X.509 457 certificate, the NETCONF/RESTCONF client needs to ensure that the 458 Issuer cartificate used for certificate path validation is unique to 459 the manufacturer of the server (e.g., not a global CA such as 460 Verisign). This is especially important when the client- 461 authentication mechanism passes a shared secret (e.g., a password) to 462 the server. Not doing so could otherwise lead to a case where the 463 client sends the shared secret to another device that happens to have 464 the same identity value (e.g., serial number) as the server the 465 client was configured to expect. 467 When using call home with the RESTCONF protocol, special care is 468 required when using some HTTP authentication mechanisms, especially 469 the Basic [RFC7617] and Digest [RFC7616] authentication schemes, 470 which convey a shared key. Implementations and deployments should be 471 sure to review the Security Considerations section for any client 472 authentication scheme used. 474 6. IANA Considerations 476 This RFC requests that IANA assigns three TCP port numbers in the 477 "Registered Port Numbers" range with the service names "netconf-ch- 478 ssh", "netconf-ch-tls", and "restconf-ch-tls". These ports will be 479 the default ports for NETCONF Call Home and RESTCONF Call Home 480 protocols. Below is the registration template following the rules in 481 [RFC6335]. 483 Service Name: netconf-ch-ssh 484 Transport Protocol(s): TCP 485 Assignee: IESG 486 Contact: IETF Chair 487 Description: NETCONF Call Home (SSH) 488 Reference: RFC XXXX 489 Port Number: PORT-X 491 Service Name: netconf-ch-tls 492 Transport Protocol(s): TCP 493 Assignee: IESG 494 Contact: IETF Chair 495 Description: NETCONF Call Home (TLS) 496 Reference: RFC XXXX 497 Port Number: PORT-Y 499 Service Name: restconf-ch-tls 500 Transport Protocol(s): TCP 501 Assignee: IESG 502 Contact: IETF Chair 503 Description: RESTCONF Call Home (TLS) 504 Reference: RFC XXXX 505 Port Number: PORT-Z 507 7. Acknowledgements 509 The author would like to thank the following for lively discussions 510 on list and in the halls (ordered by last name): Andy Bierman, Martin 511 Bjorklund, Mehmet Ersue, Wes Hardaker, Stephen Hanna, David 512 Harrington, Jeffrey Hutzelman, Radek Krejci, Alan Luchuk, Mouse, Russ 513 Mundy, Tom Petch, Juergen Schoenwaelder, Peter Saint-Andre, Joe 514 Touch, Hannes Tschofenig, Sean Turner, and Bert Wijnen. 516 8. References 517 8.1. Normative References 519 [draft-ietf-netconf-restconf] 520 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 521 Protocol", draft-ieft-netconf-restconf-04 (work in 522 progress), 2014, . 525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 526 Requirement Levels", BCP 14, RFC 2119, 527 DOI 10.17487/RFC2119, March 1997, 528 . 530 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 531 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 532 January 2006, . 534 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 535 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, 536 January 2006, . 538 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 539 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 540 January 2006, . 542 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 543 Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, 544 January 2006, . 546 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 547 (TLS) Protocol Version 1.2", RFC 5246, 548 DOI 10.17487/RFC5246, August 2008, 549 . 551 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 552 Verification of Domain-Based Application Service Identity 553 within Internet Public Key Infrastructure Using X.509 554 (PKIX) Certificates in the Context of Transport Layer 555 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 556 2011, . 558 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 559 Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, 560 March 2011, . 562 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 563 and A. Bierman, Ed., "Network Configuration Protocol 564 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 565 . 567 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 568 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 569 . 571 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 572 Cheshire, "Internet Assigned Numbers Authority (IANA) 573 Procedures for the Management of the Service Name and 574 Transport Protocol Port Number Registry", BCP 165, 575 RFC 6335, DOI 10.17487/RFC6335, August 2011, 576 . 578 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 579 Layer Security (TLS) and Datagram Transport Layer Security 580 (DTLS) Heartbeat Extension", RFC 6520, 581 DOI 10.17487/RFC6520, February 2012, 582 . 584 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 585 NETCONF Protocol over Transport Layer Security (TLS) with 586 Mutual X.509 Authentication", RFC 7589, 587 DOI 10.17487/RFC7589, June 2015, 588 . 590 [RFC793] Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, 591 September 1981, . 593 8.2. Informative References 595 [draft-ietf-netconf-server-model] 596 Watsen, K. and J. Schoenwaelder, "NETCONF Server 597 Configuration Model", 2014, . 600 [draft-ietf-tls-tls13] 601 Rescorla, E., "The Transport Layer Security (TLS) Protocol 602 Version 1.3", 2015, 603 . 605 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 606 the Network Configuration Protocol (NETCONF)", RFC 6020, 607 DOI 10.17487/RFC6020, October 2010, 608 . 610 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 611 Digest Access Authentication", RFC 7616, 612 DOI 10.17487/RFC7616, September 2015, 613 . 615 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 616 RFC 7617, DOI 10.17487/RFC7617, September 2015, 617 . 619 [Std-802.1AR-2009] 620 IEEE SA-Standards Board, "IEEE Standard for Local and 621 metropolitan area networks - Secure Device Identity", 622 December 2009, . 625 [zmap] Durumeric, Z., Wustrow, E., and J. Halderman, "ZMap: Fast 626 Internet-Wide Scanning and its Security Applications", 627 2013, . 629 In proceedings of the 22nd USENIX Security Symposium 631 Appendix A. Change Log 633 A.1. 00 to 01 635 o The term "TCP connection" is now used throughout. 637 o The terms "network element" and "management system" are now only 638 used in the Motivation section. 640 o Restructured doc a little to create an Introduction section. 642 o Fixed reference in Applicability Statement so it would work 643 equally well for SSH and TLS. 645 o Fixed reported odd wording and three references. 647 A.2. 01 to 02 649 o Added call home support for the RESTCONF protocol. 651 o Fixed paragraph 3 of Security Considerations to equally apply to 652 the TLS protocol. 654 A.3. 02 to 03 656 o Tried to improve readability (issue #6) 658 o Removed "FIXME" in section 1.3 (issue #7) 660 o Added RFC Editor notes (issue #8) 662 o Removed "TCP session" term (issue #9) 664 o Improved language for usage of IANA-assigned ports (issue #10) 666 A.4. 03 to 04 668 o Replaced "verify credentials" with "verify identity" (issue #11) 670 A.5. 04 to 05 672 o Applied many suggestions from WGLC 674 o Removed essay like "Server Identification and Verification" 675 section 677 o Added text about keep-alives 678 o Added Configuration Data Model section for client protocol 680 o Improved Security Considerations section 682 A.6. 05 to 06 684 o Addressed comments raised by Alan Luchuk. 686 A.7. 06 to 07 688 o replaced "reference identifier" with "identifier" 690 o added reference to RFC6125 692 o moved reference to 6020 to Informative section 694 A.8. 07 to 08 696 o Added text regarding client authentication 698 o Now says client-initiated (not standard) NETCONF/RESTCONF 699 connections 701 o Now says server must send all (not any) intermediate certificates 703 o Improved wording based on suggestions from Jonathan and Tom 705 A.9. 08 to 09 707 o Added dynamic DNS as an example for an IP mapping service 709 o Replaced draft-ietf-netconf-rfc5539bis with RFC7589 711 o Recharacterized this draft's relationship to RFC4253 713 A.10. 09 to 10 715 o Updates from AD review 717 A.11. 10 to 11 719 o Fixed typo introduced in -10 721 A.12. 11 to 12 723 o Addresses DISCUSS and COMMENTS from IESG review. 725 Appendix B. Open Issues 727 All issues with this draft are tracked using GitHub issues. Please 728 see: https://github.com/netconf-wg/call-home/issues to see currently 729 opened issues. 731 Author's Address 733 Kent Watsen 734 Juniper Networks 736 EMail: kwatsen@juniper.net