idnits 2.17.1 draft-ietf-rtgwg-yang-key-chain-20.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 18, 2017) is 2563 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 20, 2017 Huawei 6 D. Yeung 7 Arrcus, Inc 8 I. Chen 9 Jabil 10 J. Zhang 11 Juniper Networks 12 April 18, 2017 14 Routing Key Chain YANG Data Model 15 draft-ietf-rtgwg-yang-key-chain-20.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 In some applications, the protocols do not use the key chain element 30 key directly, but rather a key derivation function is used to derive 31 a short-lived key from the key chain element key (e.g., the Master 32 Keys used in the TCP Authentication Option(TCP-AO)). 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 20, 2017. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 69 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 71 2.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 72 2.2. Graceful Key Rollover using Key Chains . . . . . . . . . 4 73 3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 5 74 3.1. Key Chain Operational State . . . . . . . . . . . . . . . 5 75 3.2. Key Chain Model Features . . . . . . . . . . . . . . . . 6 76 3.3. Key Chain Model Tree . . . . . . . . . . . . . . . . . . 6 77 4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 7 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 83 8.2. Informative References . . . . . . . . . . . . . . . . . 17 84 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 85 A.1. Simple Key Chain with Always Valid Single Key . . . . . . 19 86 A.2. Key Chain with Keys having Different Lifetimes . . . . . 19 87 A.3. Key Chain with Independent Send and Accept Lifetimes . . 21 88 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 22 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 91 1. Introduction 93 This document describes the key chain YANG [YANG] data model. Key 94 chains are commonly used for routing protocol authentication and 95 other applications requiring symmetric keys. A key chain is a list 96 of elements each containing a key string, send lifetime, accept 97 lifetime, and algorithm (authentication or encryption). By properly 98 overlapping the send and accept lifetimes of multiple key chain 99 elements, key strings and algorithms may be gracefully updated. By 100 representing them in a YANG data model, key distribution can be 101 automated. 103 In some applications, the protocols do not use the key chain element 104 key directly, but rather a key derivation function is used to derive 105 a short-lived key from the key chain element key (e.g., the Master 106 Keys used in [TCP-AO]). 108 1.1. Requirements Notation 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in 113 [RFC-KEYWORDS]. 115 1.2. Tree Diagrams 117 A simplified graphical representation of the complete data tree is 118 presented in Section 3.3. The following tree notation is used. 120 o Brackets "[" and "]" enclose YANG list keys. These YANG list keys 121 should not be confused with the key-chain keys. 123 o Curly braces "{" and "}" contain names of optional features that 124 make the corresponding node conditional. 126 o Abbreviations before data node names: "rw" means configuration 127 (read-write), "ro" state data (read-only), "-x" RPC operations, 128 and "-n" notifications. 130 o Symbols after data node names: "?" means an optional node, "!" a 131 container with presence, and "*" denotes a "list" or "leaf-list". 133 o Parentheses enclose choice and case nodes, and case nodes are also 134 marked with a colon (":"). 136 o Ellipsis ("...") stands for contents of subtrees that are not 137 shown. 139 2. Problem Statement 141 This document describes a YANG [YANG] data model for key chains. Key 142 chains have been implemented and deployed by a large percentage of 143 network equipment vendors. Providing a standard YANG model will 144 facilitate automated key distribution and non-disruptive key 145 rollover. This will aid in tightening the security of the core 146 routing infrastructure as recommended in [IAB-REPORT]. 148 A key chain is a list containing one or more elements containing a 149 Key ID, key string, send/accept lifetimes, and the associated 150 authentication or encryption algorithm. A key chain can be used by 151 any service or application requiring authentication or encryption. 152 In essence, the key-chain is a reusable key policy that can be 153 referenced wherever it is required. The key-chain construct has been 154 implemented by most networking vendors and deployed in many networks. 156 A conceptual representation of a crypto key table is described in 157 [CRYPTO-KEYTABLE]. The crypto key table also includes keys as well 158 as their corresponding lifetimes and algorithms. Additionally, the 159 key table includes key selection criteria and envisions a deployment 160 model where the details of the applications or services requiring 161 authentication or encryption permeate into the key database. The 162 YANG key-chain model described herein doesn't include key selection 163 criteria or support this deployment model. At the same time, it does 164 not preclude it. The draft [YANG-CRYPTO-KEYTABLE] describes 165 augmentations to the key chain YANG model in support of key selection 166 criteria. 168 2.1. Applicability 170 Other YANG modules may reference ietf-key-chain YANG module key-chain 171 names for authentication and encryption applications. A YANG type 172 has been provided to facilitate reference to the key-chain name 173 without having to specify the complete YANG XML Path Language (XPath) 174 selector. 176 2.2. Graceful Key Rollover using Key Chains 178 Key chains may be used to gracefully update the key string and/or 179 algorithm used by an application for authentication or encryption. 180 This MAY be accomplished by accepting all the keys that have a valid 181 accept lifetime and sending the key with the most recent send 182 lifetime. One scenario for facilitating key rollover is to: 184 1. Distribute a key chain with a new key to all the routers or other 185 network devices in the domain of that key chain. The new key's 186 accept lifetime should be such that it is accepted during the key 187 rollover period. The send lifetime should be a time in the 188 future when it can be assured that all the routers in the domain 189 of that key are upgraded. This will have no immediate impact on 190 the keys used for transmission. 192 2. Assure that all the network devices have been updated with the 193 updated key chain and that their system times are roughly 194 synchronized. The system times of devices within an 195 administrative domain are commonly synchronized (e.g., using 196 Network Time Protocol (NTP) [NTP-PROTO]). This also may be 197 automated. 199 3. When the send lifetime of the new key becomes valid, the network 200 devices within the domain of key chain will using the new key for 201 transmissions. 203 4. At some point in the future, a new key chain with the old key 204 removed may be distributed to the network devices within the 205 domain of the key chain. However, this may be deferred until the 206 next key rollover. If this is done, the key chain will always 207 include two keys; either the current and future key (during key 208 rollovers) or the current and previous keys (between key 209 rollovers). 211 3. Design of the Key Chain Model 213 The ietf-key-chain module contains a list of one or more keys indexed 214 by a Key ID. For some applications (e.g., OSPFv3 [OSPFV3-AUTH]), the 215 Key ID is used to identify the key chain key to be used. In addition 216 to the Key ID, each key chain key includes a key-string and a 217 cryptographic algorithm. Optionally, the key chain keys include 218 send/accept lifetimes. If the send/accept lifetime is unspecified, 219 the key is always considered valid. 221 Note that different key values for transmission versus acceptance may 222 be supported with multiple key chain elements where the accept- 223 lifetime or send-lifetime is not valid (e.g., has an end-time equal 224 to the start-time). 226 Due to the differences in key chain implementations across various 227 vendors, some of the data elements are optional. Finally, the crypto 228 algorithm identities are provided for reuse when configuring legacy 229 authentication and encryption not using key-chains. 231 A key-chain is identified by a unique name within the scope of the 232 network device. The "key-chain-ref" typedef SHOULD be used by other 233 YANG modules when they need to reference a configured key-chain. 235 3.1. Key Chain Operational State 237 The key chain operational state is included in the same tree as key 238 chain configuration consistent with [NMDA]. The timestamp of the 239 last key chain modification is also maintained in the operational 240 state. Additionally, the operational state includes an indication of 241 whether or not a key chain key is valid for sending or acceptance. 243 3.2. Key Chain Model Features 245 Features are used to handle differences between vendor 246 implementations. For example, not all vendors support configuration 247 of an acceptance tolerance or configuration of key strings in 248 hexadecimal. They are also used to support of security requirements 249 (e.g., TCP-AO Algorithms [TCP-AO-ALGORITHMS]) not implemented by 250 vendors or only a single vendor. 252 3.3. Key Chain Model Tree 254 +--rw key-chains 255 +--rw key-chain* [name] 256 | +--rw name string 257 | +--rw description? string 258 | +--rw accept-tolerance {accept-tolerance}? 259 | | +--rw duration? uint32 260 | +--ro last-modified-timestamp? yang:date-and-time 261 | +--rw key* [key-id] 262 | +--rw key-id uint64 263 | +--rw lifetime 264 | | +--rw (lifetime)? 265 | | +--:(send-and-accept-lifetime) 266 | | | +--rw send-accept-lifetime 267 | | | +--rw (lifetime)? 268 | | | +--:(always) 269 | | | | +--rw always? empty 270 | | | +--:(start-end-time) 271 | | | +--rw start-date-time? 272 | | | | yang:date-and-time 273 | | | +--rw (end-time)? 274 | | | +--:(infinite) 275 | | | | +--rw no-end-time? empty 276 | | | +--:(duration) 277 | | | | +--rw duration? uint32 278 | | | +--:(end-date-time) 279 | | | +--rw end-date-time? 280 | | | yang:date-and-time 281 | | +--:(independent-send-accept-lifetime) 282 | | | {independent-send-accept-lifetime}? 283 | | +--rw send-lifetime 284 | | | +--rw (lifetime)? 285 | | | +--:(always) 286 | | | | +--rw always? empty 287 | | | +--:(start-end-time) 288 | | | +--rw start-date-time? 289 | | | | yang:date-and-time 290 | | | +--rw (end-time)? 291 | | | +--:(infinite) 292 | | | | +--rw no-end-time? empty 293 | | | +--:(duration) 294 | | | | +--rw duration? uint32 295 | | | +--:(end-date-time) 296 | | | +--rw end-date-time? 297 | | | yang:date-and-time 298 | | +--rw accept-lifetime 299 | | +--rw (lifetime)? 300 | | +--:(always) 301 | | | +--rw always? empty 302 | | +--:(start-end-time) 303 | | +--rw start-date-time? 304 | | | yang:date-and-time 305 | | +--rw (end-time)? 306 | | +--:(infinite) 307 | | | +--rw no-end-time? empty 308 | | +--:(duration) 309 | | | +--rw duration? uint32 310 | | +--:(end-date-time) 311 | | +--rw end-date-time? 312 | | yang:date-and-time 313 | +--rw crypto-algorithm identityref 314 | +--rw key-string 315 | | +--rw (key-string-style)? 316 | | +--:(keystring) 317 | | | +--rw keystring? string 318 | | +--:(hexadecimal) {hex-key-string}? 319 | | +--rw hexadecimal-string? yang:hex-string 320 | +--ro send-lifetime-active? boolean 321 | +--ro accept-lifetime-active? boolean 322 +--rw aes-key-wrap {aes-key-wrap}? 323 +--rw enable? boolean 325 4. Key Chain YANG Model 327 file "ietf-key-chain@2017-04-18.yang" 328 module ietf-key-chain { 329 yang-version 1.1; 330 namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain"; 331 prefix key-chain; 333 import ietf-yang-types { 334 prefix yang; 336 } 337 import ietf-netconf-acm { 338 prefix nacm; 339 } 341 organization 342 "IETF RTG (Routing) Working Group"; 343 contact 344 "Acee Lindem - acee@cisco.com"; 345 description 346 "This YANG module defines the generic configuration 347 data for key-chain. It is intended that the module 348 will be extended by vendors to define vendor-specific 349 key-chain configuration parameters. 351 Copyright (c) 2015 IETF Trust and the persons identified as 352 authors of the code. All rights reserved. 354 Redistribution and use in source and binary forms, with or 355 without modification, is permitted pursuant to, and subject 356 to the license terms contained in, the Simplified BSD License 357 set forth in Section 4.c of the IETF Trust's Legal Provisions 358 Relating to IETF Documents 359 (http://trustee.ietf.org/license-info). 360 This version of this YANG module is part of RFC XXXX; see 361 the RFC itself for full legal notices."; 363 revision 2017-04-18 { 364 description 365 "Initial RFC Revision"; 366 reference "RFC XXXX: A YANG Data Model for key-chain"; 367 } 369 feature hex-key-string { 370 description 371 "Support hexadecimal key string."; 372 } 374 feature accept-tolerance { 375 description 376 "To specify the tolerance or acceptance limit."; 377 } 379 feature independent-send-accept-lifetime { 380 description 381 "Support for independent send and accept key lifetimes."; 382 } 383 feature crypto-hmac-sha-1-12 { 384 description 385 "Support for TCP HMAC-SHA-1 12 byte digest hack."; 386 } 388 feature clear-text { 389 description 390 "Support for clear-text algorithm. Usage is 391 NOT RECOMMENDED."; 392 } 394 feature aes-cmac-prf-128 { 395 description 396 "Support for AES Cipher based Message Authentication 397 Code Pseudo Random Function."; 398 } 400 feature aes-key-wrap { 401 description 402 "Support for Advanced Encryption Standard (AES) Key Wrap."; 403 } 405 feature replay-protection-only { 406 description 407 "Provide replay-protection without any authentication 408 as required by protocols such as Bidirectional 409 Forwarding Detection (BFD)."; 410 } 411 identity crypto-algorithm { 412 description 413 "Base identity of cryptographic algorithm options."; 414 } 416 identity hmac-sha-1-12 { 417 base crypto-algorithm; 418 if-feature "crypto-hmac-sha-1-12"; 419 description 420 "The HMAC-SHA1-12 algorithm."; 421 } 423 identity aes-cmac-prf-128 { 424 base crypto-algorithm; 425 if-feature "aes-cmac-prf-128"; 426 description 427 "The AES-CMAC-PRF-128 algorithm - required by 428 RFC 5926 for TCP-AO key derivation functions."; 429 } 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 } 473 identity replay-protection-only { 474 base crypto-algorithm; 475 if-feature "replay-protection-only"; 476 description 477 "Provide replay-protection without any authentication as 478 required by protocols such as Bidirectional Forwarding 479 Detection (BFD)."; 480 } 482 typedef key-chain-ref { 483 type leafref { 484 path 485 "/key-chain:key-chains/key-chain:key-chain/key-chain:name"; 486 } 487 description 488 "This type is used by data models that need to reference 489 configured key-chains."; 490 } 492 grouping lifetime { 493 description 494 "Key lifetime specification."; 495 choice lifetime { 496 default "always"; 497 description 498 "Options for specifying key accept or send lifetimes"; 499 case always { 500 leaf always { 501 type empty; 502 description 503 "Indicates key lifetime is always valid."; 504 } 505 } 506 case start-end-time { 507 leaf start-date-time { 508 type yang:date-and-time; 509 description 510 "Start time."; 511 } 512 choice end-time { 513 default "infinite"; 514 description 515 "End-time setting."; 516 case infinite { 517 leaf no-end-time { 518 type empty; 519 description 520 "Indicates key lifetime end-time in 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 octets. Additionally, it discourages usage of 661 well-known words or numbers."; 662 } 663 } 664 } 665 } 666 leaf send-lifetime-active { 667 type boolean; 668 config false; 669 description 670 "Indicates if the send lifetime of the 671 key-chain key is currently active."; 672 } 673 leaf accept-lifetime-active { 674 type boolean; 675 config false; 676 description 677 "Indicates if the accept lifetime of the 678 key-chain key is currently active."; 679 } 680 } 681 } 682 container aes-key-wrap { 683 if-feature "aes-key-wrap"; 684 description 685 "AES Key Wrap password encryption."; 686 leaf enable { 687 type boolean; 688 default "false"; 689 description 690 "Enable AES Key Wrap encryption."; 691 } 692 } 693 } 694 } 695 697 5. Security Considerations 699 The YANG module defined in this document is designed to be accessed 700 via network management protocols such as NETCONF [NETCONF] or 701 RESTCONF [RESTCONF]. The lowest NETCONF layer is the secure 702 transport layer, and the mandatory-to-implement secure transport is 703 Secure Shell (SSH) [NETCONF-SSH]. The lowest RESTCONF layer is 704 HTTPS, and the mandatory-to-implement secure transport is TLS [TLS]. 706 The NETCONF access control model [NETCONF-ACM] provides the means to 707 restrict access for particular NETCONF or RESTCONF users to a pre- 708 configured subset of all available NETCONF or RESTCONF protocol 709 operations and content. The key strings are not accessible by 710 default and NETCONF Access Control Mode [NETCONF-ACM] rules are 711 required to configure or retrieve them. 713 When configured, the key-strings can be encrypted using the AES Key 714 Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) is 715 not included in the YANG model and must be set or derived independent 716 of key-chain configuration. When AES key-encryption is used, the 717 hex-key-string feature is also required since the encrypted keys will 718 contain characters that are not representable in the YANG string 719 built-in type [YANG]. AES key-encryption MAY be used for added key 720 security in situations where the NETCONF Access Control Mode is not 721 available. 723 The clear-text algorithm is included as a YANG feature. Usage is NOT 724 RECOMMENDED except in cases where the application and device have no 725 other alternative (e.g., a legacy network device that must 726 authenticate packets at intervals of 10 milliseconds or less for many 727 peers using Bidirectional Forwarding Detection [BFD]). Keys used 728 with the clear-text algorithm are considered insecure and SHOULD NOT 729 be reused with more secure algorithms. 731 Similarly, the MD5 and SHA-1 algorithms have been proven to be 732 insecure ([Dobb96a], [Dobb96b], and [SHA-SEC-CON]) and usage is NOT 733 RECOMMENDED. Usage should be confined to deployments where it is 734 required for backward compatibility. 736 It is RECOMMENDED that keys be encrypted or otherwise obfuscated when 737 stored internally on a network device supporting this specification. 739 6. IANA Considerations 741 This document registers a URI in the IETF XML registry 742 [XML-REGISTRY]. Following the format in [XML-REGISTRY], the 743 following registration is requested to be made: 745 URI: urn:ietf:params:xml:ns:yang:ietf-key-chain 746 Registrant Contact: The IESG. 747 XML: N/A, the requested URI is an XML namespace. 749 This document registers a YANG module in the YANG Module Names 750 registry [YANG]. 752 name: ietf-key-chain 753 namespace: urn:ietf:params:xml:ns:yang:ietf-key-chain 754 prefix: ietf-key-chain 755 reference: RFC XXXX 757 7. Contributors 758 Contributors' Addresses 760 Yi Yang 761 SockRate 763 Email: yi.yang@sockrate.com 765 8. References 767 8.1. Normative References 769 [NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 770 Bierman, "Network Configuration Protocol (NETCONF)", RFC 771 6241, June 2011. 773 [NETCONF-ACM] 774 Bierman, A. and M. Bjorklund, "Network Configuration 775 Protocol (NETCONF) Access Control Model", RFC 6536, March 776 2012. 778 [RFC-KEYWORDS] 779 Bradner, S., "Key words for use in RFC's to Indicate 780 Requirement Levels", BCP 14, RFC 2119, March 1997. 782 [XML-REGISTRY] 783 Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 784 January 2004. 786 [YANG] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 787 7950, August 2016. 789 8.2. Informative References 791 [AES-KEY-WRAP] 792 Housley, R. and M. Dworkin, "Advanced Encryption Standard 793 (AES) Key Wrap with Padding Algorithm", RFC 5649, August 794 2009. 796 [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 797 (BFD)", RFC 5880, June 2010. 799 [CRYPTO-KEYTABLE] 800 Housley, R., Polk, T., Hartman, S., and D. Zhang, 801 "Table of Cryptographic Keys", RFC 7210, April 2014. 803 [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", Technical 804 Report (Presented at the RUMP Session of EuroCrypt 1996), 805 2 May 1996. 807 [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", 808 CryptoBytes Vol. 2, No. 2, Summer 1996. 810 [IAB-REPORT] 811 Andersson, L., Davies, E., and L. Zhang, "Report from the 812 IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 813 4948, August 2007. 815 [NETCONF-SSH] 816 Wasserman, M., "NETCONF over SSH", RFC 6242, June 2011. 818 [NMDA] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watson, K., 819 and R. Wilton, "Network Management Datastore 820 Architecture", draft-ietf-netmod-revised-datastores-01.txt 821 (work in progress), March 2017. 823 [NTP-PROTO] 824 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 825 Time Protocol Version 4: Protocol and Algorithms 826 Specification", RFC 5905, June 2010. 828 [OSPFV3-AUTH] 829 Bhatia, M., Manral, V., and A. Lindem, "Supporting 830 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 832 [RESTCONF] 833 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 834 Protocol", RFC 8040, January 2017. 836 [SHA-SEC-CON] 837 Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 838 Considerations for the SHA-0 and SHA-1 Message-Digest 839 Algorithms", RFC 6194, February 2011. 841 [TCP-AO] Touch, J., Mankin, A., and R. Bonica, "The TCP 842 Authentication Option", RFC 5925, June 2010. 844 [TCP-AO-ALGORITHMS] 845 Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 846 for the TCP Authentication Option (TCP-AO)", RFC 5926, 847 June 2010. 849 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 850 (TLS) Protocol", RFC 5246, August 2008. 852 [YANG-CRYPTO-KEYTABLE] 853 Chen, I., "YANG Data Model for RFC 7210 Key Table", draft- 854 chen-rtg-key-table-yang-00.txt (work in progress), 855 November 2015. 857 Appendix A. Examples 859 A.1. Simple Key Chain with Always Valid Single Key 861 862 863 864 865 keychain-no-end-time 866 867 A key chain with a single key that is always valid for tx/rx 868 869 870 100 871 872 873 874 875 876 hmac-sha-256 877 878 keystring_in_ascii_100 879 880 881 882 883 885 A.2. Key Chain with Keys having Different Lifetimes 886 887 888 889 890 keychain2 891 892 A key chain where each key contains different send time 893 and accept time and a different algorithm illustrating 894 algorithm agility 895 896 897 35 898 899 900 2017-01-01T00:00:00Z 901 2017-02-01T00:00:00Z 902 903 904 2016-12-31T23:59:55Z 905 2017-02-01T00:00:05Z 906 907 908 hmac-sha-256 909 910 keystring_in_ascii_35 911 912 913 914 36 915 916 917 2017-02-01T00:00:00Z 918 2017-03-01T00:00:00Z 919 920 921 2017-01-31T23:59:55Z 922 2017-03-01T00:00:05Z 923 924 925 hmac-sha-512 926 927 fe:ed:be:af:36 928 929 930 931 932 934 A.3. Key Chain with Independent Send and Accept Lifetimes 936 937 938 939 940 keychain2 941 942 A key chain where each key contains different send time 943 and accept time 944 945 946 35 947 948 949 2017-01-01T00:00:00Z 950 2017-02-01T00:00:00Z 951 952 953 2016-12-31T23:59:55Z 954 2017-02-01T00:00:05Z 955 956 957 hmac-sha-256 958 959 keystring_in_ascii_35 960 961 962 963 36 964 965 966 2017-02-01T00:00:00Z 967 2017-03-01T00:00:00Z 968 969 970 2017-01-31T23:59:55Z 971 2017-03-01T00:00:05Z 972 973 974 hmac-sha-256 975 976 fe:ed:be:af:36 977 978 979 980 981 983 Appendix B. Acknowledgments 985 The RFC text was produced using Marshall Rose's xml2rfc tool. 987 Thanks to Brian Weis for fruitful discussions on security 988 requirements. 990 Thanks to Ines Robles for Routing Directorate QA review comments. 992 Thanks to Ladislav Lhotka for YANG Doctor comments. 994 Thanks to Martin Bjorklund for additional YANG Doctor comments. 996 Thanks to Tom Petch for comments during IETF last call. 998 Thanks to Matthew Miller for comments made during the Gen-ART review. 1000 Thanks to Vincent Roca for comments made during the Security 1001 Directorate review. 1003 Authors' Addresses 1005 Acee Lindem (editor) 1006 Cisco Systems 1007 301 Midenhall Way 1008 Cary, NC 27513 1009 USA 1011 Email: acee@cisco.com 1013 Yingzhen Qu 1014 Huawei 1016 Email: yingzhen.qu@huawei.com 1018 Derek Yeung 1019 Arrcus, Inc 1021 Email: derek@arrcus.com 1023 Ing-Wher Chen 1024 Jabil 1026 Email: ing-wher_chen@jabil.com 1027 Jeffrey Zhang 1028 Juniper Networks 1029 10 Technology Park Drive 1030 Westford, MA 01886 1031 USA 1033 Email: zzhang@juniper.net