idnits 2.17.1 draft-ietf-karp-crypto-key-table-08.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 194: '...tion of key material. The KDF MAY use...' RFC 2119 keyword, line 196: '... or received but MUST NOT depend on ot...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 127 has weird spacing: '...defines the f...' == Line 141 has weird spacing: '...defines the f...' -- The document date (15 July 2013) is 3938 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 informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Housley 3 Internet Engineering Task Force (IETF) Vigil Security 4 Intended Status: Standards Track T. Polk 5 NIST 6 S. Hartman 7 Painless Security 8 D. Zhang 9 Huawei 10 Expires: 15 January 2014 15 July 2013 12 Database of Long-Lived Symmetric Cryptographic Keys 13 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Abstract 52 This document specifies the information contained in a conceptual 53 database of long-lived cryptographic keys used by many different 54 security protocols. The database is designed to support both manual 55 and automated key management. In addition to describing the schema 56 for the database, this document describes the operations that can be 57 performed on the database as well as the requirements for the 58 security protocols that wish to use the database. In many typical 59 scenarios, the security protocols do not directly use the long-lived 60 key, but rather a key derivation function is used to derive a short- 61 lived key from a long-lived key. 63 1. Introduction 65 This document specifies the information that needs to be included in 66 a database of long-lived cryptographic keys in order to key the 67 authentication of security protocols such as cryptographic 68 authentication for routing protocols. This conceptual database is 69 designed to separate protocol-specific aspects from both manual and 70 automated key management. The intent is to allow many different 71 implementation approaches to the specified cryptographic key 72 database, while simplifying specification and heterogeneous 73 deployments. This conceptual database avoids the need to build 74 knowledge of any security protocol into key management protocols. It 75 minimizes protocol-specific knowledge in operational/management 76 interfaces, but it constrains where that knowledge can appear. 77 Textual conventions are provided for the representation of keys and 78 other identifiers. These conventions should be used when presenting 79 keys and identifiers to operational/management interfaces or reading 80 keys/identifiers from these interfaces. It is an operational 81 requirement that all implementations represent the keys and key 82 identifiers in the same way so that cross-vendor configuration 83 instructions can be provided. 85 Security protocols such as TCP-AO [RFC5925] are expected to use per- 86 connection state. Implementations may need to supply keys to the 87 protocol-specific databases as the associated entries in the 88 conceptual database are manipulated. In many instances, the long- 89 lived keys are not used directly in security protocols, but rather a 90 key derivation function is used to derive short-lived key from the 91 long-lived keys in the database. In other instances, security 92 protocols will directly use the long-lived key from the database. 93 The database design supports both use cases. 95 2. Conceptual Database Structure 97 The database is characterized as a table, where each row represents a 98 single long-lived symmetric cryptographic key. Normally, each key 99 should only have one row. Only in the (hopefully) very rare cases 100 where a key is used for more than one purpose, or where the same key 101 is used with multiple key derivation functions (KDFs) will multiple 102 rows contain the same key value. The columns in the table represent 103 the key value and attributes of the key. 105 To accommodate manual key management, the format of the fields has 106 been purposefully chosen to allow updates with a plain text editor 107 and to provide equivalent display on multiple systems. 109 The columns that the table consists of are listed as follows: 111 AdminKeyName 112 The AdminKeyName field contains a string identifying 113 the key 114 by humans. The same string can be used on the local 115 system 116 and peer systems, but this is not required. Protocols 117 do not 118 make use of this string; protocols use the 119 LocalKeyName and 120 the PeerKeyName. Implementations can use this field to 121 uniquely identify rows in the key table. 123 LocalKeyName 124 The LocalKeyName field contains a string identifying the key. 125 It can be used to retrieve the key in the local database when 126 received in a message. As discussed in Section 4, the 127 protocol defines the form of this field. For example, many 128 routing protocols restrict the format of their key names to 129 integers that can be represented in 16 or 32 bits. Typically 130 this field does not contain data in human character sets 131 requiring internationalization. If there ever are any 132 Protocols with key names requiring internationalization, those 133 specifications need to address issues of canonicalization and 134 normalization so that key names can be compared using binary 135 comparison. 137 PeerKeyName 138 For unicast communication, the PeerKeyName of a key on a system 139 matches the LocalKeyName of the identical key that is 140 maintained on one or multiple peer systems. Similar to 141 LocalKeyName, a protocol defines the form of this identifier 142 and will often restrict it to be an integer. For group keys, 143 the protocol will typically require this field be an empty 144 string as the sending and the receiving key names need to be 145 the same. 147 Peers 148 Typically for unicast keys, this field lists the peer systems 149 that have this key in their database. For group keys this field 150 names the groups for which the key is appropriate. For example, 151 this might name a routing area for a multicast routing 152 protocol. Formally, this field provides a protocol-specific set 153 of restrictions on the scope in which the key is appropriate. 154 The format of the identifiers in the Peers field is specified 155 by the protocol. 157 Interfaces 158 The Interfaces field identifies the set of physical and/or 159 virtual interfaces for which it is appropriate to use this key. 160 When the long-lived value in the Key field is intended for use 161 on any interface, this field is set to "all". The interfaces 162 field consists of a set of strings; the form of these strings 163 is specified by the implementation and is independent of the 164 protocol in question. Protocols may require support for the 165 interfaces field or may indicate that support for constraining 166 keys based on interface is not required. As an example, TCP-AO 167 implementations are unlikely to make the decision of what 168 interface to use prior to key selection. In this case, the 169 implementations are expected to use the same keying material 170 across all of the interfaces and then require the "all" 171 setting. 173 Protocol 174 The Protocol field identifies a single security protocol where 175 this key may be used to provide cryptographic protection. This 176 specification establishes a registry for this field; the 177 registry also specifies the format of the following field, 178 ProtocolSpecificInfo, for each registered protocol. 180 ProtocolSpecificInfo 181 This field contains the protocol-specified information which 182 may be useful for a protocol to apply the key correctly. Note 183 that such information must not be required for a protocol to 184 locate an appropriate key. When a protocol does not need the 185 information in ProtocolSpecificInfo, it will require this field 186 be empty. 188 KDF 189 The KDF field indicates the key derivation function which is 190 used to generate short-lived keys from the long-lived value in 191 the Key field. When the long-lived value in the Key field is 192 intended for direct use, the KDF field is set to "none". A key 193 derivation function is a one-way function that provides 194 cryptographic separation of key material. The KDF MAY use 195 inputs from the row in the key table and the message being sent 196 or received but MUST NOT depend on other configuration state. 197 This document establishes an IANA registry for the values in 198 the KDF field to simplify references in future specifications. 199 The protocol indicates what (if any) KDFs are valid. 201 AlgID 202 The AlgID field indicates which cryptographic algorithm to be 203 used with the security protocol for the specified peer or 204 peers. Such an algorithm can be an encryption algorithm and 205 mode (e.g., AES-128-CBC), an authentication algorithm (e.g., 206 HMAC-SHA1-96 or AES-128-CMAC), or any other symmetric 207 cryptographic algorithm needed by a security protocol. If the 208 KDF field contains "none", then the long-lived key is used 209 directly with this algorithm, otherwise the derived short-lived 210 key is used with this algorithm. When the long-lived key is 211 used to generate a set of short-lived keys for use with the 212 security protocol, the AlgID field identifies a ciphersuite 213 rather than a single cryptographic algorithm. This document 214 establishes an IANA registry for the values in the AlgID field 215 to simplify references in future specifications. Protocols 216 indicate which algorithms are appropriate. 218 Key 219 The Key field contains a long-lived symmetric cryptographic key 220 in the format of a lower-case hexadecimal string. The size of 221 the Key depends on the KDF and the AlgID. For instance, a 222 KDF=none and AlgID=AES128 requires a 128-bit key, which is 223 represented by 32 hexadecimal digits. 225 Direction 226 The Direction field indicates whether this key may be used for 227 inbound traffic, outbound traffic, both, or whether the key 228 has been disabled and may not currently be used at all. The 229 supported values are "in", "out", "both", and "disabled", 230 respectively. The Protocol field will determine which of these 231 values are valid. 233 SendLifetimeStart 234 The SendLifetimeStart field specifies the earliest date and 235 time in Coordinated Universal Time (UTC) at which this key 236 should be considered for use when sending traffic. The format 237 is YYYYMMDDHHSSZ, where four digits specify the year, two 238 digits specify the month, two digits specify the day, two 239 digits specify the hour, two digits specify the minute, and 240 two digits specify the second. The "Z" is included as a clear 241 indication that the time is in UTC. 243 SendLifeTimeEnd 244 The SendLifeTimeEnd field specifies the latest date and time at 245 which this key should be considered for use when sending 246 traffic. The format is the same as the SendLifetimeStart 247 field. 249 AcceptLifeTimeStart 250 The AcceptLifeTimeStart field specifies the earliest date and 251 time in Coordinated Universal Time (UTC) at which this key 252 should be considered for use when processing received traffic. 253 The format is YYYYMMDDHHSSZ, where four digits specify the 254 year, two digits specify the month, two digits specify the day, 255 two digits specify the hour, two digits specify the minute, and 256 two digits specify the second. The "Z" is included as a clear 257 indication that the time is in UTC. 259 AcceptLifeTimeEnd 260 The AcceptLifeTimeEnd field specifies the latest date and time 261 at which this key should be considered for use when processing 262 the received traffic. The format of this field is identical to 263 the format of AcceptLifeTimeStart. 265 3. Key Selection and Rollover 267 A protocol may directly consult the key table to find the key to use 268 on an outgoing message. The protocol provides a protocol (P) and a 269 peer identifier (H) into the key selection function. Optionally, an 270 interface identifier (I) may also need to be provided. Any key that 271 satisfies the following conditions may be selected: 273 (1) the Peers field includes H; 275 (2) the Protocol field matches P; 277 (3) If an interface is specified, the Interfaces field includes I 278 or "all"; 280 (4) the Direction field is either "out" or "both"; and 281 (5) SendLifetimeStart <= current time <= SendLifeTimeEnd. 283 During key selection, multiple entries may simultaneously exist 284 associated with different cryptographic algorithms or ciphersuites. 285 Systems should support selection of keys based on algorithm 286 preference to facilitate algorithm transition. 288 In addition, multiple entries with overlapping valid periods are 289 expected to be available for orderly key rollover. In these cases, 290 the expectation is that systems will transition to the newest key 291 available. To meet this requirement, this specification recommends 292 supplementing the key selection algorithm with the following 293 differentiation: select the long-lived key specifying the most recent 294 time in the SendLifetimeStart field. 296 In order to look up a key for verifying an incoming message, the 297 protocol provides its protocol (P), the peer identifier (H), the key 298 identifier (L), and optionally the interface (I). If one key matches 299 the following conditions it is selected: 301 (1) the Peer field includes H; 303 (2) the Protocol field matches P; 305 (3) if the Interface field is provided, it includes I or is 306 "all"; 308 (4) the Direction field is either "in" or "both"; 310 (5) the LocalKeyName is L; and 312 (6) AcceptLifeTimeStart <= current time <= AcceptLifeTimeEnd. 314 Note that the key usage is loosely bound by the times specified in 315 the AcceptLifeTimeStart and AcceptLifeTimeEnd fields. New security 316 associations should not be established except within the period of 317 use specified by these fields, while allowing some grace time for 318 clock skew. However, if a security association has already been 319 established based on a particular long-lived key, exceeding the 320 lifetime does not have any direct impact. The implementations of 321 security protocols that involve long-lived security association 322 should be designed to periodically interrogate the database and 323 rollover to new keys without tearing down the security association. 325 Rather than consulting the conceptual database, a security protocol 326 such as TCP-AO may update its own tables as keys are added and 327 removed. In this case, the protocol needs to maintain its own key 328 information. 330 4. Application of the Database in a Security Protocol 332 In order to use the key table database in a protocol specification, a 333 protocol needs to specify certain information. This section 334 enumerates items that a protocol must specify. 336 (1) The ways of mapping the information in a key table row to the 337 information needed to produce an outgoing message; specified 338 either as an explanation of how to fill in authentication-related 339 fields in a message based on key table information, or for 340 protocols such as TCP-AO how to construct Master Key Tuples (MKTs) 341 or other protocol-specific structures from a key table row 343 (2) The ways of locating the peer identifier (a member of the 344 Peers set) and the LocalKeyName inside an incoming message 346 (3) The methods of verifying a message given a key table row; 347 this may be stated directly or in terms of protocol-specific 348 structures such as MKTs 350 (4) The form and validation rules for LocalKeyName and 351 PeerKeyName; if either of these is an integer, the conventions in 352 Section 5.1 are used as a vendor-independent format 354 (5) The form and validation rules for members of the Peers set 356 (6) The algorithms and KDFs supported 358 (7) The form of the ProtocolSpecifics field 360 (8) The rules for canonicalizing LocalKeyName, PeerKeyName, 361 entries in the Peers set, or ProtocolSpecifics; this may include 362 normalizations such as lower-casing hexadecimal strings 364 (9) The Indication whether the support for Interfaces is required 365 by this protocol 367 The form of the interfaces field is not protocol-specific but instead 368 is shared among all protocols on an implementation. If a protocol 369 needs to distinguish instances running over the same interface, this 370 is included in the specification of peers. Generally it is desirable 371 to define the specification of peers so that an operator can use the 372 interfaces field to refer to all instances of a protocol on a link 373 without having to specify both generic interfaces information and 374 protocol-specific peer information. 376 5. Textual Conventions 378 5.1 Key Names 380 When a key for a given protocol is identified by an integer key 381 identifier, the associated key name will be represented as lower case 382 hexadecimal integers with the most significant octet first. This 383 integer is padded with leading 0's until the width of the key 384 identifier field in the protocol is reached. 386 5.2 Keys 388 A key is represented as a lower-case hexadecimal string with the most 389 significant octet of the key first. As discussed in Section 2, the 390 length of this string depends on the associated algorithm and KDF. 392 6. Operational Considerations 394 If the valid periods for long-lived keys do not overlap or the system 395 clocks are inconsistent, it is possible to construct scenarios where 396 systems cannot agree upon a long-lived key. When installing a series 397 of keys to be used one after another, operators should configure the 398 SendLifetimeStart field of the key to be several hours after the 399 AcceptLifeTimeStart field of the key to guarantee there is some 400 overlap. This overlap is intended to address the clock skew issue and 401 allow for basic operational considerations. Operators may choose to 402 specify a longer overlap (e.g., several days) to allow for 403 exceptional circumstances. 405 7. Security Considerations 407 Management of encryption and authentication keys has been a 408 significant operational problem, both in terms of key synchronization 409 and key selection. For instance, the current guidance [RFC3562] 410 warns against sharing TCP MD5 keying material between systems, and 411 recommends changing keys according to a schedule. The same general 412 operational issues are relevant for the management of other 413 cryptographic keys. 415 It has been recognized in [RFC4107] that automated key management is 416 not viable in multiple scenarios. The conceptual database specified 417 in this document is designed to accommodate both manual key 418 management and automated key management. A future specification to 419 automatically populate rows in the database is envisioned. 421 Designers should recognize the warning provided in [RFC4107]: 423 Automated key management and manual key management provide very 424 different features. In particular, the protocol associated with 425 an automated key management technique will confirm the liveness of 426 the peer, protect against replay, authenticate the source of the 427 short-term session key, associate protocol state information with 428 the short-term session key, and ensure that a fresh short-term 429 session key is generated. Moreover, an automated key management 430 protocol can improve the interoperability by including negotiation 431 mechanisms for cryptographic algorithms. These valuable features 432 are impossible or extremely cumbersome to accomplish with manual 433 key management. 435 8. IANA Considerations 437 This specification defines three registries. 439 8.1. KeyTable Protocols 440 This document requests establishment of a registry called "KeyTable 441 Protocols". The following subsection describes the registry; the 442 second subsection provides initial values for IEEE 802.1X CAK. 444 8.1.1. KeyTable Protocols Registry Definition 446 All assignments to the KeyTable Protocols registry are made on a 447 specification required basis per Section 4.1 of [RFC5226]. 449 Each registration entry must contain the three fields: 451 - Protocol Name (unique within the registry); 452 - Specification; and 453 - Protocol Specific Info. 455 The specification needs to describe parameters required for using the 456 conceptual database as outlined in Section 4. This typically means 457 that the specification focuses more on the application of security 458 protocols with the key tables rather than being a new security 459 protocol specification for general purposes. New protocols may of 460 course combine information on how to use the key tables database with 461 the protocol specification. 463 8.1.2. KeyTable Protocols Registry Initial Values 465 The registry has three columns. The first column is a string of UTF-8 466 characters representing the name protocol. The second column is a 467 string of UTF-8 characters providing a brief description of Protocol 468 Specific Info. The third column is a reference to a specification 469 defining the protocol. 471 Protocol Protocol Specific Info Reference 472 -------- ---------------------- --------- 473 IEEE 802.1X CAK KMD (A string of up to [IEEE802.1X-2010] 474 253 UTF-8 characters 475 that names the trans- 476 mitting authentica- 477 tor's key management 478 domain, or null) and 479 NID (A string of up to 480 100 UTF-8 characters 481 that identifies a net- 482 work service or null, 483 indicating the key is 484 associated with a 485 default service.) 487 8.2. KeyTable KDFs 489 This document requests the establishment of a registry called 490 "KeyTable KDFs". The remainder of this section describes the reg- 491 istry. 493 All assignments to the KeyTable KDFs registry are made on a First 494 Come First Served basis per Section 4.1 of RFC 5226. 496 The registry has three columns. The first column is a string of UTF-8 497 characters representing the name of a KDF. The second column is a 498 string of UTF-8 characters providing a brief description of the KDF. 499 The third column is a reference to a specification defining the KDF, 500 if available. 502 KDF Description Reference 503 --- ----------- --------- 504 none No KDF is used with this key 505 802.1X-01 IEEE 802.1X Table 9.1 [IEEE802.1X-2010] 507 8.3. KeyTable AlgIDs 509 This document requests establishment of a registry called "KeyTable 510 AlgIDs". The remainder of this section describes the registry. 512 All assignments to the KeyTable AlgIDs registry are made on a First 513 Come First Served basis per Section 4.1 of RFC 5226. 515 The registry has three columns. The first column is a string of UTF-8 516 characters representing the name of an AlgID. The second column is a 517 string of UTF-8 characters providing a brief description of the 518 AlgID. The third column is a reference to a specification defining 519 the AlgID, if available. 521 AlgID Description Reference 522 ----- ----------- --------- 523 AES-128-CMAC AES-CMAC using 128-bit keys [RFC4493] 525 9. Acknowledgments 527 This document reflects many discussions with many different people 528 over many years. In particular, the authors thank Jari Arkko, Ran 529 Atkinson, Ron Bonica, Ross Callon, Lars Eggert, Pasi Eronen, Adrian 530 Farrel, Gregory Lebovitz, Acee Lindem, Sandy Murphy, Eric Rescorla, 531 Mike Shand, Dave Ward, and Brian Weis for their insights. The 532 authors additionally thank Brian Weis for supplying text to address 533 IANA concerns and for help with formatting. 535 Sam Hartman's work on this draft is funded by Huawei. 537 10. Informational References 539 [IEEE802.1X-2010] IEEE Standard for Local and Metropolitan Area Networks -- 540 Port-Based Network Access Control", February 2010. 542 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 543 Signature Option", RFC 3562, July 2003. 545 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 546 Key Management", RFC 4107, BCP 107, June 2005. 548 [RFC4493] Song, J., Lee, J., Poovendran, R., and T. Iwata, "The AES-CMAC 549 Algorithm", RFC 4493, June 2006. 551 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 552 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 553 May 2008. 555 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 556 Authentication Option", RFC 5925, June 2010. 558 Authors' Addresses 560 Russell Housley 561 Vigil Security, LLC 562 918 Spring Knoll Drive 563 Herndon, VA 20170 564 USA 565 EMail: housley@vigilsec.com 567 Tim Polk 568 National Institute of Standards and Technology 569 100 Bureau Drive, Mail Stop 8930 570 Gaithersburg, MD 20899-8930 571 USA 572 EMail: tim.polk@nist.gov 574 Sam Hartman 575 Painless Security, LLC 576 USA 577 Email: hartmans@painless-security.com 579 Dacheng Zhang 580 Huawei 581 China 582 Email: zhangdacheng@huawei.com