idnits 2.17.1 draft-ietf-rtgwg-yang-key-chain-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 : ---------------------------------------------------------------------------- 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 (December 1, 2015) is 3069 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) -- Unexpected draft version: The latest known version of draft-chen-rtg-key-table-yang is -00, but you're referring to -02. 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: June 3, 2016 Cisco Systems 6 I. Chen 7 Ericsson 8 J. Zhang 9 Juniper Networks 10 Y. Yang 11 Cisco Systems 12 December 1, 2015 14 Key Chain YANG Data Model 15 draft-ietf-rtgwg-yang-key-chain-00.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 June 3, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 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-10-15.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 "IETF RTG (Routing) Working Group"; 365 contact 366 "Acee Lindem - acee@cisco.com"; 368 description 369 "This YANG module defines the generic configuration 370 data for key-chain. It is intended that the module 371 will be extended by vendors to define vendor-specific 372 key-chain configuration parameters. 374 Copyright (c) 2015 IETF Trust and the persons identified as 375 authors of the code. All rights reserved. 377 Redistribution and use in source and binary forms, with or 378 without modification, is permitted pursuant to, and subject 379 to the license terms contained in, the Simplified BSD License 380 set forth in Section 4.c of the IETF Trust's Legal Provisions 381 Relating to IETF Documents 382 (http://trustee.ietf.org/license-info). 383 This version of this YANG module is part of RFC XXXX; see 384 the RFC itself for full legal notices."; 386 revision 2015-10-15 { 387 description 388 "Updated version, organization, and copyright. 389 Added aes-cmac-prf-128 and aes-key-wrap features."; 390 reference 391 "RFC XXXX: A YANG Data Model for key-chain"; 392 } 393 revision 2015-06-29 { 394 description 395 "Updated version. Added Operation State following 396 draft-openconfig-netmod-opstate-00."; 397 reference 398 "RFC XXXX: A YANG Data Model for key-chain"; 399 } 400 revision 2015-02-24 { 401 description 402 "Initial revision."; 403 reference 404 "RFC XXXX: A YANG Data Model for key-chain"; 405 } 407 typedef key-chain-ref { 408 type leafref { 409 path "/key-chain:key-chains/key-chain:key-chain-list/" 410 + "key-chain:name"; 411 } 412 description 413 "This type is used by data models that need to reference 414 configured key-chains."; 415 } 417 /* feature list */ 418 feature hex-key-string { 419 description 420 "Support hexadecimal key string."; 421 } 423 feature accept-tolerance { 424 description 425 "To specify the tolerance or acceptance limit."; 426 } 428 feature independent-send-accept-lifetime { 429 description 430 "Support for independent send and accept key lifetimes."; 432 } 434 feature crypto-hmac-sha-1-12 { 435 description 436 "Support for TCP HMAC-SHA-1 12 byte digest hack."; 437 } 439 feature aes-cmac-prf-128 { 440 description 441 "Support for AES Cipher based Message Authentication Code 442 Pseudo Random Function."; 443 } 445 feature aes-key-wrap { 446 description 447 "Support for Advanced Encryption Standard (AES) Key Wrap."; 448 } 450 /* groupings */ 451 grouping lifetime { 452 description 453 "Key lifetime specification."; 454 choice lifetime { 455 default always; 456 description 457 "Options for specifying key accept or send lifetimes"; 458 case always { 459 leaf always { 460 type empty; 461 description 462 "Indicates key lifetime is always valid."; 463 } 464 } 465 case start-end-time { 466 leaf start-date-time { 467 type yang:date-and-time; 468 description "Start time."; 469 } 470 choice end-time { 471 default infinite; 472 description 473 "End-time setting."; 474 case infinite { 475 leaf no-end-time { 476 type empty; 477 description 478 "Indicates key lifetime end-time in infinite."; 479 } 481 } 482 case duration { 483 leaf duration { 484 type uint32 { 485 range "1..2147483646"; 486 } 487 units seconds; 488 description "Key lifetime duration, in seconds"; 489 } 490 } 491 case end-date-time { 492 leaf end-date-time { 493 type yang:date-and-time; 494 description "End time."; 495 } 496 } 497 } 498 } 499 } 500 } 502 grouping crypto-algorithm-types { 503 description "Cryptographic algorithm types."; 504 choice algorithm { 505 description 506 "Options for cryptographic algorithm specification."; 507 case hmac-sha-1-12 { 508 if-feature crypto-hmac-sha-1-12; 509 leaf hmac-sha1-12 { 510 type empty; 511 description "The HMAC-SHA1-12 algorithm."; 512 } 513 } 514 case aes-cmac-prf-128 { 515 if-feature aes-cmac-prf-128; 516 leaf aes-cmac-prf-128 { 517 type empty; 518 description "The AES-CMAC-PRF-128 algorithm - required 519 by RFC 5926 for TCP-AO key derivation 520 functions."; 521 } 522 } 523 case md5 { 524 leaf md5 { 525 type empty; 526 description "The MD5 algorithm."; 527 } 528 } 529 case sha-1 { 530 leaf sha-1 { 531 type empty; 532 description "The SHA-1 algorithm."; 533 } 534 } 535 case hmac-sha-1 { 536 leaf hmac-sha-1 { 537 type empty; 538 description "HMAC-SHA-1 authentication algorithm."; 539 } 540 } 541 case hmac-sha-256 { 542 leaf hmac-sha-256 { 543 type empty; 544 description "HMAC-SHA-256 authentication algorithm."; 545 } 546 } 547 case hmac-sha-384 { 548 leaf hmac-sha-384 { 549 type empty; 550 description "HMAC-SHA-384 authentication algorithm."; 551 } 552 } 553 case hmac-sha-512 { 554 leaf hmac-sha-512 { 555 type empty; 556 description "HMAC-SHA-512 authentication algorithm."; 557 } 558 } 559 } 560 } 562 grouping key-chain { 563 description 564 "key-chain specification grouping."; 565 leaf name { 566 type string; 567 description "Name of the key-chain."; 568 } 570 leaf name-state { 571 type string; 572 config false; 573 description "Configured name of the key-chain."; 574 } 576 container accept-tolerance { 577 if-feature accept-tolerance; 578 description 579 "Tolerance for key lifetime acceptance (seconds)."; 580 leaf duration { 581 type uint32; 582 units seconds; 583 default "0"; 584 description 585 "Tolerance range, in seconds."; 586 } 587 } 589 container accept-tolerance-state { 590 config false; 591 description 592 "Configured tolerance for key lifetime 593 acceptance (seconds)."; 594 leaf duration { 595 type uint32; 596 description 597 "Configured tolerance range, in seconds."; 598 } 599 } 601 list key-chain-entry { 602 key "key-id"; 603 description "One key."; 604 leaf key-id { 605 type uint64; 606 description "Key ID."; 607 } 608 leaf key-id-state { 609 type uint64; 610 config false; 611 description "Configured Key ID."; 612 } 613 container key-string { 614 description "The key string."; 615 choice key-string-style { 616 description 617 "Key string styles"; 618 case keystring { 619 leaf keystring { 620 type string; 621 description "Key string in ASCII format."; 622 } 623 } 624 case hexadecimal { 625 if-feature hex-key-string; 626 leaf hexadecimal-string { 627 type yang:hex-string; 628 description 629 "Key in hexadecimal string format."; 630 } 631 } 632 } 633 } 634 container lifetime { 635 description "Specify a key's lifetime."; 636 choice lifetime { 637 description 638 "Options for specification of send and accept 639 lifetimes."; 640 case send-and-accept-lifetime { 641 description 642 "Send and accept key have the same lifetime."; 643 container send-accept-lifetime { 644 uses lifetime; 645 description 646 "Single lifetime specification for both send and 647 accept lifetimes."; 648 } 649 } 650 case independent-send-accept-lifetime { 651 if-feature independent-send-accept-lifetime; 652 description 653 "Independent send and accept key lifetimes."; 654 container send-lifetime { 655 uses lifetime; 656 description 657 "Separate lifetime specification for send 658 lifetime."; 659 } 660 container accept-lifetime { 661 uses lifetime; 662 description 663 "Separate lifetime specification for accept 664 lifetime."; 665 } 666 } 667 } 668 } 669 container lifetime-state { 670 config false; 671 description "Configured key's lifetime."; 672 container send-lifetime { 673 uses lifetime; 674 description 675 "Configured send-lifetime."; 676 } 677 leaf send-valid { 678 type boolean; 679 description 680 "Status of send-lifetime."; 681 } 682 container accept-lifetime { 683 uses lifetime; 684 description 685 "Configured accept-lifetime."; 686 } 687 leaf accept-valid { 688 type boolean; 689 description 690 "Status of accept-lifetime."; 691 } 692 } 693 container crypto-algorithm { 694 uses crypto-algorithm-types; 695 description "Cryptographic algorithm associated with key."; 696 } 697 container crypto-algorithm-state { 698 config false; 699 uses crypto-algorithm-types; 700 description "Configured cryptographic algorithm."; 701 } 702 } 703 } 705 container key-chains { 706 list key-chain-list { 707 key "name"; 708 description 709 "List of key-chains."; 710 uses key-chain; 711 } 712 container aes-key-wrap { 713 if-feature aes-key-wrap; 714 leaf enable { 715 type boolean; 716 default false; 717 description 718 "Enable AES Key Wrap encryption."; 719 } 720 description 721 "AES Key Wrap password encryption."; 722 } 723 container aes-key-wrap-state { 724 if-feature aes-key-wrap; 725 config false; 726 leaf enable { 727 type boolean; 728 description "AES Key Wrap state."; 729 } 730 description "Status of AES Key Wrap."; 731 } 732 description "All configured key-chains for the device."; 733 } 734 } 735 737 5. Relationship to other Work 739 6. Security Considerations 741 This document enables the automated distribution of industry standard 742 key chains using the NETCONF [NETCONF] protocol. As such, the 743 security considerations for the NETCONF protocol are applicable. 744 Given that the key chains themselves are sensitive data, it is 745 RECOMMENDED that the NETCONF communication channel be encrypted. One 746 way to do accomplish this would be to invoke and run NETCONF over SSH 747 as described in [NETCONF-SSH]. 749 When configured, the key-strings can be encrypted using the AES Key 750 Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) is 751 not included in the YANG model and must be set or derived independent 752 of key-chain configuration. 754 The key strings are not included in the operational state. This is a 755 practice carried over from SNMP MIB modules and is an area for 756 further discussion. 758 7. IANA Considerations 760 This document registers a URI in the IETF XML registry 761 [XML-REGISTRY]. Following the format in RFC 3688, the following 762 registration is requested to be made: 764 URI: urn:ietf:params:xml:ns:yang:ietf-key-chain 766 Registrant Contact: The IESG. 768 XML: N/A, the requested URI is an XML namespace. 770 This document registers a YANG module in the YANG Module Names 771 registry [YANG]. 773 name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-key- 774 chain prefix: ietf-key-chain reference: RFC XXXX 776 8. References 778 8.1. Normative References 780 [NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 781 Bierman, "Network Configuration Protocol (NETCONF)", RFC 782 6241, June 2011. 784 [NETCONF-SSH] 785 Wasserman, M., "Using NETCONF Protocol over Secure Shell 786 (SSH)", RFC 6242, June 2011. 788 [RFC-KEYWORDS] 789 Bradner, S., "Key words for use in RFC's to Indicate 790 Requirement Levels", BCP 14, RFC 2119, March 1997. 792 [XML-REGISTRY] 793 Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 794 January 2004. 796 [YANG] Bjorklund, M., "YANG - A Data Modeling Language for the 797 Network Configuration Protocol (NETCONF)", RFC 6020, 798 October 2010. 800 8.2. Informative References 802 [AES-KEY-WRAP] 803 Housley, R. and M. Dworkin, "Advanced Encryption Standard 804 (AES) Key Wrap with Padding Algorithm", RFC 5649, August 805 2009. 807 [CRYPTO-KEYTABLE] 808 Housley, R., Polk, T., Hartman, S., and D. Zhang, 809 "Table of Cryptographic Keys", RFC 7210, April 2014. 811 [IAB-REPORT] 812 Andersson, L., Davies, E., and L. Zhang, "Report from the 813 IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 814 4948, August 2007. 816 [NTP-PROTO] 817 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 818 Time Protocol Version 4: Protocol and Algorithms 819 Specification", RFC 5905, June 2010. 821 [OSPFV3-AUTH] 822 Bhatia, M., Manral, V., and A. Lindem, "Supporting 823 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 825 [TCP-AO-ALGORITHMS] 826 Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 827 for the TCP Authentication Option (TCP-AO)", RFC 5926, 828 June 2010. 830 [YANG-CRYPTO-KEYTABLE] 831 Chen, I., "YANG Data Model for RFC 7210 Key Table", draft- 832 chen-rtg-key-table-yang-02.txt (work in progress), 833 November 2015. 835 Appendix A. Acknowledgments 837 The RFC text was produced using Marshall Rose's xml2rfc tool. 839 Thanks to Brian Weis for fruitful discussions on security 840 requirements. 842 Authors' Addresses 844 Acee Lindem (editor) 845 Cisco Systems 846 301 Midenhall Way 847 Cary, NC 27513 848 USA 850 Email: acee@cisco.com 852 Yingzhen Qu 853 Cisco Systems 854 170 West Tasman Drive 855 San Jose, CA 95134 856 USA 858 Email: yiqu@cisco.com 859 Derek Yeung 860 Cisco Systems 861 170 West Tasman Drive 862 San Jose, CA 95134 863 USA 865 Email: myeung@cisco.com 867 Ing-Wher Chen 868 Ericsson 870 Email: ing-wher.chen@ericsson.com 872 Jeffrey Zhang 873 Juniper Networks 874 10 Technology Park Drive 875 Westford, MA 01886 876 USA 878 Email: zzhang@juniper.net 880 Yi Yang 881 Cisco Systems 882 7025 Kit Creek Road 883 Research Triangle Park, NC 27709 884 USA 886 Email: yiya@cisco.com