idnits 2.17.1 draft-acee-rtg-yang-key-chain-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 25, 2015) is 3135 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) -- Duplicate reference: draft-chen-rtg-key-table-yang, mentioned in 'YANG-CRYPTO-KEYTABLE', was also mentioned in 'TCP-AO-ALGORITHMS'. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem, Ed. 3 Internet-Draft Y. Qu 4 Intended status: Standards Track D. Yeung 5 Expires: March 28, 2016 Cisco Systems 6 I. Chen 7 Ericsson 8 J. Zhang 9 Juniper Networks 10 Y. Yang 11 Cisco Systems 12 September 25, 2015 14 Key Chain YANG Data Model 15 draft-acee-rtg-yang-key-chain-08.txt 17 Abstract 19 This document describes the key chain YANG data model. A key chain 20 is a list of elements each containing a key, send lifetime, accept 21 lifetime, and algorithm. By properly overlapping the send and accept 22 lifetimes of multiple key chain elements, keys and algorithms may be 23 gracefully updated. By representing them in a YANG data model, key 24 distribution can be automated. Key chains are commonly used for 25 routing protocol authentication and other applications. In some 26 applications, the protocols do not use the key chain element key 27 directly, but rather a key derivation function is used to derive a 28 short-lived key from the key chain element key. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 28, 2016. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 66 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Graceful Key Rollover using Key Chains . . . . . . . . . 3 68 3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 4 69 3.1. Key Chain Operational State . . . . . . . . . . . . . . . 5 70 3.2. Key Chain Model Features . . . . . . . . . . . . . . . . 5 71 3.3. Key Chain Model Tree . . . . . . . . . . . . . . . . . . 5 72 4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 8 73 5. Relationship to other Work . . . . . . . . . . . . . . . . . 16 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 78 8.2. Informative References . . . . . . . . . . . . . . . . . 17 79 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 82 1. Introduction 84 This document describes the key chain YANG data model. A key chain 85 is a list of elements each containing a key, send lifetime, accept 86 lifetime, and algorithm. By properly overlapping the send and accept 87 lifetimes of multiple key chain elements, keys and algorithms may be 88 gracefully updated. By representing them in a YANG data model, key 89 distribution can be automated. Key chains are commonly used for 90 routing protocol authentication and other applications. In some 91 applications, the protocols do not use the key chain element key 92 directly, but rather a key derivation function is used to derive a 93 short-lived key from the key chain element key. 95 1.1. Requirements Notation 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC-KEYWORDS]. 101 2. Problem Statement 103 This document describes a YANG [YANG] data model for key chains. Key 104 chains have been implemented and deployed by a large percentage of 105 network equipment vendors. Providing a standard YANG model will 106 facilitate automated key distribution and non-disruptive key 107 rollover. This will aid in tightening the security of the core 108 routing infrastructure as recommended in [IAB-REPORT]. 110 A key chain is a list containing one or more elements containing a 111 Key ID, key, send/accept lifetimes, and the associated authentication 112 or encryption algorithm. A key chain can be used by any service or 113 application requiring authentication or encryption. In essence, the 114 key-chain is a reusable key policy that can be referenced where ever 115 it is required. The key-chain construct has been implemented by most 116 networking vendors and deployed in many networks. 118 A conceptual representation of a crypto key table is described in 119 [CRYPTO-KEYTABLE]. The crypto key table also includes keys as well 120 as their corresponding lifetimes and algorithms. Additionally, the 121 key table includes key selection criteria and envisions a deployment 122 model where the details of the applications or services requiring 123 authentication or encryption permeate into the key database. The 124 YANG key-chain model described herein doesn't include key selection 125 criteria or support this deployment model. At the same time, it does 126 not preclude it. The draft [YANG-CRYPTO-KEYTABLE] describes 127 augmentations to the key chain YANG model in support of key selection 128 criteria. 130 2.1. Graceful Key Rollover using Key Chains 132 Key chains may be used to gracefully update the key and/or algorithm 133 used by an application for authentication or encryption. This MAY be 134 accomplished by accepting all the keys that have a valid accept 135 lifetime and sending the key with the most recent send lifetime. One 136 scenario for facilitating key rollover is to: 138 1. Distribute a key chain with a new key to all the routers or other 139 network devices in the domain of that key chain. The new key's 140 accept lifetime should be such that it is accepted during the key 141 rollover period. The send lifetime should be a time in the 142 future when it can be assured that all the routers in the domain 143 of that key are upgraded. This will have no immediate impact on 144 the keys used for transmission. 146 2. Assure that all the network devices have been updated with the 147 updated key chain and that their system times are roughly 148 synchronized. The system times of devices within an 149 administrative domain are commonly synchronized (e.g., using 150 Network Time Protocol (NTP) [NTP-PROTO]). This also may be 151 automated. 153 3. When the send lifetime of the new key becomes valid, the network 154 devices within the domain of key chain will start sending the new 155 key. 157 4. At some point in the future, a new key chain with the old key 158 removed may be distributed to the network devices within the 159 domain of the key chain. However, this may be deferred until the 160 next key rollover. If this is done, the key chain will always 161 include two keys; either the current and future key (during key 162 rollovers) or the current and previous keys (between key 163 rollovers). 165 3. Design of the Key Chain Model 167 The ietf-keychain module contains a list of one or more keys indexed 168 by a Key ID. For some applications (e.g., OSPFv3 [OSPFV3-AUTH]), the 169 Key-Id is used to identify the key chain entry to be used. In 170 addition to the Key-ID, each key chain entry includes a key-string 171 and a cryptographic algorithm. Optionally, the key chain entries 172 include send/accept lifetimes. If the send/accept lifetime is 173 unspecified, the key is always considered valid. 175 Note that asymmetric keys, i.e., a different key value used for 176 transmission versus acceptance, may be supported with multiple key 177 chain elements where the accept-lifetime or send-lifetime is not 178 valid (e.g., has an end-time equal to the start-time). 180 Due to the differences in key chain implementations across various 181 vendors, some of the data elements are optional. Additionally, the 182 key-chain is made a grouping so that an implementation could support 183 scoping other than at the global level. Finally, the crypto- 184 algorithm-types grouping is provided for reuse when configuring 185 legacy authentication and encryption not using key-chains. 187 A key-chain is identified by a unique name within the scope of the 188 network device. The "key-chain-ref" typedef SHOULD be used by other 189 YANG modules when they need to reference a configured key-chain. 191 3.1. Key Chain Operational State 193 The key chain operational state is maintained in the key-chain 194 entries along with the configuration state. The key string itself is 195 omitted from the operational state to minimize visibility similar to 196 what was done with keys in SNMP MIBs. This is an area for further 197 discussion. Additionally, the operational state includes an 198 indication of whether or not a key chain entry is valid for sending 199 or acceptance. 201 3.2. Key Chain Model Features 203 Features are used to handle differences between vendor 204 implementations. For example, not all vendors support configuration 205 an acceptance tolerance or configuration of key strings in 206 hexadecimal. They are also used to support of security requirements 207 (e.g., TCP-AO Algorithms [TCP-AO-ALGORITHMS]) not implemented by 208 vendors or only a single vendor. 210 3.3. Key Chain Model Tree 212 +--rw key-chains 213 +--rw key-chain-list* [name] 214 | +--rw name string 215 | +--ro name-state? string 216 | +--rw accept-tolerance {accept-tolerance}? 217 | | +--rw duration? uint32 218 | +--ro accept-tolerance-state 219 | | +--ro duration? uint32 220 | +--rw key-chain-entry* [key-id] 221 | +--rw key-id uint64 222 | +--ro key-id-state? uint64 223 | +--rw key-string 224 | | +--rw (key-string-style)? 225 | | +--:(keystring) 226 | | | +--rw keystring? string 227 | | +--:(hexadecimal) {hex-key-string}? 228 | | +--rw hexadecimal-string? yang:hex-string 229 | +--rw lifetime 230 | | +--rw (lifetime)? 231 | | +--:(send-and-accept-lifetime) 232 | | | +--rw send-accept-lifetime 233 | | | +--rw (lifetime)? 234 | | | +--:(always) 235 | | | | +--rw always? empty 236 | | | +--:(start-end-time) 237 | | | +--rw start-date-time? 238 | | | yang:date-and-time 239 | | | +--rw (end-time)? 240 | | | +--:(infinite) 241 | | | | +--rw no-end-time? empty 242 | | | +--:(duration) 243 | | | | +--rw duration? uint32 244 | | | +--:(end-date-time) 245 | | | +--rw end-date-time? 246 | | | yang:date-and-time 247 | | +--:(independent-send-accept-lifetime) 248 | | {independent-send-accept-lifetime}? 249 | | +--rw send-lifetime 250 | | | +--rw (lifetime)? 251 | | | +--:(always) 252 | | | | +--rw always? empty 253 | | | +--:(start-end-time) 254 | | | +--rw start-date-time? 255 | | | yang:date-and-time 256 | | | +--rw (end-time)? 257 | | | +--:(infinite) 258 | | | | +--rw no-end-time? empty 259 | | | +--:(duration) 260 | | | | +--rw duration? uint32 261 | | | +--:(end-date-time) 262 | | | +--rw end-date-time? 263 | | | yang:date-and-time 264 | | +--rw accept-lifetime 265 | | +--rw (lifetime)? 266 | | +--:(always) 267 | | | +--rw always? empty 268 | | +--:(start-end-time) 269 | | +--rw start-date-time? 270 | | | yang:date-and-time 271 | | +--rw (end-time)? 272 | | +--:(infinite) 273 | | | +--rw no-end-time? empty 274 | | +--:(duration) 275 | | | +--rw duration? uint32 276 | | +--:(end-date-time) 277 | | +--rw end-date-time? 278 | | yang:date-and-time 279 | +--ro lifetime-state 280 | | +--ro send-lifetime 281 | | | +--ro (lifetime)? 282 | | | +--:(always) 283 | | | | +--ro always? empty 284 | | | +--:(start-end-time) 285 | | | +--ro start-date-time? yang:date-and-time 286 | | | +--ro (end-time)? 287 | | | +--:(infinite) 288 | | | | +--ro no-end-time? empty 289 | | | +--:(duration) 290 | | | | +--ro duration? uint32 291 | | | +--:(end-date-time) 292 | | | +--ro end-date-time? 293 | | | yang:date-and-time 294 | | +--ro send-valid? boolean 295 | | +--ro accept-lifetime 296 | | | +--ro (lifetime)? 297 | | | +--:(always) 298 | | | | +--ro always? empty 299 | | | +--:(start-end-time) 300 | | | +--ro start-date-time? yang:date-and-time 301 | | | +--ro (end-time)? 302 | | | +--:(infinite) 303 | | | | +--ro no-end-time? empty 304 | | | +--:(duration) 305 | | | | +--ro duration? uint32 306 | | | +--:(end-date-time) 307 | | | +--ro end-date-time? 308 | | | yang:date-and-time 309 | | +--ro accept-valid? boolean 310 | +--rw crypto-algorithm 311 | | +--rw (algorithm)? 312 | | +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}? 313 | | | +--rw hmac-sha1-12? empty 314 | | +--:(aes-cmac-prf-128) {aes-cmac-prf-128}? 315 | | | +--rw aes-cmac-prf-128? empty 316 | | +--:(md5) 317 | | | +--rw md5? empty 318 | | +--:(sha-1) 319 | | | +--rw sha-1? empty 320 | | +--:(hmac-sha-1) 321 | | | +--rw hmac-sha-1? empty 322 | | +--:(hmac-sha-256) 323 | | | +--rw hmac-sha-256? empty 324 | | +--:(hmac-sha-384) 325 | | | +--rw hmac-sha-384? empty 326 | | +--:(hmac-sha-512) 327 | | +--rw hmac-sha-512? empty 328 | +--ro crypto-algorithm-state 329 | +--ro (algorithm)? 330 | +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}? 331 | | +--ro hmac-sha1-12? empty 332 | +--:(aes-cmac-prf-128) {aes-cmac-prf-128}? 333 | | +--ro aes-cmac-prf-128? empty 334 | +--:(md5) 335 | | +--ro md5? empty 336 | +--:(sha-1) 337 | | +--ro sha-1? empty 338 | +--:(hmac-sha-1) 339 | | +--ro hmac-sha-1? empty 340 | +--:(hmac-sha-256) 341 | | +--ro hmac-sha-256? empty 342 | +--:(hmac-sha-384) 343 | | +--ro hmac-sha-384? empty 344 | +--:(hmac-sha-512) 345 | +--ro hmac-sha-512? empty 346 +--rw aes-key-wrap {aes-key-wrap}? 347 | +--rw enable? boolean 348 +--ro aes-key-wrap-state {aes-key-wrap}? 349 +--ro enable? boolean 351 4. Key Chain YANG Model 353 file "ietf-key-chain@2015-09-26.yang" 354 module ietf-key-chain { 355 namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain"; 356 // replace with IANA namespace when assigned 357 prefix "key-chain"; 359 import ietf-yang-types { 360 prefix "yang"; 361 } 363 organization 364 "Cisco Systems 365 170 West Tasman Drive 366 San Jose, CA 95134-1706 367 USA"; 368 contact 369 "Acee Lindem - acee@cisco.com"; 371 description 372 "This YANG module defines the generic configuration 373 data for key-chain. It is intended that the module 374 will be extended by vendors to define vendor-specific 375 key-chain configuration parameters. 376 "; 378 revision 2015-06-29 { 379 description 380 "Updated version. Added Operation State following 381 draft-openconfig-netmod-opstate-00."; 382 reference 383 "RFC XXXX: A YANG Data Model for key-chain"; 384 } 385 revision 2015-02-24 { 386 description 387 "Initial revision."; 388 reference 389 "RFC XXXX: A YANG Data Model for key-chain"; 390 } 392 typedef key-chain-ref { 393 type leafref { 394 path "/key-chain:key-chains/key-chain:key-chain-list/" 395 + "key-chain:name"; 396 } 397 description 398 "This type is used by data models that need to reference 399 configured key-chains."; 400 } 402 /* feature list */ 403 feature hex-key-string { 404 description 405 "Support hexadecimal key string."; 406 } 408 feature accept-tolerance { 409 description 410 "To specify the tolerance or acceptance limit."; 411 } 413 feature independent-send-accept-lifetime { 414 description 415 "Support for independent send and accept key lifetimes."; 416 } 418 feature crypto-hmac-sha-1-12 { 419 description 420 "Support for TCP HMAC-SHA-1 12 byte digest hack."; 421 } 423 feature aes-cmac-prf-128 { 424 description 425 "Support for AES Cipher based Message Authentication Code 426 Pseudo Random Function."; 427 } 429 feature aes-key-wrap { 430 description 431 "Support for Advanced Encryption Standard (AES) Key Wrap."; 432 } 434 /* groupings */ 435 grouping lifetime { 436 description 437 "Key lifetime specification."; 438 choice lifetime { 439 default always; 440 description 441 "Options for specifying key accept or send lifetimes"; 442 case always { 443 leaf always { 444 type empty; 445 description 446 "Indicates key lifetime is always valid."; 447 } 448 } 449 case start-end-time { 450 leaf start-date-time { 451 type yang:date-and-time; 452 description "Start time."; 453 } 454 choice end-time { 455 default infinite; 456 description 457 "End-time setting."; 458 case infinite { 459 leaf no-end-time { 460 type empty; 461 description 462 "Indicates key lifetime end-time in infinite."; 463 } 464 } 465 case duration { 466 leaf duration { 467 type uint32 { 468 range "1..2147483646"; 469 } 470 units seconds; 471 description "Key lifetime duration, in seconds"; 472 } 473 } 474 case end-date-time { 475 leaf end-date-time { 476 type yang:date-and-time; 477 description "End time."; 478 } 480 } 481 } 482 } 483 } 484 } 486 grouping crypto-algorithm-types { 487 description "Cryptographic algorithm types."; 488 choice algorithm { 489 description 490 "Options for cryptographic algorithm specification."; 491 case hmac-sha-1-12 { 492 if-feature crypto-hmac-sha-1-12; 493 leaf hmac-sha1-12 { 494 type empty; 495 description "The HMAC-SHA1-12 algorithm."; 496 } 497 } 498 case aes-cmac-prf-128 { 499 if-feature aes-cmac-prf-128; 500 leaf aes-cmac-prf-128 { 501 type empty; 502 description "The AES-CMAC-PRF-128 algorithm - required 503 by RFC 5926 for TCP-AO key derivation 504 functions."; 505 } 506 } 507 case md5 { 508 leaf md5 { 509 type empty; 510 description "The MD5 algorithm."; 511 } 512 } 513 case sha-1 { 514 leaf sha-1 { 515 type empty; 516 description "The SHA-1 algorithm."; 517 } 518 } 519 case hmac-sha-1 { 520 leaf hmac-sha-1 { 521 type empty; 522 description "HMAC-SHA-1 authentication algorithm."; 523 } 524 } 525 case hmac-sha-256 { 526 leaf hmac-sha-256 { 527 type empty; 528 description "HMAC-SHA-256 authentication algorithm."; 529 } 530 } 531 case hmac-sha-384 { 532 leaf hmac-sha-384 { 533 type empty; 534 description "HMAC-SHA-384 authentication algorithm."; 535 } 536 } 537 case hmac-sha-512 { 538 leaf hmac-sha-512 { 539 type empty; 540 description "HMAC-SHA-512 authentication algorithm."; 541 } 542 } 543 } 544 } 546 grouping key-chain { 547 description 548 "key-chain specification grouping."; 549 leaf name { 550 type string; 551 description "Name of the key-chain."; 552 } 554 leaf name-state { 555 type string; 556 config false; 557 description "Configured name of the key-chain."; 558 } 560 container accept-tolerance { 561 if-feature accept-tolerance; 562 description 563 "Tolerance for key lifetime acceptance (seconds)."; 564 leaf duration { 565 type uint32; 566 units seconds; 567 default "0"; 568 description 569 "Tolerance range, in seconds."; 570 } 571 } 573 container accept-tolerance-state { 574 config false; 575 description 576 "Configured tolerance for key lifetime 577 acceptance (seconds)."; 578 leaf duration { 579 type uint32; 580 description 581 "Configured tolerance range, in seconds."; 582 } 583 } 585 list key-chain-entry { 586 key "key-id"; 587 description "One key."; 588 leaf key-id { 589 type uint64; 590 description "Key id."; 591 } 592 leaf key-id-state { 593 type uint64; 594 config false; 595 description "Configured key id."; 596 } 597 container key-string { 598 description "The key string."; 599 choice key-string-style { 600 description 601 "Key string styles"; 602 case keystring { 603 leaf keystring { 604 type string; 605 description "Key string in ASCII format."; 606 } 607 } 608 case hexadecimal { 609 if-feature hex-key-string; 610 leaf hexadecimal-string { 611 type yang:hex-string; 612 description 613 "Key in hexadecimal string format."; 614 } 615 } 616 } 617 } 618 container lifetime { 619 description "Specify a key's lifetime."; 620 choice lifetime { 621 description 622 "Options for specification of send and accept 623 lifetimes."; 625 case send-and-accept-lifetime { 626 description 627 "Send and accept key have the same lifetime."; 628 container send-accept-lifetime { 629 uses lifetime; 630 description 631 "Single lifetime specification for both send and 632 accept lifetimes."; 633 } 634 } 635 case independent-send-accept-lifetime { 636 if-feature independent-send-accept-lifetime; 637 description 638 "Independent send and accept key lifetimes."; 639 container send-lifetime { 640 uses lifetime; 641 description 642 "Separate lifetime specification for send 643 lifetime."; 644 } 645 container accept-lifetime { 646 uses lifetime; 647 description 648 "Separate lifetime specification for accept 649 lifetime."; 650 } 651 } 652 } 653 } 654 container lifetime-state { 655 config false; 656 description "Configured key's lifetime."; 657 container send-lifetime { 658 uses lifetime; 659 description 660 "Configured send-lifetime."; 661 } 662 leaf send-valid { 663 type boolean; 664 description 665 "Status of send-lifetime."; 666 } 667 container accept-lifetime { 668 uses lifetime; 669 description 670 "Configured accept-lifetime."; 671 } 672 leaf accept-valid { 673 type boolean; 674 description 675 "Status of accept-lifetime."; 676 } 677 } 678 container crypto-algorithm { 679 uses crypto-algorithm-types; 680 description "Cryptographic algorithm associated with key."; 681 } 682 container crypto-algorithm-state { 683 config false; 684 uses crypto-algorithm-types; 685 description "Configured cryptographic algorithm."; 686 } 687 } 688 } 690 container key-chains { 691 list key-chain-list { 692 key "name"; 693 description 694 "List of key-chains."; 695 uses key-chain; 696 } 697 container aes-key-wrap { 698 if-feature aes-key-wrap; 699 leaf enable { 700 type boolean; 701 default false; 702 description 703 "Enable AES Key Wrap encryption."; 704 } 705 description 706 "AES Key Wrap password encryption."; 707 } 708 container aes-key-wrap-state { 709 if-feature aes-key-wrap; 710 config false; 711 leaf enable { 712 type boolean; 713 description "AES Key Wrap state."; 714 } 715 description "Status of AES Key Wrap."; 716 } 717 description "All configured key-chains for the device."; 718 } 719 } 720 722 5. Relationship to other Work 724 6. Security Considerations 726 This document enables the automated distribution of industry standard 727 key chains using the NETCONF [NETCONF] protocol. As such, the 728 security considerations for the NETCONF protocol are applicable. 729 Given that the key chains themselves are sensitive data, it is 730 RECOMMENDED that the NETCONF communication channel be encrypted. One 731 way to do accomplish this would be to invoke and run NETCONF over SSH 732 as described in [NETCONF-SSH]. 734 When configured, the key-strings can be encrypted using the AES Key 735 Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) is 736 not included in the YANG model and must be set or derived independent 737 of key-chain configuration. 739 The key strings are not included in the operational state. This is a 740 practice carried over from SNMP MIB modules and is an area for 741 further discussion. 743 7. IANA Considerations 745 This document registers a URI in the IETF XML registry 746 [XML-REGISTRY]. Following the format in RFC 3688, the following 747 registration is requested to be made: 749 URI: urn:ietf:params:xml:ns:yang:ietf-key-chain 751 Registrant Contact: The IESG. 753 XML: N/A, the requested URI is an XML namespace. 755 This document registers a YANG module in the YANG Module Names 756 registry [YANG]. 758 name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-key- 759 chain prefix: ietf-key-chain reference: RFC XXXX 761 8. References 763 8.1. Normative References 765 [NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 766 Bierman, "Network Configuration Protocol (NETCONF)", RFC 767 6241, June 2011. 769 [NETCONF-SSH] 770 Wasserman, M., "Using NETCONF Protocol over Secure Shell 771 (SSH)", RFC 6242, June 2011. 773 [RFC-KEYWORDS] 774 Bradner, S., "Key words for use in RFC's to Indicate 775 Requirement Levels", BCP 14, RFC 2119, March 1997. 777 [XML-REGISTRY] 778 Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 779 January 2004. 781 [YANG] Bjorklund, M., "YANG - A Data Modeling Language for the 782 Network Configuration Protocol (NETCONF)", RFC 6020, 783 October 2010. 785 8.2. Informative References 787 [AES-KEY-WRAP] 788 Housley, R. and M. Dworkin, "Advanced Encryption Standard 789 (AES) Key Wrap with Padding Algorithm", RFC 5649, August 790 2009. 792 [CRYPTO-KEYTABLE] 793 Housley, R., Polk, T., Hartman, S., and D. Zhang, 794 "Table of Cryptographic Keys", RFC 7210, April 2014. 796 [IAB-REPORT] 797 Andersson, L., Davies, E., and L. Zhang, "Report from the 798 IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 799 4948, August 2007. 801 [NTP-PROTO] 802 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 803 Time Protocol Version 4: Protocol and Algorithms 804 Specification", RFC 5905, June 2010. 806 [OSPFV3-AUTH] 807 Bhatia, M., Manral, V., and A. Lindem, "Supporting 808 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 810 [TCP-AO-ALGORITHMS] 811 Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 812 for the TCP Authentication Option (TCP-AO)", draft-chen- 813 rtg-key-table-yang-00.txt (work in progress), June 2010. 815 [YANG-CRYPTO-KEYTABLE] 816 Chen, I., "YANG Data Model for RFC 7210 Key Table", draft- 817 chen-rtg-key-table-yang-00.txt (work in progress), March 818 2015. 820 Appendix A. Acknowledgments 822 The RFC text was produced using Marshall Rose's xml2rfc tool. 824 Thanks to Brian Weis for fruitful discussions on security 825 requirements. 827 Authors' Addresses 829 Acee Lindem (editor) 830 Cisco Systems 831 301 Midenhall Way 832 Cary, NC 27513 833 USA 835 Email: acee@cisco.com 837 Yingzhen Qu 838 Cisco Systems 839 170 West Tasman Drive 840 San Jose, CA 95134 841 USA 843 Email: yiqu@cisco.com 845 Derek Yeung 846 Cisco Systems 847 170 West Tasman Drive 848 San Jose, CA 95134 849 USA 851 Email: myeung@cisco.com 853 Ing-Wher Chen 854 Ericsson 856 Email: ing-wher.chen@ericsson.com 857 Jeffrey Zhang 858 Juniper Networks 859 10 Technology Park Drive 860 Westford, MA 01886 861 USA 863 Email: zzhang@juniper.net 865 Yi Yang 866 Cisco Systems 867 7025 Kit Creek Road 868 Research Triangle Park, NC 27709 869 USA 871 Email: yiya@cisco.com