idnits 2.17.1 draft-ietf-rtgwg-yang-key-chain-22.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 28, 2017) is 2553 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: A later version (-10) exists of draft-ietf-netmod-revised-datastores-01 -- 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 30, 2017 Huawei 6 D. Yeung 7 Arrcus, Inc 8 I. Chen 9 Jabil 10 J. Zhang 11 Juniper Networks 12 April 28, 2017 14 Routing Key Chain YANG Data Model 15 draft-ietf-rtgwg-yang-key-chain-22.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 30, 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 . . . . . . . . . . . . . . . . . . . . . . . . 17 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 79 8.2. Informative References . . . . . . . . . . . . . . . . . 17 80 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 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 329 +--rw aes-key-wrap {aes-key-wrap}? 330 +--rw enable? boolean 332 4. Key Chain YANG Model 334 file "ietf-key-chain@2017-04-18.yang" 335 module ietf-key-chain { 336 yang-version 1.1; 337 namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain"; 338 prefix key-chain; 340 import ietf-yang-types { 341 prefix yang; 342 } 343 import ietf-netconf-acm { 344 prefix nacm; 345 } 347 organization 348 "IETF RTG (Routing) Working Group"; 349 contact 350 "Acee Lindem - acee@cisco.com"; 351 description 352 "This YANG module defines the generic configuration 353 data for key-chain. It is intended that the module 354 will be extended by vendors to define vendor-specific 355 key-chain configuration parameters. 357 Copyright (c) 2017 IETF Trust and the persons identified as 358 authors of the code. All rights reserved. 360 Redistribution and use in source and binary forms, with or 361 without modification, is permitted pursuant to, and subject 362 to the license terms contained in, the Simplified BSD License 363 set forth in Section 4.c of the IETF Trust's Legal Provisions 364 Relating to IETF Documents 365 (http://trustee.ietf.org/license-info). 366 This version of this YANG module is part of RFC XXXX; see 367 the RFC itself for full legal notices."; 369 revision 2017-04-18 { 370 description 371 "Initial RFC Revision"; 372 reference "RFC XXXX: A YANG Data Model for key-chain"; 373 } 375 feature hex-key-string { 376 description 377 "Support hexadecimal key string."; 378 } 379 feature accept-tolerance { 380 description 381 "Support the tolerance or acceptance limit."; 382 } 384 feature independent-send-accept-lifetime { 385 description 386 "Support for independent send and accept key lifetimes."; 387 } 389 feature crypto-hmac-sha-1-12 { 390 description 391 "Support for TCP HMAC-SHA-1 12 byte digest hack."; 392 } 394 feature clear-text { 395 description 396 "Support for clear-text algorithm. Usage is 397 NOT RECOMMENDED."; 398 } 400 feature aes-cmac-prf-128 { 401 description 402 "Support for AES Cipher based Message Authentication 403 Code Pseudo Random Function."; 404 } 406 feature aes-key-wrap { 407 description 408 "Support for Advanced Encryption Standard (AES) Key Wrap."; 409 } 411 feature replay-protection-only { 412 description 413 "Provide replay-protection without any authentication 414 as required by protocols such as Bidirectional 415 Forwarding Detection (BFD)."; 416 } 417 identity crypto-algorithm { 418 description 419 "Base identity of cryptographic algorithm options."; 420 } 422 identity hmac-sha-1-12 { 423 base crypto-algorithm; 424 if-feature "crypto-hmac-sha-1-12"; 425 description 426 "The HMAC-SHA1-12 algorithm."; 428 } 430 identity aes-cmac-prf-128 { 431 base crypto-algorithm; 432 if-feature "aes-cmac-prf-128"; 433 description 434 "The AES-CMAC-PRF-128 algorithm - required by 435 RFC 5926 for TCP-AO key derivation functions."; 436 } 438 identity md5 { 439 base crypto-algorithm; 440 description 441 "The MD5 algorithm."; 442 } 444 identity sha-1 { 445 base crypto-algorithm; 446 description 447 "The SHA-1 algorithm."; 448 } 450 identity hmac-sha-1 { 451 base crypto-algorithm; 452 description 453 "HMAC-SHA-1 authentication algorithm."; 454 } 456 identity hmac-sha-256 { 457 base crypto-algorithm; 458 description 459 "HMAC-SHA-256 authentication algorithm."; 460 } 462 identity hmac-sha-384 { 463 base crypto-algorithm; 464 description 465 "HMAC-SHA-384 authentication algorithm."; 466 } 468 identity hmac-sha-512 { 469 base crypto-algorithm; 470 description 471 "HMAC-SHA-512 authentication algorithm."; 472 } 474 identity clear-text { 475 base crypto-algorithm; 476 if-feature "clear-text"; 477 description 478 "Clear text."; 479 } 481 identity replay-protection-only { 482 base crypto-algorithm; 483 if-feature "replay-protection-only"; 484 description 485 "Provide replay-protection without any authentication as 486 required by protocols such as Bidirectional Forwarding 487 Detection (BFD)."; 488 } 490 typedef key-chain-ref { 491 type leafref { 492 path 493 "/key-chain:key-chains/key-chain:key-chain/key-chain:name"; 494 } 495 description 496 "This type is used by data models that need to reference 497 configured key-chains."; 498 } 500 grouping lifetime { 501 description 502 "Key lifetime specification."; 503 choice lifetime { 504 default "always"; 505 description 506 "Options for specifying key accept or send lifetimes"; 507 case always { 508 leaf always { 509 type empty; 510 description 511 "Indicates key lifetime is always valid."; 512 } 513 } 514 case start-end-time { 515 leaf start-date-time { 516 type yang:date-and-time; 517 description 518 "Start time."; 519 } 520 choice end-time { 521 default "infinite"; 522 description 523 "End-time setting."; 525 case infinite { 526 leaf no-end-time { 527 type empty; 528 description 529 "Indicates key lifetime end-time is infinite."; 530 } 531 } 532 case duration { 533 leaf duration { 534 type uint32 { 535 range "1..2147483646"; 536 } 537 units "seconds"; 538 description 539 "Key lifetime duration, in seconds"; 540 } 541 } 542 case end-date-time { 543 leaf end-date-time { 544 type yang:date-and-time; 545 description 546 "End time."; 547 } 548 } 549 } 550 } 551 } 552 } 553 grouping key-common { 554 description 555 "Key-chain key data nodes common to 556 configuration and state."; 557 } 559 container key-chains { 560 description 561 "All configured key-chains on the device."; 562 list key-chain { 563 key "name"; 564 description 565 "List of key-chains."; 566 leaf name { 567 type string; 568 description 569 "Name of the key-chain."; 570 } 571 leaf description { 572 type string; 573 description 574 "A description of the key-chain"; 575 } 576 container accept-tolerance { 577 if-feature "accept-tolerance"; 578 description 579 "Tolerance for key lifetime acceptance (seconds)."; 580 leaf duration { 581 type uint32; 582 units "seconds"; 583 default "0"; 584 description 585 "Tolerance range, in seconds."; 586 } 587 } 588 leaf last-modified-timestamp { 589 type yang:date-and-time; 590 config false; 591 description 592 "Timestamp of the most recent update to the key-chain"; 593 } 594 list key { 595 key "key-id"; 596 description 597 "Single key in key chain."; 598 leaf key-id { 599 type uint64; 600 description 601 "Numeric value uniquely identifying the key"; 602 } 603 container lifetime { 604 description 605 "Specify a key's lifetime."; 606 choice lifetime { 607 description 608 "Options for specification of send and accept 609 lifetimes."; 610 case send-and-accept-lifetime { 611 description 612 "Send and accept key have the same lifetime."; 613 container send-accept-lifetime { 614 description 615 "Single lifetime specification for both 616 send and accept lifetimes."; 617 uses lifetime; 618 } 619 } 620 case independent-send-accept-lifetime { 621 if-feature "independent-send-accept-lifetime"; 622 description 623 "Independent send and accept key lifetimes."; 624 container send-lifetime { 625 description 626 "Separate lifetime specification for send 627 lifetime."; 628 uses lifetime; 629 } 630 container accept-lifetime { 631 description 632 "Separate lifetime specification for accept 633 lifetime."; 634 uses lifetime; 635 } 636 } 637 } 638 } 639 leaf crypto-algorithm { 640 type identityref { 641 base crypto-algorithm; 642 } 643 mandatory true; 644 description 645 "Cryptographic algorithm associated with key."; 646 } 647 container key-string { 648 description 649 "The key string."; 650 nacm:default-deny-all; 651 choice key-string-style { 652 description 653 "Key string styles"; 654 case keystring { 655 leaf keystring { 656 type string; 657 description 658 "Key string in ASCII format."; 659 } 660 } 661 case hexadecimal { 662 if-feature "hex-key-string"; 663 leaf hexadecimal-string { 664 type yang:hex-string; 665 description 666 "Key in hexadecimal string format. When compared 667 to ASCII, specification in hexadecimal affords 668 greater key entropy with the same number of 669 internal key-string octets. Additionally, it 670 discourages usage of well-known words or 671 numbers."; 672 } 673 } 674 } 675 } 676 leaf send-lifetime-active { 677 type boolean; 678 config false; 679 description 680 "Indicates if the send lifetime of the 681 key-chain key is currently active."; 682 } 683 leaf accept-lifetime-active { 684 type boolean; 685 config false; 686 description 687 "Indicates if the accept lifetime of the 688 key-chain key is currently active."; 689 } 690 } 691 } 692 container aes-key-wrap { 693 if-feature "aes-key-wrap"; 694 description 695 "AES Key Wrap encryption for key-chain key-strings. The 696 encrypted key-strings are encoded as hexadecimal key 697 strings using the hex-key-string leaf."; 698 leaf enable { 699 type boolean; 700 default "false"; 701 description 702 "Enable AES Key Wrap encryption."; 703 } 704 } 705 } 706 } 707 709 5. Security Considerations 711 The YANG module defined in this document is designed to be accessed 712 via network management protocols such as NETCONF [NETCONF] or 713 RESTCONF [RESTCONF]. The lowest NETCONF layer is the secure 714 transport layer, and the mandatory-to-implement secure transport is 715 Secure Shell (SSH) [NETCONF-SSH]. The lowest RESTCONF layer is 716 HTTPS, and the mandatory-to-implement secure transport is TLS [TLS]. 718 The NETCONF access control model [NETCONF-ACM] provides the means to 719 restrict access for particular NETCONF or RESTCONF users to a pre- 720 configured subset of all available NETCONF or RESTCONF protocol 721 operations and content. The key strings are not accessible by 722 default and NETCONF Access Control Mode [NETCONF-ACM] rules are 723 required to configure or retrieve them. 725 When configured, the key-strings can be encrypted using the AES Key 726 Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) is 727 not included in the YANG model and must be set or derived independent 728 of key-chain configuration. When AES key-encryption is used, the 729 hex-key-string feature is also required since the encrypted keys will 730 contain characters that are not representable in the YANG string 731 built-in type [YANG]. It is RECOMMENDED that key-strings be 732 encrypted using AES key-encryption to prevent key-chains from being 733 retrieved and stored with the key-strings in clear text. This 734 recommendation is independent of the access protection that is 735 availed from the NETCONF Access Control Model (NACM) [NETCONF-ACM]. 737 The clear-text algorithm is included as a YANG feature. Usage is NOT 738 RECOMMENDED except in cases where the application and device have no 739 other alternative (e.g., a legacy network device that must 740 authenticate packets at intervals of 10 milliseconds or less for many 741 peers using Bidirectional Forwarding Detection [BFD]). Keys used 742 with the clear-text algorithm are considered insecure and SHOULD NOT 743 be reused with more secure algorithms. 745 Similarly, the MD5 and SHA-1 algorithms have been proven to be 746 insecure ([Dobb96a], [Dobb96b], and [SHA-SEC-CON]) and usage is NOT 747 RECOMMENDED. Usage should be confined to deployments where it is 748 required for backward compatibility. 750 6. IANA Considerations 752 This document registers a URI in the IETF XML registry 753 [XML-REGISTRY]. Following the format in [XML-REGISTRY], the 754 following registration is requested to be made: 756 URI: urn:ietf:params:xml:ns:yang:ietf-key-chain 757 Registrant Contact: The IESG. 758 XML: N/A, the requested URI is an XML namespace. 760 This document registers a YANG module in the YANG Module Names 761 registry [YANG]. 763 name: key-chain 764 namespace: urn:ietf:params:xml:ns:yang:ietf-key-chain 765 prefix: key-chain 766 reference: RFC XXXX 768 7. Contributors 770 Contributors' Addresses 772 Yi Yang 773 SockRate 775 Email: yi.yang@sockrate.com 777 8. References 779 8.1. Normative References 781 [NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 782 Bierman, "Network Configuration Protocol (NETCONF)", RFC 783 6241, June 2011. 785 [NETCONF-ACM] 786 Bierman, A. and M. Bjorklund, "Network Configuration 787 Protocol (NETCONF) Access Control Model", RFC 6536, March 788 2012. 790 [RFC-KEYWORDS] 791 Bradner, S., "Key words for use in RFC's to Indicate 792 Requirement Levels", BCP 14, RFC 2119, March 1997. 794 [XML-REGISTRY] 795 Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 796 January 2004. 798 [YANG] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 799 7950, August 2016. 801 8.2. Informative References 803 [AES-KEY-WRAP] 804 Schaad, J. and R. Housley, "Advanced Encryption Standard 805 (AES) Key Wrap Algorithm", RFC 5649, August 2009. 807 [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 808 (BFD)", RFC 5880, June 2010. 810 [CRYPTO-KEYTABLE] 811 Housley, R., Polk, T., Hartman, S., and D. Zhang, 812 "Table of Cryptographic Keys", RFC 7210, April 2014. 814 [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", Technical 815 Report (Presented at the RUMP Session of EuroCrypt 1996), 816 2 May 1996. 818 [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", 819 CryptoBytes Vol. 2, No. 2, Summer 1996. 821 [IAB-REPORT] 822 Andersson, L., Davies, E., and L. Zhang, "Report from the 823 IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 824 4948, August 2007. 826 [NETCONF-SSH] 827 Wasserman, M., "NETCONF over SSH", RFC 6242, June 2011. 829 [NMDA] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watson, K., 830 and R. Wilton, "Network Management Datastore 831 Architecture", draft-ietf-netmod-revised-datastores-01.txt 832 (work in progress), March 2017. 834 [NTP-PROTO] 835 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 836 Time Protocol Version 4: Protocol and Algorithms 837 Specification", RFC 5905, June 2010. 839 [OSPFV3-AUTH] 840 Bhatia, M., Manral, V., and A. Lindem, "Supporting 841 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 843 [RESTCONF] 844 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 845 Protocol", RFC 8040, January 2017. 847 [SHA-SEC-CON] 848 Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 849 Considerations for the SHA-0 and SHA-1 Message-Digest 850 Algorithms", RFC 6194, February 2011. 852 [TCP-AO] Touch, J., Mankin, A., and R. Bonica, "The TCP 853 Authentication Option", RFC 5925, June 2010. 855 [TCP-AO-ALGORITHMS] 856 Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 857 for the TCP Authentication Option (TCP-AO)", RFC 5926, 858 June 2010. 860 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 861 (TLS) Protocol", RFC 5246, August 2008. 863 [YANG-CRYPTO-KEYTABLE] 864 Chen, I., "YANG Data Model for RFC 7210 Key Table", draft- 865 chen-rtg-key-table-yang-00.txt (work in progress), 866 November 2015. 868 Appendix A. Examples 870 A.1. Simple Key Chain with Always Valid Single Key 872 873 874 875 876 keychain-no-end-time 877 878 A key chain with a single key that is always valid for 879 transmission and reception. 880 881 882 100 883 884 885 886 887 888 hmac-sha-256 889 890 keystring_in_ascii_100 891 892 893 894 895 897 A.2. Key Chain with Keys having Different Lifetimes 898 899 900 901 902 keychain2 903 904 A key chain where each key contains different send time 905 and accept time and a different algorithm illustrating 906 algorithm agility. 907 908 909 35 910 911 912 2017-01-01T00:00:00Z 913 2017-02-01T00:00:00Z 914 915 916 2016-12-31T23:59:55Z 917 2017-02-01T00:00:05Z 918 919 920 hmac-sha-256 921 922 keystring_in_ascii_35 923 924 925 926 36 927 928 929 2017-02-01T00:00:00Z 930 2017-03-01T00:00:00Z 931 932 933 2017-01-31T23:59:55Z 934 2017-03-01T00:00:05Z 935 936 937 hmac-sha-512 938 939 fe:ed:be:af:36 940 941 942 943 944 946 A.3. Key Chain with Independent Send and Accept Lifetimes 948 949 950 951 952 keychain2 953 954 A key chain where each key contains different send time 955 and accept times. 956 957 958 35 959 960 961 2017-01-01T00:00:00Z 962 2017-02-01T00:00:00Z 963 964 965 2016-12-31T23:59:55Z 966 2017-02-01T00:00:05Z 967 968 969 hmac-sha-256 970 971 keystring_in_ascii_35 972 973 974 975 36 976 977 978 2017-02-01T00:00:00Z 979 2017-03-01T00:00:00Z 980 981 982 2017-01-31T23:59:55Z 983 2017-03-01T00:00:05Z 984 985 986 hmac-sha-256 987 988 fe:ed:be:af:36 989 990 991 992 993 995 Appendix B. Acknowledgments 997 The RFC text was produced using Marshall Rose's xml2rfc tool. 999 Thanks to Brian Weis for fruitful discussions on security 1000 requirements. 1002 Thanks to Ines Robles for Routing Directorate QA review comments. 1004 Thanks to Ladislav Lhotka for YANG Doctor comments. 1006 Thanks to Martin Bjorklund for additional YANG Doctor comments. 1008 Thanks to Tom Petch for comments during IETF last call. 1010 Thanks to Matthew Miller for comments made during the Gen-ART review. 1012 Thanks to Vincent Roca for comments made during the Security 1013 Directorate review. 1015 Thanks to Warren Kumari, Ben Campbell, Adam Roach, and Benoit Claise 1016 for comments received during the IESG review. 1018 Authors' Addresses 1020 Acee Lindem (editor) 1021 Cisco Systems 1022 301 Midenhall Way 1023 Cary, NC 27513 1024 USA 1026 Email: acee@cisco.com 1028 Yingzhen Qu 1029 Huawei 1031 Email: yingzhen.qu@huawei.com 1033 Derek Yeung 1034 Arrcus, Inc 1036 Email: derek@arrcus.com 1037 Ing-Wher Chen 1038 Jabil 1040 Email: ing-wher_chen@jabil.com 1042 Jeffrey Zhang 1043 Juniper Networks 1044 10 Technology Park Drive 1045 Westford, MA 01886 1046 USA 1048 Email: zzhang@juniper.net