idnits 2.17.1 draft-ietf-netconf-call-home-15.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 (December 14, 2015) is 3055 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 December 14, 2015 5 Expires: June 16, 2016 7 NETCONF Call Home and RESTCONF Call Home 8 draft-ietf-netconf-call-home-15 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 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on June 16, 2016. 63 Copyright Notice 65 Copyright (c) 2015 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 82 1.2. Requirements Terminology . . . . . . . . . . . . . . . . 4 83 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4 84 1.4. Relation to RFC 4253 . . . . . . . . . . . . . . . . . . 5 85 1.5. The NETCONF/RESTCONF Convention . . . . . . . . . . . . . 5 86 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 87 3. The NETCONF or RESTCONF Client . . . . . . . . . . . . . . . 6 88 3.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 6 89 3.2. Configuration Data Model . . . . . . . . . . . . . . . . 8 90 4. The NETCONF or RESTCONF Server . . . . . . . . . . . . . . . 8 91 4.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 8 92 4.2. Configuration Data Model . . . . . . . . . . . . . . . . 9 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 95 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 97 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 98 8.2. Informative References . . . . . . . . . . . . . . . . . 13 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 101 1. Introduction 103 This RFC presents NETCONF Call Home and RESTCONF Call Home, which 104 enable a NETCONF or RESTCONF server to initiate a secure connection 105 to a NETCONF or RESTCONF client respectively. 107 NETCONF Call Home supports both of the secure transports used by the 108 NETCONF protocol [RFC6241], SSH and TLS. The NETCONF protocol's 109 binding to SSH is defined in [RFC6242]. The NETCONF protocol's 110 binding to TLS is defined in [RFC7589]. 112 RESTCONF Call Home only supports TLS, the same as the RESTCONF 113 protocol [draft-ietf-netconf-restconf]. The RESTCONF protocol's 114 binding to TLS is defined in [draft-ietf-netconf-restconf]. 116 The SSH protocol is defined in [RFC4253]. The TLS protocol is 117 defined in [RFC5246]. Both the SSH and TLS protocols are layered on 118 top of the TCP protocol, which is defined in [RFC793]. 120 Both NETCONF Call Home and RESTCONF Call Home preserve all but one of 121 the client/server roles in their respective protocol stacks, as 122 compared to client initiated NETCONF and RESTCONF connections. The 123 one and only role reversal that occurs is at the TCP layer; that is, 124 which peer is the TCP-client and which is the TCP-server. 126 For example, a network element is traditionally the TCP-server. 127 However, when calling home, the network element becomes the TCP- 128 client. The network element's secure transport layer roles (SSH- 129 server, TLS-server) and its application layer roles (NETCONF-server, 130 RESTCONF-server) both remain the same. 132 Having consistency in both the secure transport layer (SSH, TLS) and 133 application layer (NETCONF, RESTCONF) roles conveniently enables 134 deployed network management infrastructure to support call home also. 135 For instance, existing certificate chains and user authentication 136 mechanisms are unaffected by call home. 138 1.1. Motivation 140 Call home is generally useful for both the initial deployment and on- 141 going management of networking elements. Here are some scenarios 142 enabled by call home: 144 o The network element may proactively call home after being powered 145 on for the first time in order to register itself with its 146 management system. 148 o The network element may access the network in a way that 149 dynamically assigns it an IP address, but does not register its 150 assigned IP address to a mapping service (e.g., dynamic DNS). 152 o The network element may be deployed behind a firewall that 153 implements network address translation (NAT) for all internal 154 network IP addresses. 156 o The network element may be deployed behind a firewall that doesn't 157 allow any management access to the internal network. 159 o The network element may be configured in "stealth mode" and thus 160 doesn't have any open ports for the management system to connect 161 to. 163 o The operator may prefer to have network elements initiate 164 management connections, believing it is easier to secure one open 165 port in the data center than to have an open port on each network 166 element in the network. 168 1.2. Requirements Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 174 1.3. Applicability Statement 176 The techniques described in this document are suitable for network 177 management scenarios such as the ones described in Section 1.1. 178 However, these techniques are only defined for NETCONF Call Home and 179 RESTCONF Call Home, as described in this document. 181 The reason for this restriction is that different protocols have 182 different security assumptions. The NETCONF and RESTCONF protocols 183 require clients and servers to verify the identity of the other 184 party. This requirement is specified for the NETCONF protocol in 185 Section 2.2 of [RFC6241], and is specified for the RESTCONF protocol 186 in Sections 2.4 and 2.5 of [draft-ietf-netconf-restconf]). 188 This contrasts with the base SSH and TLS protocols, which do not 189 require programmatic verification of the other party (section 9.3.4 190 of [RFC4251], section 4 of [RFC4252], and section 7.3 of [RFC5246]). 191 In such circumstances, allowing the SSH/TLS server to contact the 192 SSH/TLS client would open new vulnerabilities. Any use of call home 193 with SSH/TLS for purposes other than NETCONF or RESTCONF will need a 194 thorough contextual risk assessment. A risk assessment for this RFC 195 is in the Security Considerations section (Section 5). 197 1.4. Relation to RFC 4253 199 This document uses the SSH Transport Layer Protocol [RFC4253] with 200 the exception that the statement "The client initiates the 201 connection" made in Section 4 (Connection Setup) does not apply. 202 Assuming the reference to client means "SSH client" and the reference 203 to connection means "TCP connection", this statement doesn't hold 204 true in call home, where the network element is the SSH server and 205 yet still initiates the TCP connection. Security implications 206 related to this change are discussed in Security Considerations 207 (Section 5). 209 1.5. The NETCONF/RESTCONF Convention 211 Throughout the remainder of this document, the term "NETCONF/ 212 RESTCONF" is used as an abbreviation in place of the text "the 213 NETCONF or the RESTCONF". The NETCONF/RESTCONF abbreviation is not 214 intended to require or to imply that a client or server must 215 implement both the NETCONF standard and the RESTCONF standard. 217 2. Solution Overview 219 The diagram below illustrates call home from a protocol layering 220 perspective: 222 NETCONF/RESTCONF NETCONF/RESTCONF 223 Server Client 224 | | 225 | 1. TCP | 226 |----------------------------------->| 227 | | 228 | | 229 | 2. SSH/TLS | 230 |<-----------------------------------| 231 | | 232 | | 233 | 3. NETCONF/RESTCONF | 234 |<-----------------------------------| 235 | | 237 Note: arrows point from the "client" to 238 the "server" at each protocol layer 240 This diagram makes the following points: 242 1. The NETCONF/RESTCONF server begins by initiating a TCP connection 243 to the NETCONF/RESTCONF client. 245 2. Using this TCP connection, the NETCONF/RESTCONF client initiates 246 a SSH/TLS session to the NETCONF/RESTCONF server. 248 3. Using this SSH/TLS session, the NETCONF/RESTCONF client initates 249 a NETCONF/RESTCONF session to the NETCONF/RESTCONF server. 251 3. The NETCONF or RESTCONF Client 253 The term "client" is defined in [RFC6241], Section 1.1 "client". In 254 the context of network management, the NETCONF/RESTCONF client might 255 be a network management system. 257 3.1. Protocol Operation 259 C1 The NETCONF/RESTCONF client listens for TCP connection requests 260 from NETCONF/RESTCONF servers. The client MUST support accepting 261 TCP connections on the IANA-assigned ports defined in Section 6, 262 but MAY be configured to listen a different port. 264 C2 The NETCONF/RESTCONF client accepts an incoming TCP connection 265 request and a TCP connection is established. 267 C3 Using this TCP connection, the NETCONF/RESTCONF client starts 268 either the SSH-client [RFC4253] or the TLS-client [RFC5246] 269 protocol. For example, assuming the use of the IANA-assigned 270 ports, the SSH-client protocol is started when the connection is 271 accepted on port PORT-X and the TLS-client protocol is started 272 when the connection is accepted on either port PORT-Y or PORT-Z. 274 C4 If using TLS, the NETCONF/RESTCONF client MUST advertise 275 "peer_allowed_to_send", as defined by [RFC6520]. This is 276 required so NETCONF/RESTCONF servers can depend on it being there 277 for call home connections, when keep-alives are needed the most. 279 C5 As part of establishing an SSH or TLS connection, the NETCONF/ 280 RESTCONF client MUST validate the server's presented host key or 281 certificate. This validation MAY be accomplished by certificate 282 path validation or by comparing the host key or certificate to a 283 previously trusted or "pinned" value. If a certificate is 284 presented and it contains revocation checking information, the 285 NETCONF/RESTCONF client SHOULD check the revocation status of the 286 certificate. If it is determined that a certificate has been 287 revoked, the client MUST immediately close the connection. 289 C6 If certificate path validation is used, the NETCONF/RESTCONF 290 client MUST ensure that the presented certificate has a valid 291 chain of trust to a preconfigured Issuer and that the presented 292 certificate encodes an "identifier" [RFC6125] that the client had 293 awareness of prior to the connection attempt. Clients SHOULD 294 ensure that the Issuer used to authenticate the presented 295 certificate defines the namespace for the identifiers of 296 interest. How identifiers are encoded in certificates MAY be 297 determined by a policy associated with the certificate's Issuer. 298 For instance, a given Issuer may be known to only sign IDevID 299 certificates [Std-802.1AR-2009] having a unique identifier (e.g., 300 serial number) in the X.509 certificate's "CommonName" field. 302 C7 After the server's host key or certificate is validated, the SSH 303 or TLS protocol proceeds as normal to establish a SSH or TLS 304 connection. When performing client authentication with the 305 NETCONF/RESTCONF server, the NETCONF/RESTCONF client MUST ensure 306 to only use credentials that it had previously associated for the 307 NETCONF/RESTCONF server's presented host key or server 308 certificate. 310 C8 Once the SSH or TLS connection is established, the NETCONF/ 311 RESTCONF client starts either the NETCONF-client [RFC6241] or 312 RESTCONF-client [draft-ietf-netconf-restconf] protocol. Assuming 313 the use of the IANA-assigned ports, the NETCONF-client protocol 314 is started when the connection is accepted on either port PORT-X 315 or PORT-Y and the RESTCONF-client protocol is started when the 316 connection is accepted on port PORT-Z. 318 3.2. Configuration Data Model 320 How a NETCONF or RESTCONF client is configured is outside the scope 321 of this document. For instance, such configuration might be used to 322 enable listening for call home connections, configuring trust 323 anchors, or configuring identifiers for expected connections. 325 4. The NETCONF or RESTCONF Server 327 The term "server" is defined in [RFC6241], Section 1.1 "server". In 328 the context of network management, the NETCONF/RESTCONF server might 329 be a network element or a device. 331 4.1. Protocol Operation 333 S1 The NETCONF/RESTCONF server initiates a TCP connection request to 334 the NETCONF/RESTCONF client. The server MUST support connecting 335 to one of the IANA-assigned ports defined in Section 6, but MAY 336 be configured to connect to a different port. Using the IANA- 337 assigned ports, the server connects to port PORT-X for NETCONF 338 over SSH, port PORT-Y for NETCONF over TLS, and port PORT-Z for 339 RESTCONF over TLS. 341 S2 The TCP connection request is accepted and a TCP connection is 342 established. 344 S3 Using this TCP connection, the NETCONF/RESTCONF server starts 345 either the SSH-server [RFC4253] or the TLS-server [RFC5246] 346 protocol, depending on how it is configured. For example, 347 assuming the use of the IANA-assigned ports, the SSH-server 348 protocol is used after connecting to the remote port PORT-X and 349 the TLS-server protocol is used after connecting to one of the 350 remote ports PORT-Y or PORT-Z. 352 S4 As part of establishing the SSH or TLS connection, the NETCONF/ 353 RESTCONF server will send its host key or certificate to the 354 client. If a certificate is sent, the server MUST also send all 355 intermediate certificates leading up to the certificate's trust 356 anchor. How to send a list of certificates is defined for SSH in 357 [RFC6187] Section 2.1, and for TLS in [RFC5246] Section 7.4.2. 359 S5 Establishing an SSH or TLS session requires server authentication 360 of client credentials in all cases except with RESTCONF, where 361 some client authentication schemes occur after the secure 362 transport connection (TLS) has been established. If transport 363 (SSH or TLS) level client authentication is required, and the 364 client is unable to successfully authenticate itself to the 365 server in an amount of time defined by local policy, the server 366 MUST close the connection. 368 S6 Once the SSH or TLS connection is established, the NETCONF/ 369 RESTCONF server starts either the NETCONF-server [RFC6241] or 370 RESTCONF-server [draft-ietf-netconf-restconf] protocol, depending 371 on how it is configured. Assuming the use of the IANA-assigned 372 ports, the NETCONF-server protocol is used after connecting to 373 remote port PORT-X or PORT-Y, and the RESTCONF-server protocol is 374 used after connecting to remote port PORT-Z. 376 S7 If a persistent connection is desired, the NETCONF/RESTCONF 377 server, as the connection initiator, SHOULD actively test the 378 aliveness of the connection using a keep-alive mechanism. For 379 TLS based connections, the NETCONF/RESTCONF server SHOULD send 380 HeartbeatRequest messages, as defined by [RFC6520]. For SSH 381 based connections, per Section 4 of [RFC4254], the NETCONF/ 382 RESTCONF server SHOULD send a SSH_MSG_GLOBAL_REQUEST message with 383 a purposely nonexistent "request name" value (e.g., 384 keepalive@ietf.org) and the "want reply" value set to '1'. 386 4.2. Configuration Data Model 388 How a NETCONF or RESTCONF server is configured is outside the scope 389 of this document. This includes configuration that might be used to 390 specify hostnames, IP addresses, ports, algorithms, or other relevant 391 parameters. That said, a YANG [RFC6020] model for configuring 392 NETCONF and RESTCONF servers, including call home, is provided in 393 [draft-ietf-netconf-server-model]. 395 5. Security Considerations 397 The security considerations described in [RFC6242] and [RFC7589], and 398 by extension [RFC4253], [RFC5246], and [draft-ietf-netconf-restconf] 399 apply here as well. 401 This RFC deviates from standard SSH and TLS usage by having the SSH/ 402 TLS server initiate the underlying TCP connection. This reversal is 403 incongruous with [RFC4253], which says "the client initiates the 404 connection" and also [RFC6125], which says "the client MUST construct 405 a list of acceptable reference identifiers, and MUST do so 406 independently of the identifiers presented by the service." 407 Risks associated with these variances are centered around server 408 authentication and the inability for clients to compare an 409 independently constructed reference identifier to one presented by 410 the server. To mitigate these risks, this RFC requires that the 411 NETCONF/RESTCONF client validate the server's SSH host key or 412 certificate, by certificate path validation to a preconfigured Issuer 413 certificate, or by comparing the host key or certificate to a 414 previously trusted or "pinned" value. Furthermore, when a 415 certificate is used, this RFC requires that the client be able to 416 match an identifier encoded in the presented certificate with an 417 identifier the client was preconfigured to expect (e.g., serial 418 number). 420 For cases when the NETCONF/RESTCONF server presents an X.509 421 certificate, NETCONF/RESTCONF clients should ensure that the Issuer 422 certificate used for certificate path validation is unique to the 423 manufacturer of the server. That is, the certificate should not 424 belong to a 3rd-party certificate authority that might issue 425 intermediate certificates for more than one manufacturer. This is 426 especially important when a client authentication mechanism passing a 427 shared secret (e.g., a password) to the server is used. Not doing so 428 could otherwise lead to a case where the client sends the shared 429 secret to another server that happens to have the same identity 430 (e.g., serial number) as the server the client was configured to 431 expect. 433 Considerations not associated with server authentication follow next. 435 Internet facing hosts running NETCONF or RESTCONF call home will be 436 fingerprinted via scanning tools such as `zmap` [zmap]. Both SSH and 437 TLS provide many ways in which a host can be fingerprinted. SSH and 438 TLS servers are fairly mature and able to withstand attacks, but SSH 439 and TLS clients may not be as robust. Implementers and deployments 440 need to ensure that software update mechanisms are provided so that 441 vulnerabilities can be fixed in a timely fashion. 443 An attacker could launch a denial of service (DoS) attack on the 444 NETCONF/RESTCONF client by having it perform computationally 445 expensive operations, before deducing that the attacker doesn't 446 posses a valid key. For instance, in TLS 1.3 [draft-ietf-tls-tls13], 447 the ClientHello message contains a Key Share value based on an 448 expensive asymmetric key operation. Common precautions mitigating 449 DoS attacks are recommended, such as temporarily blacklisting the 450 source address after a set number of unsuccessful login attempts. 452 When using call home with the RESTCONF protocol, special care is 453 required when using some HTTP authentication schemes, especially the 454 Basic [RFC7617] and Digest [RFC7616] schemes, which convey a shared 455 key. Implementations and deployments should be sure to review the 456 Security Considerations section in the RFC for any HTTP client 457 authentication scheme used. 459 6. IANA Considerations 461 This RFC requests that IANA assigns three TCP port numbers in the 462 "Registered Port Numbers" range with the service names "netconf-ch- 463 ssh", "netconf-ch-tls", and "restconf-ch-tls". These ports will be 464 the default ports for NETCONF Call Home and RESTCONF Call Home 465 protocols. Below is the registration template following the rules in 466 [RFC6335]. 468 Service Name: netconf-ch-ssh 469 Transport Protocol(s): TCP 470 Assignee: IESG 471 Contact: IETF Chair 472 Description: NETCONF Call Home (SSH) 473 Reference: RFC XXXX 474 Port Number: PORT-X 476 Service Name: netconf-ch-tls 477 Transport Protocol(s): TCP 478 Assignee: IESG 479 Contact: IETF Chair 480 Description: NETCONF Call Home (TLS) 481 Reference: RFC XXXX 482 Port Number: PORT-Y 484 Service Name: restconf-ch-tls 485 Transport Protocol(s): TCP 486 Assignee: IESG 487 Contact: IETF Chair 488 Description: RESTCONF Call Home (TLS) 489 Reference: RFC XXXX 490 Port Number: PORT-Z 492 7. Acknowledgements 494 The author would like to thank the following for lively discussions 495 on list and in the halls (ordered by last name): Jari Arkko, Andy 496 Bierman, Martin Bjorklund, Ben Campbell, Spencer Dawkins, Mehmet 497 Ersue, Stephen Farrell, Wes Hardaker, Stephen Hanna, David 498 Harrington, Jeffrey Hutzelman, Simon Josefsson, Radek Krejci, Suresh 499 Krishnan, Barry Leiba, Alan Luchuk, Kathleen Moriarty, Mouse, Russ 500 Mundy, Tom Petch, Peter Saint-Andre, Joseph Salowey, Juergen 501 Schoenwaelder, Martin Stiemerling, Joe Touch, Hannes Tschofenig, Sean 502 Turner, and Bert Wijnen. 504 8. References 506 8.1. Normative References 508 [draft-ietf-netconf-restconf] 509 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 510 Protocol", draft-ieft-netconf-restconf-04 (work in 511 progress), 2014, . 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, 516 DOI 10.17487/RFC2119, March 1997, 517 . 519 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 520 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 521 January 2006, . 523 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 524 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, 525 January 2006, . 527 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 528 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 529 January 2006, . 531 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 532 Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, 533 January 2006, . 535 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 536 (TLS) Protocol Version 1.2", RFC 5246, 537 DOI 10.17487/RFC5246, August 2008, 538 . 540 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 541 Verification of Domain-Based Application Service Identity 542 within Internet Public Key Infrastructure Using X.509 543 (PKIX) Certificates in the Context of Transport Layer 544 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 545 2011, . 547 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 548 Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, 549 March 2011, . 551 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 552 and A. Bierman, Ed., "Network Configuration Protocol 553 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 554 . 556 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 557 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 558 . 560 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 561 Cheshire, "Internet Assigned Numbers Authority (IANA) 562 Procedures for the Management of the Service Name and 563 Transport Protocol Port Number Registry", BCP 165, 564 RFC 6335, DOI 10.17487/RFC6335, August 2011, 565 . 567 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 568 Layer Security (TLS) and Datagram Transport Layer Security 569 (DTLS) Heartbeat Extension", RFC 6520, 570 DOI 10.17487/RFC6520, February 2012, 571 . 573 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 574 NETCONF Protocol over Transport Layer Security (TLS) with 575 Mutual X.509 Authentication", RFC 7589, 576 DOI 10.17487/RFC7589, June 2015, 577 . 579 [RFC793] Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, 580 September 1981, . 582 8.2. Informative References 584 [draft-ietf-netconf-server-model] 585 Watsen, K. and J. Schoenwaelder, "NETCONF Server 586 Configuration Model", 2014, . 589 [draft-ietf-tls-tls13] 590 Rescorla, E., "The Transport Layer Security (TLS) Protocol 591 Version 1.3", 2015, 592 . 594 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 595 the Network Configuration Protocol (NETCONF)", RFC 6020, 596 DOI 10.17487/RFC6020, October 2010, 597 . 599 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 600 Digest Access Authentication", RFC 7616, 601 DOI 10.17487/RFC7616, September 2015, 602 . 604 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 605 RFC 7617, DOI 10.17487/RFC7617, September 2015, 606 . 608 [Std-802.1AR-2009] 609 IEEE SA-Standards Board, "IEEE Standard for Local and 610 metropolitan area networks - Secure Device Identity", 611 December 2009, . 614 [zmap] Durumeric, Z., Wustrow, E., and J. Halderman, "ZMap: Fast 615 Internet-Wide Scanning and its Security Applications", 616 2013, . 618 In proceedings of the 22nd USENIX Security Symposium 620 Author's Address 622 Kent Watsen 623 Juniper Networks 625 EMail: kwatsen@juniper.net