idnits 2.17.1 draft-housley-saag-crypto-key-table-04.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 (13 October 2010) is 4941 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 INTERNET DRAFT R. Housley 3 Internet Engineering Task Force (IETF) Vigil Security 4 Intended Status: Standards Track T. Polk 5 NIST 6 Expires: 13 April 2010 13 October 2010 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) 2010 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. 43 Abstract 45 This document specifies the information contained in a database of 46 long-lived cryptographic keys used by many different security 47 protocols. The database design supports both manual and automated 48 key management. In many instances, the security protocols do not 49 directly use the long-lived key, but rather a key derivation function 50 is used to derive a short-lived key from a long-lived key. 52 1. Introduction 54 This document specifies the information that needs to be included in 55 a database of long-lived cryptographic keys. This conceptual 56 database is designed to support both manual key management and 57 automated key management. The intent is to allow many different 58 implementation approaches to the specified cryptographic key 59 database. 61 Security protocols such as TCP-AO [RFC5925] are expected to use an 62 application program interface (API) to select a long-lived key from 63 the database. In many instances, the long-lived keys are not used 64 directly in security protocols, but rather a key derivation function 65 is used to derive short-lived key from the long-lived keys in the 66 database. In other instances, security protocols will directly use 67 the long-lived key from the database. The database design supports 68 both use cases. 70 2. Conceptual Database Structure 72 The database is characterized as a table, where each row represents a 73 single long-lived symmetric cryptographic key. Each key should only 74 have one row; however, in the (hopefully) very rare cases where the 75 same key is used for more than one purpose, multiple rows will 76 contain the same key value. The columns in the table represent the 77 key value and attributes of the key. 79 To accommodate manual key management, then formatting of the fields 80 has been purposefully chosen to allow updates with a plain text 81 editor. 83 The table has the following columns: 85 LocalKeyID 86 LocalKeyID is a 16-bit integer in hexadecimal. The LocalKeyID 87 can be used by a peer to identify this entry in the database. 88 For pairwise keys, the most significant bit in LocalKeyID is 89 set to zero, and the integer value must be unique among all the 90 pairwise keys in the database. For group keys, the most 91 significant bit in LocalKeyID is set to one, but collisions 92 among group key identifiers must be accommodated. 94 PeerKeyID 95 For pairwise keys, the peersKeyID field is a 16 bit integer in 96 hexadecimal provided by the peer. If the peer has not yet 97 provided this value, the PeerKeyID is set to "unknown". For 98 group keying, the PeerKeyID field is set to "group", which 99 easily accommodates group keys generated by a third party. 101 Peers 102 The Peers field identifies the peer system or set of systems 103 that have this key configured in their own database of long- 104 lived keys. For pairwise keys, the database on the peer system 105 LocalKeyID field will contain the value specified in the 106 PeerKeyID field in the local database. For group keying, the 107 Peers field names the group, not the individual systems that 108 comprise the group. 110 Interfaces 111 The Interfaces field identifies the set of interfaces for which 112 it is appropriate to use this key. When the long-lived value 113 in the Key field is intended for use on any interface, the 114 Interfaces field is set to "all". 116 Protocol 117 The Protocol field identifies a single security protocol where 118 this key may be used to provide cryptographic protection. 120 KDF 121 The KDF field indicates which key derivation function is used 122 to generate short-lived keys from the long-lived value in the 123 Key field. When the long-lived value in the Key field is 124 intended for direct use, the KDF field is set to "none". 126 KDFInputs 127 The KDFInputs field is used when supplementary public or 128 private data is supplied to the KDF. For protocols that do not 129 require additional information for the KDF, the KDFInputs field 130 is set to "none". The Protocol field will determine the format 131 of this field if it is not "none". 133 AlgID 134 The AlgID field indicates which cryptographic algorithm to be 135 used with the security protocol for the specified peer. The 136 algorithm may be an encryption algorithm and mode (such as 137 AES-128-CBC), an authentication algorithm (such as HMAC-SHA1-96 138 or AES-128-CMAC), or any other symmetric cryptographic 139 algorithm needed by a security protocol. If the KDF field 140 contains "none", then the long-lived key is used directly with 141 this algorithm, otherwise the derived short-lived key is used 142 with this algorithm. When the long-lived key is used to 143 generate a set of short-lived keys for use with the security 144 protocol, the AlgID field identifies a ciphersuite rather than 145 a single cryptographic algorithm. 147 Key 148 The Key is a hexadecimal string representing a long-lived 149 symmetric cryptographic key. The size of the Key depends on 150 the KDF and the AlgID. For example, a KDF=none and 151 AlgID=AES128 requires a 128-bit key, which is represented by 32 152 hexadecimal digits. 154 Direction 155 The Direction field indicates whether this key may be used for 156 inbound traffic, outbound traffic, or both. The supported 157 values are "in", "out", and "both", respectively. The Protocol 158 field will determine which of these values are valid. 160 NotBefore 161 The NotBefore field specifies the earliest date and time in 162 Universal Coordinated Time (UTC) at which this key should be 163 considered for use. The format is YYYYMMDDHHSSZ, where four 164 digits specify the year, two digits specify the month, two 165 digits specify the day, two digits specify the hour, and two 166 digits specify the minute. The "Z" is included as a clear 167 indication that the time is in UTC. 169 NotAfter 170 The NotAfter field specifies the latest date and time at which 171 this key should be considered for use. The format is the same 172 as the NotBefore field. 174 Note that some security protocols use a KeyID value of zero for 175 special purposes, so care is needed if this KeyID value is included 176 in the table. 178 3. Key Selection and Rollover 180 When a system desires to protect a unicast protocol data unit for a 181 remote system H using security protocol P via interface I, the local 182 system selects a long-lived key at time T from the database, any key 183 that satisfies the following conditions may be used: 185 (1) the Peer field includes H; 187 (2) the PeerKeyID field is not "unknown"; 189 (3) the Protocol field matches P; 191 (4) the Interfaces field includes I; 193 (5) the Direction field is either "out" or "both"; and 194 (6) NotBefore <= T <= NotAfter. 196 The value in the PeerKeyID field is used to identify the selected key 197 to remote system H. 199 Group key selection is different than pairwise key selection. When a 200 system desires to protect a multicast protocol data unit for a group 201 of systems G using security protocol P via interface I, the local 202 system selects a long-lived key at time T from the database, any key 203 that satisfies the following conditions may be used: 205 (1) the Peer field includes the multicast group G; 207 (2) the PeerKeyID field is "group"; 209 (3) the Protocol field matches P; 211 (4) the Interfaces field includes I; 213 (5) the Direction field is either "out" or "both"; and 215 (6) NotBefore <= T <= NotAfter. 217 The value in the LocalKeyID field is used to identify the selected 218 key since all of the systems in the group G use the same identifier. 220 During algorithm transition, multiple entries may exist associated 221 with different cryptographic algorithms or ciphersuites. Systems 222 should support selection of keys based on algorithm preference. 224 In addition, multiple entries with overlapping use periods are 225 expected to be employed to provide orderly key rollover. In these 226 cases, the expectation is that systems will transition to the newest 227 key available. To meet this requirement, this specification 228 recommends supplementing the key selection algorithm with the 229 following differentiation: select the long-lived key specifying the 230 most recent time in the NotBefore field. 232 When a system participates in a security protocol, a sending peer 233 system H2 has selected a long-lived key and the LocalKeyID is 234 included in the protocol control information. When retrieving the 235 long-lived key (for direct use or for key derivation), the local 236 system should confirm the following conditions are satisfied before 237 use: 239 (1) the Peer field includes H2; 241 (2) the Protocol field matches P; 242 (3) the Interface field includes I; 244 (4) the Direction field is either "in" or "both"; and 246 (5) NotBefore <= T <= NotAfter. 248 Note that the key usage is loosely bound by the times specified in 249 the NotBefore and NotAfter fields. New security associations should 250 not be established except within the period of use specified by these 251 fields, while allowing some grace time for clock skew. However, if a 252 security association has already been established based on a 253 particular long-lived key, exceeding the lifetime does not have any 254 direct impact. Implementations of protocols that involve long-lived 255 security association should be designed to periodically interrogate 256 the database and rollover to new keys without tearing down the 257 security association. 259 For group keying, the local system should confirm the following 260 conditions are satisfied before use: 262 (1) the Peer field includes the multicast group G; 264 (2) the PeerKeyID field is "group"; 266 (3) the Protocol field matches P; 268 (4) the Interface field includes I; 270 (5) the Direction field is either "in" or "both"; and 272 (6) NotBefore <= T <= NotAfter. 274 4. Operational Considerations 276 If usage periods for long-lived keys do not overlap and system clocks 277 are inconsistent, it is possible to construct scenarios where systems 278 cannot agree upon a long-lived key. When installing a series of keys 279 to be used one after the other (sometimes called a key chain), 280 operators should configure the NotAfter field of the preceding key to 281 be several days after the NotBefore field of the subsequent key to 282 ensure that clock skew is not a concern. 284 For group keys, the most significant bit in LocalKeyID must be set to 285 one. Collisions among group key identifiers can be avoided by 286 subdividing the remaining 15 bits of the LocalKeyID field into an 287 identifier of the group key generator and an identifier assigned by 288 that generator. 290 5. Security Considerations 292 Management of encryption and authentication keys has been a 293 significant operational problem, both in terms of key synchronization 294 and key selection. For example, current guidance [RFC3562] warns 295 against sharing TCP MD5 keying material between systems, and 296 recommends changing keys according to a schedule. The same general 297 operational issues are relevant for the management of other 298 cryptographic keys. 300 It is recognized in [RFC4107] that automated key management is not 301 viable in some situations. The conceptual database specified in this 302 document is intended to accommodate both manual key management and 303 automated key management. A future specification to automatically 304 populate rows in the database is envisioned. 306 Designers should recognize the warning provided in [RFC4107]: 308 Automated key management and manual key management provide very 309 different features. In particular, the protocol associated with 310 an automated key management technique will confirm the liveness of 311 the peer, protect against replay, authenticate the source of the 312 short-term session key, associate protocol state information with 313 the short-term session key, and ensure that a fresh short-term 314 session key is generated. Further, an automated key management 315 protocol can improve interoperability by including negotiation 316 mechanisms for cryptographic algorithms. These valuable features 317 are impossible or extremely cumbersome to accomplish with manual 318 key management. 320 6. IANA Considerations 322 No IANA actions are required. 324 {{{ RFC Editor: Please remove this section prior to publication. }}} 326 7. Acknowledgments 328 This document reflects many discussions with many different people 329 over many years. In particular, the authors thank Jari Arkko, Ran 330 Atkinson, Ron Bonica, Ross Callon, Lars Eggert, Pasi Eronen, Adrian 331 Farrel, Sam Hartman, Gregory Lebovitz, Sandy Murphy, Eric Rescorla, 332 Mike Shand, Dave Ward, and Brian Weis for their insights. 334 8. Informational References 336 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 337 Signature Option", RFC 3562, July 2003. 339 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 340 Key Management", RFC 4107, BCP 107, June 2005. 342 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 343 Authentication Option", RFC 5925, June 2010. 345 Authors' Addresses 347 Russell Housley 348 Vigil Security, LLC 349 918 Spring Knoll Drive 350 Herndon, VA 20170 351 USA 352 EMail: housley@vigilsec.com 354 Tim Polk 355 National Institute of Standards and Technology 356 100 Bureau Drive, Mail Stop 8930 357 Gaithersburg, MD 20899-8930 358 USA 359 EMail: tim.polk@nist.gov