idnits 2.17.1 draft-acee-rtg-yang-key-chain-05.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 (June 29, 2015) is 3224 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem, Ed. 3 Internet-Draft Y. Qu 4 Intended status: Standards Track D. Yeung 5 Expires: December 31, 2015 Cisco Systems 6 I. Chen 7 Ericsson 8 J. Zhang 9 Juniper Networks 10 Y. Yang 11 Cisco Systems 12 June 29, 2015 14 Key Chain YANG Data Model 15 draft-acee-rtg-yang-key-chain-05.txt 17 Abstract 19 This document describes the key chain YANG data model. A key chain 20 is a list of elements each containing a key, send lifetime, accept 21 lifetime, and algorithm. By properly overlapping the send and accept 22 lifetimes of multiple key chain elements, keys and algorithms may be 23 gracefully updated. By representing them in a YANG data model, key 24 distribution can be automated. Key chains are commonly used for 25 routing protocol authentication and other applications. In some 26 applications, the protocols do not use the key chain element key 27 directly, but rather a key derivation function is used to derive a 28 short-lived key from the key chain element key. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 31, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 66 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Graceful Key Rollover using Key Chains . . . . . . . . . 3 68 3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 4 69 3.1. Key Chain Operational State . . . . . . . . . . . . . . . 5 70 3.2. Key Chain Model Tree . . . . . . . . . . . . . . . . . . 5 71 4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 8 72 5. Relationship to other Work . . . . . . . . . . . . . . . . . 14 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 77 8.2. Informative References . . . . . . . . . . . . . . . . . 16 78 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 This document describes the key chain YANG data model. A key chain 84 is a list of elements each containing a key, send lifetime, accept 85 lifetime, and algorithm. By properly overlapping the send and accept 86 lifetimes of multiple key chain elements, keys and algorithms may be 87 gracefully updated. By representing them in a YANG data model, key 88 distribution can be automated. Key chains are commonly used for 89 routing protocol authentication and other applications. In some 90 applications, the protocols do not use the key chain element key 91 directly, but rather a key derivation function is used to derive a 92 short-lived key from the key chain element key. 94 1.1. Requirements Notation 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC-KEYWORDS]. 100 2. Problem Statement 102 This document describes a YANG [YANG] data model for key chains. Key 103 chains have been implemented and deployed by a large percentage of 104 network equipment vendors. Providing a standard YANG model will 105 facilitate automated key distribution and non-disruptive key 106 rollover. This will aid in tightening the security of the core 107 routing infrastructure as recommended in [IAB-REPORT]. 109 A key chain is a list containing one or more elements containing a 110 Key ID, key, send/accept lifetimes, and the associated authentication 111 or encryption algorithm. A key chain can be used by any service or 112 application requiring authentication or encryption. In essence, the 113 key-chain is a reusable key policy that can be referenced where ever 114 it is required. The key-chain construct has been been implemented by 115 most networking vendors and deployed in many networks. 117 A conceptual representation of a crypto key table is described in 118 [CRYPTO-KEYTABLE]. The crypto key table also includes keys as well 119 as their corresponding lifetimes and algorithms. Additionally, the 120 key table includes key selection criteria and envisions a deployment 121 model where the details of the applications or services requiring 122 authentication or encryption permeate into the key database. The 123 YANG key-chain model described herein doesn't include key selection 124 criteria or support this deployment model. At the same time, it does 125 not preclude it. The draft [YANG-CRYPTO-KEYTABLE] describes 126 augmentations to the key chain YANG model in support of key selection 127 criteria. 129 2.1. Graceful Key Rollover using Key Chains 131 Key chains may be used to gracefully update the key and/or algorithm 132 used by an application for authentication or encryption. This MAY be 133 accomplished by accepting all the keys that have a valid accept 134 lifetime and sending the key with the most recent send lifetime. One 135 scenario for facilitating key rollover is to: 137 1. Distribute a key chain with a new key to all the routers or other 138 network devices in the domain of that key chain. The new key's 139 accept lifetime should be such that it is accepted during the key 140 rollover period. The send lifetime should be a time in the 141 future when it can be assured that all the routers in the domain 142 of that key are upgraded. This will have no immediate impact on 143 the keys used for transmission. 145 2. Assure that all the network devices have been updated with the 146 updated key chain and that their system times are roughly 147 synchronized. The system times of devices within an 148 administrative domain are commonly synchronized (e.g., using 149 Network Time Protocol (NTP) [NTP-PROTO]). This also may be 150 automated. 152 3. When the send lifetime of the new key becomes valid, the network 153 devices within the domain of key chain will start sending the new 154 key. 156 4. At some point in the future, a new key chain with the old key 157 removed may be distributed to the network devices within the 158 domain of the key chain. However, this may be deferred until the 159 next key rollover. If this is done, the key chain will always 160 include two keys; either the current and future key (during key 161 rollovers) or the current and previous keys (between key 162 rollovers). 164 3. Design of the Key Chain Model 166 The ietf-keychain module contains a list of one or more keys indexed 167 by a Key ID. For some applications (e.g., OSPFv3 [OSPFV3-AUTH]), the 168 Key-Id is used to identify the key chain entry to be used. In 169 addition to the Key-ID, each key chain entry includes a key-string 170 and a cryptographic algorithm. Optionally, the key chain entries 171 include send/accept lifetimes. If the send/accept lifetime is 172 unspecified, the key is always considered valid. 174 Note that asymmetric keys, i.e., a different key value used for 175 transmission versus acceptance, may be supported with multiple key 176 chain elements where the accept-lifetime or send-lifetime is not 177 valid (e.g., has an end-time equal to the start-time). 179 Due to the differences in key chain implementations across various 180 vendors, some of the data elements are optional. Additionally, the 181 key-chain is made a grouping so that an implementation could support 182 scoping other than at the global level. Finally, the crypto- 183 algorithm-types grouping is provided for reuse when configuring 184 legacy authentication and encryption not using key-chains. 186 A key-chain is identified by a unique name within the scope of the 187 network device. The "key-chain-ref" typedef SHOULD be used by other 188 YANG modules when they need to reference a configured key-chain. 190 3.1. Key Chain Operational State 192 The key chain operational state is maintained in the key-chain 193 entries along with the configuration state. The key string itself is 194 omitted from the operational state to minimize visibilty similar to 195 what was done with keys in SNMP MIBs. This is an area for further 196 discussion. Additionally, the operational state includes an 197 indication of whether or not a key chain entry is valid for sending 198 or acceptance. 200 3.2. Key Chain Model Tree 202 +--rw key-chains 203 +--rw key-chain-list* [name] 204 +--rw name string 205 +--ro name-state? string 206 +--rw accept-tolerance {accept-tolerance}? 207 | +--rw duration? uint32 208 +--ro accept-tolerance-state 209 | +--ro duration? uint32 210 +--rw key-chain-entry* [key-id] 211 +--rw key-id uint64 212 +--ro key-id-state? uint64 213 +--rw key-string 214 | +--rw (key-string-style)? 215 | +--:(keystring) 216 | | +--rw keystring? string 217 | +--:(hexadecimal) {hex-key-string}? 218 | +--rw hexadecimal-string? yang:hex-string 219 +--rw lifetime 220 | +--rw (lifetime)? 221 | +--:(send-and-accept-lifetime) 222 | | +--rw send-accept-lifetime 223 | | +--rw (lifetime)? 224 | | +--:(always) 225 | | | +--rw always? empty 226 | | +--:(start-end-time) 227 | | +--rw start-date-time? 228 | | | yang:date-and-time 229 | | +--rw (end-time)? 230 | | +--:(infinite) 231 | | | +--rw no-end-time? empty 232 | | +--:(duration) 233 | | | +--rw duration? uint32 234 | | +--:(end-date-time) 235 | | +--rw end-date-time? 236 | | yang:date-and-time 237 | +--:(independent-send-accept-lifetime) 238 | | {independent-send-accept-lifetime}? 239 | +--rw send-lifetime 240 | | +--rw (lifetime)? 241 | | +--:(always) 242 | | | +--rw always? empty 243 | | +--:(start-end-time) 244 | | +--rw start-date-time? 245 | | | yang:date-and-time 246 | | +--rw (end-time)? 247 | | +--:(infinite) 248 | | | +--rw no-end-time? empty 249 | | +--:(duration) 250 | | | +--rw duration? uint32 251 | | +--:(end-date-time) 252 | | +--rw end-date-time? 253 | | yang:date-and-time 254 | +--rw accept-lifetime 255 | +--rw (lifetime)? 256 | +--:(always) 257 | | +--rw always? empty 258 | +--:(start-end-time) 259 | +--rw start-date-time? 260 | | yang:date-and-time 261 | +--rw (end-time)? 262 | +--:(infinite) 263 | | +--rw no-end-time? empty 264 | +--:(duration) 265 | | +--rw duration? uint32 266 | +--:(end-date-time) 267 | +--rw end-date-time? 268 | yang:date-and-time 269 +--ro lifetime-state 270 | +--ro send-lifetime 271 | | +--ro (lifetime)? 272 | | +--:(always) 273 | | | +--ro always? empty 274 | | +--:(start-end-time) 275 | | +--ro start-date-time? 276 | | yang:date-and-time 277 | | +--ro (end-time)? 278 | | +--:(infinite) 279 | | | +--ro no-end-time? empty 280 | | +--:(duration) 281 | | | +--ro duration? uint32 282 | | +--:(end-date-time) 283 | | +--ro end-date-time? 284 | | yang:date-and-time 285 | +--ro send-valid? boolean 286 | +--ro accept-lifetime 287 | | +--ro (lifetime)? 288 | | +--:(always) 289 | | | +--ro always? empty 290 | | +--:(start-end-time) 291 | | +--ro start-date-time? yang:date-and-time 292 | | +--ro (end-time)? 293 | | +--:(infinite) 294 | | | +--ro no-end-time? empty 295 | | +--:(duration) 296 | | | +--ro duration? uint32 297 | | +--:(end-date-time) 298 | | +--ro end-date-time? 299 | | yang:date-and-time 300 | +--ro accept-valid? boolean 301 +--rw crypto-algorithm 302 | +--rw (algorithm)? 303 | +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}? 304 | | +--rw hmac-sha1-12? empty 305 | +--:(md5) 306 | | +--rw md5? empty 307 | +--:(sha-1) 308 | | +--rw sha-1? empty 309 | +--:(hmac-sha-1) 310 | | +--rw hmac-sha-1? empty 311 | +--:(hmac-sha-256) 312 | | +--rw hmac-sha-256? empty 313 | +--:(hmac-sha-384) 314 | | +--rw hmac-sha-384? empty 315 | +--:(hmac-sha-512) 316 | +--rw hmac-sha-512? empty 317 +--ro crypto-algorithm-state 318 +--ro (algorithm)? 319 +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}? 320 | +--ro hmac-sha1-12? empty 321 +--:(md5) 322 | +--ro md5? empty 323 +--:(sha-1) 324 | +--ro sha-1? empty 325 +--:(hmac-sha-1) 326 | +--ro hmac-sha-1? empty 327 +--:(hmac-sha-256) 328 | +--ro hmac-sha-256? empty 329 +--:(hmac-sha-384) 330 | +--ro hmac-sha-384? empty 331 +--:(hmac-sha-512) 332 +--ro hmac-sha-512? empty 334 4. Key Chain YANG Model 336 337 module ietf-key-chain { 338 namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain"; 339 // replace with IANA namespace when assigned 340 prefix "key-chain"; 342 import ietf-yang-types { 343 prefix "yang"; 344 } 346 organization 347 "Cisco Systems 348 170 West Tasman Drive 349 San Jose, CA 95134-1706 350 USA"; 351 contact 352 "Acee Lindem - acee@cisco.com"; 354 description 355 "This YANG module defines the generic configuration 356 data for key-chain. It is intended that the module 357 will be extended by vendors to define vendor-specific 358 key-chain configuration parameters. 359 "; 361 revision 2015-06-29 { 362 description 363 "Updated version. Added Operation State following 364 draft-openconfig-netmod-opstate-00."; 365 reference 366 "RFC XXXX: A YANG Data Model for key-chain"; 367 } 368 revision 2015-02-24 { 369 description 370 "Initial revision."; 371 reference 372 "RFC XXXX: A YANG Data Model for key-chain"; 373 } 375 typedef key-chain-ref { 376 type leafref { 377 path "/key-chain:key-chains/key-chain:key-chain-list/" 378 + "key-chain:name"; 379 } 380 description 381 "This type is used by data models that need to reference 382 configured key-chains."; 383 } 385 feature hex-key-string { 386 description 387 "Support hexadecimal key string."; 388 } 390 feature accept-tolerance { 391 description 392 "To specify the tolerance or acceptance limit."; 393 } 395 feature independent-send-accept-lifetime { 396 description 397 "Support for independent send and accept key lifetimes."; 398 } 400 feature crypto-hmac-sha-1-12 { 401 description 402 "Support for TCP HMAC-SHA-1 12 byte digest hack."; 403 } 405 grouping lifetime { 406 description 407 "Key lifetime specification."; 408 choice lifetime { 409 default always; 410 description 411 "Options for specifying key accept or send lifetimes"; 412 case always { 413 leaf always { 414 type empty; 415 description 416 "Indicates key lifetime is always valid."; 417 } 418 } 419 case start-end-time { 420 leaf start-date-time { 421 type yang:date-and-time; 422 description "Start time."; 423 } 424 choice end-time { 425 default infinite; 426 description 427 "End-time setting."; 428 case infinite { 429 leaf no-end-time { 430 type empty; 431 description 432 "Indicates key lifetime end-time in infinite."; 433 } 434 } 435 case duration { 436 leaf duration { 437 type uint32 { 438 range "1..2147483646"; 439 } 440 units seconds; 441 description "Key lifetime duration, in seconds"; 442 } 443 } 444 case end-date-time { 445 leaf end-date-time { 446 type yang:date-and-time; 447 description "End time."; 448 } 449 } 450 } 451 } 452 } 453 } 455 grouping crypto-algorithm-types { 456 description "Cryptographic algorithm types."; 457 choice algorithm { 458 description 459 "Options for crytographic algorithm specification."; 460 case hmac-sha-1-12 { 461 if-feature crypto-hmac-sha-1-12; 462 leaf hmac-sha1-12 { 463 type empty; 464 description "The HMAC-SHA1-12 algorithm."; 465 } 466 } 467 case md5 { 468 leaf md5 { 469 type empty; 470 description "The MD5 algorithm."; 471 } 472 } 473 case sha-1 { 474 leaf sha-1 { 475 type empty; 476 description "The SHA-1 algorithm."; 477 } 479 } 480 case hmac-sha-1 { 481 leaf hmac-sha-1 { 482 type empty; 483 description "HMAC-SHA-1 authentication algorithm."; 484 } 485 } 486 case hmac-sha-256 { 487 leaf hmac-sha-256 { 488 type empty; 489 description "HMAC-SHA-256 authentication algorithm."; 490 } 491 } 492 case hmac-sha-384 { 493 leaf hmac-sha-384 { 494 type empty; 495 description "HMAC-SHA-384 authentication algorithm."; 496 } 497 } 498 case hmac-sha-512 { 499 leaf hmac-sha-512 { 500 type empty; 501 description "HMAC-SHA-512 authentication algorithm."; 502 } 503 } 504 } 505 } 507 grouping key-chain { 508 description 509 "key-chain specification grouping."; 510 leaf name { 511 type string; 512 description "Name of the key-chain."; 513 } 515 leaf name-state { 516 type string; 517 config false; 518 description "Configured name of the key-chain."; 519 } 521 container accept-tolerance { 522 if-feature accept-tolerance; 523 description 524 "Tolerance for key lifetime acceptance (seconds)."; 525 leaf duration { 526 type uint32; 527 units seconds; 528 default "0"; 529 description 530 "Tolerance range, in seconds."; 531 } 532 } 534 container accept-tolerance-state { 535 config false; 536 description 537 "Configured tolerance for key lifetime 538 acceptance (seconds)."; 539 leaf duration { 540 type uint32; 541 description 542 "Configured tolerance range, in seconds."; 543 } 544 } 546 list key-chain-entry { 547 key "key-id"; 548 description "One key."; 549 leaf key-id { 550 type uint64; 551 description "Key id."; 552 } 553 leaf key-id-state { 554 type uint64; 555 config false; 556 description "Configurd key id."; 557 } 558 container key-string { 559 description "The key string."; 560 choice key-string-style { 561 description 562 "Key string styles"; 563 case keystring { 564 leaf keystring { 565 type string; 566 description "Key string in ASCII format."; 567 } 568 } 569 case hexadecimal { 570 if-feature hex-key-string; 571 leaf hexadecimal-string { 572 type yang:hex-string; 573 description 574 "Key in hexadecimal string format."; 576 } 577 } 578 } 579 } 580 container lifetime { 581 description "Specify a key's lifetime."; 582 choice lifetime { 583 description 584 "Options for specification of send and accept 585 lifetimes."; 586 case send-and-accept-lifetime { 587 description 588 "Send and accept key have the same lifetime."; 589 container send-accept-lifetime { 590 uses lifetime; 591 description 592 "Single lifetime specification for both send and 593 accept lifetimes."; 594 } 595 } 596 case independent-send-accept-lifetime { 597 if-feature independent-send-accept-lifetime; 598 description 599 "Independent send and accept key lifetimes."; 600 container send-lifetime { 601 uses lifetime; 602 description 603 "Separate lifetime specification for send 604 lifetime."; 605 } 606 container accept-lifetime { 607 uses lifetime; 608 description 609 "Separate lifetime specification for accept 610 lifetime."; 611 } 612 } 613 } 614 } 615 container lifetime-state { 616 config false; 617 description "Configured key's lifetime."; 618 container send-lifetime { 619 uses lifetime; 620 description 621 "Configured send-lifetime."; 622 } 623 leaf send-valid { 624 type boolean; 625 description 626 "Status of send-lifetime."; 627 } 628 container accept-lifetime { 629 uses lifetime; 630 description 631 "Configured accept-lifetime."; 632 } 633 leaf accept-valid { 634 type boolean; 635 description 636 "Status of accept-lifetime."; 637 } 638 } 639 container crypto-algorithm { 640 uses crypto-algorithm-types; 641 description "Cryptographic algorithm associated with key."; 642 } 643 container crypto-algorithm-state { 644 config false; 645 uses crypto-algorithm-types; 646 description "Configured cryptographic algorithm."; 647 } 648 } 649 } 651 container key-chains { 652 list key-chain-list { 653 key "name"; 654 description 655 "List of key-chains."; 656 uses key-chain; 657 } 658 description "All configured key-chains for the device."; 659 } 660 } 661 663 5. Relationship to other Work 665 6. Security Considerations 667 This document enables the automated distribution of industry standard 668 key chains using the NETCONF [NETCONF] protocol. As such, the 669 security considerations for the NETCONF protocol are applicable. 670 Given that the key chains themselves are sensitive data, it is 671 RECOMMENDED that the NETCONF communication channel be encrypted. One 672 way to do accomplish this would be to invoke and run NETCONF over SSH 673 as described in [NETCONF-SSH]. 675 The key strings themselves are not included in the operatational 676 state. This is a practice carried over from SNMP MIB modules and is 677 an are for further discussion. 679 7. IANA Considerations 681 This document registers a URI in the IETF XML registry 682 [XML-REGISTRY]. Following the format in RFC 3688, the following 683 registration is requested to be made: 685 URI: urn:ietf:params:xml:ns:yang:ietf-key-chain 687 Registrant Contact: The IESG. 689 XML: N/A, the requested URI is an XML namespace. 691 This document registers a YANG module in the YANG Module Names 692 registry [YANG]. 694 name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-key- 695 chain prefix: ietf-key-chain reference: RFC XXXX 697 8. References 699 8.1. Normative References 701 [NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 702 Bierman, "Network Configuration Protocol (NETCONF)", RFC 703 6241, June 2011. 705 [NETCONF-SSH] 706 Wasserman, M., "Using NETCONF Protocol over Secure Shell 707 (SSH)", RFC 6242, June 2011. 709 [RFC-KEYWORDS] 710 Bradner, S., "Key words for use in RFC's to Indicate 711 Requirement Levels", BCP 14, RFC 2119, March 1997. 713 [XML-REGISTRY] 714 Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 715 January 2004. 717 [YANG] Bjorklund, M., "YANG - A Data Modeling Language for the 718 Network Configuration Protocol (NETCONF)", RFC 6020, 719 October 2010. 721 8.2. Informative References 723 [CRYPTO-KEYTABLE] 724 Housley, R., Polk, T., Hartman, S., and D. Zhang, 725 "Table of Cryptographic Keys", RFC 7210, April 2014. 727 [IAB-REPORT] 728 Andersson, L., Davies, E., and L. Zhang, "Report from the 729 IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 730 4948, August 2007. 732 [NTP-PROTO] 733 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 734 Time Protocol Version 4: Protocol and Algorithms 735 Specification", RFC 5905, June 2010. 737 [OSPFV3-AUTH] 738 Bhatia, M., Manral, V., and A. Lindem, "Supporting 739 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 741 [YANG-CRYPTO-KEYTABLE] 742 Chen, I., "YANG Data Model for RFC 7210 Key Table", draft- 743 chen-rtg-key-table-yang-00.txt (work in progress), March 744 2015. 746 Appendix A. Acknowledgments 748 The RFC text was produced using Marshall Rose's xml2rfc tool. 750 Authors' Addresses 752 Acee Lindem (editor) 753 Cisco Systems 754 301 Midenhall Way 755 Cary, NC 27513 756 USA 758 Email: acee@cisco.com 760 Yingzhen Qu 761 Cisco Systems 762 170 West Tasman Drive 763 San Jose, CA 95134 764 USA 766 Email: yiqu@cisco.com 767 Derek Yeung 768 Cisco Systems 769 170 West Tasman Drive 770 San Jose, CA 95134 771 USA 773 Email: myeung@cisco.com 775 Ing-Wher Chen 776 Ericsson 778 Email: ing-wher.chen@ericsson.com 780 Jeffrey Zhang 781 Juniper Networks 782 10 Technology Park Drive 783 Westford, MA 01886 784 USA 786 Email: zzhang@juniper.net 788 Yi Yang 789 Cisco Systems 790 7025 Kit Creek Road 791 Research Triangle Park, NC 27709 792 USA 794 Email: yiya@cisco.com