idnits 2.17.1 draft-ietf-karp-crypto-key-table-02.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 (30 October 2011) is 4534 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 Expires: 30 April 2012 30 October 2011 8 Database of Long-Lived Symmetric Cryptographic Keys 9 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright Notice 33 Copyright (c) 2011 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Abstract 48 This document specifies the information contained in a database of 49 long-lived cryptographic keys used by many different security 50 protocols. The database design supports both manual and automated 51 key management. In many instances, the security protocols do not 52 directly use the long-lived key, but rather a key derivation function 53 is used to derive a short-lived key from a long-lived key. 55 1. Introduction 57 This document specifies the information that needs to be included in 58 a database of long-lived cryptographic keys. This conceptual 59 database is designed to support both manual key management and 60 automated key management. The intent is to allow many different 61 implementation approaches to the specified cryptographic key 62 database. 64 Security protocols such as TCP-AO [RFC5925] are expected to use an 65 application program interface (API) to select a long-lived key from 66 the database. In many instances, the long-lived keys are not used 67 directly in security protocols, but rather a key derivation function 68 is used to derive short-lived key from the long-lived keys in the 69 database. In other instances, security protocols will directly use 70 the long-lived key from the database. The database design supports 71 both use cases. 73 2. Conceptual Database Structure 75 The database is characterized as a table, where each row represents a 76 single long-lived symmetric cryptographic key. Each key should only 77 have one row; however, in the (hopefully) very rare cases where the 78 same key is used for more than one purpose, multiple rows will 79 contain the same key value. The columns in the table represent the 80 key value and attributes of the key. 82 To accommodate manual key management, then formatting of the fields 83 has been purposefully chosen to allow updates with a plain text 84 editor. 86 The table has the following columns: 88 LocalKeyID 89 LocalKeyID is a 16-bit integer in hexadecimal. The LocalKeyID 90 can be used by a peer to identify this entry in the database. 91 For pairwise keys, the most significant bit in LocalKeyID is 92 set to zero, and the integer value must be unique among all the 93 pairwise keys in the database. For group keys, the most 94 significant bit in LocalKeyID is set to one, but collisions 95 among group key identifiers must be accommodated. 97 PeerKeyID 98 For pairwise keys, the PeerKeyID field is a 16 bit integer in 99 hexadecimal provided by the peer. If the peer has not yet 100 provided this value, the PeerKeyID is set to "unknown". For 101 group keying, the PeerKeyID field is set to "group", which 102 easily accommodates group keys generated by a third party. If 103 the protocol associated wit this key uses a keyname instead of 104 a numeric identifier, the PeerKeyID field is set to "null". 105 (Note that some protocols include keynames and numeric 106 identifiers.) 108 KeyName 109 The KeyName field is a variable length text field that 110 identifies the key material. If the value has not yet been 111 established, the KeyName field is set to the special value 112 "unknown". If the protocol associated with the key does not 113 use keynames, the KeyName field is set to "null". 115 Peers 116 The Peers field identifies the peer system or set of systems 117 that have this key configured in their own database of long- 118 lived keys. For pairwise keys, the database on the peer system 119 LocalKeyID field will contain the value specified in the 120 PeerKeyID field in the local database. For group keying, the 121 Peers field names the group, not the individual systems that 122 comprise the group. 124 Interfaces 125 The Interfaces field identifies the set of physical and/or 126 virtual interfaces for which it is appropriate to use this key. 127 When the long-lived value in the Key field is intended for use 128 on any interface, the Interfaces field is set to "all". 130 Protocol 131 The Protocol field identifies a single security protocol where 132 this key may be used to provide cryptographic protection. This 133 protocol establishes a registry for this field; the registry 134 also specifies the contents of the following field, 135 ProtcolSpecificInfo, for each registered protocol. 137 ProtocolSpecificInfo 138 The ProtocolSpecificInfo field contains a variable length 139 binary object with any protocol specific values. From the 140 perspective of the database, this is an opaque object. The 141 type and contents of the subfields are specified as part of the 142 IANA registration for the Protocol field value. 144 KDF 145 The KDF field indicates which key derivation function is used 146 to generate short-lived keys from the long-lived value in the 147 Key field. When the long-lived value in the Key field is 148 intended for direct use, the KDF field is set to "none". This 149 document establishes an IANA registry for the values in the KDF 150 field to simplify references in future specifications. 152 KDFInputs 153 The KDFInputs field is used when supplementary public or 154 private data is supplied to the KDF. For protocols that do not 155 require additional information for the KDF, the KDFInputs field 156 is set to "none". The Protocol field will determine the format 157 of this field if it is not "none". 159 AlgID 160 The AlgID field indicates which cryptographic algorithm to be 161 used with the security protocol for the specified peer. The 162 algorithm may be an encryption algorithm and mode (such as 163 AES-128-CBC), an authentication algorithm (such as HMAC-SHA1-96 164 or AES-128-CMAC), or any other symmetric cryptographic 165 algorithm needed by a security protocol. If the KDF field 166 contains "none", then the long-lived key is used directly with 167 this algorithm, otherwise the derived short-lived key is used 168 with this algorithm. When the long-lived key is used to 169 generate a set of short-lived keys for use with the security 170 protocol, the AlgID field identifies a ciphersuite rather than 171 a single cryptographic algorithm. This document establishes an 172 IANA registry for the values in the AlgID field to simplify 173 references in future specifications. 175 Key 176 The Key is a hexadecimal string representing a long-lived 177 symmetric cryptographic key. The size of the Key depends on 178 the KDF and the AlgID. For example, a KDF=none and 179 AlgID=AES128 requires a 128-bit key, which is represented by 32 180 hexadecimal digits. 182 Direction 183 The Direction field indicates whether this key may be used for 184 inbound traffic, outbound traffic, or both. The supported 185 values are "in", "out", and "both", respectively. The Protocol 186 field will determine which of these values are valid. 188 SendNotBefore 189 The NotBefore field specifies the earliest date and time in 190 Universal Coordinated Time (UTC) at which this key should be 191 considered for use when sending traffic. The format is 192 YYYYMMDDHHSSZ, where four digits specify the year, two digits 193 specify the month, two digits specify the day, two digits 194 specify the hour, and two digits specify the minute. The "Z" 195 is included as a clear indication that the time is in UTC. 197 SendNotAfter 198 The NotAfter field specifies the latest date and time at which 199 this key should be considered for use when sending traffic. 200 The format is the same as the NotBefore field. 202 RcvNotBefore 203 The NotBefore field specifies the earliest date and time in 204 Universal Coordinated Time (UTC) at which this key should be 205 considered for use when processing received traffic. The 206 format is YYYYMMDDHHSSZ, where four digits specify the year, 207 two digits specify the month, two digits specify the day, two 208 digits specify the hour, and two digits specify the minute. 209 The "Z" is included as a clear indication that the time is in 210 UTC. 212 RcvNotAfter 213 The NotAfter field specifies the latest date and time at which 214 this key should be considered for use when processing received 215 traffic. The format is the same as the NotBefore field. 217 Note that some security protocols use a KeyID value of zero for 218 special purposes, so care is needed if this KeyID value is included 219 in the table. 221 3. Key Selection and Rollover 223 When a system desires to protect a unicast protocol data unit for a 224 remote system H using security protocol P via interface I, the local 225 system selects a long-lived key at time T from the database, any key 226 that satisfies the following conditions may be used: 228 (1) the Peer field includes H; 230 (2) the PeerKeyID field is not "unknown"; 232 (3) the Protocol field matches P; 234 (4) the Interfaces field includes I; 236 (5) the Direction field is either "out" or "both"; and 238 (6) NotBefore <= T <= NotAfter. 240 The value in the PeerKeyID field is used to identify the selected key 241 to the remote system H. 243 Group key selection is different than pairwise key selection. When a 244 system desires to protect a multicast protocol data unit for a group 245 of systems G using security protocol P via interface I, the local 246 system selects a long-lived key at time T from the database, any key 247 that satisfies the following conditions may be used: 249 (1) the Peer field includes the multicast group G; 251 (2) the PeerKeyID field is "group"; 253 (3) the Protocol field matches P; 255 (4) the Interfaces field includes I; 257 (5) the Direction field is either "out" or "both"; and 259 (6) NotBefore <= T <= NotAfter. 261 The value in the LocalKeyID field is used to identify the selected 262 key since all of the systems in the group G use the same identifier. 264 During algorithm transition, multiple entries may exist associated 265 with different cryptographic algorithms or ciphersuites. Systems 266 should support selection of keys based on algorithm preference. 268 In addition, multiple entries with overlapping use periods are 269 expected to be employed to provide orderly key rollover. In these 270 cases, the expectation is that systems will transition to the newest 271 key available. To meet this requirement, this specification 272 recommends supplementing the key selection algorithm with the 273 following differentiation: select the long-lived key specifying the 274 most recent time in the NotBefore field. 276 When a system participates in a security protocol, a sending peer 277 system H has selected a long-lived key and the LocalKeyID is included 278 in the protocol control information. When retrieving the long-lived 279 key (for direct use or for key derivation), the local system should 280 confirm the following conditions are satisfied before use: 282 (1) the Peer field includes H; 284 (2) the Protocol field matches P; 286 (3) the Interface field includes I; 287 (4) the Direction field is either "in" or "both"; and 289 (5) NotBefore <= T <= NotAfter. 291 Note that the key usage is loosely bound by the times specified in 292 the NotBefore and NotAfter fields. New security associations should 293 not be established except within the period of use specified by these 294 fields, while allowing some grace time for clock skew. However, if a 295 security association has already been established based on a 296 particular long-lived key, exceeding the lifetime does not have any 297 direct impact. Implementations of protocols that involve long-lived 298 security association should be designed to periodically interrogate 299 the database and rollover to new keys without tearing down the 300 security association. 302 For group keying, the local system should confirm the following 303 conditions are satisfied before use: 305 (1) the Peer field includes the multicast group G; 307 (2) the PeerKeyID field is "group"; 309 (3) the Protocol field matches P; 311 (4) the Interface field includes I; 313 (5) the Direction field is either "in" or "both"; and 315 (6) NotBefore <= T <= NotAfter. 317 As long as a key remains in the database, the key may be used for 318 received traffic. Any key that is unacceptable for received traffic 319 needs to be removed from the database. 321 4. Operational Considerations 323 If usage periods for long-lived keys do not overlap and system clocks 324 are inconsistent, it is possible to construct scenarios where systems 325 cannot agree upon a long-lived key. When installing a series of keys 326 to be used one after the other (sometimes called a key chain), 327 operators should configure the NotAfter field of the preceding key to 328 be several days after the NotBefore field of the subsequent key to 329 ensure that clock skew is not a concern. 331 For group keys, the most significant bit in LocalKeyID must be set to 332 one. Collisions among group key identifiers can be avoided by 333 subdividing the remaining 15 bits of the LocalKeyID field into an 334 identifier of the group key generator and an identifier assigned by 335 that generator. 337 5. Security Considerations 339 Management of encryption and authentication keys has been a 340 significant operational problem, both in terms of key synchronization 341 and key selection. For example, current guidance [RFC3562] warns 342 against sharing TCP MD5 keying material between systems, and 343 recommends changing keys according to a schedule. The same general 344 operational issues are relevant for the management of other 345 cryptographic keys. 347 It is recognized in [RFC4107] that automated key management is not 348 viable in some situations. The conceptual database specified in this 349 document is intended to accommodate both manual key management and 350 automated key management. A future specification to automatically 351 populate rows in the database is envisioned. 353 Designers should recognize the warning provided in [RFC4107]: 355 Automated key management and manual key management provide very 356 different features. In particular, the protocol associated with 357 an automated key management technique will confirm the liveness of 358 the peer, protect against replay, authenticate the source of the 359 short-term session key, associate protocol state information with 360 the short-term session key, and ensure that a fresh short-term 361 session key is generated. Further, an automated key management 362 protocol can improve interoperability by including negotiation 363 mechanisms for cryptographic algorithms. These valuable features 364 are impossible or extremely cumbersome to accomplish with manual 365 key management. 367 6. IANA Considerations 369 This specification defines three registries. 371 6.1. KeyTable Protocols 373 This document requests establishment of a registry called "KeyTable 374 Protocols". The following subsection describes the registry; the 375 second subsection provides initial values for IEEE 802.1X. 377 6.1.1. KeyTable Protocols Registry Definition 379 All assignments to the KeyTable Protocols registry are made on on a 380 Specification Required basis per Section 4.1 of [RFC5226]. 382 Each registration entry must contain the three fields: 384 - protocol name (unique within the registry); 385 - specification; and 386 - protocol specific values. 388 6.1.2. KeyTable Protocols Registry Initial Values 390 protocol name: IEEE 802.1X 392 specification: IEEE Std 802.1X-2010, "IEEE Standard for Local 393 and Metropolitan Area Networks -- Port-Based Network Access 394 Control". 396 protocol specific values: there are two: 398 - A Key Management Domain (KMD). 399 A string of up to 253 UTF-8 characters that names the 400 transmitting authenticator's key management domain. 402 - A Network Identifier (NID). 403 A string of up to 100 UTF-8 characters that identifies 404 a network service. The NID can also be null, indicating 405 the key is associated with a default service. 407 6.2. KeyTable KDFs 409 This document requests establishment of a registry called "KeyTable 410 KDFs". The remainder of this section describes the registry. 412 All assignments to the KeyTable KDFs registry are made on a First 413 Come First Served basis per Section 4.1 of RFC 5226. 415 6.3. KeyTable AlgIDs 417 This document requests establishment of a registry called "KeyTable 418 AlgIDs". The remainder of this section describes the registry. 420 All assignments to the KeyTable KDFs registry are made on a First 421 Come First Served basis per Section 4.1 of RFC 5226. 423 7. Acknowledgments 425 This document reflects many discussions with many different people 426 over many years. In particular, the authors thank Jari Arkko, Ran 427 Atkinson, Ron Bonica, Ross Callon, Lars Eggert, Pasi Eronen, Adrian 428 Farrel, Sam Hartman, Gregory Lebovitz, Sandy Murphy, Eric Rescorla, 429 Mike Shand, Dave Ward, and Brian Weis for their insights. 431 8. Informational References 433 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 434 Signature Option", RFC 3562, July 2003. 436 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 437 Key Management", RFC 4107, BCP 107, June 2005. 439 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 440 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 441 May 2008. 443 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 444 Authentication Option", RFC 5925, June 2010. 446 Authors' Addresses 448 Russell Housley 449 Vigil Security, LLC 450 918 Spring Knoll Drive 451 Herndon, VA 20170 452 USA 453 EMail: housley@vigilsec.com 455 Tim Polk 456 National Institute of Standards and Technology 457 100 Bureau Drive, Mail Stop 8930 458 Gaithersburg, MD 20899-8930 459 USA 460 EMail: tim.polk@nist.gov