idnits 2.17.1 draft-ietf-saag-crypto-key-table-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (10 July 2009) is 5397 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: 1 error (**), 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 Intended Status: Standards Track Vigil Security 4 T. Polk 5 NIST 6 Expires: 10 February 2010 10 July 2009 8 Database of Long-Lived 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) 2009 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 in effect on the date of 38 publication of this document (http://trustee.ietf.org/license-info). 39 Please review these documents carefully, as they describe your rights 40 and restrictions with respect to this document. 42 Abstract 44 This document specifies the information contained in a database of 45 long-lived cryptographic keys used by many different security 46 protocols. The database design supports both manual and automated 47 key management. In many instances, the security protocols do not 48 directly use the long-lived key, but rather a key derivation function 49 is used to derive a short-lived key from a long-lived key. 51 1. Introduction 53 This document specifies the information that needs to be included in 54 a database of long-lived cryptographic keys. This conceptual 55 database is designed to support both manual key management and 56 automated key management. The intent is to allow many different 57 implementation approaches to the specified cryptographic key 58 database. 60 Security protocols are expected to use an application program 61 interface (API) to select a long-lived key from the database. In 62 many instances, the long-lived keys are not used directly in security 63 protocols, but rather a key derivation function is used to derive 64 short-lived key from the long-lived keys in the database. 66 2. Conceptual Database Structure 68 The database is characterized as a table, where each row represents a 69 single long-lived symmetric cryptographic key. Each key should only 70 have one row; however, in the (hopefully) very rare cases where the 71 same key is used for more than one purpose, multiple rows will 72 contain the same key value. The columns in the table represent the 73 key value and attributes of the key. 75 To accommodate manual key management, then formatting of the fields 76 has been purposefully chosen to allow updates with a plain text 77 editor. 79 The table has the following columns: 81 LocalKeyID 82 LocalKeyID is a 16-bit integer in hexadecimal, and the integer 83 value must be unique in the context of the database. The 84 LocalKeyID can be used by a peer to identify this entry in the 85 database. For pairwise keys, the most significant bit in 86 LocalKeyID is set to zero. For group keys, the most significant 87 bit in LocalKeyID is set to one. 89 PeerKeyID 90 For pairwise keys, the peersKeyID field is a 16 bit integer in 91 hexadecimal provided by the peer. If the peer has not yet 92 provided this value, the PeerKeyID is set to "unknown". For 93 group keying, the PeerKeyID field is set to "group", which 94 easily accommodates group keys generated by a third party. 96 KDF 97 The KDF field indicates which key derivation function is used 98 to generate short-lived keys from the long-lived value in the 99 Key field. When the long-lived value in the Key field is 100 intended for direct use, the KDF field is set to "none". 102 KDFInputs 103 The KDFInputs field is used when supplementary public or 104 private data is supplied to the KDF. For protocols that do not 105 require additional information for the KDF, the KDFInputs field 106 is set to "none". The Protocol field will determine the format 107 of this field if it is not "none". 109 AlgID 110 The AlgID field indicates which cryptographic algorithm to be 111 used with the security protocol for the specified peer. The 112 algorithm may be an encryption algorithm, and authentication 113 algorithm, or any other symmetric cryptographic algorithm 114 needed by a security protocol. If the KDF field contains 115 "none", then the long-lived key is used directly with this 116 algorithm, otherwise the derived short-lived key is used with 117 this algorithm. When the long-lived key is used to generate a 118 set of short-lived keys for use with the security protocol, the 119 AlgID field identifies a ciphersuite rather than a single 120 cryptographic algorithm. 122 Key 123 The Key is a hexadecimal string representing a ling-lived 124 symmetric cryptographic key. The size of the Key depends on 125 the KDF and the AlgID. For example, a KDF=none and 126 AlgID=AES128 requires a 128-bit key, which is represented by 32 127 hexadecimal digits. 129 Direction 130 The Direction field indicates whether this key may be used for 131 inbound traffic, outbound traffic, or both. The supported 132 values are "in", "out", and "both", respectively. The Protocol 133 field will determine which of these values are valid. 135 NotBefore 136 The NotBefore field specifies the earliest date and time in 137 Universal Coordinated Time (UTC) at which this key should be 138 considered for use. The format is YYYYMMDDHHSSZ, where four 139 digits specify the year, two digits specify the month, two 140 digits specify the day, two digits specify the hour, and two 141 digits specify the minute. The "Z" is included as a clear 142 indication that the time is in UTC. 144 NotAfter 145 The NotAfter field specifies the latest date and time at which 146 this key should be considered for use. The format is the same 147 as the NotBefore field. 149 Peers 150 The Peers field identifies the peer system or set of systems 151 that have this key configured in their own database of long- 152 lived keys. For pairwise keys, the database on the peer system 153 LocalKeyID field will contain the value specified in the 154 PeerKeyID field in the local database. 156 Protocol 157 The Protocol field identifies a single security protocol where 158 this key may be used to provide cryptographic protection. 160 3. Key Selection and Rollover 162 When a system desires to communicate with a remote system H using 163 security protocol P, the local system selects a long-lived key at 164 time T from the database, any key that satisfies the following 165 conditions may be used: 167 (1) the Peer field includes H; 169 (2) the PeerKeyID field is not "unknown"; 171 (3) the Protocol field matches P; and 173 (4) NotBefore < T < NotAfter. 175 During algorithm transition, multiple entries may exist associated 176 with different cryptographic algorithms or ciphersuites. Systems 177 should support selection of keys based on algorithm preference. 179 In addition, multiple entries with overlapping use periods are 180 expected to be employed to implement orderly key rollover. In these 181 cases, the expectation is that systems will transition to the newest 182 key available. To meet this requirement, this specification 183 recommends supplementing the key selection algorithm with the 184 following differentiator: select the long-lived key specifying the 185 most recent time in the NotBefore field. 187 When a system participates in a security protocol, and a peer H2 has 188 selected a long-lived key, the LocalKeyID should be asserted as part 189 of the protocol control information. When retrieving the long-lived 190 key (for direct use or for key derivation), the local system should 191 confirm the following conditions are satisfied before use: 193 (1) the Peer field includes H2; 194 (2) the Protocol field matches P; and 196 (3) NotBefore < T < NotAfter. 198 Note that the key usage is loosely bound by the times specified in 199 the NotBefore and NotAfter fields. New security associations should 200 not be established except within the period of use specified by these 201 fields, with the possible allowance of some grace time for clock 202 skew. However, if a security association has already been 203 established based on a particular long-lived key, exceeding the 204 lifetime does not have any direct impact. Implementations of 205 protocols that involve long-lived security association should be 206 designed to periodically interrogate the database and rollover to new 207 keys without tearing down the security association. To support this 208 feature, the PeerKeyID associated with the newly selected long-lived 209 key will need to be conveyed to the peers by the security protocol. 211 4. Operational Considerations 213 If usage periods for long-lived keys do not overlap and system clocks 214 are inconsistent, it is possible to construct scenarios where systems 215 cannot agree upon a long-lived key. When installing a series of keys 216 to be used one after the other (sometimes called a key chain), 217 operators should configure the NotAfter field of the preceding key to 218 be several days after the NotBefore field of the subsequent key to 219 ensure that clock skew is not a concern. 221 5. Security Considerations 223 Management of encryption and authentication keys has been a 224 significant operational problem, both in terms of key synchronization 225 and key selection. For example, current guidance [RFC3562] warns 226 against sharing TCP MD5 keying material between systems, and 227 recommends changing keys according to a schedule. The same general 228 operational issues are relevant for the management of other 229 cryptographic keys. 231 It is recognized in [RFC4107] that automated key management is not 232 viable in some situations. The conceptual database specified in this 233 document is intended to accommodate both manual key management and 234 automated key management. A future specification to automatically 235 populate rows in the database is envisioned. 237 Designers should recognize the warning provided in [RFC4107]: 239 Automated key management and manual key management provide very 240 different features. In particular, the protocol associated with 241 an automated key management technique will confirm the liveness of 242 the peer, protect against replay, authenticate the source of the 243 short-term session key, associate protocol state information with 244 the short-term session key, and ensure that a fresh short-term 245 session key is generated. Further, an automated key management 246 protocol can improve interoperability by including negotiation 247 mechanisms for cryptographic algorithms. These valuable features 248 are impossible or extremely cumbersome to accomplish with manual 249 key management. 251 6. IANA Considerations 253 No IANA actions are required. 255 {{{ RFC Editor: Please remove this section prior to publication. }}} 257 7. Acknowledgments 259 This document reflects many discussions with many different people of 260 many years. In particular, the authors thank Jari Arkko, Ron Bonica, 261 Ross Callon, Lars Eggert, Pasi Eronen, Adrian Farrel, Sam Hartman, 262 Gregory Lebovitz, Sandy Murphy, Eric Rescorla, Dave Ward, and Brian 263 Weis for their insights. 265 8. Informational References 267 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 268 Signature Option", RFC 3562, July 2003. 270 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 271 Key Management", RFC 4107, BCP 107, June 2005. 273 Authors' Addresses 275 Russell Housley 276 Vigil Security, LLC 277 918 Spring Knoll Drive 278 Herndon, VA 20170 279 USA 280 EMail: housley@vigilsec.com 282 Tim Polk 283 National Institute of Standards and Technology 284 100 Bureau Drive, Mail Stop 8930 285 Gaithersburg, MD 20899-8930 286 USA 287 EMail: tim.polk@nist.gov