idnits 2.17.1 draft-ietf-rtgwg-yang-key-chain-07.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 (August 17, 2016) is 2808 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: February 18, 2017 Cisco Systems 6 I. Chen 7 Ericsson 8 J. Zhang 9 Juniper Networks 10 Y. Yang 11 Cisco Systems 12 August 17, 2016 14 Routing Key Chain YANG Data Model 15 draft-ietf-rtgwg-yang-key-chain-07.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 February 18, 2017. 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 . . . . . . . . . . . . . . . . . 18 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 78 8.2. Informative References . . . . . . . . . . . . . . . . . 19 79 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 20 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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]. However, due to popular demand, 121 the module name has been restored to simply ietf-key-chain. 123 A conceptual representation of a crypto key table is described in 124 [CRYPTO-KEYTABLE]. The crypto key table also includes keys as well 125 as their corresponding lifetimes and algorithms. Additionally, the 126 key table includes key selection criteria and envisions a deployment 127 model where the details of the applications or services requiring 128 authentication or encryption permeate into the key database. The 129 YANG key-chain model described herein doesn't include key selection 130 criteria or support this deployment model. At the same time, it does 131 not preclude it. The draft [YANG-CRYPTO-KEYTABLE] describes 132 augmentations to the key chain YANG model in support of key selection 133 criteria. 135 2.1. Graceful Key Rollover using Key Chains 137 Key chains may be used to gracefully update the key and/or algorithm 138 used by an application for authentication or encryption. This MAY be 139 accomplished by accepting all the keys that have a valid accept 140 lifetime and sending the key with the most recent send lifetime. One 141 scenario for facilitating key rollover is to: 143 1. Distribute a key chain with a new key to all the routers or other 144 network devices in the domain of that key chain. The new key's 145 accept lifetime should be such that it is accepted during the key 146 rollover period. The send lifetime should be a time in the 147 future when it can be assured that all the routers in the domain 148 of that key are upgraded. This will have no immediate impact on 149 the keys used for transmission. 151 2. Assure that all the network devices have been updated with the 152 updated key chain and that their system times are roughly 153 synchronized. The system times of devices within an 154 administrative domain are commonly synchronized (e.g., using 155 Network Time Protocol (NTP) [NTP-PROTO]). This also may be 156 automated. 158 3. When the send lifetime of the new key becomes valid, the network 159 devices within the domain of key chain will start sending the new 160 key. 162 4. At some point in the future, a new key chain with the old key 163 removed may be distributed to the network devices within the 164 domain of the key chain. However, this may be deferred until the 165 next key rollover. If this is done, the key chain will always 166 include two keys; either the current and future key (during key 167 rollovers) or the current and previous keys (between key 168 rollovers). 170 3. Design of the Key Chain Model 172 The ietf-key-chain module contains a list of one or more keys indexed 173 by a Key ID. For some applications (e.g., OSPFv3 [OSPFV3-AUTH]), the 174 Key-Id is used to identify the key chain entry to be used. In 175 addition to the Key-ID, each key chain entry includes a key-string 176 and a cryptographic algorithm. Optionally, the key chain entries 177 include send/accept lifetimes. If the send/accept lifetime is 178 unspecified, the key is always considered valid. 180 Note that asymmetric keys, i.e., a different key value used for 181 transmission versus acceptance, may be supported with multiple key 182 chain elements where the accept-lifetime or send-lifetime is not 183 valid (e.g., has an end-time equal to the start-time). 185 Due to the differences in key chain implementations across various 186 vendors, some of the data elements are optional. Additionally, the 187 key-chain is made a grouping so that an implementation could support 188 scoping other than at the global level. Finally, the crypto- 189 algorithm-types grouping is provided for reuse when configuring 190 legacy authentication and encryption not using key-chains. 192 A key-chain is identified by a unique name within the scope of the 193 network device. The "key-chain-ref" typedef SHOULD be used by other 194 YANG modules when they need to reference a configured key-chain. 196 3.1. Key Chain Operational State 198 The key chain operational state is maintained in the key-chain 199 entries along with the configuration state. The key string itself is 200 omitted from the operational state to minimize visibility similar to 201 what was done with keys in SNMP MIBs. The timestamp of the last key- 202 chain modification is also maintained in the operational state. 203 Additionally, the operational state includes an indication of whether 204 or not a key chain entry is valid for sending or acceptance. 206 3.2. Key Chain Model Features 208 Features are used to handle differences between vendor 209 implementations. For example, not all vendors support configuration 210 an acceptance tolerance or configuration of key strings in 211 hexadecimal. They are also used to support of security requirements 212 (e.g., TCP-AO Algorithms [TCP-AO-ALGORITHMS]) not implemented by 213 vendors or only a single vendor. 215 3.3. Key Chain Model Tree 217 module: ietf-key-chain 218 +--rw key-chains 219 +--rw key-chain-list* [name] 220 | +--rw name string 221 | +--ro name-state? string 222 | +--rw description? string 223 | +--rw accept-tolerance {accept-tolerance}? 224 | | +--rw duration? uint32 225 | +--ro accept-tolerance-state 226 | | +--ro duration? uint32 227 | +--ro last-modified-timestamp? yang:date-and-time 228 | +--rw key-chain-entry* [key-id] 229 | +--rw key-id uint64 230 | +--ro key-id-state? uint64 231 | +--rw key-string 232 | | +--rw (key-string-style)? 233 | | +--:(keystring) 234 | | | +--rw keystring? string 235 | | +--:(hexadecimal) {hex-key-string}? 236 | | +--rw hexadecimal-string? yang:hex-string 237 | +--rw lifetime 238 | | +--rw (lifetime)? 239 | | +--:(send-and-accept-lifetime) 240 | | | +--rw send-accept-lifetime 241 | | | +--rw (lifetime)? 242 | | | +--:(always) 243 | | | | +--rw always? empty 244 | | | +--:(start-end-time) 245 | | | +--rw start-date-time? yang:date-and-time 246 | | | +--rw (end-time)? 247 | | | +--:(infinite) 248 | | | | +--rw no-end-time? empty 249 | | | +--:(duration) 250 | | | | +--rw duration? uint32 251 | | | +--:(end-date-time) 252 | | | +--rw end-date-time? 253 | | | yang:date-and-time 254 | | +--:(independent-send-accept-lifetime) 255 | | {independent-send-accept-lifetime}? 256 | | +--rw send-lifetime 257 | | | +--rw (lifetime)? 258 | | | +--:(always) 259 | | | | +--rw always? empty 260 | | | +--:(start-end-time) 261 | | | +--rw start-date-time? yang:date-and-time 262 | | | +--rw (end-time)? 263 | | | +--:(infinite) 264 | | | | +--rw no-end-time? empty 265 | | | +--:(duration) 266 | | | | +--rw duration? uint32 267 | | | +--:(end-date-time) 268 | | | +--rw end-date-time? 269 | | | yang:date-and-time 270 | | +--rw accept-lifetime 271 | | +--rw (lifetime)? 272 | | +--:(always) 273 | | | +--rw always? empty 274 | | +--:(start-end-time) 275 | | +--rw start-date-time? yang:date-and-time 276 | | +--rw (end-time)? 277 | | +--:(infinite) 278 | | | +--rw no-end-time? empty 279 | | +--:(duration) 280 | | | +--rw duration? uint32 281 | | +--:(end-date-time) 282 | | +--rw end-date-time? 283 | | yang:date-and-time 284 | +--ro lifetime-state 285 | | +--ro send-lifetime 286 | | | +--ro (lifetime)? 287 | | | +--:(always) 288 | | | | +--ro always? empty 289 | | | +--:(start-end-time) 290 | | | +--ro start-date-time? yang:date-and-time 291 | | | +--ro (end-time)? 292 | | | +--:(infinite) 293 | | | | +--ro no-end-time? empty 294 | | | +--:(duration) 295 | | | | +--ro duration? uint32 296 | | | +--:(end-date-time) 297 | | | +--ro end-date-time? yang:date-and-time 298 | | +--ro send-valid? boolean 299 | | +--ro accept-lifetime 300 | | | +--ro (lifetime)? 301 | | | +--:(always) 302 | | | | +--ro always? empty 303 | | | +--:(start-end-time) 304 | | | +--ro start-date-time? yang:date-and-time 305 | | | +--ro (end-time)? 306 | | | +--:(infinite) 307 | | | | +--ro no-end-time? empty 308 | | | +--:(duration) 309 | | | | +--ro duration? uint32 310 | | | +--:(end-date-time) 311 | | | +--ro end-date-time? yang:date-and-time 312 | | +--ro accept-valid? boolean 313 | +--rw crypto-algorithm 314 | | +--rw (algorithm)? 315 | | +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}? 316 | | | +--rw hmac-sha1-12? empty 317 | | +--:(aes-cmac-prf-128) {aes-cmac-prf-128}? 318 | | | +--rw aes-cmac-prf-128? empty 319 | | +--:(md5) 320 | | | +--rw md5? empty 321 | | +--:(sha-1) 322 | | | +--rw sha-1? empty 323 | | +--:(hmac-sha-1) 324 | | | +--rw hmac-sha-1? empty 325 | | +--:(hmac-sha-256) 326 | | | +--rw hmac-sha-256? empty 327 | | +--:(hmac-sha-384) 328 | | | +--rw hmac-sha-384? empty 329 | | +--:(hmac-sha-512) 330 | | | +--rw hmac-sha-512? empty 331 | | +--:(clear-text) {clear-text}? 332 | | | +--rw clear-text? empty 333 | | +--:(replay-protection-only) {replay-protection-only}? 334 | | +--rw replay-protection-only? empty 335 | +--ro crypto-algorithm-state 336 | +--ro (algorithm)? 337 | +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}? 338 | | +--ro hmac-sha1-12? empty 339 | +--:(aes-cmac-prf-128) {aes-cmac-prf-128}? 340 | | +--ro aes-cmac-prf-128? empty 341 | +--:(md5) 342 | | +--ro md5? empty 343 | +--:(sha-1) 344 | | +--ro sha-1? empty 345 | +--:(hmac-sha-1) 346 | | +--ro hmac-sha-1? empty 347 | +--:(hmac-sha-256) 348 | | +--ro hmac-sha-256? empty 349 | +--:(hmac-sha-384) 350 | | +--ro hmac-sha-384? empty 351 | +--:(hmac-sha-512) 352 | | +--ro hmac-sha-512? empty 353 | +--:(clear-text) {clear-text}? 354 | | +--ro clear-text? empty 355 | +--:(replay-protection-only) {replay-protection-only}? 356 | +--ro replay-protection-only? empty 357 +--rw aes-key-wrap {aes-key-wrap}? 358 | +--rw enable? boolean 359 +--ro aes-key-wrap-state {aes-key-wrap}? 360 +--ro enable? boolean 362 4. Key Chain YANG Model 364 file "ietf-key-chain@2016-08-17.yang" 365 module ietf-key-chain { 366 namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain"; 367 // replace with IANA namespace when assigned 368 prefix "key-chain"; 370 import ietf-yang-types { 371 prefix "yang"; 372 } 374 organization 375 "IETF RTG (Routing) Working Group"; 376 contact 377 "Acee Lindem - acee@cisco.com"; 379 description 380 "This YANG module defines the generic configuration 381 data for key-chain. It is intended that the module 382 will be extended by vendors to define vendor-specific 383 key-chain configuration parameters. 385 Copyright (c) 2015 IETF Trust and the persons identified as 386 authors of the code. All rights reserved. 388 Redistribution and use in source and binary forms, with or 389 without modification, is permitted pursuant to, and subject 390 to the license terms contained in, the Simplified BSD License 391 set forth in Section 4.c of the IETF Trust's Legal Provisions 392 Relating to IETF Documents 393 (http://trustee.ietf.org/license-info). 394 This version of this YANG module is part of RFC XXXX; see 395 the RFC itself for full legal notices."; 397 revision 2016-08-17 { 398 description 399 "Add description and last-modified timestamp leaves."; 400 reference 401 "RFC XXXX: A YANG Data Model for key-chain"; 402 } 403 revision 2016-07-01 { 404 description 405 "Rename module back to ietf-key-chain. 406 Added replay-protection-only feature and algorithm."; 407 reference 408 "RFC XXXX: A YANG Data Model for key-chain"; 409 } 410 revision 2016-03-15 { 411 description 412 "Rename module from ietf-key-chain to 413 ietf-routing-key-chain."; 414 reference 415 "RFC XXXX: A YANG Data Model for Routing key-chain"; 416 } 417 revision 2016-02-16 { 418 description 419 "Updated version. Added clear-text algorithm as a 420 feature."; 421 reference 422 "RFC XXXX: A YANG Data Model for key-chain"; 423 } 424 revision 2015-10-15 { 425 description 426 "Updated version, organization, and copyright. 427 Added aes-cmac-prf-128 and aes-key-wrap features."; 428 reference 429 "RFC XXXX: A YANG Data Model for key-chain"; 430 } 431 revision 2015-06-29 { 432 description 433 "Updated version. Added Operation State following 434 draft-openconfig-netmod-opstate-00."; 435 reference 436 "RFC XXXX: A YANG Data Model for key-chain"; 437 } 438 revision 2015-02-24 { 439 description 440 "Initial revision."; 441 reference 442 "RFC XXXX: A YANG Data Model for key-chain"; 443 } 445 typedef key-chain-ref { 446 type leafref { 447 path "/key-chain:key-chains/key-chain:key-chain-list/" 448 + "key-chain:name"; 449 } 450 description 451 "This type is used by data models that need to reference 452 configured key-chains."; 453 } 455 /* feature list */ 456 feature hex-key-string { 457 description 458 "Support hexadecimal key string."; 459 } 461 feature accept-tolerance { 462 description 463 "To specify the tolerance or acceptance limit."; 464 } 466 feature independent-send-accept-lifetime { 467 description 468 "Support for independent send and accept key lifetimes."; 469 } 471 feature crypto-hmac-sha-1-12 { 472 description 473 "Support for TCP HMAC-SHA-1 12 byte digest hack."; 474 } 476 feature clear-text { 477 description 478 "Support for clear-text algorithm. Usage is NOT RECOMMENDED."; 479 } 480 feature aes-cmac-prf-128 { 481 description 482 "Support for AES Cipher based Message Authentication Code 483 Pseudo Random Function."; 484 } 486 feature aes-key-wrap { 487 description 488 "Support for Advanced Encryption Standard (AES) Key Wrap."; 489 } 491 feature replay-protection-only { 492 description 493 "Provide replay-protection without any authentication 494 as required by protocols such as Bidirectional 495 Forwarding Detection (BFD)."; 496 } 498 /* groupings */ 499 grouping lifetime { 500 description 501 "Key lifetime specification."; 502 choice lifetime { 503 default always; 504 description 505 "Options for specifying key accept or send lifetimes"; 506 case always { 507 leaf always { 508 type empty; 509 description 510 "Indicates key lifetime is always valid."; 511 } 512 } 513 case start-end-time { 514 leaf start-date-time { 515 type yang:date-and-time; 516 description "Start time."; 517 } 518 choice end-time { 519 default infinite; 520 description 521 "End-time setting."; 522 case infinite { 523 leaf no-end-time { 524 type empty; 525 description 526 "Indicates key lifetime end-time in infinite."; 527 } 529 } 530 case duration { 531 leaf duration { 532 type uint32 { 533 range "1..2147483646"; 534 } 535 units seconds; 536 description "Key lifetime duration, in seconds"; 537 } 538 } 539 case end-date-time { 540 leaf end-date-time { 541 type yang:date-and-time; 542 description "End time."; 543 } 544 } 545 } 546 } 547 } 548 } 550 grouping crypto-algorithm-types { 551 description "Cryptographic algorithm types."; 552 choice algorithm { 553 description 554 "Options for cryptographic algorithm specification."; 555 case hmac-sha-1-12 { 556 if-feature crypto-hmac-sha-1-12; 557 leaf hmac-sha1-12 { 558 type empty; 559 description "The HMAC-SHA1-12 algorithm."; 560 } 561 } 562 case aes-cmac-prf-128 { 563 if-feature aes-cmac-prf-128; 564 leaf aes-cmac-prf-128 { 565 type empty; 566 description "The AES-CMAC-PRF-128 algorithm - required 567 by RFC 5926 for TCP-AO key derivation 568 functions."; 569 } 570 } 571 case md5 { 572 leaf md5 { 573 type empty; 574 description "The MD5 algorithm."; 575 } 576 } 577 case sha-1 { 578 leaf sha-1 { 579 type empty; 580 description "The SHA-1 algorithm."; 581 } 582 } 583 case hmac-sha-1 { 584 leaf hmac-sha-1 { 585 type empty; 586 description "HMAC-SHA-1 authentication algorithm."; 587 } 588 } 589 case hmac-sha-256 { 590 leaf hmac-sha-256 { 591 type empty; 592 description "HMAC-SHA-256 authentication algorithm."; 593 } 594 } 595 case hmac-sha-384 { 596 leaf hmac-sha-384 { 597 type empty; 598 description "HMAC-SHA-384 authentication algorithm."; 599 } 600 } 601 case hmac-sha-512 { 602 leaf hmac-sha-512 { 603 type empty; 604 description "HMAC-SHA-512 authentication algorithm."; 605 } 606 } 607 case clear-text { 608 if-feature clear-text; 609 leaf clear-text { 610 type empty; 611 description "Clear text."; 612 } 613 } 614 case replay-protection-only { 615 if-feature replay-protection-only; 616 leaf replay-protection-only { 617 type empty; 618 description 619 "Provide replay-protection without any authentication 620 as required by protocols such as Bidirectional 621 Forwarding Detection (BFD)."; 622 } 623 } 624 } 626 } 628 grouping key-chain { 629 description 630 "key-chain specification grouping."; 631 leaf name { 632 type string; 633 description "Name of the key-chain."; 634 } 636 leaf name-state { 637 type string; 638 config false; 639 description "Configured name of the key-chain."; 640 } 642 leaf description { 643 type string; 644 description "A description of the key-chain"; 645 } 647 container accept-tolerance { 648 if-feature accept-tolerance; 649 description 650 "Tolerance for key lifetime acceptance (seconds)."; 651 leaf duration { 652 type uint32; 653 units seconds; 654 default "0"; 655 description 656 "Tolerance range, in seconds."; 657 } 658 } 660 container accept-tolerance-state { 661 config false; 662 description 663 "Configured tolerance for key lifetime 664 acceptance (seconds)."; 665 leaf duration { 666 type uint32; 667 description 668 "Configured tolerance range, in seconds."; 669 } 670 } 672 leaf last-modified-timestamp { 673 type yang:date-and-time; 674 config false; 675 description "Timestamp of the most recent update 676 to the key-chain"; 677 } 679 list key-chain-entry { 680 key "key-id"; 681 description "One key."; 682 leaf key-id { 683 type uint64; 684 description "Key ID."; 685 } 686 leaf key-id-state { 687 type uint64; 688 config false; 689 description "Configured Key ID."; 690 } 691 container key-string { 692 description "The key string."; 693 choice key-string-style { 694 description 695 "Key string styles"; 696 case keystring { 697 leaf keystring { 698 type string; 699 description "Key string in ASCII format."; 700 } 701 } 702 case hexadecimal { 703 if-feature hex-key-string; 704 leaf hexadecimal-string { 705 type yang:hex-string; 706 description 707 "Key in hexadecimal string format."; 708 } 709 } 710 } 711 } 712 container lifetime { 713 description "Specify a key's lifetime."; 714 choice lifetime { 715 description 716 "Options for specification of send and accept 717 lifetimes."; 718 case send-and-accept-lifetime { 719 description 720 "Send and accept key have the same lifetime."; 721 container send-accept-lifetime { 722 uses lifetime; 723 description 724 "Single lifetime specification for both send and 725 accept lifetimes."; 726 } 727 } 728 case independent-send-accept-lifetime { 729 if-feature independent-send-accept-lifetime; 730 description 731 "Independent send and accept key lifetimes."; 732 container send-lifetime { 733 uses lifetime; 734 description 735 "Separate lifetime specification for send 736 lifetime."; 737 } 738 container accept-lifetime { 739 uses lifetime; 740 description 741 "Separate lifetime specification for accept 742 lifetime."; 743 } 744 } 745 } 746 } 747 container lifetime-state { 748 config false; 749 description "Configured key's lifetime."; 750 container send-lifetime { 751 uses lifetime; 752 description 753 "Configured send-lifetime."; 754 } 755 leaf send-valid { 756 type boolean; 757 description 758 "Status of send-lifetime."; 759 } 760 container accept-lifetime { 761 uses lifetime; 762 description 763 "Configured accept-lifetime."; 764 } 765 leaf accept-valid { 766 type boolean; 767 description 768 "Status of accept-lifetime."; 769 } 771 } 772 container crypto-algorithm { 773 uses crypto-algorithm-types; 774 description "Cryptographic algorithm associated with key."; 775 } 776 container crypto-algorithm-state { 777 config false; 778 uses crypto-algorithm-types; 779 description "Configured cryptographic algorithm."; 780 } 781 } 782 } 784 container key-chains { 785 list key-chain-list { 786 key "name"; 787 description 788 "List of key-chains."; 789 uses key-chain; 790 } 791 container aes-key-wrap { 792 if-feature aes-key-wrap; 793 leaf enable { 794 type boolean; 795 default false; 796 description 797 "Enable AES Key Wrap encryption."; 798 } 799 description 800 "AES Key Wrap password encryption."; 801 } 802 container aes-key-wrap-state { 803 if-feature aes-key-wrap; 804 config false; 805 leaf enable { 806 type boolean; 807 description "AES Key Wrap state."; 808 } 809 description "Status of AES Key Wrap."; 810 } 811 description "All configured key-chains for the device."; 812 } 813 } 814 816 5. Relationship to other Work 818 6. Security Considerations 820 This document enables the automated distribution of industry standard 821 key chains using the NETCONF [NETCONF] protocol. As such, the 822 security considerations for the NETCONF protocol are applicable. 823 Given that the key chains themselves are sensitive data, it is 824 RECOMMENDED that the NETCONF communication channel be encrypted. One 825 way to do accomplish this would be to invoke and run NETCONF over SSH 826 as described in [NETCONF-SSH]. 828 When configured, the key-strings can be encrypted using the AES Key 829 Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) is 830 not included in the YANG model and must be set or derived independent 831 of key-chain configuration. 833 The key strings are not included in the operational state. This is a 834 practice carried over from SNMP MIB modules and is an area for 835 further discussion. 837 The clear-text algorithm is included as a YANG feature. Usage is NOT 838 RECOMMENDED except in cases where the application and device have no 839 other alternative (e.g., a legacy network device that must 840 authenticate packets at intervals of 10 milliseconds or less for many 841 peers using Bidirectional Forwarding Detection [BFD]). Keys used 842 with the clear-text algorithm are considered insecure and SHOULD NOT 843 be reused with more secure algorithms. 845 7. IANA Considerations 847 This document registers a URI in the IETF XML registry 848 [XML-REGISTRY]. Following the format in RFC 3688, the following 849 registration is requested to be made: 851 URI: urn:ietf:params:xml:ns:yang:ietf-key-chain 853 Registrant Contact: The IESG. 855 XML: N/A, the requested URI is an XML namespace. 857 This document registers a YANG module in the YANG Module Names 858 registry [YANG]. 860 name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-key- 861 chain prefix: ietf-key-chain reference: RFC XXXX 863 8. References 865 8.1. Normative References 867 [NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 868 Bierman, "Network Configuration Protocol (NETCONF)", RFC 869 6241, June 2011. 871 [NETCONF-SSH] 872 Wasserman, M., "Using NETCONF Protocol over Secure Shell 873 (SSH)", RFC 6242, June 2011. 875 [RFC-KEYWORDS] 876 Bradner, S., "Key words for use in RFC's to Indicate 877 Requirement Levels", BCP 14, RFC 2119, March 1997. 879 [XML-REGISTRY] 880 Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 881 January 2004. 883 [YANG] Bjorklund, M., "YANG - A Data Modeling Language for the 884 Network Configuration Protocol (NETCONF)", RFC 6020, 885 October 2010. 887 8.2. Informative References 889 [AES-KEY-WRAP] 890 Housley, R. and M. Dworkin, "Advanced Encryption Standard 891 (AES) Key Wrap with Padding Algorithm", RFC 5649, August 892 2009. 894 [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 895 (BFD)", RFC 5880, June 2010. 897 [CRYPTO-KEYTABLE] 898 Housley, R., Polk, T., Hartman, S., and D. Zhang, 899 "Table of Cryptographic Keys", RFC 7210, April 2014. 901 [IAB-REPORT] 902 Andersson, L., Davies, E., and L. Zhang, "Report from the 903 IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 904 4948, August 2007. 906 [NETCONF-SERVER-CONF] 907 Watsen, K. and J. Schoenwaelder, "NETCONF Server and 908 RESTCONF Server Configuration Models", draft-ietf-netconf- 909 server-model-08.txt (work in progress), October 2015. 911 [NTP-PROTO] 912 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 913 Time Protocol Version 4: Protocol and Algorithms 914 Specification", RFC 5905, June 2010. 916 [OSPFV3-AUTH] 917 Bhatia, M., Manral, V., and A. Lindem, "Supporting 918 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 920 [TCP-AO-ALGORITHMS] 921 Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 922 for the TCP Authentication Option (TCP-AO)", RFC 5926, 923 June 2010. 925 [YANG-CRYPTO-KEYTABLE] 926 Chen, I., "YANG Data Model for RFC 7210 Key Table", draft- 927 chen-rtg-key-table-yang-02.txt (work in progress), 928 November 2015. 930 Appendix A. Acknowledgments 932 The RFC text was produced using Marshall Rose's xml2rfc tool. 934 Thanks to Brian Weis for fruitful discussions on security 935 requirements. 937 Authors' Addresses 939 Acee Lindem (editor) 940 Cisco Systems 941 301 Midenhall Way 942 Cary, NC 27513 943 USA 945 Email: acee@cisco.com 947 Yingzhen Qu 948 Cisco Systems 949 170 West Tasman Drive 950 San Jose, CA 95134 951 USA 953 Email: yiqu@cisco.com 954 Derek Yeung 955 Cisco Systems 956 170 West Tasman Drive 957 San Jose, CA 95134 958 USA 960 Email: myeung@cisco.com 962 Ing-Wher Chen 963 Ericsson 965 Email: ichen@kuatrotech.com 967 Jeffrey Zhang 968 Juniper Networks 969 10 Technology Park Drive 970 Westford, MA 01886 971 USA 973 Email: zzhang@juniper.net 975 Yi Yang 976 Cisco Systems 977 7025 Kit Creek Road 978 Research Triangle Park, NC 27709 979 USA 981 Email: yiya@cisco.com