idnits 2.17.1 draft-acee-rtg-yang-key-chain-00.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 == Line 466 has weird spacing: '...age for the...' -- The document date (December 1, 2014) is 3433 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 (~~), 2 warnings (==), 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: June 4, 2015 Cisco Systems 6 I. Chen 7 Ericsson 8 J. Zhang 9 Juniper Networks 10 Y. Yang 11 Cisco Systems 12 December 1, 2014 14 Key Chain YANG Data Model 15 draft-acee-rtg-yang-key-chain-00.txt 17 Abstract 19 This document describes the key chain YANG data model. Industry 20 standard key chains are lists of keys, send lifetimes, accept 21 lifetimes, and algorithms. By properly overlapping the send and 22 accept lifetimes of multiple key chain entries, keys and algorithms 23 may be gracefully updated. By representing them in a YANG data 24 model, key distribution can be automated. Key chains are commonly 25 used for routing protocol authentication and other applications. In 26 some applications, the protocols do not directly use the key chain 27 entry keys, but rather a key derivation function is used to derive a 28 short-lived key from the key-chain 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 June 4, 2015. 47 Copyright Notice 48 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 65 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Graceful Key Rollover using Key Chains . . . . . . . . . . 4 67 3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 5 68 4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . . 7 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 74 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 77 1. Introduction 79 This document describes the key chain YANG data model. Industry 80 standard key chains are lists of keys, send lifetimes, accept 81 lifetimes, and algorithms. By properly overlapping the send and 82 accept lifetimes of multiple key chain entries, keys and algorithms 83 may be gracefully updated. By representing them in a YANG data 84 model, key distribution can be automated. Key chains are commonly 85 used for routing protocol authentication and other applications. In 86 some applications, the protocols do not directly use the key chain 87 entry keys, but rather a key derivation function is used to derive a 88 short-lived key from the key-chain key. 90 1.1. Requirements Notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC-KEYWORDS]. 96 2. Problem Statement 98 This document describes a YANG [YANG] data model for key chains. Key 99 chains have been implemented and deployed by a large percentage of 100 network equipment vendors. Providing a standard YANG model will 101 facilitate automated key distribution and non-disruptive key 102 rollover. This will aid in tightening the security the of the core 103 routing infrastructure as recommended in [IAB-REPORT]. 105 A key-chain is a list of containing one or more keys, Key IDs, their 106 send/accept lifetimes, and the associated algorithm. A conceptual 107 representation of a crypto key table is described in 108 [CRYPTO-KEYTABLE]. The key chain model presented herein represents a 109 practical implementation of the crypto key table. However, the key 110 selection is left to the using applications which is more inline with 111 the current operational models. 113 2.1. Graceful Key Rollover using Key Chains 115 Key chains may be used to gracefully update key and/or algorithms. 116 This MAY be accomplished by accepting all the keys that have a valid 117 accept lifetime and sending the key with the most recent send life 118 time. One scenario for key rollover would be: 120 1. Distribute a key chain with a new key to all the routers or other 121 networking devices in the domain of that key chain. The new 122 key's accept lifetime should be such that it is accepted during 123 the key rollover period. The send lifetime should be a time in 124 the future when it can be assured that all the routers in the 125 domain of that key are upgraded. This will have no immediate 126 impact on the keys used for transmission. 128 2. Assure that all the network devices have been updated with the 129 updated key chain and that their system times are roughly 130 synchronized. The system times of devices within an 131 administrative domain are commonly synchronized using Network 132 Time Protocol [NTP-PROTO]. This also may be automated. 134 3. When the send lifetime of the new key becomes valid, the network 135 devices within the domain of the key chain will start sending the 136 new key. 138 4. At some point in the future, a new key chain with the old key 139 removed may be distributed to the the network devices within the 140 domain of the key chain. However, this may be deferred until the 141 next key rollover. If this is done, the key chain will include 142 two keys; either the current and future key during rollover 143 periods or the current and previous keys the rest of the time. 145 3. Design of the Key Chain Model 147 The ietf-keychain module contains a list of one or more keys indexed 148 by a Key ID. For some applications (e.g., OSPFv3 [OSPFV3-AUTH]), the 149 Key-Id is used to identify the key-chain entry to be used. In 150 addition to the Key-ID, each key-chain entry includes a key-string. 151 Optionally, the keys send/accept lifetimes and a cryptographic 152 algorithm. If the send/accept lifetime is unspecified, the key is 153 always considered valid. 155 Note that asymmetric keys, i.e., a different key value used for 156 transmission versus acceptance, may be supported with multiple key- 157 chain entries where the accept-lifetime or send-lifetime is not valid 158 (e.g., has an end-time equal to the start-time). 160 +--rw key-chain 161 +--rw key-chain* [name] 162 +--rw name string 163 +--rw accept-tolerance {accept-tolerance}? 164 | +--rw (limit)? 165 | +--:(infinite) 166 | | +--rw infinite? empty 167 | +--:(duration) 168 | +--rw duration? yang:timeticks 169 +--rw key* [key-id] 170 +--rw key-id uint64 171 +--rw key-string 172 | +--rw (key-string-style)? 173 | +--:(keystring) 174 | | +--rw keystring? string 175 | +--:(hexadecimal) {hex-key-string}? 176 | +--rw hexadecimal-string? yang:hex-string 177 +--rw accept-lifetime 178 | +--rw (lifetime)? 179 | +--:(always) 180 | | +--rw always? empty 181 | +--:(start-end-time) 182 | +--rw start-date-time? yang:date-and-time 183 | +--rw (end-time)? 184 | +--:(infinite) 185 | | +--rw no-end-time? empty 186 | +--:(duration) 187 | | +--rw duration? uint32 188 | +--:(end-date-time) 189 | +--rw end-date-time? yang:date-and-time 190 +--rw send-lifetime 191 | +--rw (lifetime)? 192 | +--:(always) 193 | | +--rw always? empty 194 | +--:(start-end-time) 195 | +--rw start-date-time? yang:date-and-time 196 | +--rw (end-time)? 197 | +--:(infinite) 198 | | +--rw no-end-time? empty 199 | +--:(duration) 200 | | +--rw duration? uint32 201 | +--:(end-date-time) 202 | +--rw end-date-time? yang:date-and-time 203 +--rw crypto-algorithm? enumeration {cryptographic-algorithm}? 205 4. Key Chain YANG Model 207 module ietf-key-chain { 208 namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain"; 209 // replace with IANA namespace when assigned 210 prefix key-chain; 212 import ietf-yang-types { 213 prefix "yang"; 214 } 216 import ietf-routing { 217 prefix "rt"; 218 } 220 organization 221 "Cisco Systems 222 170 West Tasman Drive 223 San Jose, CA 95134-1706 224 USA"; 225 contact 226 "Derek Yeung myeung@cisco.com"; 228 description 229 "This YANG module defines the generic configuration 230 data for key-chain. It is intended that the module 231 will be extended by vendors to define vendor-specific 232 key-chain configuration parameters. 233 "; 235 revision 2014-11-22 { 236 description 237 "Initial revision."; 238 reference 239 "RFC XXXX: A YANG Data Model for key-chain"; 240 } 242 feature cryptographic-algorithm { 243 description 244 "Support cryptographic algorithm."; 245 } 247 feature hex-key-string { 248 description 249 "Support hesadecimal key string."; 250 } 252 feature accept-tolerance { 253 description 254 "To specify the tolerance or acceptance limit."; 255 } 257 grouping lifetime { 258 description 259 "Key lifetime specification."; 260 choice lifetime { 261 default always; 262 case always { 263 leaf always { 264 type empty; 265 } 266 description 267 "Key is always valid."; 268 } 269 case start-end-time { 270 leaf start-date-time { 271 type yang:date-and-time; 272 description "Start time."; 273 } 274 choice end-time { 275 default infinite; 276 description 277 "End-time setting."; 278 case infinite { 279 leaf no-end-time { 280 type empty; 281 } 282 description 283 "Never expires."; 284 } 285 case duration { 286 leaf duration { 287 type uint32 { 288 range "1..2147483646"; 289 } 290 description "Key lifetime duration, in seconds"; 291 } 292 } 293 case end-date-time { 294 leaf end-date-time { 295 type yang:date-and-time; 296 description "End time."; 297 } 298 } 299 } 300 } 302 } 303 } 305 container key-chain { 306 description 307 "Container for key chains."; 309 list key-chain { 310 key "name"; 311 description 312 "A key-chain is a sequence of keys that are collectively 313 managed for authentication."; 315 leaf name { 316 type string; 317 description "Name of the key-chain."; 318 } 320 container accept-tolerance { 321 if-feature accept-tolerance; 322 choice limit { 323 case infinite { 324 leaf infinite { 325 type empty; 326 description 327 "The accept key never expires."; 328 } 329 } 330 case duration { 331 leaf duration { 332 type yang:timeticks; 333 description 334 "Tolerance range, in seconds."; 335 } 336 } 337 } 338 } 340 list key { 341 key "key-id"; 342 description "One key."; 343 leaf key-id { 344 type uint64; 345 description "Key id."; 346 } 347 container key-string { 348 description "The key string."; 349 choice key-string-style { 350 description 351 "Key string styles"; 352 case keystring { 353 leaf keystring { 354 type string; 355 description 356 "A string."; 357 } 358 } 359 case hexadecimal { 360 if-feature hex-key-string; 361 leaf hexadecimal-string { 362 type yang:hex-string; 363 description 364 "Hexadecimal string."; 365 } 366 } 367 } 368 } 369 container accept-lifetime { 370 description "Specify accept lifetime."; 371 uses lifetime; 372 } 373 container send-lifetime { 374 description "Specify send lifetime."; 375 uses lifetime; 376 } 378 leaf crypto-algorithm { 379 if-feature cryptographic-algorithm; 380 type enumeration { 381 enum hmac-md5 { 382 description "The hmac-md5 algorithm."; 383 } 384 enum hmac-sha1-12 { 385 description "The hmac-sha1-12 algorithm."; 386 } 387 enum hmac-sha1-20 { 388 description "The hmac-sha1-20 algorithm."; 389 } 390 enum md5 { 391 description "The md5 algorithm."; 392 } 393 enum sha-1 { 394 description "The sha-1 algorithm."; 395 } 396 enum hmac-sha-1 { 397 description "HMAC-SHA-1 authentication algorithm."; 399 } 400 enum hmac-sha-256 { 401 description "HMAC-SHA-256 authentication algorithm."; 402 } 403 enum hmac-sha-384 { 404 description "HMAC-SHA-384 authentication algorithm."; 405 } 406 enum hmac-sha-512 { 407 description "HMAC-SHA-512 authentication algorithm."; 408 } 409 } 410 description "The crypto algorithm used."; 411 } 412 } 413 } 414 } 415 } 417 5. Security Considerations 419 This document enable the automated distribution of industry standard 420 key chains using the NETCONF [NETCONF] protocol. As such, the 421 security considerations for the NETCONF protocol are applicable. 422 Given that the key chains themselves are sensitive data, it is 423 RECOMMENDED that the NETCONF communication channel be encrypted. One 424 way to do accomplish this would be to invoke and run NETCONF over SSH 425 as described in [NETCONF-SSH]. 427 6. IANA Considerations 429 This document registers a URI in the IETF XML registry 430 [XML-REGISTRY]. Following the format in RFC 3688, the following 431 registration is requested to be made: 433 URI: urn:ietf:params:xml:ns:yang:ietf-key-chain 435 Registrant Contact: The IESG. 437 XML: N/A, the requested URI is an XML namespace. 439 This document registers a YANG module in the YANG Module Names 440 registry [YANG]. 442 name: ietf-acl namespace: 443 urn:ietf:params:xml:ns:yang:ietf-key-chain prefix: ietf-key-chain 444 reference: RFC XXXX 446 7. References 448 7.1. Normative References 450 [NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 451 Bierman, "Network Configuration Protocol (NETCONF)", 452 RFC 6241, June 2011. 454 [NETCONF-SSH] 455 Wasserman, M., "Using NETCONF Protocol over Secure Shell 456 (SSH)", RFC 6242, June 2011. 458 [RFC-KEYWORDS] 459 Bradner, S., "Key words for use in RFC's to Indicate 460 Requirement Levels", BCP 14, RFC 2119, March 1997. 462 [XML-REGISTRY] 463 Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 464 January 2004. 466 [YANG] Bjorklund, M., "YANG - A Data Modeling Language for the 467 Network Configuration Protocol (NETCONF)", RFC 6020, 468 October 2010. 470 7.2. Informative References 472 [CRYPTO-KEYTABLE] 473 Housley, R., Polk, T., Hartman, S., and D. Zhang, "Table 474 of Cryptographic Keys", RFC 7210, April 2014. 476 [IAB-REPORT] 477 Andersson, L., Davies, E., and L. Zhang, "Report from the 478 IAB workshop on Unwanted Traffic March 9-10, 2006", 479 RFC 4948, August 2007. 481 [NTP-PROTO] 482 Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 483 Time Protocol Version 4: Protocol and Algorithms 484 Specification", RFC 5905, June 2010. 486 [OSPFV3-AUTH] 487 Bhatia, M., Manral, V., and A. Lindem, "Supporting 488 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 490 Appendix A. Acknowledgments 492 The RFC text was produced using Marshall Rose's xml2rfc tool. 494 Authors' Addresses 496 Acee Lindem (editor) 497 Cisco Systems 498 301 Midenhall Way 499 Cary, NC 27513 500 USA 502 Email: acee@cisco.com 504 Yingzhen Qu 505 Cisco Systems 506 170 West Tasman Drive 507 San Jose, CA 95134 508 USA 510 Email: yiqu@cisco.com 512 Derek Yeung 513 Cisco Systems 514 170 West Tasman Drive 515 San Jose, CA 95134 516 USA 518 Email: myeung@cisco.com 520 Ing-Wher Chen 521 Ericsson 523 Email: ing-wher.chen@ericsson.com 525 Jeffrey Zhang 526 Juniper Networks 527 10 Technology Park Drive 528 Westford, MA 01886 529 USA 531 Email: zzhang@juniper.net 532 Yi Yang 533 Cisco Systems 534 7025 Kit Creek Road 535 Research Triangle Park, NC 27709 536 USA 538 Email: yiya@cisco.com