idnits 2.17.00 (12 Aug 2021) /tmp/idnits16167/draft-ietf-rtgwg-yang-key-chain-21.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 (April 26, 2017) is 1851 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) ** Obsolete normative reference: RFC 6536 (ref. 'NETCONF-ACM') (Obsoleted by RFC 8341) == Outdated reference: draft-ietf-netmod-revised-datastores has been published as RFC 8342 -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track Y. Qu 5 Expires: October 28, 2017 Huawei 6 D. Yeung 7 Arrcus, Inc 8 I. Chen 9 Jabil 10 J. Zhang 11 Juniper Networks 12 April 26, 2017 14 Routing Key Chain YANG Data Model 15 draft-ietf-rtgwg-yang-key-chain-21.txt 17 Abstract 19 This document describes the key chain YANG data model. Key chains 20 are commonly used for routing protocol authentication and other 21 applications requiring symmetric keys. A key chain is a list of 22 elements each containing a key string, send lifetime, accept 23 lifetime, and algorithm (authentication or encryption). By properly 24 overlapping the send and accept lifetimes of multiple key chain 25 elements, key strings and algorithms may be gracefully updated. By 26 representing them in a YANG data model, key distribution can be 27 automated. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 28, 2017. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 65 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 68 2.2. Graceful Key Rollover using Key Chains . . . . . . . . . 4 69 3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 5 70 3.1. Key Chain Operational State . . . . . . . . . . . . . . . 6 71 3.2. Key Chain Model Features . . . . . . . . . . . . . . . . 6 72 3.3. Key Chain Model Tree . . . . . . . . . . . . . . . . . . 6 73 4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 8 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 79 8.2. Informative References . . . . . . . . . . . . . . . . . 17 80 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 81 A.1. Simple Key Chain with Always Valid Single Key . . . . . . 19 82 A.2. Key Chain with Keys having Different Lifetimes . . . . . 19 83 A.3. Key Chain with Independent Send and Accept Lifetimes . . 21 84 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 22 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 87 1. Introduction 89 This document describes the key chain YANG [YANG] data model. Key 90 chains are commonly used for routing protocol authentication and 91 other applications requiring symmetric keys. A key chain is a list 92 of elements each containing a key string, send lifetime, accept 93 lifetime, and algorithm (authentication or encryption). By properly 94 overlapping the send and accept lifetimes of multiple key chain 95 elements, key strings and algorithms may be gracefully updated. By 96 representing them in a YANG data model, key distribution can be 97 automated. 99 In some applications, the protocols do not use the key chain element 100 key directly, but rather a key derivation function is used to derive 101 a short-lived key from the key chain element key (e.g., the Master 102 Keys used in [TCP-AO]). 104 1.1. Requirements Notation 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in 109 [RFC-KEYWORDS]. 111 1.2. Tree Diagrams 113 A simplified graphical representation of the complete data tree is 114 presented in Section 3.3. The following tree notation is used. 116 o Brackets "[" and "]" enclose YANG list keys. These YANG list keys 117 should not be confused with the key-chain keys. 119 o Curly braces "{" and "}" contain names of optional features that 120 make the corresponding node conditional. 122 o Abbreviations before data node names: "rw" means configuration 123 (read-write), "ro" state data (read-only), "-x" RPC operations, 124 and "-n" notifications. 126 o Symbols after data node names: "?" means an optional node, "!" a 127 container with presence, and "*" denotes a "list" or "leaf-list". 129 o Parentheses enclose choice and case nodes, and case nodes are also 130 marked with a colon (":"). 132 o Ellipsis ("...") stands for contents of subtrees that are not 133 shown. 135 2. Problem Statement 137 This document describes a YANG [YANG] data model for key chains. Key 138 chains have been implemented and deployed by a large percentage of 139 network equipment vendors. Providing a standard YANG model will 140 facilitate automated key distribution and non-disruptive key 141 rollover. This will aid in tightening the security of the core 142 routing infrastructure as recommended in [IAB-REPORT]. 144 A key chain is a list containing one or more elements containing a 145 Key ID, key string, send/accept lifetimes, and the associated 146 authentication or encryption algorithm. A key chain can be used by 147 any service or application requiring authentication or encryption 148 using symmetric keys. In essence, the key-chain is a reusable key 149 policy that can be referenced wherever it is required. The key-chain 150 construct has been implemented by most networking vendors and 151 deployed in many networks. 153 A conceptual representation of a crypto key table is described in 154 [CRYPTO-KEYTABLE]. The crypto key table also includes keys as well 155 as their corresponding lifetimes and algorithms. Additionally, the 156 key table includes key selection criteria and envisions a deployment 157 model where the details of the applications or services requiring 158 authentication or encryption permeate into the key database. The 159 YANG key-chain model described herein doesn't include key selection 160 criteria or support this deployment model. At the same time, it does 161 not preclude it. The draft [YANG-CRYPTO-KEYTABLE] describes 162 augmentations to the key chain YANG model in support of key selection 163 criteria. 165 2.1. Applicability 167 Other YANG modules may reference ietf-key-chain YANG module key-chain 168 names for authentication and encryption applications. A YANG type 169 has been provided to facilitate reference to the key-chain name 170 without having to specify the complete YANG XML Path Language (XPath) 171 selector. 173 2.2. Graceful Key Rollover using Key Chains 175 Key chains may be used to gracefully update the key string and/or 176 algorithm used by an application for authentication or encryption. 177 To achieve graceful key rollover, the receiver MAY accept all the 178 keys that have a valid accept lifetime and the sender MAY send the 179 key with the most recent send lifetime. One scenario for 180 facilitating key rollover is to: 182 1. Distribute a key chain with a new key to all the routers or other 183 network devices in the domain of that key chain. The new key's 184 accept lifetime should be such that it is accepted during the key 185 rollover period. The send lifetime should be a time in the 186 future when it can be assured that all the routers in the domain 187 of that key are upgraded. This will have no immediate impact on 188 the keys used for transmission. 190 2. Assure that all the network devices have been updated with the 191 updated key chain and that their system times are roughly 192 synchronized. The system times of devices within an 193 administrative domain are commonly synchronized (e.g., using 194 Network Time Protocol (NTP) [NTP-PROTO]). This also may be 195 automated. 197 3. When the send lifetime of the new key becomes valid, the network 198 devices within the domain of key chain will using the new key for 199 transmissions. 201 4. At some point in the future, a new key chain with the old key 202 removed may be distributed to the network devices within the 203 domain of the key chain. However, this may be deferred until the 204 next key rollover. If this is done, the key chain will always 205 include two keys; either the current and future key (during key 206 rollovers) or the current and previous keys (between key 207 rollovers). 209 Since the most recent send lifetime is defined as the one with the 210 latest start-time, specification of "always" will prevent using the 211 graceful key rollover technique described above. Other key 212 configuration and usage scenarios are possible but these are beyond 213 the scope of this document. 215 3. Design of the Key Chain Model 217 The ietf-key-chain module contains a list of one or more keys indexed 218 by a Key ID. For some applications (e.g., OSPFv3 [OSPFV3-AUTH]), the 219 Key ID is used to identify the key chain key to be used. In addition 220 to the Key ID, each key chain key includes a key-string and a 221 cryptographic algorithm. Optionally, the key chain keys include 222 send/accept lifetimes. If the send/accept lifetime is unspecified, 223 the key is always considered valid. 225 Note that different key values for transmission versus acceptance may 226 be supported with multiple key chain elements. The key used for 227 transmission will have a valid send-lifetime and invalid accept- 228 lifetime (e.g., has an end-time equal to the start-time). The key 229 used for acceptance will have a valid accept-lifetime and invalid 230 send-lifetime. 232 Due to the differences in key chain implementations across various 233 vendors, some of the data elements are optional. Finally, the crypto 234 algorithm identities are provided for reuse when configuring legacy 235 authentication and encryption not using key-chains. 237 A key-chain is identified by a unique name within the scope of the 238 network device. The "key-chain-ref" typedef SHOULD be used by other 239 YANG modules when they need to reference a configured key-chain. 241 3.1. Key Chain Operational State 243 The key chain operational state is included in the same tree as key 244 chain configuration consistent with Network Management Datastore 245 Architecture [NMDA]. The timestamp of the last key chain 246 modification is also maintained in the operational state. 247 Additionally, the operational state includes an indication of whether 248 or not a key chain key is valid for sending or acceptance. 250 3.2. Key Chain Model Features 252 Features are used to handle differences between vendor 253 implementations. For example, not all vendors support configuration 254 of an acceptance tolerance or configuration of key strings in 255 hexadecimal. They are also used to support of security requirements 256 (e.g., TCP-AO Algorithms [TCP-AO-ALGORITHMS]) not yet implemented by 257 vendors or only a single vendor. 259 3.3. Key Chain Model Tree 261 +--rw key-chains 262 +--rw key-chain* [name] 263 +--rw name string 264 +--rw description? string 265 +--rw accept-tolerance {accept-tolerance}? 266 | +--rw duration? uint32 267 +--ro last-modified-timestamp? yang:date-and-time 268 +--rw key* [key-id] 269 +--rw key-id uint64 270 +--rw lifetime 271 | +--rw (lifetime)? 272 | +--:(send-and-accept-lifetime) 273 | | +--rw send-accept-lifetime 274 | | +--rw (lifetime)? 275 | | +--:(always) 276 | | | +--rw always? empty 277 | | +--:(start-end-time) 278 | | +--rw start-date-time? 279 | | | yang:date-and-time 280 | | +--rw (end-time)? 281 | | +--:(infinite) 282 | | | +--rw no-end-time? empty 283 | | +--:(duration) 284 | | | +--rw duration? uint32 285 | | +--:(end-date-time) 286 | | +--rw end-date-time? 287 | | yang:date-and-time 288 | +--:(independent-send-accept-lifetime) 289 | | {independent-send-accept-lifetime}? 290 | +--rw send-lifetime 291 | | +--rw (lifetime)? 292 | | +--:(always) 293 | | | +--rw always? empty 294 | | +--:(start-end-time) 295 | | +--rw start-date-time? 296 | | yang:date-and-time 297 | | +--rw (end-time)? 298 | | +--:(infinite) 299 | | | +--rw no-end-time? empty 300 | | +--:(duration) 301 | | | +--rw duration? uint32 302 | | +--:(end-date-time) 303 | | +--rw end-date-time? 304 | | yang:date-and-time 305 | +--rw accept-lifetime 306 | +--rw (lifetime)? 307 | +--:(always) 308 | | +--rw always? empty 309 | +--:(start-end-time) 310 | +--rw start-date-time? 311 | | yang:date-and-time 312 | +--rw (end-time)? 313 | +--:(infinite) 314 | | +--rw no-end-time? empty 315 | +--:(duration) 316 | | +--rw duration? uint32 317 | +--:(end-date-time) 318 | +--rw end-date-time? 319 | yang:date-and-time 320 +--rw crypto-algorithm identityref 321 +--rw key-string 322 | +--rw (key-string-style)? 323 | +--:(keystring) 324 | | +--rw keystring? string 325 | +--:(hexadecimal) {hex-key-string}? 326 | +--rw hexadecimal-string? yang:hex-string 327 +--ro send-lifetime-active? boolean 328 +--ro accept-lifetime-active? boolean 330 4. Key Chain YANG Model 332 file "ietf-key-chain@2017-04-18.yang" 333 module ietf-key-chain { 334 yang-version 1.1; 335 namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain"; 336 prefix key-chain; 338 import ietf-yang-types { 339 prefix yang; 340 } 341 import ietf-netconf-acm { 342 prefix nacm; 343 } 345 organization 346 "IETF RTG (Routing) Working Group"; 347 contact 348 "Acee Lindem - acee@cisco.com"; 349 description 350 "This YANG module defines the generic configuration 351 data for key-chain. It is intended that the module 352 will be extended by vendors to define vendor-specific 353 key-chain configuration parameters. 355 Copyright (c) 2017 IETF Trust and the persons identified as 356 authors of the code. All rights reserved. 358 Redistribution and use in source and binary forms, with or 359 without modification, is permitted pursuant to, and subject 360 to the license terms contained in, the Simplified BSD License 361 set forth in Section 4.c of the IETF Trust's Legal Provisions 362 Relating to IETF Documents 363 (http://trustee.ietf.org/license-info). 364 This version of this YANG module is part of RFC XXXX; see 365 the RFC itself for full legal notices."; 367 revision 2017-04-18 { 368 description 369 "Initial RFC Revision"; 370 reference "RFC XXXX: A YANG Data Model for key-chain"; 371 } 373 feature hex-key-string { 374 description 375 "Support hexadecimal key string."; 376 } 377 feature accept-tolerance { 378 description 379 "Support the tolerance or acceptance limit."; 380 } 382 feature independent-send-accept-lifetime { 383 description 384 "Support for independent send and accept key lifetimes."; 385 } 387 feature crypto-hmac-sha-1-12 { 388 description 389 "Support for TCP HMAC-SHA-1 12 byte digest hack."; 390 } 392 feature clear-text { 393 description 394 "Support for clear-text algorithm. Usage is 395 NOT RECOMMENDED."; 396 } 398 feature aes-cmac-prf-128 { 399 description 400 "Support for AES Cipher based Message Authentication 401 Code Pseudo Random Function."; 402 } 404 feature replay-protection-only { 405 description 406 "Provide replay-protection without any authentication 407 as required by protocols such as Bidirectional 408 Forwarding Detection (BFD)."; 409 } 410 identity crypto-algorithm { 411 description 412 "Base identity of cryptographic algorithm options."; 413 } 415 identity hmac-sha-1-12 { 416 base crypto-algorithm; 417 if-feature "crypto-hmac-sha-1-12"; 418 description 419 "The HMAC-SHA1-12 algorithm."; 420 } 422 identity aes-cmac-prf-128 { 423 base crypto-algorithm; 424 if-feature "aes-cmac-prf-128"; 425 description 426 "The AES-CMAC-PRF-128 algorithm - required by 427 RFC 5926 for TCP-AO key derivation functions."; 428 } 430 identity md5 { 431 base crypto-algorithm; 432 description 433 "The MD5 algorithm."; 434 } 436 identity sha-1 { 437 base crypto-algorithm; 438 description 439 "The SHA-1 algorithm."; 440 } 442 identity hmac-sha-1 { 443 base crypto-algorithm; 444 description 445 "HMAC-SHA-1 authentication algorithm."; 446 } 448 identity hmac-sha-256 { 449 base crypto-algorithm; 450 description 451 "HMAC-SHA-256 authentication algorithm."; 452 } 454 identity hmac-sha-384 { 455 base crypto-algorithm; 456 description 457 "HMAC-SHA-384 authentication algorithm."; 458 } 460 identity hmac-sha-512 { 461 base crypto-algorithm; 462 description 463 "HMAC-SHA-512 authentication algorithm."; 464 } 466 identity clear-text { 467 base crypto-algorithm; 468 if-feature "clear-text"; 469 description 470 "Clear text."; 471 } 472 identity replay-protection-only { 473 base crypto-algorithm; 474 if-feature "replay-protection-only"; 475 description 476 "Provide replay-protection without any authentication as 477 required by protocols such as Bidirectional Forwarding 478 Detection (BFD)."; 479 } 481 typedef key-chain-ref { 482 type leafref { 483 path 484 "/key-chain:key-chains/key-chain:key-chain/key-chain:name"; 485 } 486 description 487 "This type is used by data models that need to reference 488 configured key-chains."; 489 } 491 grouping lifetime { 492 description 493 "Key lifetime specification."; 494 choice lifetime { 495 default "always"; 496 description 497 "Options for specifying key accept or send lifetimes"; 498 case always { 499 leaf always { 500 type empty; 501 description 502 "Indicates key lifetime is always valid."; 503 } 504 } 505 case start-end-time { 506 leaf start-date-time { 507 type yang:date-and-time; 508 description 509 "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 is infinite."; 521 } 522 } 523 case duration { 524 leaf duration { 525 type uint32 { 526 range "1..2147483646"; 527 } 528 units "seconds"; 529 description 530 "Key lifetime duration, in seconds"; 531 } 532 } 533 case end-date-time { 534 leaf end-date-time { 535 type yang:date-and-time; 536 description 537 "End time."; 538 } 539 } 540 } 541 } 542 } 543 } 544 grouping key-common { 545 description 546 "Key-chain key data nodes common to 547 configuration and state."; 548 } 550 container key-chains { 551 description 552 "All configured key-chains on the device."; 553 list key-chain { 554 key "name"; 555 description 556 "List of key-chains."; 557 leaf name { 558 type string; 559 description 560 "Name of the key-chain."; 561 } 562 leaf description { 563 type string; 564 description 565 "A description of the key-chain"; 566 } 567 container accept-tolerance { 568 if-feature "accept-tolerance"; 569 description 570 "Tolerance for key lifetime acceptance (seconds)."; 571 leaf duration { 572 type uint32; 573 units "seconds"; 574 default "0"; 575 description 576 "Tolerance range, in seconds."; 577 } 578 } 579 leaf last-modified-timestamp { 580 type yang:date-and-time; 581 config false; 582 description 583 "Timestamp of the most recent update to the key-chain"; 584 } 585 list key { 586 key "key-id"; 587 description 588 "Single key in key chain."; 589 leaf key-id { 590 type uint64; 591 description 592 "Numeric value uniquely identifying the key"; 593 } 594 container lifetime { 595 description 596 "Specify a key's lifetime."; 597 choice lifetime { 598 description 599 "Options for specification of send and accept 600 lifetimes."; 601 case send-and-accept-lifetime { 602 description 603 "Send and accept key have the same lifetime."; 604 container send-accept-lifetime { 605 description 606 "Single lifetime specification for both 607 send and accept lifetimes."; 608 uses lifetime; 609 } 610 } 611 case independent-send-accept-lifetime { 612 if-feature "independent-send-accept-lifetime"; 613 description 614 "Independent send and accept key lifetimes."; 615 container send-lifetime { 616 description 617 "Separate lifetime specification for send 618 lifetime."; 619 uses lifetime; 620 } 621 container accept-lifetime { 622 description 623 "Separate lifetime specification for accept 624 lifetime."; 625 uses lifetime; 626 } 627 } 628 } 629 } 630 leaf crypto-algorithm { 631 type identityref { 632 base crypto-algorithm; 633 } 634 mandatory true; 635 description 636 "Cryptographic algorithm associated with key."; 637 } 638 container key-string { 639 description 640 "The key string."; 641 nacm:default-deny-all; 642 choice key-string-style { 643 description 644 "Key string styles"; 645 case keystring { 646 leaf keystring { 647 type string; 648 description 649 "Key string in ASCII format."; 650 } 651 } 652 case hexadecimal { 653 if-feature "hex-key-string"; 654 leaf hexadecimal-string { 655 type yang:hex-string; 656 description 657 "Key in hexadecimal string format. When compared 658 to ASCII, specification in hexadecimal affords 659 greater key entropy with the same number of 660 internal key-string octets. Additionally, it 661 discourages usage of well-known words or 662 numbers."; 663 } 664 } 666 } 667 } 668 leaf send-lifetime-active { 669 type boolean; 670 config false; 671 description 672 "Indicates if the send lifetime of the 673 key-chain key is currently active."; 674 } 675 leaf accept-lifetime-active { 676 type boolean; 677 config false; 678 description 679 "Indicates if the accept lifetime of the 680 key-chain key is currently active."; 681 } 682 } 683 } 684 } 685 } 686 688 5. Security Considerations 690 The YANG module defined in this document is designed to be accessed 691 via network management protocols such as NETCONF [NETCONF] or 692 RESTCONF [RESTCONF]. The lowest NETCONF layer is the secure 693 transport layer, and the mandatory-to-implement secure transport is 694 Secure Shell (SSH) [NETCONF-SSH]. The lowest RESTCONF layer is 695 HTTPS, and the mandatory-to-implement secure transport is TLS [TLS]. 697 The NETCONF access control model [NETCONF-ACM] provides the means to 698 restrict access for particular NETCONF or RESTCONF users to a pre- 699 configured subset of all available NETCONF or RESTCONF protocol 700 operations and content. The key strings are not accessible by 701 default and NETCONF Access Control Mode [NETCONF-ACM] rules are 702 required to configure or retrieve them. 704 The clear-text algorithm is included as a YANG feature. Usage is NOT 705 RECOMMENDED except in cases where the application and device have no 706 other alternative (e.g., a legacy network device that must 707 authenticate packets at intervals of 10 milliseconds or less for many 708 peers using Bidirectional Forwarding Detection [BFD]). Keys used 709 with the clear-text algorithm are considered insecure and SHOULD NOT 710 be reused with more secure algorithms. 712 Similarly, the MD5 and SHA-1 algorithms have been proven to be 713 insecure ([Dobb96a], [Dobb96b], and [SHA-SEC-CON]) and usage is NOT 714 RECOMMENDED. Usage should be confined to deployments where it is 715 required for backward compatibility. 717 It is RECOMMENDED that keys be encrypted or otherwise obfuscated when 718 stored internally on a network device supporting this specification. 720 6. IANA Considerations 722 This document registers a URI in the IETF XML registry 723 [XML-REGISTRY]. Following the format in [XML-REGISTRY], the 724 following registration is requested to be made: 726 URI: urn:ietf:params:xml:ns:yang:ietf-key-chain 727 Registrant Contact: The IESG. 728 XML: N/A, the requested URI is an XML namespace. 730 This document registers a YANG module in the YANG Module Names 731 registry [YANG]. 733 name: ietf-key-chain 734 namespace: urn:ietf:params:xml:ns:yang:ietf-key-chain 735 prefix: key-chain 736 reference: RFC XXXX 738 7. Contributors 740 Contributors' Addresses 742 Yi Yang 743 SockRate 745 Email: yi.yang@sockrate.com 747 8. References 749 8.1. Normative References 751 [NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 752 Bierman, "Network Configuration Protocol (NETCONF)", RFC 753 6241, June 2011. 755 [NETCONF-ACM] 756 Bierman, A. and M. Bjorklund, "Network Configuration 757 Protocol (NETCONF) Access Control Model", RFC 6536, March 758 2012. 760 [RFC-KEYWORDS] 761 Bradner, S., "Key words for use in RFC's to Indicate 762 Requirement Levels", BCP 14, RFC 2119, March 1997. 764 [XML-REGISTRY] 765 Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 766 January 2004. 768 [YANG] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 769 7950, August 2016. 771 8.2. Informative References 773 [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 774 (BFD)", RFC 5880, June 2010. 776 [CRYPTO-KEYTABLE] 777 Housley, R., Polk, T., Hartman, S., and D. Zhang, 778 "Table of Cryptographic Keys", RFC 7210, April 2014. 780 [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", Technical 781 Report (Presented at the RUMP Session of EuroCrypt 1996), 782 2 May 1996. 784 [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", 785 CryptoBytes Vol. 2, No. 2, Summer 1996. 787 [IAB-REPORT] 788 Andersson, L., Davies, E., and L. Zhang, "Report from the 789 IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 790 4948, August 2007. 792 [NETCONF-SSH] 793 Wasserman, M., "NETCONF over SSH", RFC 6242, June 2011. 795 [NMDA] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watson, K., 796 and R. Wilton, "Network Management Datastore 797 Architecture", draft-ietf-netmod-revised-datastores-01.txt 798 (work in progress), March 2017. 800 [NTP-PROTO] 801 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 802 Time Protocol Version 4: Protocol and Algorithms 803 Specification", RFC 5905, June 2010. 805 [OSPFV3-AUTH] 806 Bhatia, M., Manral, V., and A. Lindem, "Supporting 807 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 809 [RESTCONF] 810 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 811 Protocol", RFC 8040, January 2017. 813 [SHA-SEC-CON] 814 Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 815 Considerations for the SHA-0 and SHA-1 Message-Digest 816 Algorithms", RFC 6194, February 2011. 818 [TCP-AO] Touch, J., Mankin, A., and R. Bonica, "The TCP 819 Authentication Option", RFC 5925, June 2010. 821 [TCP-AO-ALGORITHMS] 822 Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 823 for the TCP Authentication Option (TCP-AO)", RFC 5926, 824 June 2010. 826 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 827 (TLS) Protocol", RFC 5246, August 2008. 829 [YANG-CRYPTO-KEYTABLE] 830 Chen, I., "YANG Data Model for RFC 7210 Key Table", draft- 831 chen-rtg-key-table-yang-00.txt (work in progress), 832 November 2015. 834 Appendix A. Examples 835 A.1. Simple Key Chain with Always Valid Single Key 837 838 839 840 841 keychain-no-end-time 842 843 A key chain with a single key that is always valid for tx/rx 844 845 846 100 847 848 849 850 851 852 hmac-sha-256 853 854 keystring_in_ascii_100 855 856 857 858 859 861 A.2. Key Chain with Keys having Different Lifetimes 862 863 864 865 866 keychain2 867 868 A key chain where each key contains a different send time 869 and accept time and a different algorithm illustrating 870 algorithm agility 871 872 873 35 874 875 876 2017-01-01T00:00:00Z 877 2017-02-01T00:00:00Z 878 879 880 2016-12-31T23:59:55Z 881 2017-02-01T00:00:05Z 882 883 884 hmac-sha-256 885 886 keystring_in_ascii_35 887 888 889 890 36 891 892 893 2017-02-01T00:00:00Z 894 2017-03-01T00:00:00Z 895 896 897 2017-01-31T23:59:55Z 898 2017-03-01T00:00:05Z 899 900 901 hmac-sha-512 902 903 fe:ed:be:af:36 904 905 906 907 908 910 A.3. Key Chain with Independent Send and Accept Lifetimes 912 913 914 915 916 keychain2 917 918 A key chain where each key contains different send time 919 and accept time 920 921 922 35 923 924 925 2017-01-01T00:00:00Z 926 2017-02-01T00:00:00Z 927 928 929 2016-12-31T23:59:55Z 930 2017-02-01T00:00:05Z 931 932 933 hmac-sha-256 934 935 keystring_in_ascii_35 936 937 938 939 36 940 941 942 2017-02-01T00:00:00Z 943 2017-03-01T00:00:00Z 944 945 946 2017-01-31T23:59:55Z 947 2017-03-01T00:00:05Z 948 949 950 hmac-sha-256 951 952 fe:ed:be:af:36 953 954 955 956 957 959 Appendix B. Acknowledgments 961 The RFC text was produced using Marshall Rose's xml2rfc tool. 963 Thanks to Brian Weis for fruitful discussions on security 964 requirements. 966 Thanks to Ines Robles for Routing Directorate QA review comments. 968 Thanks to Ladislav Lhotka for YANG Doctor comments. 970 Thanks to Martin Bjorklund for additional YANG Doctor comments. 972 Thanks to Tom Petch for comments during IETF last call. 974 Thanks to Matthew Miller for comments made during the Gen-ART review. 976 Thanks to Vincent Roca for comments made during the Security 977 Directorate review. 979 Thanks to Warren Kumari, Ben Campbell, Adam Roach, and Benoit Claise 980 for comments received during the IESG review. 982 Authors' Addresses 984 Acee Lindem (editor) 985 Cisco Systems 986 301 Midenhall Way 987 Cary, NC 27513 988 USA 990 Email: acee@cisco.com 992 Yingzhen Qu 993 Huawei 995 Email: yingzhen.qu@huawei.com 997 Derek Yeung 998 Arrcus, Inc 1000 Email: derek@arrcus.com 1001 Ing-Wher Chen 1002 Jabil 1004 Email: ing-wher_chen@jabil.com 1006 Jeffrey Zhang 1007 Juniper Networks 1008 10 Technology Park Drive 1009 Westford, MA 01886 1010 USA 1012 Email: zzhang@juniper.net