idnits 2.17.00 (12 Aug 2021) /tmp/idnits11577/draft-ietf-rtgwg-yang-key-chain-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 (March 15, 2016) is 2258 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) == Outdated reference: A later version (-09) exists of draft-ietf-netconf-server-model-08 -- 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 (~~), 3 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: September 16, 2016 Cisco Systems 6 I. Chen 7 Ericsson 8 J. Zhang 9 Juniper Networks 10 Y. Yang 11 Cisco Systems 12 March 15, 2016 14 Routing Key Chain YANG Data Model 15 draft-ietf-rtgwg-yang-key-chain-02.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 September 16, 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 . . . . . . . . . . . . . . . . . 17 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 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 The module name was change from ietf-key-chain to ietf-routing-key- 119 chain to avoid disambiguate it from the ietf-system-keychain module 120 defined in [NETCONF-SERVER-CONF]. 122 A conceptual representation of a crypto key table is described in 123 [CRYPTO-KEYTABLE]. The crypto key table also includes keys as well 124 as their corresponding lifetimes and algorithms. Additionally, the 125 key table includes key selection criteria and envisions a deployment 126 model where the details of the applications or services requiring 127 authentication or encryption permeate into the key database. The 128 YANG key-chain model described herein doesn't include key selection 129 criteria or support this deployment model. At the same time, it does 130 not preclude it. The draft [YANG-CRYPTO-KEYTABLE] describes 131 augmentations to the key chain YANG model in support of key selection 132 criteria. 134 2.1. Graceful Key Rollover using Key Chains 136 Key chains may be used to gracefully update the key and/or algorithm 137 used by an application for authentication or encryption. This MAY be 138 accomplished by accepting all the keys that have a valid accept 139 lifetime and sending the key with the most recent send lifetime. One 140 scenario for facilitating key rollover is to: 142 1. Distribute a key chain with a new key to all the routers or other 143 network devices in the domain of that key chain. The new key's 144 accept lifetime should be such that it is accepted during the key 145 rollover period. The send lifetime should be a time in the 146 future when it can be assured that all the routers in the domain 147 of that key are upgraded. This will have no immediate impact on 148 the keys used for transmission. 150 2. Assure that all the network devices have been updated with the 151 updated key chain and that their system times are roughly 152 synchronized. The system times of devices within an 153 administrative domain are commonly synchronized (e.g., using 154 Network Time Protocol (NTP) [NTP-PROTO]). This also may be 155 automated. 157 3. When the send lifetime of the new key becomes valid, the network 158 devices within the domain of key chain will start sending the new 159 key. 161 4. At some point in the future, a new key chain with the old key 162 removed may be distributed to the network devices within the 163 domain of the key chain. However, this may be deferred until the 164 next key rollover. If this is done, the key chain will always 165 include two keys; either the current and future key (during key 166 rollovers) or the current and previous keys (between key 167 rollovers). 169 3. Design of the Key Chain Model 171 The ietf-routing-key-chain module contains a list of one or more keys 172 indexed by a Key ID. For some applications (e.g., OSPFv3 173 [OSPFV3-AUTH]), the Key-Id is used to identify the key chain entry to 174 be used. In addition to the Key-ID, each key chain entry includes a 175 key-string and a cryptographic algorithm. Optionally, the key chain 176 entries include send/accept lifetimes. If the send/accept lifetime 177 is unspecified, the key is always considered valid. 179 Note that asymmetric keys, i.e., a different key value used for 180 transmission versus acceptance, may be supported with multiple key 181 chain elements where the accept-lifetime or send-lifetime is not 182 valid (e.g., has an end-time equal to the start-time). 184 Due to the differences in key chain implementations across various 185 vendors, some of the data elements are optional. Additionally, the 186 key-chain is made a grouping so that an implementation could support 187 scoping other than at the global level. Finally, the crypto- 188 algorithm-types grouping is provided for reuse when configuring 189 legacy authentication and encryption not using key-chains. 191 A key-chain is identified by a unique name within the scope of the 192 network device. The "key-chain-ref" typedef SHOULD be used by other 193 YANG modules when they need to reference a configured key-chain. 195 3.1. Key Chain Operational State 197 The key chain operational state is maintained in the key-chain 198 entries along with the configuration state. The key string itself is 199 omitted from the operational state to minimize visibility similar to 200 what was done with keys in SNMP MIBs. This is an area for further 201 discussion. Additionally, the operational state includes an 202 indication of whether or not a key chain entry is valid for sending 203 or acceptance. 205 3.2. Key Chain Model Features 207 Features are used to handle differences between vendor 208 implementations. For example, not all vendors support configuration 209 an acceptance tolerance or configuration of key strings in 210 hexadecimal. They are also used to support of security requirements 211 (e.g., TCP-AO Algorithms [TCP-AO-ALGORITHMS]) not implemented by 212 vendors or only a single vendor. 214 3.3. Key Chain Model Tree 216 +--rw key-chains 217 +--rw key-chain-list* [name] 218 | +--rw name string 219 | +--ro name-state? string 220 | +--rw accept-tolerance {accept-tolerance}? 221 | | +--rw duration? uint32 222 | +--ro accept-tolerance-state 223 | | +--ro duration? uint32 224 | +--rw key-chain-entry* [key-id] 225 | +--rw key-id uint64 226 | +--ro key-id-state? uint64 227 | +--rw key-string 228 | | +--rw (key-string-style)? 229 | | +--:(keystring) 230 | | | +--rw keystring? string 231 | | +--:(hexadecimal) {hex-key-string}? 232 | | +--rw hexadecimal-string? yang:hex-string 233 | +--rw lifetime 234 | | +--rw (lifetime)? 235 | | +--:(send-and-accept-lifetime) 236 | | | +--rw send-accept-lifetime 237 | | | +--rw (lifetime)? 238 | | | +--:(always) 239 | | | | +--rw always? empty 240 | | | +--:(start-end-time) 241 | | | +--rw start-date-time? yang:date-and-time 242 | | | +--rw (end-time)? 243 | | | +--:(infinite) 244 | | | | +--rw no-end-time? empty 245 | | | +--:(duration) 246 | | | | +--rw duration? uint32 247 | | | +--:(end-date-time) 248 | | | +--rw end-date-time? 249 | | | yang:date-and-time 250 | | +--:(independent-send-accept-lifetime) 251 | | | {independent-send-accept-lifetime}? 252 | | +--rw send-lifetime 253 | | | +--rw (lifetime)? 254 | | | +--:(always) 255 | | | | +--rw always? empty 256 | | | +--:(start-end-time) 257 | | | +--rw start-date-time? yang:date-and-time 258 | | | +--rw (end-time)? 259 | | | +--:(infinite) 260 | | | | +--rw no-end-time? empty 261 | | | +--:(duration) 262 | | | | +--rw duration? uint32 263 | | | +--:(end-date-time) 264 | | | +--rw end-date-time? 265 | | | yang:date-and-time 266 | | +--rw accept-lifetime 267 | | +--rw (lifetime)? 268 | | +--:(always) 269 | | | +--rw always? empty 270 | | +--:(start-end-time) 271 | | +--rw start-date-time? yang:date-and-time 272 | | +--rw (end-time)? 273 | | +--:(infinite) 274 | | | +--rw no-end-time? empty 275 | | +--:(duration) 276 | | | +--rw duration? uint32 277 | | +--:(end-date-time) 278 | | +--rw end-date-time? 279 | | yang:date-and-time 280 | +--ro lifetime-state 281 | | +--ro send-lifetime 282 | | | +--ro (lifetime)? 283 | | | +--:(always) 284 | | | | +--ro always? empty 285 | | | +--:(start-end-time) 286 | | | +--ro start-date-time? yang:date-and-time 287 | | | +--ro (end-time)? 288 | | | +--:(infinite) 289 | | | | +--ro no-end-time? empty 290 | | | +--:(duration) 291 | | | | +--ro duration? uint32 292 | | | +--:(end-date-time) 293 | | | +--ro end-date-time? 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? 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-routing-key-chain@2016-03-15.yang" 357 module ietf-routing-key-chain { 358 namespace "urn:ietf:params:xml:ns:yang:ietf-routing-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-03-15 { 390 description 391 "Rename module from ietf-key-chain to 392 ietf-routing-key-chain."; 393 reference 394 "RFC XXXX: A YANG Data Model for Routing key-chain"; 395 } 396 revision 2016-02-16 { 397 description 398 "Updated version. Added clear-text algorithm as a 399 feature."; 400 reference 401 "RFC XXXX: A YANG Data Model for key-chain"; 402 } 403 revision 2015-10-15 { 404 description 405 "Updated version, organization, and copyright. 406 Added aes-cmac-prf-128 and aes-key-wrap features."; 407 reference 408 "RFC XXXX: A YANG Data Model for key-chain"; 409 } 410 revision 2015-06-29 { 411 description 412 "Updated version. Added Operation State following 413 draft-openconfig-netmod-opstate-00."; 414 reference 415 "RFC XXXX: A YANG Data Model for key-chain"; 416 } 417 revision 2015-02-24 { 418 description 419 "Initial revision."; 420 reference 421 "RFC XXXX: A YANG Data Model for key-chain"; 422 } 424 typedef key-chain-ref { 425 type leafref { 426 path "/key-chain:key-chains/key-chain:key-chain-list/" 427 + "key-chain:name"; 428 } 429 description 430 "This type is used by data models that need to reference 431 configured key-chains."; 432 } 434 /* feature list */ 435 feature hex-key-string { 436 description 437 "Support hexadecimal key string."; 438 } 440 feature accept-tolerance { 441 description 442 "To specify the tolerance or acceptance limit."; 443 } 445 feature independent-send-accept-lifetime { 446 description 447 "Support for independent send and accept key lifetimes."; 448 } 450 feature crypto-hmac-sha-1-12 { 451 description 452 "Support for TCP HMAC-SHA-1 12 byte digest hack."; 453 } 455 feature clear-text { 456 description 457 "Support for clear-text algorithm. Usage is NOT RECOMMENDED."; 458 } 460 feature aes-cmac-prf-128 { 461 description 462 "Support for AES Cipher based Message Authentication Code 463 Pseudo Random Function."; 464 } 466 feature aes-key-wrap { 467 description 468 "Support for Advanced Encryption Standard (AES) Key Wrap."; 469 } 471 /* groupings */ 472 grouping lifetime { 473 description 474 "Key lifetime specification."; 475 choice lifetime { 476 default always; 477 description 478 "Options for specifying key accept or send lifetimes"; 480 case always { 481 leaf always { 482 type empty; 483 description 484 "Indicates key lifetime is always valid."; 485 } 486 } 487 case start-end-time { 488 leaf start-date-time { 489 type yang:date-and-time; 490 description "Start time."; 491 } 492 choice end-time { 493 default infinite; 494 description 495 "End-time setting."; 496 case infinite { 497 leaf no-end-time { 498 type empty; 499 description 500 "Indicates key lifetime end-time in infinite."; 501 } 502 } 503 case duration { 504 leaf duration { 505 type uint32 { 506 range "1..2147483646"; 507 } 508 units seconds; 509 description "Key lifetime duration, in seconds"; 510 } 511 } 512 case end-date-time { 513 leaf end-date-time { 514 type yang:date-and-time; 515 description "End time."; 516 } 517 } 518 } 519 } 520 } 521 } 523 grouping crypto-algorithm-types { 524 description "Cryptographic algorithm types."; 525 choice algorithm { 526 description 527 "Options for cryptographic algorithm specification."; 529 case hmac-sha-1-12 { 530 if-feature crypto-hmac-sha-1-12; 531 leaf hmac-sha1-12 { 532 type empty; 533 description "The HMAC-SHA1-12 algorithm."; 534 } 535 } 536 case aes-cmac-prf-128 { 537 if-feature aes-cmac-prf-128; 538 leaf aes-cmac-prf-128 { 539 type empty; 540 description "The AES-CMAC-PRF-128 algorithm - required 541 by RFC 5926 for TCP-AO key derivation 542 functions."; 543 } 544 } 545 case md5 { 546 leaf md5 { 547 type empty; 548 description "The MD5 algorithm."; 549 } 550 } 551 case sha-1 { 552 leaf sha-1 { 553 type empty; 554 description "The SHA-1 algorithm."; 555 } 556 } 557 case hmac-sha-1 { 558 leaf hmac-sha-1 { 559 type empty; 560 description "HMAC-SHA-1 authentication algorithm."; 561 } 562 } 563 case hmac-sha-256 { 564 leaf hmac-sha-256 { 565 type empty; 566 description "HMAC-SHA-256 authentication algorithm."; 567 } 568 } 569 case hmac-sha-384 { 570 leaf hmac-sha-384 { 571 type empty; 572 description "HMAC-SHA-384 authentication algorithm."; 573 } 574 } 575 case hmac-sha-512 { 576 leaf hmac-sha-512 { 577 type empty; 578 description "HMAC-SHA-512 authentication algorithm."; 579 } 580 } 581 case clear-text { 582 if-feature clear-text; 583 leaf clear-text { 584 type empty; 585 description "Clear text."; 586 } 587 } 588 } 589 } 591 grouping key-chain { 592 description 593 "key-chain specification grouping."; 594 leaf name { 595 type string; 596 description "Name of the key-chain."; 597 } 599 leaf name-state { 600 type string; 601 config false; 602 description "Configured name of the key-chain."; 603 } 605 container accept-tolerance { 606 if-feature accept-tolerance; 607 description 608 "Tolerance for key lifetime acceptance (seconds)."; 609 leaf duration { 610 type uint32; 611 units seconds; 612 default "0"; 613 description 614 "Tolerance range, in seconds."; 615 } 616 } 618 container accept-tolerance-state { 619 config false; 620 description 621 "Configured tolerance for key lifetime 622 acceptance (seconds)."; 623 leaf duration { 624 type uint32; 625 description 626 "Configured tolerance range, in seconds."; 627 } 628 } 630 list key-chain-entry { 631 key "key-id"; 632 description "One key."; 633 leaf key-id { 634 type uint64; 635 description "Key ID."; 636 } 637 leaf key-id-state { 638 type uint64; 639 config false; 640 description "Configured Key ID."; 641 } 642 container key-string { 643 description "The key string."; 644 choice key-string-style { 645 description 646 "Key string styles"; 647 case keystring { 648 leaf keystring { 649 type string; 650 description "Key string in ASCII format."; 651 } 652 } 653 case hexadecimal { 654 if-feature hex-key-string; 655 leaf hexadecimal-string { 656 type yang:hex-string; 657 description 658 "Key in hexadecimal string format."; 659 } 660 } 661 } 662 } 663 container lifetime { 664 description "Specify a key's lifetime."; 665 choice lifetime { 666 description 667 "Options for specification of send and accept 668 lifetimes."; 669 case send-and-accept-lifetime { 670 description 671 "Send and accept key have the same lifetime."; 672 container send-accept-lifetime { 673 uses lifetime; 674 description 675 "Single lifetime specification for both send and 676 accept lifetimes."; 677 } 678 } 679 case independent-send-accept-lifetime { 680 if-feature independent-send-accept-lifetime; 681 description 682 "Independent send and accept key lifetimes."; 683 container send-lifetime { 684 uses lifetime; 685 description 686 "Separate lifetime specification for send 687 lifetime."; 688 } 689 container accept-lifetime { 690 uses lifetime; 691 description 692 "Separate lifetime specification for accept 693 lifetime."; 694 } 695 } 696 } 697 } 698 container lifetime-state { 699 config false; 700 description "Configured key's lifetime."; 701 container send-lifetime { 702 uses lifetime; 703 description 704 "Configured send-lifetime."; 705 } 706 leaf send-valid { 707 type boolean; 708 description 709 "Status of send-lifetime."; 710 } 711 container accept-lifetime { 712 uses lifetime; 713 description 714 "Configured accept-lifetime."; 715 } 716 leaf accept-valid { 717 type boolean; 718 description 719 "Status of accept-lifetime."; 720 } 722 } 723 container crypto-algorithm { 724 uses crypto-algorithm-types; 725 description "Cryptographic algorithm associated with key."; 726 } 727 container crypto-algorithm-state { 728 config false; 729 uses crypto-algorithm-types; 730 description "Configured cryptographic algorithm."; 731 } 732 } 733 } 735 container key-chains { 736 list key-chain-list { 737 key "name"; 738 description 739 "List of key-chains."; 740 uses key-chain; 741 } 742 container aes-key-wrap { 743 if-feature aes-key-wrap; 744 leaf enable { 745 type boolean; 746 default false; 747 description 748 "Enable AES Key Wrap encryption."; 749 } 750 description 751 "AES Key Wrap password encryption."; 752 } 753 container aes-key-wrap-state { 754 if-feature aes-key-wrap; 755 config false; 756 leaf enable { 757 type boolean; 758 description "AES Key Wrap state."; 759 } 760 description "Status of AES Key Wrap."; 761 } 762 description "All configured key-chains for the device."; 763 } 764 } 765 767 5. Relationship to other Work 769 6. Security Considerations 771 This document enables the automated distribution of industry standard 772 key chains using the NETCONF [NETCONF] protocol. As such, the 773 security considerations for the NETCONF protocol are applicable. 774 Given that the key chains themselves are sensitive data, it is 775 RECOMMENDED that the NETCONF communication channel be encrypted. One 776 way to do accomplish this would be to invoke and run NETCONF over SSH 777 as described in [NETCONF-SSH]. 779 When configured, the key-strings can be encrypted using the AES Key 780 Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) is 781 not included in the YANG model and must be set or derived independent 782 of key-chain configuration. 784 The key strings are not included in the operational state. This is a 785 practice carried over from SNMP MIB modules and is an area for 786 further discussion. 788 The clear-text algorithm is included as a YANG feature. Usage is NOT 789 RECOMMENDED except in cases where the application and device have no 790 other alternative (e.g., a legacy network device that must 791 authenticate packets at intervals of 10 milliseconds or less for many 792 peers using Bidirectional Forwarding Detection [BFD]). Keys used 793 with the clear-text algorithm are considered insecure and SHOULD NOT 794 be reused with more secure algorithms. 796 7. IANA Considerations 798 This document registers a URI in the IETF XML registry 799 [XML-REGISTRY]. Following the format in RFC 3688, the following 800 registration is requested to be made: 802 URI: urn:ietf:params:xml:ns:yang:ietf-routing-key-chain 804 Registrant Contact: The IESG. 806 XML: N/A, the requested URI is an XML namespace. 808 This document registers a YANG module in the YANG Module Names 809 registry [YANG]. 811 name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf- 812 routing-key-chain prefix: ietf-key-chain reference: RFC XXXX 814 8. References 816 8.1. Normative References 818 [NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 819 Bierman, "Network Configuration Protocol (NETCONF)", RFC 820 6241, June 2011. 822 [NETCONF-SSH] 823 Wasserman, M., "Using NETCONF Protocol over Secure Shell 824 (SSH)", RFC 6242, June 2011. 826 [RFC-KEYWORDS] 827 Bradner, S., "Key words for use in RFC's to Indicate 828 Requirement Levels", BCP 14, RFC 2119, March 1997. 830 [XML-REGISTRY] 831 Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 832 January 2004. 834 [YANG] Bjorklund, M., "YANG - A Data Modeling Language for the 835 Network Configuration Protocol (NETCONF)", RFC 6020, 836 October 2010. 838 8.2. Informative References 840 [AES-KEY-WRAP] 841 Housley, R. and M. Dworkin, "Advanced Encryption Standard 842 (AES) Key Wrap with Padding Algorithm", RFC 5649, August 843 2009. 845 [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 846 (BFD)", RFC 5880, June 2010. 848 [CRYPTO-KEYTABLE] 849 Housley, R., Polk, T., Hartman, S., and D. Zhang, 850 "Table of Cryptographic Keys", RFC 7210, April 2014. 852 [IAB-REPORT] 853 Andersson, L., Davies, E., and L. Zhang, "Report from the 854 IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 855 4948, August 2007. 857 [NETCONF-SERVER-CONF] 858 Watsen, K. and J. Schoenwaelder, "NETCONF Server and 859 RESTCONF Server Configuration Models", draft-ietf-netconf- 860 server-model-08.txt (work in progress), October 2015. 862 [NTP-PROTO] 863 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 864 Time Protocol Version 4: Protocol and Algorithms 865 Specification", RFC 5905, June 2010. 867 [OSPFV3-AUTH] 868 Bhatia, M., Manral, V., and A. Lindem, "Supporting 869 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 871 [TCP-AO-ALGORITHMS] 872 Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 873 for the TCP Authentication Option (TCP-AO)", RFC 5926, 874 June 2010. 876 [YANG-CRYPTO-KEYTABLE] 877 Chen, I., "YANG Data Model for RFC 7210 Key Table", draft- 878 chen-rtg-key-table-yang-02.txt (work in progress), 879 November 2015. 881 Appendix A. Acknowledgments 883 The RFC text was produced using Marshall Rose's xml2rfc tool. 885 Thanks to Brian Weis for fruitful discussions on security 886 requirements. 888 Authors' Addresses 890 Acee Lindem (editor) 891 Cisco Systems 892 301 Midenhall Way 893 Cary, NC 27513 894 USA 896 Email: acee@cisco.com 898 Yingzhen Qu 899 Cisco Systems 900 170 West Tasman Drive 901 San Jose, CA 95134 902 USA 904 Email: yiqu@cisco.com 905 Derek Yeung 906 Cisco Systems 907 170 West Tasman Drive 908 San Jose, CA 95134 909 USA 911 Email: myeung@cisco.com 913 Ing-Wher Chen 914 Ericsson 916 Email: ing-wher.chen@ericsson.com 918 Jeffrey Zhang 919 Juniper Networks 920 10 Technology Park Drive 921 Westford, MA 01886 922 USA 924 Email: zzhang@juniper.net 926 Yi Yang 927 Cisco Systems 928 7025 Kit Creek Road 929 Research Triangle Park, NC 27709 930 USA 932 Email: yiya@cisco.com