idnits 2.17.1 draft-ietf-netconf-rfc5539bis-06.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 (September 30, 2014) is 3489 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) == Outdated reference: A later version (-09) exists of draft-ietf-netconf-server-model-03 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 4742 (Obsoleted by RFC 6242) -- Obsolete informational reference (is this intentional?): RFC 5539 (Obsoleted by RFC 7589) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group M. Badra 3 Internet-Draft Zayed University 4 Obsoletes: 5539 (if approved) A. Luchuk 5 Intended status: Standards Track SNMP Research, Inc. 6 Expires: April 3, 2015 J. Schoenwaelder 7 Jacobs University Bremen 8 September 30, 2014 10 Using the NETCONF Protocol over Transport Layer Security (TLS) 11 draft-ietf-netconf-rfc5539bis-06 13 Abstract 15 The Network Configuration Protocol (NETCONF) provides mechanisms to 16 install, manipulate, and delete the configuration of network devices. 17 This document describes how to use the Transport Layer Security (TLS) 18 protocol to secure the exchange of NETCONF messages. This revision 19 of RFC 5539 documents the new message framing for NETCONF 1.1 and it 20 obsoletes RFC 5539. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 3, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. NETCONF over TLS . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Connection Initiation . . . . . . . . . . . . . . . . . . 3 59 2.2. Message Framing . . . . . . . . . . . . . . . . . . . . . 3 60 2.3. Connection Closure . . . . . . . . . . . . . . . . . . . 4 61 2.4. X.509-based Authentication, Identification and 62 Authorization . . . . . . . . . . . . . . . . . . . . . . 4 63 2.4.1. Server Identity . . . . . . . . . . . . . . . . . . . 4 64 2.4.2. Client Identity . . . . . . . . . . . . . . . . . . . 4 65 2.4.3. Deriving NETCONF Usernames from X.509 Certificates . 5 66 2.5. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 6. Contributor's Address . . . . . . . . . . . . . . . . . . . . 7 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 7.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Appendix A. Changes from RFC 5539 . . . . . . . . . . . . . . . 8 75 Appendix B. Change Log (to be removed by RFC Editor before 76 publication) . . . . . . . . . . . . . . . . . . . . 8 77 B.1. draft-ietf-netconf-rfc5539bis-06 . . . . . . . . . . . . 8 78 B.2. draft-ietf-netconf-rfc5539bis-05 . . . . . . . . . . . . 8 79 B.3. draft-ietf-netconf-rfc5539bis-04 . . . . . . . . . . . . 8 80 B.4. draft-ietf-netconf-rfc5539bis-03 . . . . . . . . . . . . 9 81 B.5. draft-ietf-netconf-rfc5539bis-02 . . . . . . . . . . . . 9 82 B.6. draft-ietf-netconf-rfc5539bis-00 . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 The NETCONF protocol [RFC6241] defines a mechanism through which a 88 network device can be managed. NETCONF is connection-oriented, 89 requiring a persistent connection between peers. This connection 90 must provide integrity, confidentiality, peer authentication, and 91 reliable, sequenced data delivery. 93 This document defines how NETCONF messages can be exchanged over 94 Transport Layer Security (TLS) [RFC5246]. The TLS protocol provides 95 support for certificate-based mutual authentication, key derivation, 96 protected ciphersuite negotiation, and key management capabilities. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. NETCONF over TLS 104 Since TLS is application-protocol-independent, NETCONF can operate on 105 top of the TLS protocol transparently. This document defines how 106 NETCONF can be used within a TLS session. 108 2.1. Connection Initiation 110 The peer acting as the NETCONF client MUST act as the TLS client. 111 The TLS client actively opens the TLS connection and the TLS server 112 passively listens for the incoming TLS connection on the TCP port 113 6513. The TLS client MUST therefore send the TLS ClientHello message 114 to begin the TLS handshake. Once the TLS handshake has finished, the 115 client and the server MAY begin to exchange NETCONF messages. Client 116 and server identity verification (as described in Section 2.4) is 117 done before the message is sent. This means that the 118 identity verification is completed before the NETCONF session has 119 started. 121 The well-known port number 6513 is used by NETCONF servers to listen 122 for connections established by NETCONF clients. NETCONF clients 123 connect to the server on the server port 6513 in order to send 124 NETCONF messages to the NETCONF server. 126 2.2. Message Framing 128 All NETCONF messages MUST be sent as TLS "application data". It is 129 possible that multiple NETCONF messages be contained in one TLS 130 record, or that a NETCONF message be transferred in multiple TLS 131 records. 133 The previous version [RFC5539] of this document used the framing 134 sequence defined in [RFC4742], under the assumption that it could not 135 be found in well-formed XML documents. However, this assumption is 136 not correct [RFC6242]. In order to solve this problem, this document 137 adopts the framing protocol defined in [RFC6242] as follows: 139 The message MUST be followed by the character sequence 140 ]]>]]>. Upon reception of the message, the peers inspect the 141 announced capabilities. If the :base:1.1 capability is advertised by 142 both peers, the chunked framing mechanism defined in Section 4.2 of 143 [RFC6242] is used for the remainder of the NETCONF session. 144 Otherwise, the old end-of-message-based mechanism (see Section 4.3 of 145 [RFC6242]) is used. 147 2.3. Connection Closure 149 A NETCONF server will process NETCONF messages from the NETCONF 150 client in the order in which they are received. A NETCONF session is 151 closed using the operation. When the NETCONF server 152 processes a operation, the NETCONF server SHALL 153 respond and close the TLS session as described in Section 7.2.1 of 154 [RFC5246]. 156 2.4. X.509-based Authentication, Identification and Authorization 158 Implementations MAY optionally support TLS certificate-based 159 authentication [RFC5246]. If the implementation supports TLS 160 certificate-based authentication, then the following sections apply. 162 2.4.1. Server Identity 164 If the certificate presented by a NETCONF server has passed 165 certification path validation [RFC5280] to a configured trust anchor, 166 the NETCONF client MUST carefully examine the certificate presented 167 by the server to determine if it meets the client's expectations. If 168 the NETCONF client has external information as to the expected 169 identity of the NETCONF server, the hostname check MAY be omitted. 170 Otherwise, the NETCONF client MUST check its understanding of the 171 NETCONF server hostname against the server's identity as presented in 172 the server Certificate message, in order to prevent man-in-the-middle 173 attacks. 175 Matching is performed according to the rules and guidelines defined 176 in [RFC6125]. If the match fails, the NETCONF client MUST either ask 177 for explicit user confirmation or terminate the connection and 178 indicate the NETCONF server's identity is suspect. 180 Additionally, NETCONF clients MUST verify the binding between the 181 identity of the NETCONF servers to which they connect and the public 182 keys presented by those servers. NETCONF clients SHOULD implement 183 the algorithm in Section 6 of [RFC5280] for general certificate 184 validation, but MAY supplement that algorithm with other validation 185 methods that achieve equivalent levels of verification (such as 186 comparing the NETCONF server certificate against a local store of 187 already-verified certificates and identity bindings). 189 2.4.2. Client Identity 191 The NETCONF server MUST verify the identity of the NETCONF client to 192 ensure that the incoming request to establish a NETCONF session is 193 legitimate before the NETCONF session is started. 195 The NETCONF protocol [RFC6241] requires that the transport protocol's 196 authentication process MUST result in an authenticated NETCONF client 197 identity whose permissions are known to the server. The 198 authenticated identity of a client is commonly referred to as the 199 NETCONF username. 201 The username provided by the NETCONF over TLS implementation will be 202 made available to the NETCONF message layer as the NETCONF username 203 without modification. If the username does not comply to the NETCONF 204 requirements on usernames [RFC6241], i.e., the username is not 205 representable in XML, the TLS session MUST be dropped. 207 2.4.3. Deriving NETCONF Usernames from X.509 Certificates 209 After completing the TLS handshake, the NETCONF server attempts to 210 derive a NETCONF username from the X.509 certificate presented by the 211 NETCONF client. If the NETCONF server cannot derive a valid NETCONF 212 username from the presented certificate, then the NETCONF server MUST 213 close the TLS connection, and MUST NOT accept NETCONF messages over 214 it. The NETCONF server uses the algorithm defined in 215 [I-D.ietf-netconf-server-model] to extract a NETCONF username from 216 the X.509 certificate presented by the NETCONF client. 218 2.5. Cipher Suites 220 Implementations of the protocol specified in this document MAY 221 implement any TLS cipher suite that provides mutual authentication 222 [RFC5246]. However, implementations MUST support TLS 1.2 [RFC5246] 223 and are REQUIRED to support the mandatory-to-implement cipher suite. 225 3. Security Considerations 227 NETCONF is used to access configuration and state information and to 228 modify configuration information, so the ability to access this 229 protocol should be limited to users and systems that are authorized 230 to view the NETCONF server's configuration and state or to modify the 231 NETCONF server's configuration. 233 Configuration or state data may include sensitive information, such 234 as usernames or security keys. So, NETCONF requires communications 235 channels that provide strong encryption for data privacy. This 236 document defines a NETCONF over TLS mapping that provides for support 237 of strong encryption and authentication. The security considerations 238 for TLS [RFC5246] and NETCONF [RFC6241] apply here as well. 240 NETCONF over TLS requires mutual authentication. Neither side should 241 establish a NETCONF over SSH connection with an unknown, unexpected, 242 or incorrect identity on the opposite side. This document does not 243 support third-party authentication (e.g., backend Authentication, 244 Authorization, and Accounting (AAA) servers) due to the fact that TLS 245 does not specify this way of authentication and that NETCONF depends 246 on the transport protocol for the authentication service. If third- 247 party authentication is needed, the SSH transport can be used. 249 RFC 5539 assumes that the end-of-message (EOM) sequence, ]]>]]>, 250 cannot appear in any well-formed XML document, which turned out to be 251 mistaken. The EOM sequence can cause operational problems and open 252 space for attacks if sent deliberately in NETCONF messages. It is 253 however believed that the associated threat is not very high. This 254 document still uses the EOM sequence for the initial message 255 to avoid incompatibility with existing implementations. When both 256 peers implement base:1.1 capability, a proper framing protocol 257 (chunked framing mechanism; see Section 2.2) is used for the rest of 258 the NETCONF session, to avoid injection attacks. 260 4. IANA Considerations 262 Based on the previous version of this document, RFC 5539, IANA has 263 assigned a TCP port number (6513) in the "Registered Port Numbers" 264 range with the service name "netconf-tls". This port will be the 265 default port for NETCONF over TLS, as defined in Section 2.1. Below 266 is the registration template following the rules in [RFC6335]. 268 Service Name: netconf-tls 269 Transport Protocol(s): TCP 270 Assignee: IESG 271 Contact: IETF Chair 272 Description: NETCONF over TLS 273 Reference: RFC XXXX 274 Port Number: 6513 276 5. Acknowledgements 278 The authors like to acknowledge Martin Bjorklund, Olivier Coupelon, 279 Mehmet Ersue, Miao Fuyou, David Harrington, Alfred Hoenes, Simon 280 Josefsson, Eric Rescorla, Dan Romascanu, Kent Watsen, Bert Wijnen and 281 the NETCONF mailing list members for their comments on this document. 282 Charlie Kaufman, Pasi Eronen, and Tim Polk provided a thorough review 283 of previous versions of this document. 285 Juergen Schoenwaelder was partly funded by Flamingo, a Network of 286 Excellence project (ICT-318488) supported by the European Commission 287 under its Seventh Framework Programme. 289 6. Contributor's Address 291 Ibrahim Hajjeh 292 Ineovation 293 France 295 EMail: ibrahim.hajjeh@ineovation.fr 297 7. References 299 7.1. Normative References 301 [I-D.ietf-netconf-server-model] 302 Watsen, K. and J. Schoenwaelder, "NETCONF Server 303 Configuration Model", draft-ietf-netconf-server-model-03 304 (work in progress), September 2014. 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, March 1997. 309 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 310 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 312 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 313 Housley, R., and W. Polk, "Internet X.509 Public Key 314 Infrastructure Certificate and Certificate Revocation List 315 (CRL) Profile", RFC 5280, May 2008. 317 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 318 Verification of Domain-Based Application Service Identity 319 within Internet Public Key Infrastructure Using X.509 320 (PKIX) Certificates in the Context of Transport Layer 321 Security (TLS)", RFC 6125, March 2011. 323 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 324 Bierman, "Network Configuration Protocol (NETCONF)", RFC 325 6241, June 2011. 327 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 328 Shell (SSH)", RFC 6242, June 2011. 330 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 331 Cheshire, "Internet Assigned Numbers Authority (IANA) 332 Procedures for the Management of the Service Name and 333 Transport Protocol Port Number Registry", BCP 165, RFC 334 6335, August 2011. 336 7.2. Informative References 338 [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF 339 Configuration Protocol over Secure SHell (SSH)", RFC 4742, 340 December 2006. 342 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", 343 RFC 5539, May 2009. 345 Appendix A. Changes from RFC 5539 347 This section lists major changes between this document and RFC 5539. 349 o Documented that NETCONF uses the new message framing if both peers 350 support the base:1.1 capability. 352 o Removed redundant text that can be found in the TLS and NETCONF 353 specifications. 355 o Merged sections 2 and 3 into a new section 2 and restructured the 356 text. 358 o Removed the reference to BEEP. 360 Appendix B. Change Log (to be removed by RFC Editor before publication) 362 B.1. draft-ietf-netconf-rfc5539bis-06 364 o Removed all call-home related text. 366 o Removed redundant text as discussed at the Toronto IETF meeting. 368 B.2. draft-ietf-netconf-rfc5539bis-05 370 o Removed the YANG configuration data model since it became a 371 separate document. 373 o Added reference to RFC 3234 plus editorial updates. 375 B.3. draft-ietf-netconf-rfc5539bis-04 377 o Added the applicability statement proposed by Stephen Hanna. 379 o Added call-home configuration objects and a tls-call-home feature. 381 o Rewrote the text such that the role swap happens right after the 382 TCP connection has been established. 384 B.4. draft-ietf-netconf-rfc5539bis-03 386 o Added support for call home (allocation of a new port number, 387 rewrote text to allow a NETCONF client to be a TLS server and a 388 NETCONF server to be a TLS client). 390 o Merged sections 2 and 3 into a new section 2 and restructured the 391 text. 393 o Extended the IANA considerations section. 395 o Using the cert-to-name mapping grouping from the SNMP 396 configuration data model and updated the examples. 398 o Creating an extensible set of YANG (sub)modules for NETCONF 399 following the (sub)module structure of the SNMP configuration 400 model. 402 B.5. draft-ietf-netconf-rfc5539bis-02 404 o Addressed remaining issues identified at IETF 85 406 * Harmonized the cert-maps container of the YANG module in this 407 draft with the tlstm container in the ietf-snmp-tls sub-module 408 specified in draft-ietf-netmod-snmp-cfg. Replaced the children 409 of the cert-maps container with the children copied from the 410 tlstm container of the ietf-snmp-tls sub-module. 412 * Added an overview of data model in the ietf-netconf-tls YANG 413 module. 415 * Added example configurations. 417 o Addessed issues posted on NETCONF WG E-mail list. 419 o Deleted the superfluous tls container that was directly below the 420 netconf-config container. 422 o Added a statement to the text indicating that support for mapping 423 X.509 certificates to NETCONF usernames is optional. This is 424 analogous to existing text indicating that support for mapping 425 pre-shared keys to NETCONF usernames is optional. Resource- 426 constrained systems now can omit support for mapping X.509 427 certificates to NETCONF usernames and still comply with this 428 specification. 430 o Clarified the document structure by promoting the sections of the 431 document related to the data model. 433 o Updated author's addresses. 435 B.6. draft-ietf-netconf-rfc5539bis-00 437 o Remove the reference to BEEP. 439 o Rename host-part to domain-part in the description of RFC822. 441 Authors' Addresses 443 Mohamad Badra 444 Zayed University 446 Email: mbadra@gmail.com 448 Alan Luchuk 449 SNMP Research, Inc. 450 3001 Kimberlin Heights Road 451 Knoxville, TN 37920 452 USA 454 Phone: +1 865 573 1434 455 Email: luchuk@snmp.com 456 URI: http://www.snmp.com/ 458 Juergen Schoenwaelder 459 Jacobs University Bremen 460 Campus Ring 1 461 28759 Bremen 462 Germany 464 Phone: +49 421 200 3587 465 Email: j.schoenwaelder@jacobs-university.de 466 URI: http://www.jacobs-university.de/