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