idnits 2.17.00 (12 Aug 2021) /tmp/idnits20648/draft-ietf-rtgwg-yang-key-chain-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (February 12, 2016) is 2290 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 (~~), 2 warnings (==), 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: August 15, 2016 Cisco Systems 6 I. Chen 7 Ericsson 8 J. Zhang 9 Juniper Networks 10 Y. Yang 11 Cisco Systems 12 February 12, 2016 14 Key Chain YANG Data Model 15 draft-ietf-rtgwg-yang-key-chain-01.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 August 15, 2016. 47 Copyright Notice 49 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . 17 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 78 8.2. Informative References . . . . . . . . . . . . . . . . . 18 79 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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? yang:date-and-time 270 | | +--rw (end-time)? 271 | | +--:(infinite) 272 | | | +--rw no-end-time? empty 273 | | +--:(duration) 274 | | | +--rw duration? uint32 275 | | +--:(end-date-time) 276 | | +--rw end-date-time? 277 | | yang:date-and-time 278 | +--ro lifetime-state 279 | | +--ro send-lifetime 280 | | | +--ro (lifetime)? 281 | | | +--:(always) 282 | | | | +--ro always? empty 283 | | | +--:(start-end-time) 284 | | | +--ro start-date-time? yang:date-and-time 285 | | | +--ro (end-time)? 286 | | | +--:(infinite) 287 | | | | +--ro no-end-time? empty 288 | | | +--:(duration) 289 | | | | +--ro duration? uint32 290 | | | +--:(end-date-time) 291 | | | +--ro end-date-time? 292 | | | yang:date-and-time 293 | | +--ro send-valid? boolean 294 | | +--ro accept-lifetime 295 | | | +--ro (lifetime)? 296 | | | +--:(always) 297 | | | | +--ro always? empty 298 | | | +--:(start-end-time) 299 | | | +--ro start-date-time? yang:date-and-time 300 | | | +--ro (end-time)? 301 | | | +--:(infinite) 302 | | | | +--ro no-end-time? empty 303 | | | +--:(duration) 304 | | | | +--ro duration? uint32 305 | | | +--:(end-date-time) 306 | | | +--ro end-date-time? 307 | | | yang:date-and-time 308 | | +--ro accept-valid? boolean 309 | +--rw crypto-algorithm 310 | | +--rw (algorithm)? 311 | | +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}? 312 | | | +--rw hmac-sha1-12? empty 313 | | +--:(aes-cmac-prf-128) {aes-cmac-prf-128}? 314 | | | +--rw aes-cmac-prf-128? empty 315 | | +--:(md5) 316 | | | +--rw md5? empty 317 | | +--:(sha-1) 318 | | | +--rw sha-1? empty 319 | | +--:(hmac-sha-1) 320 | | | +--rw hmac-sha-1? empty 321 | | +--:(hmac-sha-256) 322 | | | +--rw hmac-sha-256? empty 323 | | +--:(hmac-sha-384) 324 | | | +--rw hmac-sha-384? empty 325 | | +--:(hmac-sha-512) 326 | | | +--rw hmac-sha-512? empty 327 | | +--:(clear-text) {clear-text}? 328 | | +--rw clear-text? empty 329 | +--ro crypto-algorithm-state 330 | +--ro (algorithm)? 331 | +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}? 332 | | +--ro hmac-sha1-12? empty 333 | +--:(aes-cmac-prf-128) {aes-cmac-prf-128}? 334 | | +--ro aes-cmac-prf-128? empty 335 | +--:(md5) 336 | | +--ro md5? empty 337 | +--:(sha-1) 338 | | +--ro sha-1? empty 339 | +--:(hmac-sha-1) 340 | | +--ro hmac-sha-1? empty 341 | +--:(hmac-sha-256) 342 | | +--ro hmac-sha-256? empty 343 | +--:(hmac-sha-384) 344 | | +--ro hmac-sha-384? empty 345 | +--:(hmac-sha-512) 346 | | +--ro hmac-sha-512? empty 347 | +--:(clear-text) {clear-text}? 348 | +--ro clear-text? empty 349 +--rw aes-key-wrap {aes-key-wrap}? 350 | +--rw enable? boolean 351 +--ro aes-key-wrap-state {aes-key-wrap}? 352 +--ro enable? boolean 354 4. Key Chain YANG Model 356 file "ietf-key-chain@2016-02-16.yang" 357 module ietf-key-chain { 358 namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain"; 359 // replace with IANA namespace when assigned 360 prefix "key-chain"; 362 import ietf-yang-types { 363 prefix "yang"; 364 } 366 organization 367 "IETF RTG (Routing) Working Group"; 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. 377 Copyright (c) 2015 IETF Trust and the persons identified as 378 authors of the code. All rights reserved. 380 Redistribution and use in source and binary forms, with or 381 without modification, is permitted pursuant to, and subject 382 to the license terms contained in, the Simplified BSD License 383 set forth in Section 4.c of the IETF Trust's Legal Provisions 384 Relating to IETF Documents 385 (http://trustee.ietf.org/license-info). 386 This version of this YANG module is part of RFC XXXX; see 387 the RFC itself for full legal notices."; 389 revision 2016-02-16 { 390 description 391 "Updated version. Added clear-text algorithm as a 392 feature."; 393 reference 394 "RFC XXXX: A YANG Data Model for key-chain"; 395 } 396 revision 2015-10-15 { 397 description 398 "Updated version, organization, and copyright. 399 Added aes-cmac-prf-128 and aes-key-wrap features."; 400 reference 401 "RFC XXXX: A YANG Data Model for key-chain"; 402 } 403 revision 2015-06-29 { 404 description 405 "Updated version. Added Operation State following 406 draft-openconfig-netmod-opstate-00."; 407 reference 408 "RFC XXXX: A YANG Data Model for key-chain"; 409 } 410 revision 2015-02-24 { 411 description 412 "Initial revision."; 413 reference 414 "RFC XXXX: A YANG Data Model for key-chain"; 415 } 417 typedef key-chain-ref { 418 type leafref { 419 path "/key-chain:key-chains/key-chain:key-chain-list/" 420 + "key-chain:name"; 421 } 422 description 423 "This type is used by data models that need to reference 424 configured key-chains."; 425 } 427 /* feature list */ 428 feature hex-key-string { 429 description 430 "Support hexadecimal key string."; 432 } 434 feature accept-tolerance { 435 description 436 "To specify the tolerance or acceptance limit."; 437 } 439 feature independent-send-accept-lifetime { 440 description 441 "Support for independent send and accept key lifetimes."; 442 } 444 feature crypto-hmac-sha-1-12 { 445 description 446 "Support for TCP HMAC-SHA-1 12 byte digest hack."; 447 } 449 feature clear-text { 450 description 451 "Support for clear-text algorithm. Usage is NOT RECOMMENDED."; 452 } 454 feature aes-cmac-prf-128 { 455 description 456 "Support for AES Cipher based Message Authentication Code 457 Pseudo Random Function."; 458 } 460 feature aes-key-wrap { 461 description 462 "Support for Advanced Encryption Standard (AES) Key Wrap."; 463 } 465 /* groupings */ 466 grouping lifetime { 467 description 468 "Key lifetime specification."; 469 choice lifetime { 470 default always; 471 description 472 "Options for specifying key accept or send lifetimes"; 473 case always { 474 leaf always { 475 type empty; 476 description 477 "Indicates key lifetime is always valid."; 478 } 479 } 480 case start-end-time { 481 leaf start-date-time { 482 type yang:date-and-time; 483 description "Start time."; 484 } 485 choice end-time { 486 default infinite; 487 description 488 "End-time setting."; 489 case infinite { 490 leaf no-end-time { 491 type empty; 492 description 493 "Indicates key lifetime end-time in infinite."; 494 } 495 } 496 case duration { 497 leaf duration { 498 type uint32 { 499 range "1..2147483646"; 500 } 501 units seconds; 502 description "Key lifetime duration, in seconds"; 503 } 504 } 505 case end-date-time { 506 leaf end-date-time { 507 type yang:date-and-time; 508 description "End time."; 509 } 510 } 511 } 512 } 513 } 514 } 516 grouping crypto-algorithm-types { 517 description "Cryptographic algorithm types."; 518 choice algorithm { 519 description 520 "Options for cryptographic algorithm specification."; 521 case hmac-sha-1-12 { 522 if-feature crypto-hmac-sha-1-12; 523 leaf hmac-sha1-12 { 524 type empty; 525 description "The HMAC-SHA1-12 algorithm."; 526 } 527 } 528 case aes-cmac-prf-128 { 529 if-feature aes-cmac-prf-128; 530 leaf aes-cmac-prf-128 { 531 type empty; 532 description "The AES-CMAC-PRF-128 algorithm - required 533 by RFC 5926 for TCP-AO key derivation 534 functions."; 535 } 536 } 537 case md5 { 538 leaf md5 { 539 type empty; 540 description "The MD5 algorithm."; 541 } 542 } 543 case sha-1 { 544 leaf sha-1 { 545 type empty; 546 description "The SHA-1 algorithm."; 547 } 548 } 549 case hmac-sha-1 { 550 leaf hmac-sha-1 { 551 type empty; 552 description "HMAC-SHA-1 authentication algorithm."; 553 } 554 } 555 case hmac-sha-256 { 556 leaf hmac-sha-256 { 557 type empty; 558 description "HMAC-SHA-256 authentication algorithm."; 559 } 560 } 561 case hmac-sha-384 { 562 leaf hmac-sha-384 { 563 type empty; 564 description "HMAC-SHA-384 authentication algorithm."; 565 } 566 } 567 case hmac-sha-512 { 568 leaf hmac-sha-512 { 569 type empty; 570 description "HMAC-SHA-512 authentication algorithm."; 571 } 572 } 573 case clear-text { 574 if-feature clear-text; 575 leaf clear-text { 576 type empty; 577 description "Clear text."; 578 } 579 } 580 } 581 } 583 grouping key-chain { 584 description 585 "key-chain specification grouping."; 586 leaf name { 587 type string; 588 description "Name of the key-chain."; 589 } 591 leaf name-state { 592 type string; 593 config false; 594 description "Configured name of the key-chain."; 595 } 597 container accept-tolerance { 598 if-feature accept-tolerance; 599 description 600 "Tolerance for key lifetime acceptance (seconds)."; 601 leaf duration { 602 type uint32; 603 units seconds; 604 default "0"; 605 description 606 "Tolerance range, in seconds."; 607 } 608 } 610 container accept-tolerance-state { 611 config false; 612 description 613 "Configured tolerance for key lifetime 614 acceptance (seconds)."; 615 leaf duration { 616 type uint32; 617 description 618 "Configured tolerance range, in seconds."; 619 } 620 } 622 list key-chain-entry { 623 key "key-id"; 624 description "One key."; 625 leaf key-id { 626 type uint64; 627 description "Key ID."; 628 } 629 leaf key-id-state { 630 type uint64; 631 config false; 632 description "Configured Key ID."; 633 } 634 container key-string { 635 description "The key string."; 636 choice key-string-style { 637 description 638 "Key string styles"; 639 case keystring { 640 leaf keystring { 641 type string; 642 description "Key string in ASCII format."; 643 } 644 } 645 case hexadecimal { 646 if-feature hex-key-string; 647 leaf hexadecimal-string { 648 type yang:hex-string; 649 description 650 "Key in hexadecimal string format."; 651 } 652 } 653 } 654 } 655 container lifetime { 656 description "Specify a key's lifetime."; 657 choice lifetime { 658 description 659 "Options for specification of send and accept 660 lifetimes."; 661 case send-and-accept-lifetime { 662 description 663 "Send and accept key have the same lifetime."; 664 container send-accept-lifetime { 665 uses lifetime; 666 description 667 "Single lifetime specification for both send and 668 accept lifetimes."; 669 } 670 } 671 case independent-send-accept-lifetime { 672 if-feature independent-send-accept-lifetime; 673 description 674 "Independent send and accept key lifetimes."; 675 container send-lifetime { 676 uses lifetime; 677 description 678 "Separate lifetime specification for send 679 lifetime."; 680 } 681 container accept-lifetime { 682 uses lifetime; 683 description 684 "Separate lifetime specification for accept 685 lifetime."; 686 } 687 } 688 } 689 } 690 container lifetime-state { 691 config false; 692 description "Configured key's lifetime."; 693 container send-lifetime { 694 uses lifetime; 695 description 696 "Configured send-lifetime."; 697 } 698 leaf send-valid { 699 type boolean; 700 description 701 "Status of send-lifetime."; 702 } 703 container accept-lifetime { 704 uses lifetime; 705 description 706 "Configured accept-lifetime."; 707 } 708 leaf accept-valid { 709 type boolean; 710 description 711 "Status of accept-lifetime."; 712 } 713 } 714 container crypto-algorithm { 715 uses crypto-algorithm-types; 716 description "Cryptographic algorithm associated with key."; 717 } 718 container crypto-algorithm-state { 719 config false; 720 uses crypto-algorithm-types; 721 description "Configured cryptographic algorithm."; 722 } 723 } 724 } 726 container key-chains { 727 list key-chain-list { 728 key "name"; 729 description 730 "List of key-chains."; 731 uses key-chain; 732 } 733 container aes-key-wrap { 734 if-feature aes-key-wrap; 735 leaf enable { 736 type boolean; 737 default false; 738 description 739 "Enable AES Key Wrap encryption."; 740 } 741 description 742 "AES Key Wrap password encryption."; 743 } 744 container aes-key-wrap-state { 745 if-feature aes-key-wrap; 746 config false; 747 leaf enable { 748 type boolean; 749 description "AES Key Wrap state."; 750 } 751 description "Status of AES Key Wrap."; 752 } 753 description "All configured key-chains for the device."; 754 } 755 } 756 758 5. Relationship to other Work 760 6. Security Considerations 762 This document enables the automated distribution of industry standard 763 key chains using the NETCONF [NETCONF] protocol. As such, the 764 security considerations for the NETCONF protocol are applicable. 765 Given that the key chains themselves are sensitive data, it is 766 RECOMMENDED that the NETCONF communication channel be encrypted. One 767 way to do accomplish this would be to invoke and run NETCONF over SSH 768 as described in [NETCONF-SSH]. 770 When configured, the key-strings can be encrypted using the AES Key 771 Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) is 772 not included in the YANG model and must be set or derived independent 773 of key-chain configuration. 775 The key strings are not included in the operational state. This is a 776 practice carried over from SNMP MIB modules and is an area for 777 further discussion. 779 The clear-text algorithm is included as a YANG feature. Usage is NOT 780 RECOMMENDED except in cases where the application and device have no 781 other alternative (e.g., a legacy network device that must 782 authenticate packets at intervals of 10 milliseconds or less for many 783 peers using Bidirectional Forwarding Detection [BFD]). Keys used 784 with the clear-text algorithm are considered insecure and SHOULD NOT 785 be reused with more secure algorithms. 787 7. IANA Considerations 789 This document registers a URI in the IETF XML registry 790 [XML-REGISTRY]. Following the format in RFC 3688, the following 791 registration is requested to be made: 793 URI: urn:ietf:params:xml:ns:yang:ietf-key-chain 795 Registrant Contact: The IESG. 797 XML: N/A, the requested URI is an XML namespace. 799 This document registers a YANG module in the YANG Module Names 800 registry [YANG]. 802 name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-key- 803 chain prefix: ietf-key-chain reference: RFC XXXX 805 8. References 807 8.1. Normative References 809 [NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 810 Bierman, "Network Configuration Protocol (NETCONF)", RFC 811 6241, June 2011. 813 [NETCONF-SSH] 814 Wasserman, M., "Using NETCONF Protocol over Secure Shell 815 (SSH)", RFC 6242, June 2011. 817 [RFC-KEYWORDS] 818 Bradner, S., "Key words for use in RFC's to Indicate 819 Requirement Levels", BCP 14, RFC 2119, March 1997. 821 [XML-REGISTRY] 822 Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 823 January 2004. 825 [YANG] Bjorklund, M., "YANG - A Data Modeling Language for the 826 Network Configuration Protocol (NETCONF)", RFC 6020, 827 October 2010. 829 8.2. Informative References 831 [AES-KEY-WRAP] 832 Housley, R. and M. Dworkin, "Advanced Encryption Standard 833 (AES) Key Wrap with Padding Algorithm", RFC 5649, August 834 2009. 836 [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 837 (BFD)", RFC 5880, June 2010. 839 [CRYPTO-KEYTABLE] 840 Housley, R., Polk, T., Hartman, S., and D. Zhang, 841 "Table of Cryptographic Keys", RFC 7210, April 2014. 843 [IAB-REPORT] 844 Andersson, L., Davies, E., and L. Zhang, "Report from the 845 IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 846 4948, August 2007. 848 [NTP-PROTO] 849 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 850 Time Protocol Version 4: Protocol and Algorithms 851 Specification", RFC 5905, June 2010. 853 [OSPFV3-AUTH] 854 Bhatia, M., Manral, V., and A. Lindem, "Supporting 855 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 857 [TCP-AO-ALGORITHMS] 858 Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 859 for the TCP Authentication Option (TCP-AO)", RFC 5926, 860 June 2010. 862 [YANG-CRYPTO-KEYTABLE] 863 Chen, I., "YANG Data Model for RFC 7210 Key Table", draft- 864 chen-rtg-key-table-yang-02.txt (work in progress), 865 November 2015. 867 Appendix A. Acknowledgments 869 The RFC text was produced using Marshall Rose's xml2rfc tool. 871 Thanks to Brian Weis for fruitful discussions on security 872 requirements. 874 Authors' Addresses 876 Acee Lindem (editor) 877 Cisco Systems 878 301 Midenhall Way 879 Cary, NC 27513 880 USA 882 Email: acee@cisco.com 884 Yingzhen Qu 885 Cisco Systems 886 170 West Tasman Drive 887 San Jose, CA 95134 888 USA 890 Email: yiqu@cisco.com 892 Derek Yeung 893 Cisco Systems 894 170 West Tasman Drive 895 San Jose, CA 95134 896 USA 898 Email: myeung@cisco.com 900 Ing-Wher Chen 901 Ericsson 903 Email: ing-wher.chen@ericsson.com 904 Jeffrey Zhang 905 Juniper Networks 906 10 Technology Park Drive 907 Westford, MA 01886 908 USA 910 Email: zzhang@juniper.net 912 Yi Yang 913 Cisco Systems 914 7025 Kit Creek Road 915 Research Triangle Park, NC 27709 916 USA 918 Email: yiya@cisco.com