idnits 2.17.1 draft-ietf-netconf-rfc5539bis-00.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 is 1 instance of too long lines in the document, the longest one being 1 character 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 (September 13, 2012) is 4235 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 693, 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) September 13, 2012 5 Intended status: Standards Track 6 Expires: March 17, 2013 8 NETCONF Over Transport Layer Security (TLS) 9 draft-ietf-netconf-rfc5539bis-00 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 March 17, 2013. 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 . . . . . . . . . . . . . . . . . . . . . 17 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 66 7. Contributor's Address . . . . . . . . . . . . . . . . . . . . 18 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 70 Appendix A. Change Log (to be removed by RFC Editor before 71 publication) . . . . . . . . . . . . . . . . . . . . 19 72 A.1. From draft-badra-netconf-rfc5539bis-02 to 73 draft-ietf-netconf-rfc5539bis-00 . . . . . . . . . . . . . 19 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 1. Introduction 78 The NETCONF protocol [RFC6241] defines a mechanism through which a 79 network device can be managed. NETCONF is connection-oriented, 80 requiring a persistent connection between peers. This connection 81 must provide integrity, confidentiality, peer authentication, and 82 reliable, sequenced data delivery. 84 This document defines "NETCONF over TLS", which includes support for 85 certificate and pre-shared key (PSK)-based authentication and key 86 derivation, utilizing the protected ciphersuite negotiation, mutual 87 authentication, and key management capabilities of the TLS (Transport 88 Layer Security) protocol, described in [RFC5246]. 90 1.1. Conventions Used in This Document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. NETCONF over TLS 98 Since TLS is application-protocol-independent, NETCONF can operate on 99 top of the TLS protocol transparently. This document defines how 100 NETCONF can be used within a TLS session. 102 2.1. Connection Initiation 104 The peer acting as the NETCONF client MUST also act as the TLS 105 client. The client actively opens the TLS connection and the server 106 passively listens for the incoming TLS connection on the TCP port 107 6513. It MUST therefore send the TLS ClientHello message to begin 108 the TLS handshake. Once the TLS handshake has finished, the client 109 and the server MAY begin to exchange NETCONF data. In particular, 110 the client will send complete XML documents to the server containing 111 elements, and the server will respond with complete XML 112 documents containing elements. The client MAY indicate 113 interest in receiving event notifications from a server by creating a 114 subscription to receive event notifications [RFC5277]. In this case, 115 the server replies to indicate whether the subscription request was 116 successful and, if it was successful, the server begins sending the 117 event notifications to the client as the events occur within the 118 system. 120 All NETCONF messages MUST be sent as TLS "application data". It is 121 possible that multiple NETCONF messages be contained in one TLS 122 record, or that a NETCONF message be transferred in multiple TLS 123 records. 125 The previous version [RFC5539] of this document used the same framing 126 sequence defined in [RFC6242], under the assumption that it could not 127 be found in well-formed XML documents. However, this assumption is 128 not correct [RFC6242]. In order to solve this problem, and at the 129 same time be compatible with existing implementations, this document 130 uses the framing protocol defined in [RFC6242] as following : 132 The message MUST be followed by the character sequence 133 ]]>]]>. Upon reception of the message, the receiving peer's 134 TLS Transport layer conceptually passes the message to the 135 Messages layer. If the :base:1.1 capability is advertised by both 136 peers, the chunked framing mechanism defined in Section 4.2 of 137 [RFC6242] is used for the remainder of the NETCONF session. 138 Otherwise, the old end-of-message-based mechanism (see Section 4.3 of 139 [RFC6242]) is used. 141 Implementation of the protocol specified in this document MAY 142 implement any TLS cipher suite that provides mutual authentication 143 [RFC5246]. 145 Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to 146 support the mandatory-to-implement cipher suite, which is 147 TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to 148 future versions of TLS; in which case, the mandatory-to-implement 149 cipher suite for the implemented version MUST be supported. 151 2.2. Connection Closure 153 Exiting NETCONF is accomplished using the operation. 154 A NETCONF server will process NETCONF messages from the NETCONF 155 client in the order in which they are received. When the NETCONF 156 server processes a operation, the NETCONF server 157 SHALL respond and close the TLS session channel. The NETCONF server 158 MUST NOT process any NETCONF messages received after the operation. The TLS session is closed as described in 160 [RFC6242] Section 7.2.1. 162 3. Endpoint Authentication, Identification and Authorization 164 3.1. Server Identity 166 If the server's presented certificate has passed certification path 167 validation [RFC5280] to a configured trust anchor, the client MUST 168 carefully examine the certificate presented by the server to 169 determine if it meets the client's expectations. Particularly, the 170 client MUST check its understanding of the server hostname against 171 the server's identity as presented in the server Certificate message, 172 in order to prevent man- in-the-middle attacks. 174 Matching is performed according to the rules and guidelines defined 175 in [RFC6125]. 177 If the match fails, the client MUST either ask for explicit user 178 confirmation or terminate the connection and indicate the server's 179 identity is suspect. 181 Additionally, clients MUST verify the binding between the identity of 182 the servers to which they connect and the public keys presented by 183 those servers. Clients SHOULD implement the algorithm in Section 6 184 of [RFC5280] for general certificate validation, but MAY supplement 185 that algorithm with other validation methods that achieve equivalent 186 levels of verification (such as comparing the server certificate 187 against a local store of already-verified certificates and identity 188 bindings). 190 If the client has external information as to the expected identity of 191 the server, the hostname check MAY be omitted. 193 3.2. Client Identity 195 The server MUST verify the identity of the client to ensure that the 196 incoming client request is legitimate before any configuration or 197 state data is sent to or received from the client. 199 The NETCONF protocol [RFC6241] requires that the transport protocol's 200 authentication process MUST result in an authenticated client 201 identity whose permissions are known to the server. The 202 authenticated identity of a client is commonly referred to as the 203 NETCONF username. 205 The username provided by the TLS implementation will be made 206 available to the NETCONF message layer as the NETCONF username 207 without modification. If the username does not comply to the NETCONF 208 requirements on usernames [RFC6241], i.e., the username is not 209 representable in XML, the TLS session MUST be dropped. 211 Algorithms for mapping certificates or PSK identities (sent by the 212 client) to NETCONF usernames are described below. 214 3.2.1. Deriving NETCONF Usernames From NETCONF Client Certificates 216 The algorithm for deriving NETCONF usernames from TLS certificates is 217 patterned after the algorithm for deriving tmSecurityNames from TLS 218 certificates specified in Transport Layer Security (TLS) Transport 219 Model for the Simple Network Management Protocol (SNMP) [RFC6353]. 220 The NETCONF server MUST implement the algorithms for deriving NETCONF 221 usernames from presented certificates that are documented in the 222 ietf-netconf-tls YANG module. This YANG module lets the NETCONF 223 security administrator configure how the NETCONF server derives 224 NETCONF usernames from presented certificates. It also lets 225 different certificate-to-username derivation algorithms be used for 226 different certificates. 228 When a NETCONF server accepts a TLS connection from a NETCONF client, 229 the NETCONF server attempts to derive a NETCONF username from the 230 certificate presented by the NETCONF client. If the NETCONF server 231 cannot derive a valid NETCONF username from the client's presented 232 certificate, then the NETCONF server MUST close the TLS connection, 233 and MUST NOT accept NETCONF messages over it. The NETCONF server MAY 234 use any of the following algorithms to produce the NETCONF username 235 from the certificate presented by the NETCONF client: 237 o Map a certificate directly to a specified, pre-configured, NETCONF 238 username; 240 o Extract the subjectAltName's rfc822Name from the certificate, then 241 use the extracted rfc822Name as the NETCONF username; 243 o Extract the subjectAltName's dnsName from the certificate, then 244 use the extracted dnsName as the NETCONF username; 246 o Extract the subjectAltName's iPAddress from the certificate, then 247 use the extracted iPAddress as the NETCONF username; 249 o Examine the subjectAltName's rfc822Name, dnsName, and iPAddress 250 fields in a pre-defined order. Return the value from the first 251 subjectAltName field that is examined, defined, and populated with 252 a non-empty value. If no subjectAltName field of a specific type 253 is defined, then the examination skips that field and proceeds to 254 examine the next field type. If a subjectAltName field is 255 defined, but the value is not populated, or is populated by an 256 empty value, then the examination skips that field and proceeds to 257 examine the next field type. 259 The NETCONF server MUST implement all of these algorithms, and allow 260 the deployer to choose the algorithm used. The certificate-to- 261 username-transforms container in the ietf-netconf-tls YANG module 262 specifies how a NETCONF server transforms a certificate into a 263 NETCONF username. 265 3.2.1.1. Identifying a Certificate 267 A client certificate has an identity: the certificate. The TLS and 268 corresponding protocols provide an identity. The identity shows that 269 "this client certificate has shown that it, indeed, is on the other 270 side of the connection". With a complete certificate, the 271 certificate receiver can be certain that for someone or something on 272 the other side to use that certificate successfully, it has the 273 associated private key. 275 The problem with using the entire certificates as the identity is 276 that they are difficult for people to use. It is generally accepted 277 that a fingerprint of a certificate is not likely to come up with a 278 collision against a fingerprint of another (different) certificate. 279 Thus, assuming a good hash algorithm, a fingerprint can be a safe 280 short-hand for identifying a certificate. 282 If a locally held copy of a trusted CA certificate is configured in 283 the transformation container, and that CA certificate was used to 284 validate the path to the presented certificate, then the NETCONF 285 server SHOULD use that list entry in the transformation container. 286 All presented certificates validated by the configured CA certificate 287 will be transformed to NETCONF usernames using the same 288 transformation algorithm. 290 3.2.1.2. Deriving NETCONF Usernames From PSK identities 292 Implementations MAY optionally support TLS Pre-Shared Key (PSK) 293 authentication [RFC4279]. RFC4279 describes pre-shared key 294 ciphersuites for TLS. During the TLS Handshake, the client indicates 295 which key to use by including a "PSK identity" in the TLS 296 ClientKeyExchange message [RFC4279]. On the server side, this PSK 297 identity is used to look up the key corresponding to the presented 298 PSK identity. If the selected pre-shared keys match and the key is 299 valid, then the client is authenticated and the NETCONF username 300 associated with the PSK identity. For details on how the PSK 301 identity MAY be encoded in UTF-8, see section 5.1. of RFC [RFC6241]. 303 3.2.1.3. Remote Configuration 305 The ietf-netconf-tls YANG module defines objects for remotely 306 configuring the mapping of TLS certficates and of PSK Identities to 307 NETCONF usernames. 309 module ietf-netconf-tls { 310 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-tls"; 312 prefix "nctls"; 314 import ietf-yang-types { 315 prefix yang; 316 } 318 import ietf-netconf-acm { 319 prefix nacm; 320 } 322 organization 323 "IETF NETCONF (Network Configuration) Working Group"; 325 contact 326 "WG Web: 327 WG List: 329 WG Chair: Mehmet Ersue 330 332 WG Chair: Bert Wijnen 333 335 Editor: Mohamad Badra 336 "; 338 description 339 "This module applies to NETCONF over TLS. It specifies how NETCONF 340 servers transform X.509 certificates presented by clients into 341 NETCONF usernames. It also specifies how NETCONF servers transform 342 pre-shared TLS keys into NETCONF usernames. 344 This YANG module is patterned after parts of the SNMP-TLS-TM-MIB 345 defined in RFC 6353. Much of the description text has been copied 346 directly from the SNMP-TLS-TM-MIB, and modified as necessary. 348 Copyright (c) 2012 IETF Trust and the persons identified as 349 authors of the code. All rights reserved. 351 Redistribution and use in source and binary forms, with or 352 without modification, is permitted pursuant to, and subject 353 to the license terms contained in, the Simplified BSD 354 License set forth in Section 4.c of the IETF Trust's 355 Legal Provisions Relating to IETF Documents 356 (http://trustee.ietf.org/license-info). 357 This version of this YANG module is part of RFC XXXX; see 358 the RFC itself for full legal notices."; 359 // RFC Ed.: replace XXXX with actual RFC number and 360 // remove this note 362 // RFC Ed.: please update the date to the date of publication 364 revision "2012-09-13" { 365 description 366 "rename host-part to domain-part in the description of RFC822". 367 reference 368 "RFC XXXX: NETCONF over Transport Layer Security (TLS)"; 369 } 371 revision "2012-04-27" { 372 description 373 "Changed data type of fingerprints and keys from binary to string."; 374 reference 375 "RFC XXXX: NETCONF over Transport Layer Security (TLS)"; 376 } 378 revision "2012-04-11" { 379 description 380 "Incorporates comments on draft-badra-netconf-rfc5539bis-01.txt."; 381 reference 382 "RFC XXXX: NETCONF over Transport Layer Security (TLS)"; 383 } 385 revision "2012-02-13" { 386 description 387 "Initial version"; 388 reference 389 "RFC XXXX: NETCONF over Transport Layer Security (TLS)"; 390 } 392 feature map-certificates { 393 description 394 "The :map-certificates capability implements mapping X.509 395 certificates to NETCONF user names."; 396 } 398 feature map-pre-shared-keys { 399 description 400 "The :map-pre-shared-keys capability implements mapping TLS 401 pre-shared keys to NETCONF user names."; 402 } 403 typedef tls-fingerprint-type { 404 type string { 405 pattern '([0-9a-fA-F]){2}(:([0-9a-fA-F]){2})*'; 406 } 407 description 408 "A cryptographic signature (fingerprint) value that can be used to 409 uniquely reference other data of potentially arbitrary length."; 410 } 412 // 413 // Objects related to deriving NETCONF usernames from X.509 414 // certificates. 415 // 417 container cert-mappings { 418 if-feature map-certificates; 419 config true; 420 description 421 "This container is used by a NETCONF server to map the NETCONF 422 client's presented X.509 certificate to a NETCONF username. 424 On an incoming TLS connection, the client's presented certificate 425 MUST either be validated based on an established trust anchor, or 426 it MUST directly match a fingerprint in this container. This 427 container does not provide any mechanisms for configuring the 428 trust anchors; the transfer of any needed trusted certificates 429 for certificate chain validation is expected to occur through an 430 out-of-band transfer. 432 Once the certificate has been found acceptable (either by 433 certificate chain validation or directly matching a fingerprint 434 in this container), this container is consulted to determine the 435 appropriate NETCONF username to associate with the remote 436 connection. This is done by considering each list entry from 437 this container in prioritized order according to its index value. 438 Each list entry's fingerprint value determines whether the list 439 entry is a match for the incoming connection: 441 1) If the list entry's fingerprint value matches that 442 of the presented certificate, then consider the list entry 443 as a successful match. 445 2) If the list entry's fingerprint value matches that 446 of a locally held copy of a trusted CA certificate, and 447 that CA certificate was part of the CA certificate chain 448 to the presented certificate, then consider the list entry 449 as a successful match. 451 This feature lets the NETCONF server derive NETCONF 452 usernames from all certificates signed by the trusted 453 CA certificate. The NETCONF server will derive all 454 NETCONF usernames using the same derivation algorithm. 455 The NETCONF server requires only a single list entry 456 to configure this behavior. 458 Once a matching list entry has been found, the NETCONF server 459 uses the map-type value to determine how the NETCONF username 460 associated with the session should be determined. See the map- 461 type leaf's description for details on determining the NETCONF 462 username value. If it is impossible to determine a NETCONF 463 username from the list entry's data combined with the data 464 presented in the certificate, then additional list entries MUST 465 be searched looking for another potential match. If a resulting 466 NETCONF username mapped from a given list entry is not compatible 467 with the needed requirements of a NETCONF username, then it MUST 468 be considered an invalid match and additional list entries MUST 469 be searched looking for another potential match. 471 If no matching and valid list entry can be found, then the 472 NETCONF server MUST close the connection, and MUST NOT accept 473 NETCONF messages over it. 475 Non-consecutive values of index are acceptable and implementations 476 should continue to the next highest numbered list entry. It is 477 recommended that administrators skip index values to leave room 478 for the insertion of future list entries (for example, use values 479 of 10 and 20 when creating initial list entries). 481 Security administrators are encouraged to make use of certificates 482 with subjectAltName fields that can be used as NETCONF usernames 483 so that a single root CA certificate can allow all child 484 certificate's subjectAltName to map directly to a NETCONF 485 usernames via a 1:1 transformation. However, this container is 486 flexible to allow for situations where existing deployed 487 certificate infrastructures do not provide adequate subjectAltName 488 values for use as NETCONF usernames."; 490 list cert-map { 491 key "index"; 492 description 493 "A single list entry that specifies a mapping for an incoming 494 TLS certificate to a NETCONF username."; 496 leaf index { 497 type uint32 { 498 range "1..4294967295"; 499 } 500 description 501 "A unique, prioritized index for the given entry. Lower 502 numbers indicate a higher priority."; 503 } 505 container fingerprint { 506 choice algorithm-and-hash { 507 leaf md5 { 508 type tls-fingerprint-type; 509 } 510 leaf sha1 { 511 type tls-fingerprint-type; 512 } 513 leaf sha224 { 514 type tls-fingerprint-type; 515 } 516 leaf sha256 { 517 type tls-fingerprint-type; 518 } 519 leaf sha384 { 520 type tls-fingerprint-type; 521 } 522 leaf sha512 { 523 type tls-fingerprint-type; 524 } 525 description 526 "Specifies the signature algorithm and cryptographic 527 signature (fingerprint) used to identify an X.509 528 certificate. 530 Implementations of this YANG module MAY, but are not 531 required to, implement all of these cryptographic signature 532 algorithms. Implementations of this YANG module MUST 533 implement at least one of these cryptographic signature 534 algorithms. 536 The available choices may be extended in the future as 537 stronger cryptographic signature algorithms become 538 available and are deemed necessary."; 540 reference 541 "RFC 5246: The Transport Layer Security (TLS) Protocol 542 Version 1.2; Section 7.4.1.4.1, Signature Algorithms"; 543 } // choice algorithm-and-hash 544 } // container fingerprint 545 leaf map-type { 546 type enumeration { 547 enum specified { value 1; } 548 enum rfc822Name { value 2; } 549 enum dnsName { value 3; } 550 enum ipAddress { value 4; } 551 enum rfc822Name-dnsName-ipAddress { value 5; } 552 } 554 description 555 "Specifies the algorithm for deriving a NETCONF username from 556 a certificate. If a mapping succeeds, then it will return a 557 NETCONF username. 559 If the resulting mapped value is not compatible with the 560 needed requirements of a NETCONF username, then subsequent 561 list entries MUST be searched for additional NETCONF username 562 matches to look for a mapping that succeeds. 564 For each enumerated value listed above, the NETCONF server 565 derives the NETCONF from the presented client certificate 566 as described: 568 specified 570 Directly specifies the NETCONF username to be used for 571 this certificate. The value of the NETCONF username 572 to use is specified in the data leaf of the list. The 573 data leaf MUST contain a non-zero length value or the 574 mapping described in this list entry MUST be considered a 575 failure. 577 rfc822Name 579 Maps a subjectAltName's rfc822Name to a NETCONF username. 580 The local part of the rfc822Name is passed unaltered but 581 the host-part of the name MUST be passed in lowercase. 582 This mapping results in a 1:1 correspondence between 583 equivalent subjectAltName rfc822Name values and NETCONF 584 username values except that the host-part of the name 585 MUST be passed in lowercase. 587 Example rfc822Name Field: FooBar@Example.COM 588 is mapped to NETCONF username: FooBar@example.com. 590 dnsName 592 Maps a subjectAltName's dNSName to a NETCONF username after 593 first converting it to all lowercase (RFC 5280 does not 594 specify converting to lowercase so this involves an extra 595 step). This mapping results in a 1:1 correspondence between 596 subjectAltName dNSName values and the NETCONF username 597 values. 599 reference: RFC 5280 - Internet X.509 Public Key 600 Infrastructure Certificate and Certificate 601 Revocation List (CRL) Profile. 603 ipAddress 605 Maps a subjectAltName's iPAddress to a NETCONF username by 606 transforming the binary encoded address as follows: 608 1) for IPv4, the value is converted into a 609 decimal-dotted quad address (e.g., '192.0.2.1'). 611 2) for IPv6 addresses, the value is converted into a 612 32-character all lowercase hexadecimal string 613 without any colon separators. 615 This mapping results in a 1:1 correspondence between 616 subjectAltName iPAddress values and the NETCONF username 617 values. 619 rfc822Name-dnsName-ipAddress 621 The NETCONF server derives the NETCONF username from the 622 subjectAltName fields rfc822Name, dnsName, and ipAddress, 623 as described in sections above. This enumeration specifies 624 the NETCONF server first examines the rfc822Name, then 625 examines the dnsName, then finally examines the ipAddress. 626 The first matching subjectAltName value found in the 627 certificate MUST be used when deriving the NETCONF username. 629 These mappings result in a 1:1 correspondence between 630 subjectAltName values and NETCONF username values. The 631 sub-mapping algorithms produced by these combined algorithms 632 cannot produce conflicting results between themselves."; 633 } // leaf map-type 635 leaf data { 636 type string { 637 length "1..max"; 638 } 639 description 640 "Auxiliary data used as optional configuration information for 641 a given mapping specified by the map-type leaf. Only some 642 mapping systems will make use of this leaf. When the NETCONF 643 server derives the NETCONF username from the client's presented 644 certificate, the value in this leaf MUST be ignored for any 645 mapping type that does not require data present in this leaf."; 646 } 647 } // list cert-map 648 } // container cert-mappings 650 // 651 // Objects related to deriving NETCONF usernames from TLS pre-shared 652 // keys. 653 // 655 container psk-map { 656 if-feature map-pre-shared-keys; 657 list psk { 658 key psk-identity; 660 leaf psk-identity { 661 type string; 662 description 663 "The PSK identity encoded as a UTF-8 string."; 664 reference 665 "RFC 4279: Pre-Shared Key Ciphersuites for Transport Layer 666 Security (TLS)"; 667 } 669 leaf user-name { 670 type nacm:user-name-type; 671 mandatory true; 672 description 673 "The NETCONF username associated with this PSK identity."; 674 } 676 leaf valid-not-before { 677 type yang:date-and-time; 678 description 679 "This PSK identity is not valid before the given data 680 and time."; 681 } 683 leaf valid-not-after { 684 type yang:date-and-time; 685 description 686 "This PSK identity is not valid before the given data 687 and time."; 689 } 691 leaf key { 692 type string; 693 pattern '([0-9a-fA-F]){2}(:([0-9a-fA-F]){2})*'; 694 nacm:default-deny-all; 695 description 696 "The key associated with the PSK identity"; 697 } 698 } 699 } // container psk-map 700 } 702 4. Security Considerations 704 The security considerations described throughout [RFC5246] and 705 [RFC6241] apply here as well. 707 This document in its current version does not support third-party 708 authentication (e.g., backend Authentication, Authorization, and 709 Accounting (AAA) servers) due to the fact that TLS does not specify 710 this way of authentication and that NETCONF depends on the transport 711 protocol for the authentication service. If third-party 712 authentication is needed, SSH transport can be used. 714 An attacker might be able to inject arbitrary NETCONF messages via 715 some application that does not carefully check exchanged messages. 716 When the :base:1.1 capability is not advertised by both peers, an 717 attacker might be able to deliberately insert the delimiter sequence 718 ]]>]]> in a NETCONF message to create a DoS attack. If the :base:1.1 719 capability is not advertised by both peers, applications and NETCONF 720 APIs MUST ensure that the delimiter sequence ]]>]]> never appears in 721 NETCONF messages; otherwise, those messages can be dropped, garbled, 722 or misinterpreted. More specifically, if the delimiter sequence is 723 found in a NETCONF message by the sender side, a robust 724 implementation of this document SHOULD warn the user that illegal 725 characters have been discovered. If the delimiter sequence is found 726 in a NETCONF message by the receiver side (including any XML 727 attribute values, XML comments, or processing instructions), a robust 728 implementation of this document MUST silently discard the message 729 without further processing and then stop the NETCONF session. 731 Finally, this document does not introduce any new security 732 considerations compared to [RFC6242]. 734 5. IANA Considerations 736 Based on the previous version of this document, RFC 5539, IANA has 737 assigned a TCP port number (6513) in the "Registered Port Numbers" 738 range with the name "netconf-tls". This port will be the default 739 port for NETCONF over TLS, as defined in this document. 741 Registration Contact: Mohamad Badra, mbadra@gmail.com. 742 Transport Protocol: TCP. 743 Port Number: 6513 744 Broadcast, Multicast or Anycast: No. 745 Port Name: netconf-tls. 746 Service Name: netconf. 747 Reference: RFC 5539 749 6. Acknowledgements 751 A significant amount of the text in Section 3 was lifted from 752 [RFC4642]. 754 The author would like to acknowledge David Harrington, Miao Fuyou, 755 Eric Rescorla, Juergen Schoenwaelder, Simon Josefsson, Olivier 756 Coupelon, Alfred Hoenes, and the NETCONF mailing list members for 757 their comments on the document. The author also appreciates Bert 758 Wijnen, Mehmet Ersue, and Dan Romascanu for their efforts on issues 759 resolving discussion; and Charlie Kaufman, Pasi Eronen, and Tim Polk 760 for the thorough review of previous versions of this document. 762 7. Contributor's Address 764 Ibrahim Hajjeh 765 Ineovation 766 France 768 EMail: ibrahim.hajjeh@ineovation.fr 770 Alan Luchuk 771 SNMP Research, Inc. 772 3001 Kimberlin Heights Road 773 Knoxville, TN 37920-9716 775 EMail: luchuk@snmp.com 777 Juergen Schoenwaelder 778 Jacobs University Bremen 779 Campus Ring 1 780 28725 Bremen 781 Germany 783 EMail: j.schoenwaelder@jacobs-university.de 785 8. References 787 8.1. Normative References 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, March 1997. 792 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 793 for Transport Layer Security (TLS)", RFC 4279, 794 December 2005. 796 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 797 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 799 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 800 Housley, R., and W. Polk, "Internet X.509 Public Key 801 Infrastructure Certificate and Certificate Revocation List 802 (CRL) Profile", RFC 5280, May 2008. 804 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 805 Verification of Domain-Based Application Service Identity 806 within Internet Public Key Infrastructure Using X.509 807 (PKIX) Certificates in the Context of Transport Layer 808 Security (TLS)", RFC 6125, March 2011. 810 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 811 Shell (SSH)", RFC 6242, June 2011. 813 [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport 814 Model for the Simple Network Management Protocol (SNMP)", 815 RFC 6353, July 2011. 817 8.2. Informative References 819 [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using 820 Transport Layer Security (TLS) with Network News Transfer 821 Protocol (NNTP)", RFC 4642, October 2006. 823 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 824 Notifications", RFC 5277, July 2008. 826 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", 827 RFC 5539, May 2009. 829 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 830 Bierman, "Network Configuration Protocol (NETCONF)", 831 RFC 6241, June 2011. 833 Appendix A. Change Log (to be removed by RFC Editor before publication) 835 A.1. From draft-badra-netconf-rfc5539bis-02 to 836 draft-ietf-netconf-rfc5539bis-00 838 o Remove the reference to BEEP 840 o rename host-part to domain-part in the description of RFC822. 842 Author's Address 844 Mohamad Badra 845 LIMOS Laboratory 847 Email: mbadra@gmail.com