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