idnits 2.17.1 draft-ietf-netconf-call-home-17.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 22, 2015) is 3045 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 22, 2015 5 Expires: June 24, 2016 7 NETCONF Call Home and RESTCONF Call Home 8 draft-ietf-netconf-call-home-17 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 24, 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 to 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 certificate, and that 292 the presented certificate encodes an "identifier" [RFC6125] that 293 the client had awareness of prior to the connection attempt. How 294 identifiers are encoded in certificates MAY be determined by a 295 policy associated with the certificate's issuer. For instance, a 296 given issuer may be known to only sign IDevID certificates 297 [Std-802.1AR-2009] having a unique identifier (e.g., serial 298 number) in the X.509 certificate's "CommonName" field. 300 C7 After the server's host key or certificate is validated, the SSH 301 or TLS protocol proceeds as normal to establish a SSH or TLS 302 connection. When performing client authentication with the 303 NETCONF/RESTCONF server, the NETCONF/RESTCONF client MUST ensure 304 to only use credentials that it had previously associated for the 305 NETCONF/RESTCONF server's presented host key or server 306 certificate. 308 C8 Once the SSH or TLS connection is established, the NETCONF/ 309 RESTCONF client starts either the NETCONF-client [RFC6241] or 310 RESTCONF-client [draft-ietf-netconf-restconf] protocol. Assuming 311 the use of the IANA-assigned ports, the NETCONF-client protocol 312 is started when the connection is accepted on either port PORT-X 313 or PORT-Y and the RESTCONF-client protocol is started when the 314 connection is accepted on port PORT-Z. 316 3.2. Configuration Data Model 318 How a NETCONF or RESTCONF client is configured is outside the scope 319 of this document. For instance, such configuration might be used to 320 enable listening for call home connections, configuring trusted 321 certificate issuers, or configuring identifiers for expected 322 connections. 324 4. The NETCONF or RESTCONF Server 326 The term "server" is defined in [RFC6241], Section 1.1 "server". In 327 the context of network management, the NETCONF/RESTCONF server might 328 be a network element or a device. 330 4.1. Protocol Operation 332 S1 The NETCONF/RESTCONF server initiates a TCP connection request to 333 the NETCONF/RESTCONF client. The server MUST support connecting 334 to one of the IANA-assigned ports defined in Section 6, but MAY 335 be configured to connect to a different port. Using the IANA- 336 assigned ports, the server connects to port PORT-X for NETCONF 337 over SSH, port PORT-Y for NETCONF over TLS, and port PORT-Z for 338 RESTCONF over TLS. 340 S2 The TCP connection request is accepted and a TCP connection is 341 established. 343 S3 Using this TCP connection, the NETCONF/RESTCONF server starts 344 either the SSH-server [RFC4253] or the TLS-server [RFC5246] 345 protocol, depending on how it is configured. For example, 346 assuming the use of the IANA-assigned ports, the SSH-server 347 protocol is used after connecting to the remote port PORT-X and 348 the TLS-server protocol is used after connecting to one of the 349 remote ports PORT-Y or PORT-Z. 351 S4 As part of establishing the SSH or TLS connection, the NETCONF/ 352 RESTCONF server will send its host key or certificate to the 353 client. If a certificate is sent, the server MUST also send all 354 intermediate certificates leading up to a well known and trusted 355 issuer. How to send a list of certificates is defined for SSH in 356 [RFC6187] Section 2.1, and for TLS in [RFC5246] Section 7.4.2. 358 S5 Establishing an SSH or TLS session requires server authentication 359 of client credentials in all cases except with RESTCONF, where 360 some client authentication schemes occur after the secure 361 transport connection (TLS) has been established. If transport 362 (SSH or TLS) level client authentication is required, and the 363 client is unable to successfully authenticate itself to the 364 server in an amount of time defined by local policy, the server 365 MUST close the connection. 367 S6 Once the SSH or TLS connection is established, the NETCONF/ 368 RESTCONF server starts either the NETCONF-server [RFC6241] or 369 RESTCONF-server [draft-ietf-netconf-restconf] protocol, depending 370 on how it is configured. Assuming the use of the IANA-assigned 371 ports, the NETCONF-server protocol is used after connecting to 372 remote port PORT-X or PORT-Y, and the RESTCONF-server protocol is 373 used after connecting to remote port PORT-Z. 375 S7 If a persistent connection is desired, the NETCONF/RESTCONF 376 server, as the connection initiator, SHOULD actively test the 377 aliveness of the connection using a keep-alive mechanism. For 378 TLS based connections, the NETCONF/RESTCONF server SHOULD send 379 HeartbeatRequest messages, as defined by [RFC6520]. For SSH 380 based connections, per Section 4 of [RFC4254], the NETCONF/ 381 RESTCONF server SHOULD send a SSH_MSG_GLOBAL_REQUEST message with 382 a purposely nonexistent "request name" value (e.g., 383 keepalive@ietf.org) and the "want reply" value set to '1'. 385 4.2. Configuration Data Model 387 How a NETCONF or RESTCONF server is configured is outside the scope 388 of this document. This includes configuration that might be used to 389 specify hostnames, IP addresses, ports, algorithms, or other relevant 390 parameters. That said, a YANG [RFC6020] model for configuring 391 NETCONF and RESTCONF servers, including call home, is provided in 392 [draft-ietf-netconf-server-model]. 394 5. Security Considerations 396 The security considerations described in [RFC6242] and [RFC7589], and 397 by extension [RFC4253], [RFC5246], and [draft-ietf-netconf-restconf] 398 apply here as well. 400 This RFC deviates from standard SSH and TLS usage by having the SSH/ 401 TLS server initiate the underlying TCP connection. This reversal is 402 incongruous with [RFC4253], which says "the client initiates the 403 connection" and also [RFC6125], which says "the client MUST construct 404 a list of acceptable reference identifiers, and MUST do so 405 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 422 preconfigured issuer certificate used for certificate path validation 423 is unique to the manufacturer of the server. That is, the 424 certificate should not belong to a 3rd-party certificate authority 425 that might issue certificates for more than one manufacturer. This 426 is especially important when a client authentication mechanism 427 passing a shared secret (e.g., a password) to the server is used. 428 Not doing so could otherwise lead to a case where the client sends 429 the shared secret to another server that happens to have the same 430 identity (e.g., serial number) as the server the client was 431 configured to 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 possess a valid key. For instance, in TLS 1.3 447 [draft-ietf-tls-tls13], the ClientHello message contains a Key Share 448 value based on an expensive asymmetric key operation. Common 449 precautions mitigating DoS attacks are recommended, such as 450 temporarily blacklisting the source address after a set number of 451 unsuccessful login attempts. 453 When using call home with the RESTCONF protocol, special care is 454 required when using some HTTP authentication schemes, especially the 455 Basic [RFC7617] and Digest [RFC7616] schemes, which convey a shared 456 secret (e.g., a password). Implementations and deployments should be 457 sure to review the Security Considerations section in the RFC for any 458 HTTP client authentication scheme used. 460 6. IANA Considerations 462 This RFC requests that IANA assigns three TCP port numbers in the 463 "Registered Port Numbers" range with the service names "netconf-ch- 464 ssh", "netconf-ch-tls", and "restconf-ch-tls". These ports will be 465 the default ports for NETCONF Call Home and RESTCONF Call Home 466 protocols. Below is the registration template following the rules in 467 [RFC6335]. 469 Service Name: netconf-ch-ssh 470 Transport Protocol(s): TCP 471 Assignee: IESG 472 Contact: IETF Chair 473 Description: NETCONF Call Home (SSH) 474 Reference: RFC XXXX 475 Port Number: PORT-X 477 Service Name: netconf-ch-tls 478 Transport Protocol(s): TCP 479 Assignee: IESG 480 Contact: IETF Chair 481 Description: NETCONF Call Home (TLS) 482 Reference: RFC XXXX 483 Port Number: PORT-Y 485 Service Name: restconf-ch-tls 486 Transport Protocol(s): TCP 487 Assignee: IESG 488 Contact: IETF Chair 489 Description: RESTCONF Call Home (TLS) 490 Reference: RFC XXXX 491 Port Number: PORT-Z 493 7. Acknowledgements 495 The author would like to thank the following for lively discussions 496 on list and in the halls (ordered by last name): Jari Arkko, Andy 497 Bierman, Martin Bjorklund, Ben Campbell, Spencer Dawkins, Mehmet 498 Ersue, Stephen Farrell, Wes Hardaker, Stephen Hanna, David 499 Harrington, Jeffrey Hutzelman, Simon Josefsson, Radek Krejci, Suresh 500 Krishnan, Barry Leiba, Alan Luchuk, Kathleen Moriarty, Mouse, Russ 501 Mundy, Tom Petch, Peter Saint-Andre, Joseph Salowey, Juergen 502 Schoenwaelder, Martin Stiemerling, Joe Touch, Hannes Tschofenig, Sean 503 Turner, and Bert Wijnen. 505 8. References 507 8.1. Normative References 509 [draft-ietf-netconf-restconf] 510 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 511 Protocol", draft-ieft-netconf-restconf-04 (work in 512 progress), 2014, . 515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 516 Requirement Levels", BCP 14, RFC 2119, 517 DOI 10.17487/RFC2119, March 1997, 518 . 520 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 521 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 522 January 2006, . 524 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 525 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, 526 January 2006, . 528 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 529 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 530 January 2006, . 532 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 533 Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, 534 January 2006, . 536 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 537 (TLS) Protocol Version 1.2", RFC 5246, 538 DOI 10.17487/RFC5246, August 2008, 539 . 541 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 542 Verification of Domain-Based Application Service Identity 543 within Internet Public Key Infrastructure Using X.509 544 (PKIX) Certificates in the Context of Transport Layer 545 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 546 2011, . 548 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 549 Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, 550 March 2011, . 552 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 553 and A. Bierman, Ed., "Network Configuration Protocol 554 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 555 . 557 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 558 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 559 . 561 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 562 Cheshire, "Internet Assigned Numbers Authority (IANA) 563 Procedures for the Management of the Service Name and 564 Transport Protocol Port Number Registry", BCP 165, 565 RFC 6335, DOI 10.17487/RFC6335, August 2011, 566 . 568 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 569 Layer Security (TLS) and Datagram Transport Layer Security 570 (DTLS) Heartbeat Extension", RFC 6520, 571 DOI 10.17487/RFC6520, February 2012, 572 . 574 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 575 NETCONF Protocol over Transport Layer Security (TLS) with 576 Mutual X.509 Authentication", RFC 7589, 577 DOI 10.17487/RFC7589, June 2015, 578 . 580 [RFC793] Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, 581 September 1981, . 583 8.2. Informative References 585 [draft-ietf-netconf-server-model] 586 Watsen, K. and J. Schoenwaelder, "NETCONF Server 587 Configuration Model", 2014, . 590 [draft-ietf-tls-tls13] 591 Rescorla, E., "The Transport Layer Security (TLS) Protocol 592 Version 1.3", 2015, 593 . 595 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 596 the Network Configuration Protocol (NETCONF)", RFC 6020, 597 DOI 10.17487/RFC6020, October 2010, 598 . 600 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 601 Digest Access Authentication", RFC 7616, 602 DOI 10.17487/RFC7616, September 2015, 603 . 605 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 606 RFC 7617, DOI 10.17487/RFC7617, September 2015, 607 . 609 [Std-802.1AR-2009] 610 IEEE SA-Standards Board, "IEEE Standard for Local and 611 metropolitan area networks - Secure Device Identity", 612 December 2009, . 615 [zmap] Durumeric, Z., Wustrow, E., and J. Halderman, "ZMap: Fast 616 Internet-Wide Scanning and its Security Applications", 617 2013, . 619 In proceedings of the 22nd USENIX Security Symposium 621 Author's Address 623 Kent Watsen 624 Juniper Networks 626 EMail: kwatsen@juniper.net