idnits 2.17.1 draft-ietf-netconf-rfc5539bis-10.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 (April 10, 2015) is 3297 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 (-11) exists of draft-ietf-uta-tls-bcp-09 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-09) exists of draft-ietf-netconf-server-model-06 -- 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 (~~), 3 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: October 12, 2015 J. Schoenwaelder 7 Jacobs University Bremen 8 April 10, 2015 10 Using the NETCONF Protocol over Transport Layer Security (TLS) with 11 Mutual X.509 Authentication 12 draft-ietf-netconf-rfc5539bis-10 14 Abstract 16 The Network Configuration Protocol (NETCONF) provides mechanisms to 17 install, manipulate, and delete the configuration of network devices. 18 This document describes how to use the Transport Layer Security (TLS) 19 protocol with mutual X.509 authentication to secure the exchange of 20 NETCONF messages. This revision of RFC 5539 documents the new 21 message framing used by NETCONF 1.1 and it obsoletes RFC 5539. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 12, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Connection Initiation . . . . . . . . . . . . . . . . . . . . 3 59 3. Message Framing . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Connection Closure . . . . . . . . . . . . . . . . . . . . . 3 61 5. Certificate Validation . . . . . . . . . . . . . . . . . . . 3 62 6. Server Identity . . . . . . . . . . . . . . . . . . . . . . . 4 63 7. Client Identity . . . . . . . . . . . . . . . . . . . . . . . 4 64 8. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 6 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 12.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Appendix A. Changes from RFC 5539 . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 The NETCONF protocol [RFC6241] defines a mechanism through which a 77 network device can be managed. NETCONF is connection-oriented, 78 requiring a persistent connection between peers. This connection 79 must provide integrity, confidentiality, peer authentication, and 80 reliable, sequenced data delivery. 82 This document defines how NETCONF messages can be exchanged over 83 Transport Layer Security (TLS) [RFC5246]. Implementations MUST 84 support mutual TLS certificate-based authentication [RFC5246]. This 85 assures the NETCONF server of the identity of the principal who 86 wishes to manipulate the management information. It also assures the 87 NETCONF client of the identity of the server for which it wishes to 88 manipulate the management information. 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. Connection Initiation 96 The peer acting as the NETCONF client MUST act as the TLS client. 97 The TLS client actively opens the TLS connection and the TLS server 98 passively listens for the incoming TLS connections. The well-known 99 TCP port number 6513 is used by NETCONF servers to listen for TCP 100 connections established by NETCONF over TLS clients. The TLS client 101 MUST send the TLS ClientHello message to begin the TLS handshake. 102 The TLS server MUST send a CertificateRequest in order to request a 103 certificate from the TLS client. Once the TLS handshake has 104 finished, the client and the server MAY begin to exchange NETCONF 105 messages. Client and server identity verification is done before the 106 NETCONF message is sent. This means that the identity 107 verification is completed before the NETCONF session is started. 109 3. Message Framing 111 All NETCONF messages MUST be sent as TLS "application data". It is 112 possible that multiple NETCONF messages be contained in one TLS 113 record, or that a NETCONF message be transferred in multiple TLS 114 records. 116 The previous version of this document [RFC5539] used the framing 117 sequence defined in [RFC4742]. This version aligns with [RFC6242] 118 and adopts the framing protocol defined in [RFC6242] as follows: 120 The NETCONF message MUST be followed by the character 121 sequence ]]>]]>. Upon reception of the message, the peers 122 inspect the announced capabilities. If the :base:1.1 capability is 123 advertised by both peers, the chunked framing mechanism defined in 124 Section 4.2 of [RFC6242] is used for the remainder of the NETCONF 125 session. Otherwise, the old end-of-message-based mechanism (see 126 Section 4.3 of [RFC6242]) is used. 128 4. Connection Closure 130 A NETCONF server will process NETCONF messages from the NETCONF 131 client in the order in which they are received. A NETCONF session is 132 closed using the operation. When the NETCONF server 133 processes a operation, the NETCONF server SHALL 134 respond and close the TLS session as described in Section 7.2.1 of 135 [RFC5246]. 137 5. Certificate Validation 139 Both peers MUST use X.509 certificate path validation [RFC5280] to 140 verify the integrity of the certificate presented by the peer. The 141 presented X.509 certificate may also be considered valid if it 142 matches one obtained by another trusted mechanism, such as using a 143 locally configured certificate fingerprint. If X.509 certificate 144 path validation fails and the presented X.509 certificate does not 145 match a certificate obtained by a trusted mechanism, the connection 146 MUST be terminated as defined in [RFC5246]. 148 6. Server Identity 150 The NETCONF client MUST check the identity of the server according to 151 Section 6 of [RFC6125]. 153 7. Client Identity 155 The NETCONF server MUST verify the identity of the NETCONF client to 156 ensure that the incoming request to establish a NETCONF session is 157 legitimate before the NETCONF session is started. 159 The NETCONF protocol [RFC6241] requires that the transport protocol's 160 authentication process results in an authenticated NETCONF client 161 identity whose permissions are known to the server. The 162 authenticated identity of a client is commonly referred to as the 163 NETCONF username. The following algorithm is used by the NETCONF 164 server to derive a NETCONF username from a certificate. (Note that 165 the algorithm below is the same as the one described in the SNMP-TLS- 166 TM-MIB MIB module defined in [RFC6353] and in the ietf-x509-cert-to- 167 name YANG module defined in [RFC7407].) 169 (a) The server maintains an ordered list of mappings of certificates 170 to NETCONF usernames. Each list entry contains 172 * a certificate fingerprint (used for matching the presented 173 certificate), 175 * a map type (indicates how the NETCONF username is derived 176 from the certificate), and 178 * optional auxiliary data (used to carry a NETCONF username if 179 the map type indicates the user name is explicitly 180 configured). 182 (b) The NETCONF username is derived by considering each list entry 183 in order. The fingerprint member of the current list entry 184 determines whether the current list entry is a match: 186 1. If the list entry's fingerprint value matches the 187 fingerprint of the presented certificate, then consider the 188 list entry as a successful match. 190 2. If the list entry's fingerprint value matches that of a 191 locally held copy of a trusted CA certificate, and that CA 192 certificate was part of the CA certificate chain to the 193 presented certificate, then consider the list entry as a 194 successful match. 196 (c) Once a matching list entry has been found, the map type of the 197 current list entry is used to determine how the username 198 associated with the certificate should be determined. Possible 199 mapping options are: 201 A. The username is taken from the auxiliary data of the current 202 list entry. This means the username is explicitely 203 configured (map type 'specified'). 205 B. The subjectAltName's rfc822Name field is mapped to the 206 username (map type 'san-rfc822-name'). The local part of 207 the rfc822Name is used unaltered but the host-part of the 208 name must be converted to lowercase. 210 C. The subjectAltName's dNSName is mapped to the username (map 211 type 'san-dns-name'). The characters of the dNSName are 212 converted to lowercase. 214 D. The subjectAltName's iPAddress is mapped to the username 215 (map type 'san-ip-address'). IPv4 addresses are converted 216 into decimal-dotted quad notation (e.g., '192.0.2.1'). IPv6 217 addresses are converted into a 32-character all lowercase 218 hexadecimal string without any colon separators. 220 E. Any of the subjectAltName's rfc822Name, dNSName, iPAddress 221 is mapped to the username (map type 'san-any'). The first 222 matching subjectAltName value found in the certificate of 223 the above types MUST be used when deriving the name. 225 F. The certificate's CommonName is mapped to the username (map 226 type 'common-name'). The CommonName is converted to UTF-8 227 encoding. The usage of CommonNames is deprecated and users 228 are encouraged to use subjectAltName mapping methods 229 instead. 231 (d) If it is impossible to determine a username from the list 232 entry's data combined with the data presented in the 233 certificate, then additional list entries MUST be searched 234 looking for another potential match. Similarily, if the 235 username does not comply to the NETCONF requirements on 236 usernames [RFC6241], then additional list entries MUST be 237 searched looking for another potential match. If there are no 238 further list entries, the TLS session MUST be terminated. 240 The username provided by the NETCONF over TLS implementation will be 241 made available to the NETCONF message layer as the NETCONF username 242 without modification. 244 The NETCONF server configuration data model 245 [I-D.ietf-netconf-server-model] covers NETCONF over TLS and provides 246 further details such as certificate fingerprint formats exposed to 247 network configuration systems. 249 8. Cipher Suites 251 Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to 252 support the mandatory-to-implement cipher suite. Implementations MAY 253 implement additional TLS cipher suites that provide mutual 254 authentication [RFC5246] and confidentiality as required by NETCONF 255 [RFC6241]. Implementations SHOULD follow the recommendations given 256 in [I-D.ietf-uta-tls-bcp]. 258 9. Security Considerations 260 NETCONF is used to access configuration and state information and to 261 modify configuration information, so the ability to access this 262 protocol should be limited to users and systems that are authorized 263 to view the NETCONF server's configuration and state or to modify the 264 NETCONF server's configuration. 266 Configuration or state data may include sensitive information, such 267 as usernames or security keys. So, NETCONF requires communications 268 channels that provide strong encryption for data privacy. This 269 document defines a NETCONF over TLS mapping that provides for support 270 of strong encryption and authentication. The security considerations 271 for TLS [RFC5246] and NETCONF [RFC6241] apply here as well. 273 NETCONF over TLS requires mutual authentication. Neither side should 274 establish a NETCONF over TLS connection with an unknown, unexpected, 275 or incorrect identity on the opposite side. Note that the decision 276 whether a certificate presented by the client is accepted can depend 277 on whether a trusted CA certificate is white listed (see Section 7). 278 If deployments make use of this option, it is recommended that the 279 white listed CA certificate is used only to issue certificates that 280 are used for accessing NETCONF servers. Should the CA certificate be 281 used to issue certificates for other purposes, then all certificates 282 created for other purposes will be accepted by a NETCONF server as 283 well, which is likely not suitable. 285 This document does not support third-party authentication (e.g., 286 backend Authentication, Authorization, and Accounting (AAA) servers) 287 due to the fact that TLS does not specify this way of authentication 288 and that NETCONF depends on the transport protocol for the 289 authentication service. If third-party authentication is needed, the 290 SSH transport [RFC6242] can be used. 292 RFC 5539 assumes that the end-of-message (EOM) sequence, ]]>]]>, 293 cannot appear in any well-formed XML document, which turned out to be 294 mistaken. The EOM sequence can cause operational problems and open 295 space for attacks if sent deliberately in NETCONF messages. It is 296 however believed that the associated threat is not very high. This 297 document still uses the EOM sequence for the initial message 298 to avoid incompatibility with existing implementations. When both 299 peers implement :base:1.1 capability, a proper framing protocol 300 (chunked framing mechanism; see Section 3) is used for the rest of 301 the NETCONF session, to avoid injection attacks. 303 10. IANA Considerations 305 Based on the previous version of this document, RFC 5539, IANA has 306 assigned a TCP port number (6513) in the "Registered Port Numbers" 307 range with the service name "netconf-tls". This port will be the 308 default port for NETCONF over TLS, as defined in Section 2. Below is 309 the registration template following the rules in [RFC6335]. 311 Service Name: netconf-tls 312 Transport Protocol(s): TCP 313 Assignee: IESG 314 Contact: IETF Chair 315 Description: NETCONF over TLS 316 Reference: RFC XXXX 317 Port Number: 6513 319 [[CREF1: RFC Editor: Please replace XXXX above with the allocated RFC 320 number and remove this comment. --JS]] 322 11. Acknowledgements 324 The authors like to acknowledge Martin Bjorklund, Olivier Coupelon, 325 Mehmet Ersue, Stephen Farrell, Miao Fuyou, Ibrahim Hajjeh, David 326 Harrington, Sam Hartman, Alfred Hoenes, Simon Josefsson, Barry Leiba, 327 Tom Petch, Eric Rescorla, Dan Romascanu, Kent Watsen, Bert Wijnen, 328 Stefan Winter and the NETCONF mailing list members for their comments 329 on this document. Charlie Kaufman, Pasi Eronen, and Tim Polk 330 provided a thorough review of previous versions of this document. 332 Juergen Schoenwaelder was partly funded by Flamingo, a Network of 333 Excellence project (ICT-318488) supported by the European Commission 334 under its Seventh Framework Programme. 336 12. References 338 12.1. Normative References 340 [I-D.ietf-uta-tls-bcp] 341 Sheffer, Y., Holz, R., and P. Saint-Andre, 342 "Recommendations for Secure Use of TLS and DTLS", draft- 343 ietf-uta-tls-bcp-09 (work in progress), February 2015. 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 349 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 351 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 352 Housley, R., and W. Polk, "Internet X.509 Public Key 353 Infrastructure Certificate and Certificate Revocation List 354 (CRL) Profile", RFC 5280, May 2008. 356 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 357 Verification of Domain-Based Application Service Identity 358 within Internet Public Key Infrastructure Using X.509 359 (PKIX) Certificates in the Context of Transport Layer 360 Security (TLS)", RFC 6125, March 2011. 362 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 363 Bierman, "Network Configuration Protocol (NETCONF)", RFC 364 6241, June 2011. 366 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 367 Shell (SSH)", RFC 6242, June 2011. 369 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 370 Cheshire, "Internet Assigned Numbers Authority (IANA) 371 Procedures for the Management of the Service Name and 372 Transport Protocol Port Number Registry", BCP 165, RFC 373 6335, August 2011. 375 12.2. Informative References 377 [I-D.ietf-netconf-server-model] 378 Watsen, K. and J. Schoenwaelder, "NETCONF Server and 379 RESTCONF Server Configuration Models", draft-ietf-netconf- 380 server-model-06 (work in progress), February 2015. 382 [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF 383 Configuration Protocol over Secure SHell (SSH)", RFC 4742, 384 December 2006. 386 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", 387 RFC 5539, May 2009. 389 [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport 390 Model for the Simple Network Management Protocol (SNMP)", 391 STD 78, RFC 6353, July 2011. 393 [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for 394 SNMP Configuration", RFC 7407, December 2014. 396 Appendix A. Changes from RFC 5539 398 This section summarizes major changes between this document and RFC 399 5539. 401 o Documented that NETCONF over TLS uses the new message framing if 402 both peers support the :base:1.1 capability. 404 o Removed redundant text that can be found in the TLS and NETCONF 405 specifications and restructured the text. Alignment with 406 [RFC6125]. 408 o Added a high-level description how NETCONF usernames are derived 409 from certificates. 411 o Removed the reference to BEEP. 413 Authors' Addresses 415 Mohamad Badra 416 Zayed University 418 Email: mbadra@gmail.com 419 Alan Luchuk 420 SNMP Research, Inc. 421 3001 Kimberlin Heights Road 422 Knoxville, TN 37920 423 USA 425 Phone: +1 865 573 1434 426 Email: luchuk@snmp.com 427 URI: http://www.snmp.com/ 429 Juergen Schoenwaelder 430 Jacobs University Bremen 431 Campus Ring 1 432 28759 Bremen 433 Germany 435 Phone: +49 421 200 3587 436 Email: j.schoenwaelder@jacobs-university.de 437 URI: http://www.jacobs-university.de/