idnits 2.17.1 draft-ietf-netconf-rfc5539bis-01.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 : ---------------------------------------------------------------------------- ** There are 27 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4201 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) == Missing Reference: '0-9a-fA-F' is mentioned on line 630, but not defined ** 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 5539 (Obsoleted by RFC 7589) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group M. Badra 3 Internet-Draft LIMOS Laboratory 4 Obsoletes: 5539 (if approved) A. Luchuk 5 Intended status: Standards Track SNMP Research 6 Expires: April 25, 2013 J. Schoenwaelder 7 Jacobs University Bremen 8 October 22, 2012 10 NETCONF Over Transport Layer Security (TLS) 11 draft-ietf-netconf-rfc5539bis-01 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 NETCONF exchanges. This document obsoletes RFC 19 5539. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 25, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 57 2. NETCONF over TLS . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Connection Initiation . . . . . . . . . . . . . . . . . . 3 59 2.2. Connection Closure . . . . . . . . . . . . . . . . . . . . 4 60 3. Endpoint Authentication, Identification and Authorization . . 4 61 3.1. Server Identity . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Client Identity . . . . . . . . . . . . . . . . . . . . . 5 63 3.2.1. Deriving NETCONF Usernames From NETCONF Client 64 Certificates . . . . . . . . . . . . . . . . . . . . . 5 65 3.2.2. Deriving NETCONF Usernames From PSK identities . . . . 7 66 3.2.3. Remote Configuration . . . . . . . . . . . . . . . . . 7 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 70 7. Contributor's Address . . . . . . . . . . . . . . . . . . . . 16 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 74 Appendix A. Change Log (to be removed by RFC Editor before 75 publication) . . . . . . . . . . . . . . . . . . . . 17 76 A.1. From draft-ietf-netconf-rfc5539bis-00 to 77 draft-ietf-netconf-rfc5539bis-01 . . . . . . . . . . . . . 17 78 A.2. From draft-badra-netconf-rfc5539bis-02 to 79 draft-ietf-netconf-rfc5539bis-00 . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 The NETCONF protocol [RFC6241] defines a mechanism through which a 85 network device can be managed. NETCONF is connection-oriented, 86 requiring a persistent connection between peers. This connection 87 must provide integrity, confidentiality, peer authentication, and 88 reliable, sequenced data delivery. 90 This document defines "NETCONF over TLS", which includes support for 91 certificate and pre-shared key (PSK)-based authentication and key 92 derivation, utilizing the protected ciphersuite negotiation, mutual 93 authentication, and key management capabilities of the TLS (Transport 94 Layer Security) protocol, described in [RFC5246]. 96 1.1. Conventions Used in This Document 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 also act as the TLS 111 client. The client actively opens the TLS connection and the server 112 passively listens for the incoming TLS connection on the TCP port 113 6513. It MUST therefore send the TLS ClientHello message to begin 114 the TLS handshake. Once the TLS handshake has finished, the client 115 and the server MAY begin to exchange NETCONF data. In particular, 116 the client will send complete XML documents to the server containing 117 elements, and the server will respond with complete XML 118 documents containing elements. The client MAY indicate 119 interest in receiving event notifications from a server by creating a 120 subscription to receive event notifications [RFC5277]. In this case, 121 the server replies to indicate whether the subscription request was 122 successful and, if it was successful, the server begins sending the 123 event notifications to the client as the events occur within the 124 system. 126 All NETCONF messages MUST be sent as TLS "application data". It is 127 possible that multiple NETCONF messages be contained in one TLS 128 record, or that a NETCONF message be transferred in multiple TLS 129 records. 131 The previous version [RFC5539] of this document used the same framing 132 sequence defined in [RFC6242], under the assumption that it could not 133 be found in well-formed XML documents. However, this assumption is 134 not correct [RFC6242]. In order to solve this problem, and at the 135 same time be compatible with existing implementations, this document 136 uses the framing protocol defined in [RFC6242] as following: 138 The message MUST be followed by the character sequence 139 ]]>]]>. Upon reception of the message, the receiving peer's 140 TLS Transport layer conceptually passes the message to the 141 Messages layer. If the :base:1.1 capability is advertised by both 142 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 Implementation of the protocol specified in this document MAY 148 implement any TLS cipher suite that provides mutual authentication 149 [RFC5246]. 151 Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to 152 support the mandatory-to-implement cipher suite, which is 153 TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to 154 future versions of TLS; in which case, the mandatory-to-implement 155 cipher suite for the implemented version MUST be supported. 157 2.2. Connection Closure 159 Exiting NETCONF is accomplished using the operation. 160 A NETCONF server will process NETCONF messages from the NETCONF 161 client in the order in which they are received. When the NETCONF 162 server processes a operation, the NETCONF server 163 SHALL respond and close the TLS session channel. The NETCONF server 164 MUST NOT process any NETCONF messages received after the operation. The TLS session is closed as described in 166 [RFC6242] Section 7.2.1. 168 3. Endpoint Authentication, Identification and Authorization 170 3.1. Server Identity 172 If the server's presented certificate has passed certification path 173 validation [RFC5280] to a configured trust anchor, the client MUST 174 carefully examine the certificate presented by the server to 175 determine if it meets the client's expectations. Particularly, the 176 client MUST check its understanding of the server hostname against 177 the server's identity as presented in the server Certificate message, 178 in order to prevent man- in-the-middle attacks. 180 Matching is performed according to the rules and guidelines defined 181 in [RFC6125]. 183 If the match fails, the client MUST either ask for explicit user 184 confirmation or terminate the connection and indicate the server's 185 identity is suspect. 187 Additionally, clients MUST verify the binding between the identity of 188 the servers to which they connect and the public keys presented by 189 those servers. Clients SHOULD implement the algorithm in Section 6 190 of [RFC5280] for general certificate validation, but MAY supplement 191 that algorithm with other validation methods that achieve equivalent 192 levels of verification (such as comparing the server certificate 193 against a local store of already-verified certificates and identity 194 bindings). 196 If the client has external information as to the expected identity of 197 the server, the hostname check MAY be omitted. 199 3.2. Client Identity 201 The server MUST verify the identity of the client to ensure that the 202 incoming client request is legitimate before the NETCONF session is 203 started. 205 The NETCONF protocol [RFC6241] requires that the transport protocol's 206 authentication process MUST result in an authenticated client 207 identity whose permissions are known to the server. The 208 authenticated identity of a client is commonly referred to as the 209 NETCONF username. 211 The username provided by the TLS implementation will be made 212 available to the NETCONF message layer as the NETCONF username 213 without modification. If the username does not comply to the NETCONF 214 requirements on usernames [RFC6241], i.e., the username is not 215 representable in XML, the TLS session MUST be dropped. 217 Algorithms for mapping certificates or PSK identities (sent by the 218 client) to NETCONF usernames are described below. 220 3.2.1. Deriving NETCONF Usernames From NETCONF Client Certificates 222 The algorithm for deriving NETCONF usernames from TLS certificates is 223 patterned after the algorithm for deriving tmSecurityNames from TLS 224 certificates specified in Transport Layer Security (TLS) Transport 225 Model for the Simple Network Management Protocol (SNMP) [RFC6353]. 226 The NETCONF server MUST implement the algorithms for deriving NETCONF 227 usernames from presented certificates that are documented in the 228 ietf-netconf-tls YANG module, defined in Section 3.2.3. This YANG 229 module lets the NETCONF security administrator configure how the 230 NETCONF server derives NETCONF usernames from presented certificates. 231 It also lets different certificate-to-username derivation algorithms 232 be used for different certificates. 234 When a NETCONF server accepts a TLS connection from a NETCONF client, 235 the NETCONF server attempts to derive a NETCONF username from the 236 certificate presented by the NETCONF client. If the NETCONF server 237 cannot derive a valid NETCONF username from the client's presented 238 certificate, then the NETCONF server MUST close the TLS connection, 239 and MUST NOT accept NETCONF messages over it. The NETCONF server 240 uses one of the following algorithms to produce a NETCONF username 241 from the certificate presented by the NETCONF client: 243 o Map a certificate directly to a specified, pre-configured, NETCONF 244 username; 246 o Extract the subjectAltName's rfc822Name from the certificate, then 247 use the extracted rfc822Name as the NETCONF username; 249 o Extract the subjectAltName's dnsName from the certificate, then 250 use the extracted dnsName as the NETCONF username; 252 o Extract the subjectAltName's iPAddress from the certificate, then 253 use the extracted iPAddress as the NETCONF username; 255 o Examine the subjectAltName's rfc822Name, dnsName, and iPAddress 256 fields in a pre-defined order. Return the value from the first 257 subjectAltName field that is examined, defined, and populated with 258 a non-empty value. If no subjectAltName field of a specific type 259 is defined, then the examination skips that field and proceeds to 260 examine the next field type. If a subjectAltName field is 261 defined, but the value is not populated, or is populated by an 262 empty value, then the examination skips that field and proceeds to 263 examine the next field type. 265 The NETCONF server MUST implement all of these algorithms, and allow 266 the deployer to choose the algorithm used. The cert-map list in the 267 ietf-netconf-tls YANG module specifies how a NETCONF server 268 transforms a certificate into a NETCONF username. 270 If the fingerprint of locally held copy of a trusted CA certificate 271 is configured in the cert-map list in the ietf-netconf-tls YANG 272 module, and that CA certificate is used to validate the certificate 273 presented by the client, then the NETCONF server uses that cert-map 274 list entry to produce the NETCONF username. This allows multiple 275 client certificates (all signed by the same trusted CA certificate) 276 to be mapped to a NETCONF username by a single entry in the cert-map 277 list. 279 3.2.2. Deriving NETCONF Usernames From PSK identities 281 Implementations MAY optionally support TLS Pre-Shared Key (PSK) 282 authentication [RFC4279]. RFC4279 describes pre-shared key 283 ciphersuites for TLS. The description of the psk-maps container in 284 the ietf-netconf-tls YANG module, defined in section 3.2.3, specifies 285 how a NETCONF server transforms a TLS pre-shared key into a NETCONF 286 username. 288 3.2.3. Remote Configuration 290 The ietf-netconf-tls YANG module defines objects for remotely 291 configuring the mapping of TLS certficates and of PSK Identities to 292 NETCONF usernames. 294 module ietf-netconf-tls { 296 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-tls"; 298 prefix "nctls"; 300 import ietf-yang-types { 301 prefix yang; 302 } 304 import ietf-netconf-acm { 305 prefix nacm; 306 } 308 organization 309 "IETF NETCONF (Network Configuration) Working Group"; 311 contact 312 "WG Web: 313 WG List: 315 WG Chair: Mehmet Ersue 316 318 WG Chair: Bert Wijnen 319 321 Editor: Mohamad Badra 322 "; 324 description 325 "This module applies to NETCONF over TLS. It specifies how NETCONF 326 servers transform X.509 certificates presented by clients into 327 NETCONF usernames. It also specifies how NETCONF servers transform 328 pre-shared TLS keys into NETCONF usernames. 330 The cert-maps container in this YANG module is patterned after parts 331 of the SNMP-TLS-TM-MIB defined in RFC 6353. Much of the description 332 text has been copied directly from the SNMP-TLS-TM-MIB, and modified 333 as necessary. 335 Copyright (c) 2012 IETF Trust and the persons identified as 336 authors of the code. All rights reserved. 338 Redistribution and use in source and binary forms, with or 339 without modification, is permitted pursuant to, and subject 340 to the license terms contained in, the Simplified BSD 341 License set forth in Section 4.c of the IETF Trust's 342 Legal Provisions Relating to IETF Documents 343 (http://trustee.ietf.org/license-info). 345 This version of this YANG module is part of RFC XXXX; see 346 the RFC itself for full legal notices."; 347 // RFC Ed.: replace XXXX with actual RFC number and 348 // remove this note 350 // RFC Ed.: please update the date to the date of publication 352 revision "2012-02-13" { 353 description 354 "Initial version"; 355 reference 356 "RFC XXXX: NETCONF over Transport Layer Security (TLS)"; 357 } 359 feature map-certificates { 360 description 361 "The map-certificates feature indicates that the server implements 362 mapping X.509 certificates to NETCONF user names."; 363 } 365 feature map-pre-shared-keys { 366 description 367 "The map-pre-shared-keys feature indicates that the server 368 implements mapping TLS pre-shared keys to NETCONF user names."; 370 } 372 typedef tls-fingerprint-type { 373 type string { 374 pattern '([0-9a-fA-F]){2}(:([0-9a-fA-F]){2})*'; 375 } 376 description 377 "A cryptographic signature (fingerprint) value that can be used to 378 uniquely reference other data of potentially arbitrary length."; 379 } 381 container netconf-config { 383 container tls { 385 // 386 // Objects related to deriving NETCONF usernames from X.509 387 // certificates. 388 // 390 container cert-maps { 391 if-feature map-certificates; 392 config true; 394 description 395 "The cert-maps container is used by a NETCONF server to map the 396 NETCONF client's presented X.509 certificate to a NETCONF username. 398 On an incoming TLS connection, the client's presented certificate 399 MUST either be validated based on an established trust anchor, or 400 it MUST directly match a fingerprint in the 'cert-map' list. This 401 module does not provide any mechanisms for configuring the 402 trust anchors; the transfer of any needed trusted certificates 403 for certificate chain validation is expected to occur through an 404 out-of-band transfer. 406 Once the certificate has been found acceptable (either by 407 certificate chain validation or directly matching a fingerprint 408 in the cert-map list), the cert-map list is consulted to determine 409 the appropriate NETCONF username to associate with the remote 410 connection. This is done by considering each cert-map list entry 411 in order. The cert-map entry's fingerprint determines whether the 412 list entry is a match for the incoming connection: 414 1) If the cert-map list entry's fingerprint value matches that 415 of the presented certificate, then consider the list entry 416 as a successful match. 418 2) If the cert-map list entry's fingerprint value matches that 419 of a locally held copy of a trusted CA certificate, and 420 that CA certificate was part of the CA certificate chain 421 to the presented certificate, then consider the list entry 422 as a successful match. 424 Once a matching cert-map list entry has been found, the NETCONF 425 server uses the map-type list to determine how the NETCONF username 426 associated with the session should be determined. See the map- 427 type leaf's description for details on determining the NETCONF 428 username value. If it is impossible to determine a NETCONF 429 username from the cert-map list entry's data combined with the data 430 presented in the certificate, then additional cert-map list entries 431 MUST be searched looking for another potential match. If a resulting 432 NETCONF username mapped from a given cert-map list entry is not 433 compatible with the needed requirements of a NETCONF username, 434 then it MUST be considered an invalid match and additional cert-map 435 list entries MUST be searched looking for another potential match. 437 If no matching and valid cert-map list entry can be found, then the 438 NETCONF server MUST close the connection, and MUST NOT accept 439 NETCONF messages over it. 441 Security administrators are encouraged to make use of certificates 442 with subjectAltName fields that can be used as NETCONF usernames 443 so that a single root CA certificate can allow all child 444 certificate's subjectAltName to map directly to a NETCONF 445 usernames via a 1:1 transformation."; 447 list cert-map { 448 key "key"; 449 ordered-by user; 450 description 451 "A single list entry that specifies a mapping for an incoming 452 TLS certificate to a NETCONF username."; 454 leaf key { 455 type string; 456 nacm:default-deny-all; 457 description 458 "The key associated with the cert-map list."; 459 } 461 container fingerprint { 462 choice algorithm-and-hash { 463 mandatory true; 464 leaf md5 { 465 type tls-fingerprint-type; 466 } 467 leaf sha1 { 468 type tls-fingerprint-type; 469 } 470 leaf sha224 { 471 type tls-fingerprint-type; 472 } 473 leaf sha256 { 474 type tls-fingerprint-type; 475 } 476 leaf sha384 { 477 type tls-fingerprint-type; 478 } 479 leaf sha512 { 480 type tls-fingerprint-type; 481 } 482 description 483 "Specifies the signature algorithm and cryptographic 484 signature (fingerprint) used to identify an X.509 485 certificate. 487 Implementations of this YANG module MAY, but are not 488 required to, implement all of these cryptographic signature 489 algorithms. Implementations of this YANG module MUST 490 implement at least one of these cryptographic signature 491 algorithms. 493 The available choices may be extended in the future as 494 stronger cryptographic signature algorithms become 495 available and are deemed necessary."; 497 reference 498 "RFC 5246: The Transport Layer Security (TLS) Protocol 499 Version 1.2; Section 7.4.1.4.1, Signature Algorithms"; 500 } // choice algorithm-and-hash 501 } // container fingerprint 503 choice map-type { 504 leaf specified { 505 type nacm:user-name-type; 506 description 507 "Directly specifies the NETCONF username to be used for this 508 certificate."; 509 } 510 leaf-list from-certificate { 511 ordered-by user; 512 type enumeration { 513 enum rfc822Name { 514 description 515 "Maps a subjectAltName's rfc822Name to a NETCONF username. 516 The local part of the rfc822Name is passed unaltered but 517 the domain-part of the name MUST be passed in lowercase. 518 This mapping results in a 1:1 correspondence between 519 equivalent subjectAltName rfc822Name values and NETCONF 520 username values except that the domain-part of the name 521 MUST be passed in lowercase. 523 Example rfc822Name Field: FooBar@Example.COM 524 is mapped to NETCONF username: FooBar@example.com."; 525 } 526 enum dNSName { 527 description 528 "Maps a subjectAltName's dNSName to a NETCONF username after 529 first converting it to all lowercase (RFC 5280 does not 530 specify converting to lowercase so this involves an extra 531 step). This mapping results in a 1:1 correspondence between 532 subjectAltName dNSName values and the NETCONF username 533 values. 535 reference: RFC 5280 - Internet X.509 Public Key 536 Infrastructure Certificate and Certificate 537 Revocation List (CRL) Profile."; 538 } 539 enum ipAddress { 540 description 541 "Maps a subjectAltName's iPAddress to a NETCONF username by 542 transforming the binary encoded address as follows: 544 1) for IPv4, the value is converted into a 545 decimal-dotted quad address (e.g., '192.0.2.1'). 547 2) for IPv6 addresses, the value is converted into a 548 32-character all lowercase hexadecimal string 549 without any colon separators. 551 This mapping results in a 1:1 correspondence between 552 subjectAltName iPAddress values and the NETCONF username 553 values."; 554 } 555 } 556 } // leaf-list from-certificate 557 description 558 "Specifies the algorithm for deriving a NETCONF username from 559 a certificate. If a mapping succeeds, then it will return a 560 NETCONF username. 562 If the resulting mapped value is not compatible with the 563 needed requirements of a NETCONF username, then subsequent 564 cert-map list entries MUST be searched for additional 565 matches to look for a mapping that succeeds."; 567 } // choice map-type 568 } // list cert-map 569 } // container cert-maps 571 // 572 // Objects related to deriving NETCONF usernames from TLS pre-shared 573 // keys. 574 // 576 container psk-maps { 577 if-feature map-pre-shared-keys; 579 description 580 "During the TLS Handshake, the client indicates which key to use 581 by including a PSK identity in the TLS ClientKeyExchange message. 582 On the server side, this PSK identity is used to look up an entry 583 in the psk-map list. If such an entry is found, and the pre-shared 584 keys match, then the client is authenticated. The server uses the 585 value from the user-name leaf in the psk-map list as the NETCONF 586 username. If the server cannot find an entry in the psk-map list, 587 or if the pre-shared keys do not match, then the server terminates 588 the connection. For details on how the PSK identity MAY be encoded 589 in UTF-8, see section 5.1. of RFC 4279."; 591 reference 592 "RFC 4279: Pre-Shared Key Ciphersuites for Transport Layer 593 Security (TLS)"; 595 list psk-map { 596 key psk-identity; 598 leaf psk-identity { 599 type string; 600 description 601 "The PSK identity encoded as a UTF-8 string."; 602 reference 603 "RFC 4279: Pre-Shared Key Ciphersuites for Transport Layer 604 Security (TLS)"; 605 } 607 leaf user-name { 608 type nacm:user-name-type; 609 mandatory true; 610 description 611 "The NETCONF username associated with this PSK identity."; 612 } 614 leaf valid-not-before { 615 type yang:date-and-time; 616 description 617 "This PSK identity is not valid before the given data 618 and time."; 619 } 621 leaf valid-not-after { 622 type yang:date-and-time; 623 description 624 "This PSK identity is not valid before the given date 625 and time."; 626 } 628 leaf key { 629 type string { 630 pattern '([0-9a-fA-F]){2}(:([0-9a-fA-F]){2})*'; 631 } 632 nacm:default-deny-all; 633 description 634 "The key associated with the PSK identity"; 635 } 636 } // list psk-map 637 } // container psk-maps 639 } // container tls 640 } // container netconf-config 641 } 643 4. Security Considerations 645 The security considerations described throughout [RFC5246] and 646 [RFC6241] apply here as well. 648 This document in its current version does not support third-party 649 authentication (e.g., backend Authentication, Authorization, and 650 Accounting (AAA) servers) due to the fact that TLS does not specify 651 this way of authentication and that NETCONF depends on the transport 652 protocol for the authentication service. If third-party 653 authentication is needed, SSH transport can be used. 655 An attacker might be able to inject arbitrary NETCONF messages via 656 some application that does not carefully check exchanged messages. 657 When the :base:1.1 capability is not advertised by both peers, an 658 attacker might be able to deliberately insert the delimiter sequence 659 ]]>]]> in a NETCONF message to create a DoS attack. If the :base:1.1 660 capability is not advertised by both peers, applications and NETCONF 661 APIs MUST ensure that the delimiter sequence ]]>]]> never appears in 662 NETCONF messages; otherwise, those messages can be dropped, garbled, 663 or misinterpreted. More specifically, if the delimiter sequence is 664 found in a NETCONF message by the sender side, a robust 665 implementation of this document SHOULD warn the user that illegal 666 characters have been discovered. If the delimiter sequence is found 667 in a NETCONF message by the receiver side (including any XML 668 attribute values, XML comments, or processing instructions), a robust 669 implementation of this document MUST silently discard the message 670 without further processing and then stop the NETCONF session. 672 Finally, this document does not introduce any new security 673 considerations compared to [RFC6242]. 675 5. IANA Considerations 677 Based on the previous version of this document, RFC 5539, IANA has 678 assigned a TCP port number (6513) in the "Registered Port Numbers" 679 range with the name "netconf-tls". This port will be the default 680 port for NETCONF over TLS, as defined in this document. 682 Registration Contact: Mohamad Badra, mbadra@gmail.com. 683 Transport Protocol: TCP. 684 Port Number: 6513 685 Broadcast, Multicast or Anycast: No. 686 Port Name: netconf-tls. 687 Service Name: netconf. 688 Reference: RFC 5539 690 6. Acknowledgements 692 A significant amount of the text in Section 3 was lifted from 693 [RFC4642]. 695 The author would like to acknowledge David Harrington, Miao Fuyou, 696 Eric Rescorla, Simon Josefsson, Olivier Coupelon, Alfred Hoenes, and 697 the NETCONF mailing list members for their comments on the document. 698 The author also appreciates Bert Wijnen, Mehmet Ersue, and Dan 699 Romascanu for their efforts on issues resolving discussion; and 700 Charlie Kaufman, Pasi Eronen, and Tim Polk for the thorough review of 701 previous versions of this document. 703 7. Contributor's Address 705 Ibrahim Hajjeh 706 Ineovation 707 France 709 EMail: ibrahim.hajjeh@ineovation.fr 711 Martin Bjorklund 712 Tail-f Systems 714 Email: mbj@tail-f.com 716 8. References 718 8.1. Normative References 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, March 1997. 723 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 724 for Transport Layer Security (TLS)", RFC 4279, 725 December 2005. 727 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 728 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 730 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 731 Housley, R., and W. Polk, "Internet X.509 Public Key 732 Infrastructure Certificate and Certificate Revocation List 733 (CRL) Profile", RFC 5280, May 2008. 735 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 736 Verification of Domain-Based Application Service Identity 737 within Internet Public Key Infrastructure Using X.509 738 (PKIX) Certificates in the Context of Transport Layer 739 Security (TLS)", RFC 6125, March 2011. 741 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 742 Shell (SSH)", RFC 6242, June 2011. 744 [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport 745 Model for the Simple Network Management Protocol (SNMP)", 746 RFC 6353, July 2011. 748 8.2. Informative References 750 [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using 751 Transport Layer Security (TLS) with Network News Transfer 752 Protocol (NNTP)", RFC 4642, October 2006. 754 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 755 Notifications", RFC 5277, July 2008. 757 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", 758 RFC 5539, May 2009. 760 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 761 Bierman, "Network Configuration Protocol (NETCONF)", 762 RFC 6241, June 2011. 764 Appendix A. Change Log (to be removed by RFC Editor before publication) 766 A.1. From draft-ietf-netconf-rfc5539bis-00 to 767 draft-ietf-netconf-rfc5539bis-01 769 o Update Section 3.2 and address some issues raised during WGLC 771 A.2. From draft-badra-netconf-rfc5539bis-02 to 772 draft-ietf-netconf-rfc5539bis-00 774 o Remove the reference to BEEP 776 o Rename host-part to domain-part in the description of RFC822. 778 Authors' Addresses 780 Mohamad Badra 781 LIMOS Laboratory 783 Email: mbadra@gmail.com 785 Alan Luchuk 786 SNMP Research 788 Email: luchuk@snmp.com 790 Juergen Schoenwaelder 791 Jacobs University Bremen 793 Email: j.schoenwaelder@jacobs-university.de