idnits 2.17.1 draft-acee-rtg-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 date (March 3, 2015) is 3341 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 4, 2015 Cisco Systems 6 I. Chen 7 Ericsson 8 J. Zhang 9 Juniper Networks 10 Y. Yang 11 Cisco Systems 12 March 3, 2015 14 Key Chain YANG Data Model 15 draft-acee-rtg-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 4, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 66 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Graceful Key Rollover using Key Chains . . . . . . . . . 3 68 3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 4 69 4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 10 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 74 7.2. Informative References . . . . . . . . . . . . . . . . . 16 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 78 1. Introduction 80 This document describes the key chain YANG data model. A key chain 81 is a list of elements each containing a key, send lifetime, accept 82 lifetime, and algorithm. By properly overlapping the send and accept 83 lifetimes of multiple key chain elements, keys and algorithms may be 84 gracefully updated. By representing them in a YANG data model, key 85 distribution can be automated. Key chains are commonly used for 86 routing protocol authentication and other applications. In some 87 applications, the protocols do not use the key chain element key 88 directly, but rather a key derivation function is used to derive a 89 short-lived key from the key chain element key. 91 1.1. Requirements Notation 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC-KEYWORDS]. 97 2. Problem Statement 99 This document describes a YANG [YANG] data model for key chains. Key 100 chains have been implemented and deployed by a large percentage of 101 network equipment vendors. Providing a standard YANG model will 102 facilitate automated key distribution and non-disruptive key 103 rollover. This will aid in tightening the security of the core 104 routing infrastructure as recommended in [IAB-REPORT]. 106 A key chain is a list of containing one or more elements containing a 107 Key ID, key, send/accept lifetimes, and the associated authentication 108 or encryption algorithm. A conceptual representation of a crypto key 109 table is described in [CRYPTO-KEYTABLE]. The key chain model 110 presented herein represents a practical implementation of the crypto 111 key table. However, the key selection is left to the applications 112 requiring authentication or encryption. This is more inline with the 113 current operational model. 115 2.1. Graceful Key Rollover using Key Chains 117 Key chains may be used to gracefully update the key and/or algorithm 118 used by an application for authentication or encryption. This MAY be 119 accomplished by accepting all the keys that have a valid accept 120 lifetime and sending the key with the most recent send lifetime. One 121 scenario for facilitating key rollover is to: 123 1. Distribute a key chain with a new key to all the routers or other 124 network devices in the domain of that key chain. The new key's 125 accept lifetime should be such that it is accepted during the key 126 rollover period. The send lifetime should be a time in the 127 future when it can be assured that all the routers in the domain 128 of that key are upgraded. This will have no immediate impact on 129 the keys used for transmission. 131 2. Assure that all the network devices have been updated with the 132 updated key chain and that their system times are roughly 133 synchronized. The system times of devices within an 134 administrative domain are commonly synchronized (e.g., using 135 Network Time Protocol (NTP) [NTP-PROTO]). This also may be 136 automated. 138 3. When the send lifetime of the new key becomes valid, the network 139 devices within the domain of key chain will start sending the new 140 key. 142 4. At some point in the future, a new key chain with the old key 143 removed may be distributed to the network devices within the 144 domain of the key chain. However, this may be deferred until the 145 next key rollover. If this is done, the key chain will always 146 include two keys; either the current and future key (during key 147 rollovers) or the current and previous keys (between key 148 rollovers). 150 3. Design of the Key Chain Model 152 The ietf-keychain module contains a list of one or more keys indexed 153 by a Key ID. For some applications (e.g., OSPFv3 [OSPFV3-AUTH]), the 154 Key-Id is used to identify the key chain element to be used. In 155 addition to the Key-ID, each key chain element includes a key-string 156 and a cryptographic algorithm. Optionally, the key chain entries 157 include send/accept lifetimes. If the send/accept lifetime is 158 unspecified, the key is always considered valid. 160 Note that asymmetric keys, i.e., a different key value used for 161 transmission versus acceptance, may be supported with multiple key 162 chain elements where the accept-lifetime or send-lifetime is not 163 valid (e.g., has an end-time equal to the start-time). 165 Due to the differences in key chain implementations across various 166 vendors, some of the data elements are optional. Additionally, the 167 key-chain is made a grouping so that an implementation could support 168 scoping other than at the global level. 170 A key-chain is identified by a unique name within the scope of the 171 network device. The "key-chain-ref" typedef SHOULD be used by other 172 YANG modules when they need to reference a configured key-chain. 174 module ietf-key-chain { 175 namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain"; 176 // replace with IANA namespace when assigned 177 prefix "key-chain"; 179 import ietf-yang-types { 180 prefix "yang"; 181 } 183 organization 184 "Cisco Systems 185 170 West Tasman Drive 186 San Jose, CA 95134-1706 187 USA"; 188 contact 189 "Acee Lindem - acee@cisco.com"; 191 description 192 "This YANG module defines the generic configuration 193 data for key-chain. It is intended that the module 194 will be extended by vendors to define vendor-specific 195 key-chain configuration parameters. 196 "; 198 revision 2015-02-24 { 199 description 200 "Initial revision."; 201 reference 202 "RFC XXXX: A YANG Data Model for key-chain"; 203 } 205 typedef key-chain-ref { 206 type leafref { 207 path "/key-chain:key-chains/key-chain:name"; 208 } 209 description 210 "This type is used by data models that need to reference 211 configured key-chains."; 212 } 214 feature hex-key-string { 215 description 216 "Support hexadecimal key string."; 217 } 219 feature accept-tolerance { 220 description 221 "To specify the tolerance or acceptance limit."; 222 } 224 feature independent-send-accept-lifetime { 225 description 226 "Support for independent send and accept key lifetimes."; 227 } 229 grouping lifetime { 230 description 231 "Key lifetime specification."; 232 choice lifetime { 233 default always; 234 description 235 "Options for specifying key accept or send lifetimes"; 236 case always { 237 leaf always { 238 type empty; 239 description 240 "Indicates key lifetime is always valid."; 241 } 242 } 243 case start-end-time { 244 leaf start-date-time { 245 type yang:date-and-time; 246 description "Start time."; 247 } 248 choice end-time { 249 default infinite; 250 description 251 "End-time setting."; 252 case infinite { 253 leaf no-end-time { 254 type empty; 255 description 256 "Indicates key lifetime end-time in infinite."; 257 } 258 } 259 case duration { 260 leaf duration { 261 type uint32 { 262 range "1..2147483646"; 263 } 264 units seconds; 265 description "Key lifetime duration, in seconds"; 266 } 267 } 268 case end-date-time { 269 leaf end-date-time { 270 type yang:date-and-time; 271 description "End time."; 272 } 273 } 274 } 275 } 276 } 277 } 279 grouping key-chain { 280 description 281 "Grouping for one key-chain."; 283 leaf name { 284 type string; 285 description "Name of the key-chain."; 286 } 288 container accept-tolerance { 289 if-feature accept-tolerance; 290 description 291 "Tolerance for key lifetime acceptance (seconds)."; 292 leaf duration { 293 type uint32; 294 units seconds; 295 default "0"; 296 description 297 "Tolerance range, in seconds."; 298 } 299 } 301 list key { 302 key "key-id"; 303 description "One key."; 304 leaf key-id { 305 type uint64; 306 description "Key id."; 307 } 308 container key-string { 309 description "The key string."; 310 choice key-string-style { 311 description 312 "Key string styles"; 313 case keystring { 314 leaf keystring { 315 type string; 316 description "Key string in ASCII format."; 317 } 318 } 319 case hexadecimal { 320 if-feature hex-key-string; 321 leaf hexadecimal-string { 322 type yang:hex-string; 323 description 324 "Key in hexadecimal string format."; 325 } 326 } 327 } 328 } 329 container lifetime { 330 description "Specify a key's lifetime."; 331 choice lifetime { 332 description 333 "Options for specification of send and accept 334 lifetimes."; 335 case send-and-accept-lifetime { 336 description 337 "Send and accept key have the same lifetime."; 338 container send-accept-lifetime { 339 uses lifetime; 340 description 341 "Single lifetime specification for both send and 342 accept lifetimes."; 343 } 344 } 345 case independent-send-accept-lifetime { 346 if-feature independent-send-accept-lifetime; 347 description 348 "Independent send and accept key lifetimes."; 349 container send-lifetime { 350 uses lifetime; 351 description 352 "Separate lifetime specification for send 353 lifetime."; 354 } 355 container accept-lifetime { 356 uses lifetime; 357 description 358 "Separate lifetime specification for accept 359 lifetime."; 360 } 361 } 362 } 363 } 365 container crypto-algorithm { 366 choice algorithm { 367 description 368 "Options for crytographic algorithm specification."; 369 case hmac-sha1-12 { 370 leaf hmac-sha1-12 { 371 type empty; 372 description "The HMAC-SHA1-12 algorithm."; 373 } 374 } 375 case hmac-sha1-20 { 376 leaf hmac-sha1-20 { 377 type empty; 378 description "The HMAC-SHA1-20 algorithm."; 380 } 381 } 382 case md5 { 383 leaf md5 { 384 type empty; 385 description "The MD5 algorithm."; 386 } 387 } 388 case sha-1 { 389 leaf sha-1 { 390 type empty; 391 description "The SHA-1 algorithm."; 392 } 393 } 394 case hmac-sha-1 { 395 leaf hmac-sha-1 { 396 type empty; 397 description "HMAC-SHA-1 authentication algorithm."; 398 } 399 } 400 case hmac-sha-256 { 401 leaf hmac-sha-256 { 402 type empty; 403 description "HMAC-SHA-256 authentication algorithm."; 404 } 405 } 406 case hmac-sha-384 { 407 leaf hmac-sha-384 { 408 type empty; 409 description "HMAC-SHA-384 authentication algorithm."; 410 } 411 } 412 case hmac-sha-512 { 413 leaf hmac-sha-512 { 414 type empty; 415 description "HMAC-SHA-512 authentication algorithm."; 416 } 417 } 418 } 419 description "The crypto algorithm used."; 420 } 421 } 422 } 424 list key-chains { 425 key "name"; 426 description 427 "A key-chain is a sequence of keys that are collectively 428 managed for authentication."; 429 uses key-chain; 430 } 431 } 433 4. Key Chain YANG Model 435 module ietf-key-chain { 436 namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain"; 437 // replace with IANA namespace when assigned 438 prefix key-chain; 440 import ietf-yang-types { 441 prefix "yang"; 442 } 444 organization 445 "Cisco Systems 446 170 West Tasman Drive 447 San Jose, CA 95134-1706 448 USA"; 449 contact 450 "Acee Lindem - acee@cisco.com"; 452 description 453 "This YANG module defines the generic configuration 454 data for key-chain. It is intended that the module 455 will be extended by vendors to define vendor-specific 456 key-chain configuration parameters. 457 "; 459 revision 2015-02-24 { 460 description 461 "Initial revision."; 462 reference 463 "RFC XXXX: A YANG Data Model for key-chain"; 464 } 466 feature hex-key-string { 467 description 468 "Support hexadecimal key string."; 469 } 471 feature accept-tolerance { 472 description 473 "To specify the tolerance or acceptance limit."; 474 } 475 feature independent-send-accept-lifetime { 476 description 477 "Support for independent send and accept key lifetimes."; 478 } 480 grouping lifetime { 481 description 482 "Key lifetime specification."; 483 choice lifetime { 484 default always; 485 case always { 486 leaf always { 487 type empty; 488 } 489 description 490 "Key is always valid."; 491 } 492 case start-end-time { 493 leaf start-date-time { 494 type yang:date-and-time; 495 description "Start time."; 496 } 497 choice end-time { 498 default infinite; 499 description 500 "End-time setting."; 501 case infinite { 502 leaf no-end-time { 503 type empty; 504 } 505 description 506 "Never expires."; 507 } 508 case duration { 509 leaf duration { 510 type uint32 { 511 range "1..2147483646"; 512 } 513 units seconds; 514 description "Key lifetime duration, in seconds"; 515 } 516 } 517 case end-date-time { 518 leaf end-date-time { 519 type yang:date-and-time; 520 description "End time."; 521 } 522 } 524 } 525 } 526 } 527 } 529 grouping key-chain { 530 description 531 "Grouping for one key-chain."; 533 leaf name { 534 type string; 535 description "Name of the key-chain."; 536 } 538 container accept-tolerance { 539 if-feature accept-tolerance; 540 leaf duration { 541 type uint32; 542 units seconds; 543 default "0"; 544 description 545 "Tolerance range, in seconds."; 546 } 547 } 549 list key { 550 key "key-id"; 551 description "One key."; 552 leaf key-id { 553 type uint64; 554 description "Key id."; 555 } 556 container key-string { 557 description "The key string."; 558 choice key-string-style { 559 description 560 "Key string styles"; 561 case keystring { 562 leaf keystring { 563 type string; 564 } 565 } 566 case hexadecimal { 567 if-feature hex-key-string; 568 leaf hexadecimal-string { 569 type yang:hex-string; 570 description 571 "Hexadecimal string."; 573 } 574 } 575 } 576 } 577 container lifetime { 578 description "Specify a key's lifetime."; 579 choice lifetime { 580 case send-and-accept-lifetime { 581 description 582 "Send and accept key have the same lifetime."; 583 container send-accept-lifetime { 584 uses lifetime; 585 } 586 } 587 case independent-send-accept-lifetime { 588 if-feature independent-send-accept-lifetime; 589 description 590 "Independent send and accept key lifetimes."; 591 container send-lifetime { 592 uses lifetime; 593 } 594 container accept-lifetime { 595 uses lifetime; 596 } 597 } 598 } 599 } 601 container crypto-algorithm { 602 choice algorithm { 603 case hmac-sha1-12 { 604 leaf hmac-sha1-12 { 605 type empty; 606 description "The HMAC-SHA1-12 algorithm."; 607 } 608 } 609 case hmac-sha1-20 { 610 leaf hmac-sha1-20 { 611 type empty; 612 description "The HMAC-SHA1-20 algorithm."; 613 } 614 } 615 case md5 { 616 leaf md5 { 617 type empty; 618 description "The MD5 algorithm."; 619 } 620 } 621 case sha-1 { 622 leaf sha-1 { 623 type empty; 624 description "The SHA-1 algorithm."; 625 } 626 } 627 case hmac-sha-1 { 628 leaf hmac-sha-1 { 629 type empty; 630 description "HMAC-SHA-1 authentication algorithm."; 631 } 632 } 633 case hmac-sha-256 { 634 leaf hmac-sha-256 { 635 type empty; 636 description "HMAC-SHA-256 authentication algorithm."; 637 } 638 } 639 case hmac-sha-384 { 640 leaf hmac-sha-384 { 641 type empty; 642 description "HMAC-SHA-384 authentication algorithm."; 643 } 644 } 645 case hmac-sha-512 { 646 leaf hmac-sha-512 { 647 type empty; 648 description "HMAC-SHA-512 authentication algorithm."; 649 } 650 } 651 } 652 description "The crypto algorithm used."; 653 } 654 } 655 } 657 list key-chains { 658 key "name"; 659 description 660 "A key-chain is a sequence of keys that are collectively 661 managed for authentication."; 662 uses key-chain; 663 } 664 } 666 5. Security Considerations 668 This document enables the automated distribution of industry standard 669 key chains using the NETCONF [NETCONF] protocol. As such, the 670 security considerations for the NETCONF protocol are applicable. 671 Given that the key chains themselves are sensitive data, it is 672 RECOMMENDED that the NETCONF communication channel be encrypted. One 673 way to do accomplish this would be to invoke and run NETCONF over SSH 674 as described in [NETCONF-SSH]. 676 6. IANA Considerations 678 This document registers a URI in the IETF XML registry 679 [XML-REGISTRY]. Following the format in RFC 3688, the following 680 registration is requested to be made: 682 URI: urn:ietf:params:xml:ns:yang:ietf-key-chain 684 Registrant Contact: The IESG. 686 XML: N/A, the requested URI is an XML namespace. 688 This document registers a YANG module in the YANG Module Names 689 registry [YANG]. 691 name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-key- 692 chain prefix: ietf-key-chain reference: RFC XXXX 694 7. References 696 7.1. Normative References 698 [NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 699 Bierman, "Network Configuration Protocol (NETCONF)", RFC 700 6241, June 2011. 702 [NETCONF-SSH] 703 Wasserman, M., "Using NETCONF Protocol over Secure Shell 704 (SSH)", RFC 6242, June 2011. 706 [RFC-KEYWORDS] 707 Bradner, S., "Key words for use in RFC's to Indicate 708 Requirement Levels", BCP 14, RFC 2119, March 1997. 710 [XML-REGISTRY] 711 Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 712 January 2004. 714 [YANG] Bjorklund, M., "YANG - A Data Modeling Language for the 715 Network Configuration Protocol (NETCONF)", RFC 6020, 716 October 2010. 718 7.2. Informative References 720 [CRYPTO-KEYTABLE] 721 Housley, R., Polk, T., Hartman, S., and D. Zhang, 722 "Table of Cryptographic Keys", RFC 7210, April 2014. 724 [IAB-REPORT] 725 Andersson, L., Davies, E., and L. Zhang, "Report from the 726 IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 727 4948, August 2007. 729 [NTP-PROTO] 730 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 731 Time Protocol Version 4: Protocol and Algorithms 732 Specification", RFC 5905, June 2010. 734 [OSPFV3-AUTH] 735 Bhatia, M., Manral, V., and A. Lindem, "Supporting 736 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 738 Appendix A. Acknowledgments 740 The RFC text was produced using Marshall Rose's xml2rfc tool. 742 Authors' Addresses 744 Acee Lindem (editor) 745 Cisco Systems 746 301 Midenhall Way 747 Cary, NC 27513 748 USA 750 Email: acee@cisco.com 752 Yingzhen Qu 753 Cisco Systems 754 170 West Tasman Drive 755 San Jose, CA 95134 756 USA 758 Email: yiqu@cisco.com 759 Derek Yeung 760 Cisco Systems 761 170 West Tasman Drive 762 San Jose, CA 95134 763 USA 765 Email: myeung@cisco.com 767 Ing-Wher Chen 768 Ericsson 770 Email: ing-wher.chen@ericsson.com 772 Jeffrey Zhang 773 Juniper Networks 774 10 Technology Park Drive 775 Westford, MA 01886 776 USA 778 Email: zzhang@juniper.net 780 Yi Yang 781 Cisco Systems 782 7025 Kit Creek Road 783 Research Triangle Park, NC 27709 784 USA 786 Email: yiya@cisco.com