idnits 2.17.1 draft-badra-netconf-rfc5539bis-02.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 28, 2012) is 4382 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 681, 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: 2 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 Dhofar University 4 Obsoletes: 5539 (if approved) April 28, 2012 5 Intended status: Standards Track 6 Expires: October 30, 2012 8 NETCONF Over Transport Layer Security (TLS) 9 draft-badra-netconf-rfc5539bis-02 11 Abstract 13 The Network Configuration Protocol (NETCONF) provides mechanisms to 14 install, manipulate, and delete the configuration of network devices. 15 This document describes how to use the Transport Layer Security (TLS) 16 protocol to secure NETCONF exchanges. This document obsoletes RFC 17 5539. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 30, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 55 2. NETCONF over TLS . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Connection Initiation . . . . . . . . . . . . . . . . . . 3 57 2.2. Connection Closure . . . . . . . . . . . . . . . . . . . . 4 58 3. Endpoint Authentication, Identification and Authorization . . 4 59 3.1. Server Identity . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Client Identity . . . . . . . . . . . . . . . . . . . . . 5 61 3.2.1. Deriving NETCONF Usernames From NETCONF Client 62 Certificates . . . . . . . . . . . . . . . . . . . . . 5 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 66 7. Contributor's Address . . . . . . . . . . . . . . . . . . . . 17 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 70 Appendix A. Change Log (to be removed by RFC Editor before 71 publication) . . . . . . . . . . . . . . . . . . . . 19 72 A.1. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 19 73 A.2. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 19 74 A.3. From RFC5539 to draft-badra-netconf-rfc5539bis-00 . . . . 19 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 77 1. Introduction 79 The NETCONF protocol [RFC6241] defines a mechanism through which a 80 network device can be managed. NETCONF is connection-oriented, 81 requiring a persistent connection between peers. This connection 82 must provide integrity, confidentiality, peer authentication, and 83 reliable, sequenced data delivery. 85 This document defines "NETCONF over TLS", which includes support for 86 certificate and pre-shared key (PSK)-based authentication and key 87 derivation, utilizing the protected ciphersuite negotiation, mutual 88 authentication, and key management capabilities of the TLS (Transport 89 Layer Security) protocol, described in [RFC5246]. 91 1.1. Conventions Used in This Document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. NETCONF over TLS 99 Since TLS is application-protocol-independent, NETCONF can operate on 100 top of the TLS protocol transparently. This document defines how 101 NETCONF can be used within a TLS session. 103 2.1. Connection Initiation 105 The peer acting as the NETCONF client MUST also act as the TLS 106 client. The client actively opens the TLS connection and the server 107 passively listens for the incoming TLS connection on the TCP port 108 6513. It MUST therefore send the TLS ClientHello message to begin 109 the TLS handshake. Once the TLS handshake has finished, the client 110 and the server MAY begin to exchange NETCONF data. In particular, 111 the client will send complete XML documents to the server containing 112 elements, and the server will respond with complete XML 113 documents containing elements. The client MAY indicate 114 interest in receiving event notifications from a server by creating a 115 subscription to receive event notifications [RFC5277]. In this case, 116 the server replies to indicate whether the subscription request was 117 successful and, if it was successful, the server begins sending the 118 event notifications to the client as the events occur within the 119 system. 121 All NETCONF messages MUST be sent as TLS "application data". It is 122 possible that multiple NETCONF messages be contained in one TLS 123 record, or that a NETCONF message be transferred in multiple TLS 124 records. 126 The previous version [RFC5539] of this document used the same framing 127 sequence defined in [RFC6242], under the assumption that it could not 128 be found in well-formed XML documents. However, this assumption is 129 not correct [RFC6242]. In order to solve this problem, and at the 130 same time be compatible with existing implementations, this document 131 uses the framing protocol defined in [RFC6242] as following : 133 The message MUST be followed by the character sequence 134 ]]>]]>. Upon reception of the message, the receiving peer's 135 TLS Transport layer conceptually passes the message to the 136 Messages layer. If the :base:1.1 capability is advertised by both 137 peers, the chunked framing mechanism defined in Section 4.2 of 138 [RFC6242] is used for the remainder of the NETCONF session. 139 Otherwise, the old end-of-message-based mechanism (see Section 4.3 of 140 [RFC6242]) is used. 142 Implementation of the protocol specified in this document MAY 143 implement any TLS cipher suite that provides mutual authentication 144 [RFC5246]. 146 Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to 147 support the mandatory-to-implement cipher suite, which is 148 TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to 149 future versions of TLS; in which case, the mandatory-to-implement 150 cipher suite for the implemented version MUST be supported. 152 2.2. Connection Closure 154 Exiting NETCONF is accomplished using the operation. 155 A NETCONF server will process NETCONF messages from the NETCONF 156 client in the order in which they are received. When the NETCONF 157 server processes a operation, the NETCONF server 158 SHALL respond and close the TLS session channel. The NETCONF server 159 MUST NOT process any NETCONF messages received after the operation. The TLS session is closed as described in 161 [RFC6242] Section 7.2.1. 163 3. Endpoint Authentication, Identification and Authorization 165 3.1. Server Identity 167 If the server's presented certificate has passed certification path 168 validation [RFC5280] to a configured trust anchor, the client MUST 169 carefully examine the certificate presented by the server to 170 determine if it meets the client's expectations. Particularly, the 171 client MUST check its understanding of the server hostname against 172 the server's identity as presented in the server Certificate message, 173 in order to prevent man- in-the-middle attacks. 175 Matching is performed according to the rules and guidelines defined 176 in [RFC6125]. 178 If the match fails, the client MUST either ask for explicit user 179 confirmation or terminate the connection and indicate the server's 180 identity is suspect. 182 Additionally, clients MUST verify the binding between the identity of 183 the servers to which they connect and the public keys presented by 184 those servers. Clients SHOULD implement the algorithm in Section 6 185 of [RFC5280] for general certificate validation, but MAY supplement 186 that algorithm with other validation methods that achieve equivalent 187 levels of verification (such as comparing the server certificate 188 against a local store of already-verified certificates and identity 189 bindings). 191 If the client has external information as to the expected identity of 192 the server, the hostname check MAY be omitted. 194 3.2. Client Identity 196 The server MUST verify the identity of the client to ensure that the 197 incoming client request is legitimate before any configuration or 198 state data is sent to or received from the client. 200 The NETCONF protocol [RFC6241] requires that the transport protocol's 201 authentication process MUST result in an authenticated client 202 identity whose permissions are known to the server. The 203 authenticated identity of a client is commonly referred to as the 204 NETCONF username. 206 The username provided by the TLS implementation will be made 207 available to the NETCONF message layer as the NETCONF username 208 without modification. If the username does not comply to the NETCONF 209 requirements on usernames [RFC6241], i.e., the username is not 210 representable in XML, the TLS session MUST be dropped. 212 Algorithms for mapping certificates or PSK identities (sent by the 213 client) to NETCONF usernames are described below. 215 3.2.1. Deriving NETCONF Usernames From NETCONF Client Certificates 217 The algorithm for deriving NETCONF usernames from TLS certificates is 218 patterned after the algorithm for deriving tmSecurityNames from TLS 219 certificates specified in Transport Layer Security (TLS) Transport 220 Model for the Simple Network Management Protocol (SNMP) [RFC6353]. 221 The NETCONF server MUST implement the algorithms for deriving NETCONF 222 usernames from presented certificates that are documented in the 223 ietf-netconf-tls YANG module. This YANG module lets the NETCONF 224 security administrator configure how the NETCONF server derives 225 NETCONF usernames from presented certificates. It also lets 226 different certificate-to-username derivation algorithms be used for 227 different certificates. 229 When a NETCONF server accepts a TLS connection from a NETCONF client, 230 the NETCONF server attempts to derive a NETCONF username from the 231 certificate presented by the NETCONF client. If the NETCONF server 232 cannot derive a valid NETCONF username from the client's presented 233 certificate, then the NETCONF server MUST close the TLS connection, 234 and MUST NOT accept NETCONF messages over it. The NETCONF server MAY 235 use any of the following algorithms to produce the NETCONF username 236 from the certificate presented by the NETCONF client: 238 o Map a certificate directly to a specified, pre-configured, NETCONF 239 username; 241 o Extract the subjectAltName's rfc822Name from the certificate, then 242 use the extracted rfc822Name as the NETCONF username; 244 o Extract the subjectAltName's dnsName from the certificate, then 245 use the extracted dnsName as the NETCONF username; 247 o Extract the subjectAltName's iPAddress from the certificate, then 248 use the extracted iPAddress as the NETCONF username; 250 o Examine the subjectAltName's rfc822Name, dnsName, and iPAddress 251 fields in a pre-defined order. Return the value from the first 252 subjectAltName field that is examined, defined, and populated with 253 a non-empty value. If no subjectAltName field of a specific type 254 is defined, then the examination skips that field and proceeds to 255 examine the next field type. If a subjectAltName field is 256 defined, but the value is not populated, or is populated by an 257 empty value, then the examination skips that field and proceeds to 258 examine the next field type. 260 The NETCONF server MUST implement all of these algorithms, and allow 261 the deployer to choose the algorithm used. The certificate-to- 262 username-transforms container in the ietf-netconf-tls YANG module 263 specifies how a NETCONF server transforms a certificate into a 264 NETCONF username. 266 3.2.1.1. Identifying a Certificate 268 A client certificate has an identity: the certificate. The TLS and 269 corresponding protocols provide an identity. The identity shows that 270 "this client certificate has shown that it, indeed, is on the other 271 side of the connection". With a complete certificate, the 272 certificate receiver can be certain that for someone or something on 273 the other side to use that certificate successfully, it has the 274 associated private key. 276 The problem with using the entire certificates as the identity is 277 that they are difficult for people to use. It is generally accepted 278 that a fingerprint of a certificate is not likely to come up with a 279 collision against a fingerprint of another (different) certificate. 280 Thus, assuming a good hash algorithm, a fingerprint can be a safe 281 short-hand for identifying a certificate. 283 If a locally held copy of a trusted CA certificate is configured in 284 the transformation container, and that CA certificate was used to 285 validate the path to the presented certificate, then the NETCONF 286 server SHOULD use that list entry in the transformation container. 287 All presented certificates validated by the configured CA certificate 288 will be transformed to NETCONF usernames using the same 289 transformation algorithm. 291 3.2.1.2. Deriving NETCONF Usernames From PSK identities 293 Implementations MAY optionally support TLS Pre-Shared Key (PSK) 294 authentication [RFC4279]. RFC4279 describes pre-shared key 295 ciphersuites for TLS. During the TLS Handshake, the client indicates 296 which key to use by including a "PSK identity" in the TLS 297 ClientKeyExchange message [RFC4279]. On the server side, this PSK 298 identity is used to look up the key corresponding to the presented 299 PSK identity. If the selected pre-shared keys match and the key is 300 valid, then the client is authenticated and the NETCONF username 301 associated with the PSK identity. For details on how the PSK 302 identity MAY be encoded in UTF-8, see section 5.1. of RFC [RFC6241]. 304 3.2.1.3. Remote Configuration 306 The ietf-netconf-tls YANG module defines objects for remotely 307 configuring the mapping of TLS certficates and of PSK Identities to 308 NETCONF usernames. 310 module ietf-netconf-tls { 311 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-tls"; 313 prefix "nctls"; 315 import ietf-yang-types { 316 prefix yang; 317 } 319 import ietf-netconf-acm { 320 prefix nacm; 321 } 323 organization 324 "IETF NETCONF (Network Configuration) Working Group"; 326 contact 327 "WG Web: 328 WG List: 330 WG Chair: Mehmet Ersue 331 333 WG Chair: Bert Wijnen 334 336 Editor: Mohamad Badra 337 "; 339 description 340 "This module applies to NETCONF over TLS. It specifies how NETCONF 341 servers transform X.509 certificates presented by clients into 342 NETCONF usernames. It also specifies how NETCONF servers transform 343 pre-shared TLS keys into NETCONF usernames. 345 This YANG module is patterned after parts of the SNMP-TLS-TM-MIB 346 defined in RFC 6353. Much of the description text has been copied 347 directly from the SNMP-TLS-TM-MIB, and modified as necessary. 349 Copyright (c) 2012 IETF Trust and the persons identified as 350 authors of the code. All rights reserved. 352 Redistribution and use in source and binary forms, with or 353 without modification, is permitted pursuant to, and subject 354 to the license terms contained in, the Simplified BSD 355 License set forth in Section 4.c of the IETF Trust's 356 Legal Provisions Relating to IETF Documents 357 (http://trustee.ietf.org/license-info). 358 This version of this YANG module is part of RFC XXXX; see 359 the RFC itself for full legal notices."; 360 // RFC Ed.: replace XXXX with actual RFC number and 361 // remove this note 363 // RFC Ed.: please update the date to the date of publication 365 revision "2012-04-11" { 366 description 367 "Incorporates comments on draft-badra-netconf-rfc5539bis-01.txt."; 368 reference 369 "RFC XXXX: NETCONF over Transport Layer Security (TLS)"; 370 } 372 revision "2012-02-13" { 373 description 374 "Initial version"; 375 reference 376 "RFC XXXX: NETCONF over Transport Layer Security (TLS)"; 377 } 379 feature map-certificates { 380 description 381 "The :map-certificates capability implements mapping X.509 382 certificates to NETCONF user names."; 383 } 385 feature map-pre-shared-keys { 386 description 387 "The :map-pre-shared-keys capability implements mapping TLS 388 pre-shared keys to NETCONF user names."; 389 } 391 typedef tls-fingerprint-type { 392 type string { 393 pattern '([0-9a-fA-F]){2}(:([0-9a-fA-F]){2})*'; 394 } 395 description 396 "A cryptographic signature (fingerprint) value that can be used to 397 uniquely reference other data of potentially arbitrary length."; 398 } 400 // 401 // Objects related to deriving NETCONF usernames from X.509 402 // certificates. 403 // 405 container cert-mappings { 406 if-feature map-certificates; 407 config true; 408 description 409 "This container is used by a NETCONF server to map the NETCONF 410 client's presented X.509 certificate to a NETCONF username. 412 On an incoming TLS connection, the client's presented certificate 413 MUST either be validated based on an established trust anchor, or 414 it MUST directly match a fingerprint in this container. This 415 container does not provide any mechanisms for configuring the 416 trust anchors; the transfer of any needed trusted certificates 417 for certificate chain validation is expected to occur through an 418 out-of-band transfer. 420 Once the certificate has been found acceptable (either by 421 certificate chain validation or directly matching a fingerprint 422 in this container), this container is consulted to determine the 423 appropriate NETCONF username to associate with the remote 424 connection. This is done by considering each list entry from 425 this container in prioritized order according to its index value. 426 Each list entry's fingerprint value determines whether the list 427 entry is a match for the incoming connection: 429 1) If the list entry's fingerprint value matches that 430 of the presented certificate, then consider the list entry 431 as a successful match. 433 2) If the list entry's fingerprint value matches that 434 of a locally held copy of a trusted CA certificate, and 435 that CA certificate was part of the CA certificate chain 436 to the presented certificate, then consider the list entry 437 as a successful match. 439 This feature lets the NETCONF server derive NETCONF 440 usernames from all certificates signed by the trusted 441 CA certificate. The NETCONF server will derive all 442 NETCONF usernames using the same derivation algorithm. 443 The NETCONF server requires only a single list entry 444 to configure this behavior. 446 Once a matching list entry has been found, the NETCONF server 447 uses the map-type value to determine how the NETCONF username 448 associated with the session should be determined. See the map- 449 type leaf's description for details on determining the NETCONF 450 username value. If it is impossible to determine a NETCONF 451 username from the list entry's data combined with the data 452 presented in the certificate, then additional list entries MUST 453 be searched looking for another potential match. If a resulting 454 NETCONF username mapped from a given list entry is not compatible 455 with the needed requirements of a NETCONF username, then it MUST 456 be considered an invalid match and additional list entries MUST 457 be searched looking for another potential match. 459 If no matching and valid list entry can be found, then the 460 NETCONF server MUST close the connection, and MUST NOT accept 461 NETCONF messages over it. 463 Non-consecutive values of index are acceptable and implementations 464 should continue to the next highest numbered list entry. It is 465 recommended that administrators skip index values to leave room 466 for the insertion of future list entries (for example, use values 467 of 10 and 20 when creating initial list entries). 469 Security administrators are encouraged to make use of certificates 470 with subjectAltName fields that can be used as NETCONF usernames 471 so that a single root CA certificate can allow all child 472 certificate's subjectAltName to map directly to a NETCONF 473 usernames via a 1:1 transformation. However, this container is 474 flexible to allow for situations where existing deployed 475 certificate infrastructures do not provide adequate subjectAltName 476 values for use as NETCONF usernames."; 478 list cert-map { 479 key "index"; 480 description 481 "A single list entry that specifies a mapping for an incoming 482 TLS certificate to a NETCONF username."; 484 leaf index { 485 type uint32 { 486 range "1..4294967295"; 487 } 488 description 489 "A unique, prioritized index for the given entry. Lower 490 numbers indicate a higher priority."; 491 } 493 container fingerprint { 494 choice algorithm-and-hash { 495 leaf md5 { 496 type tls-fingerprint-type; 498 } 499 leaf sha1 { 500 type tls-fingerprint-type; 501 } 502 leaf sha224 { 503 type tls-fingerprint-type; 504 } 505 leaf sha256 { 506 type tls-fingerprint-type; 507 } 508 leaf sha384 { 509 type tls-fingerprint-type; 510 } 511 leaf sha512 { 512 type tls-fingerprint-type; 513 } 514 description 515 "Specifies the signature algorithm and cryptographic 516 signature (fingerprint) used to identify an X.509 517 certificate. 519 Implementations of this YANG module MAY, but are not 520 required to, implement all of these cryptographic signature 521 algorithms. Implementations of this YANG module MUST 522 implement at least one of these cryptographic signature 523 algorithms. 525 The available choices may be extended in the future as 526 stronger cryptographic signature algorithms become 527 available and are deemed necessary."; 529 reference 530 "RFC 5246: The Transport Layer Security (TLS) Protocol 531 Version 1.2; Section 7.4.1.4.1, Signature Algorithms"; 532 } // choice algorithm-and-hash 533 } // container fingerprint 535 leaf map-type { 536 type enumeration { 537 enum specified { value 1; } 538 enum rfc822Name { value 2; } 539 enum dnsName { value 3; } 540 enum ipAddress { value 4; } 541 enum rfc822Name-dnsName-ipAddress { value 5; } 542 } 544 description 545 "Specifies the algorithm for deriving a NETCONF username from 546 a certificate. If a mapping succeeds, then it will return a 547 NETCONF username. 549 If the resulting mapped value is not compatible with the 550 needed requirements of a NETCONF username, then subsequent 551 list entries MUST be searched for additional NETCONF username 552 matches to look for a mapping that succeeds. 554 For each enumerated value listed above, the NETCONF server 555 derives the NETCONF from the presented client certificate 556 as described: 558 specified 560 Directly specifies the NETCONF username to be used for 561 this certificate. The value of the NETCONF username 562 to use is specified in the data leaf of the list. The 563 data leaf MUST contain a non-zero length value or the 564 mapping described in this list entry MUST be considered a 565 failure. 567 rfc822Name 569 Maps a subjectAltName's rfc822Name to a NETCONF username. 570 The local part of the rfc822Name is passed unaltered but 571 the host-part of the name MUST be passed in lowercase. 572 This mapping results in a 1:1 correspondence between 573 equivalent subjectAltName rfc822Name values and NETCONF 574 username values except that the host-part of the name 575 MUST be passed in lowercase. 577 Example rfc822Name Field: FooBar@Example.COM 578 is mapped to NETCONF username: FooBar@example.com. 580 dnsName 582 Maps a subjectAltName's dNSName to a NETCONF username after 583 first converting it to all lowercase (RFC 5280 does not 584 specify converting to lowercase so this involves an extra 585 step). This mapping results in a 1:1 correspondence between 586 subjectAltName dNSName values and the NETCONF username 587 values. 589 reference: RFC 5280 - Internet X.509 Public Key 590 Infrastructure Certificate and Certificate 591 Revocation List (CRL) Profile. 593 ipAddress 595 Maps a subjectAltName's iPAddress to a NETCONF username by 596 transforming the binary encoded address as follows: 598 1) for IPv4, the value is converted into a 599 decimal-dotted quad address (e.g., '192.0.2.1'). 601 2) for IPv6 addresses, the value is converted into a 602 32-character all lowercase hexadecimal string 603 without any colon separators. 605 This mapping results in a 1:1 correspondence between 606 subjectAltName iPAddress values and the NETCONF username 607 values. 609 rfc822Name-dnsName-ipAddress 611 The NETCONF server derives the NETCONF username from the 612 subjectAltName fields rfc822Name, dnsName, and ipAddress, 613 as described in sections above. This enumeration specifies 614 the NETCONF server first examines the rfc822Name, then 615 examines the dnsName, then finally examines the ipAddress. 616 The first matching subjectAltName value found in the 617 certificate MUST be used when deriving the NETCONF username. 619 These mappings result in a 1:1 correspondence between 620 subjectAltName values and NETCONF username values. The 621 sub-mapping algorithms produced by these combined algorithms 622 cannot produce conflicting results between themselves."; 623 } // leaf map-type 625 leaf data { 626 type string { 627 length "1..max"; 628 } 629 description 630 "Auxiliary data used as optional configuration information for 631 a given mapping specified by the map-type leaf. Only some 632 mapping systems will make use of this leaf. When the NETCONF 633 server derives the NETCONF username from the client's presented 634 certificate, the value in this leaf MUST be ignored for any 635 mapping type that does not require data present in this leaf."; 636 } 637 } // list cert-map 638 } // container cert-mappings 639 // 640 // Objects related to deriving NETCONF usernames from TLS pre-shared 641 // keys. 642 // 644 container psk-map { 645 if-feature map-pre-shared-keys; 646 list psk { 647 key psk-identity; 649 leaf psk-identity { 650 type string; 651 description 652 "The PSK identity encoded as a UTF-8 string."; 653 reference 654 "RFC 4279: Pre-Shared Key Ciphersuites for Transport Layer 655 Security (TLS)"; 656 } 658 leaf user-name { 659 type nacm:user-name-type; 660 mandatory true; 661 description 662 "The NETCONF username associated with this PSK identity."; 663 } 665 leaf valid-not-before { 666 type yang:date-and-time; 667 description 668 "This PSK identity is not valid before the given data 669 and time."; 670 } 672 leaf valid-not-after { 673 type yang:date-and-time; 674 description 675 "This PSK identity is not valid before the given data 676 and time."; 677 } 679 leaf key { 680 type string; 681 pattern '([0-9a-fA-F]){2}(:([0-9a-fA-F]){2})*'; 682 nacm:default-deny-all; 683 description 684 "The key associated with the PSK identity"; 685 } 686 } 688 } // container psk-map 689 } 691 4. Security Considerations 693 The security considerations described throughout [RFC5246] and 694 [RFC6241] apply here as well. 696 This document in its current version does not support third-party 697 authentication (e.g., backend Authentication, Authorization, and 698 Accounting (AAA) servers) due to the fact that TLS does not specify 699 this way of authentication and that NETCONF depends on the transport 700 protocol for the authentication service. If third-party 701 authentication is needed, BEEP or SSH transport can be used. 703 An attacker might be able to inject arbitrary NETCONF messages via 704 some application that does not carefully check exchanged messages. 705 When the :base:1.1 capability is not advertised by both peers, an 706 attacker might be able to deliberately insert the delimiter sequence 707 ]]>]]> in a NETCONF message to create a DoS attack. If the :base:1.1 708 capability is not advertised by both peers, applications and NETCONF 709 APIs MUST ensure that the delimiter sequence ]]>]]> never appears in 710 NETCONF messages; otherwise, those messages can be dropped, garbled, 711 or misinterpreted. More specifically, if the delimiter sequence is 712 found in a NETCONF message by the sender side, a robust 713 implementation of this document SHOULD warn the user that illegal 714 characters have been discovered. If the delimiter sequence is found 715 in a NETCONF message by the receiver side (including any XML 716 attribute values, XML comments, or processing instructions), a robust 717 implementation of this document MUST silently discard the message 718 without further processing and then stop the NETCONF session. 720 Finally, this document does not introduce any new security 721 considerations compared to [RFC6242]. 723 5. IANA Considerations 725 Based on the previous version of this document, RFC 5539, IANA has 726 assigned a TCP port number (6513) in the "Registered Port Numbers" 727 range with the name "netconf-tls". This port will be the default 728 port for NETCONF over TLS, as defined in this document. 730 Registration Contact: Mohamad Badra, mbadra@gmail.com. 731 Transport Protocol: TCP. 732 Port Number: 6513 733 Broadcast, Multicast or Anycast: No. 734 Port Name: netconf-tls. 735 Service Name: netconf. 736 Reference: RFC 5539 738 6. Acknowledgements 740 A significant amount of the text in Section 3 was lifted from 741 [RFC4642]. 743 The author would like to acknowledge David Harrington, Miao Fuyou, 744 Eric Rescorla, Juergen Schoenwaelder, Simon Josefsson, Olivier 745 Coupelon, Alfred Hoenes, and the NETCONF mailing list members for 746 their comments on the document. The author also appreciates Bert 747 Wijnen, Mehmet Ersue, and Dan Romascanu for their efforts on issues 748 resolving discussion; and Charlie Kaufman, Pasi Eronen, and Tim Polk 749 for the thorough review of previous versions of this document. 751 7. Contributor's Address 753 Ibrahim Hajjeh 754 Ineovation 755 France 757 EMail: ibrahim.hajjeh@ineovation.fr 759 Alan Luchuk 760 SNMP Research, Inc. 761 3001 Kimberlin Heights Road 762 Knoxville, TN 37920-9716 764 EMail: luchuk@snmp.com 766 Juergen Schoenwaelder 767 Jacobs University Bremen 768 Campus Ring 1 769 28725 Bremen 770 Germany 772 EMail: j.schoenwaelder@jacobs-university.de 774 8. References 776 8.1. Normative References 778 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 779 Requirement Levels", BCP 14, RFC 2119, March 1997. 781 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 782 for Transport Layer Security (TLS)", RFC 4279, 783 December 2005. 785 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 786 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 788 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 789 Housley, R., and W. Polk, "Internet X.509 Public Key 790 Infrastructure Certificate and Certificate Revocation List 791 (CRL) Profile", RFC 5280, May 2008. 793 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 794 Verification of Domain-Based Application Service Identity 795 within Internet Public Key Infrastructure Using X.509 796 (PKIX) Certificates in the Context of Transport Layer 797 Security (TLS)", RFC 6125, March 2011. 799 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 800 Shell (SSH)", RFC 6242, June 2011. 802 [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport 803 Model for the Simple Network Management Protocol (SNMP)", 804 RFC 6353, July 2011. 806 8.2. Informative References 808 [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using 809 Transport Layer Security (TLS) with Network News Transfer 810 Protocol (NNTP)", RFC 4642, October 2006. 812 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 813 Notifications", RFC 5277, July 2008. 815 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", 816 RFC 5539, May 2009. 818 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 819 Bierman, "Network Configuration Protocol (NETCONF)", 820 RFC 6241, June 2011. 822 Appendix A. Change Log (to be removed by RFC Editor before publication) 824 A.1. From -01 to -02 826 o Update the server identity check and add rfc6125 828 o Update the closure session and remove text related to close_notify 829 alert specified by TLS 831 o Update YANG Module 833 A.2. From -00 to -01 835 o Move RFC5539 to informative references and remove RFC4742. 837 o Shorten the YANG object names; 839 o Extend the YANG module to support configuration of PSK; 841 A.3. From RFC5539 to draft-badra-netconf-rfc5539bis-00 843 o Added text on how the generation of a NETCONF username is done. 845 o Added text on how does this document fulfill the requirements in 846 6241 for the format of the username. 848 o Removed unneeded wording about client/server, and changed use of 849 client/server, manager/agent to TLS client/server and NETCONF 850 client/server. 852 o Added text to Security Considerations about EOM issues. 854 o Added option for the chunked encoding described in RFC6242. 856 o Added 1.1 capability to enable the chunked encoding described in 857 RFC6242. 859 Author's Address 861 Mohamad Badra 862 Dhofar University 864 Email: mbadra@gmail.com