idnits 2.17.1 draft-ietf-karp-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 == Line 76 has weird spacing: '...strains where...' -- The document date (22 October 2012) is 4202 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 (~~), 2 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: 22 April 2013 22 October 2012 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 96 The database is characterized as a table, where each row 97 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 101 key 102 is used with multiple key derivation functions (KDFs) will 103 multiple 104 rows will contain the same key value. The columns in the table 105 represent the key value and attributes of the key. 107 To accommodate manual key management, the format of the fields has 108 been purposefully chosen to allow updates with a plain text editor 109 and to provide equivalent display on multiple systems. 111 The columns that the table consists of are listed as follows: 113 LocalKeyName 114 LocalKeyName is a string identifying the key when it is 115 received in a packet. A protocol may restrict the form of a 116 key name. For example, many routing protocols will restrict key 117 names to integers that can be represented in 16 or 32 bits. 119 PeerKeyName 120 For unicast communication, PeerKeyName on one system matches 121 LocalKeyName on the other system. Similar to LocalKeyName, the 122 protocol may restrict the form of this identifier and will 123 often restrict it to be an integer. For group keys, the 124 protocol will typically require this field be an empty string 125 as the sending and the receiving key names need to be the same. 127 Peers 128 Typically for unicast keys, this field lists the peer systems 129 that have this key in their database. For group keys this field 130 names the groups for which the key is appropriate. For example, 131 this might name a routing area for a multicast routing 132 protocol. Formally, this field provides a protocol-specific set 133 of restrictions on the scope in which the key is appropriate. 134 The form of the identifiers in the Peers field is specified by 135 the protocol. 137 Interfaces 138 The Interfaces field identifies the set of physical and/or 139 virtual interfaces for which it is appropriate to use this key. 140 When the long-lived value in the Key field is intended for use 141 on any interface, this field is set to "all". The interfaces 142 field consists of a set of strings; the form of these strings 143 is specified by the implementation and is independent of the 144 protocol in question. Protocols may require support for the 145 interfaces field or may indicate that support for constraining 146 keys based on interface is not required. As an example, TCP-AO 147 implementations are unlikely to make the decision of what 148 interface to use prior to key selection. In this case, the 149 implementations are expected to use the same keying material 150 across all of the interfaces and then require the "all" 151 setting. 153 Protocol 154 The Protocol field identifies a single security protocol where 155 this key may be used to provide cryptographic protection. This 156 specification establishes a registry for this field; the 157 registry also specifies the format of the following field, 158 ProtocolSpecificInfo, for each registered protocol. 160 ProtocolSpecificInfo 161 This field contains the protocol-specified information which 162 may be useful for a protocol to apply the key correctly. Note 163 that such information must not be required for a protocol to 164 locate an appropriate key. When a protocol does not need the 165 information in ProtocolSpecificInfo, it will require this field 166 be empty. 168 KDF 169 The KDF field indicates which key derivation function is used 170 to generate short-lived keys from the long-lived value in the 171 Key field. When the long-lived value in the Key field is 172 intended for direct use, the KDF field is set to "none". This 173 document establishes an IANA registry for the values in the KDF 174 field to simplify references in future specifications. The 175 protocol indicates what (if any) KDFs are valid. 177 AlgID 178 The AlgID field indicates the cryptographic algorithm used with 179 the security protocol for the specified peer. The algorithm 180 may be an encryption algorithm and mode (such as AES-128-CBC), 181 an authentication algorithm (such as HMAC-SHA1-96 or 182 AES-128-CMAC), or any other symmetric cryptographic algorithm 183 needed by a security protocol. If the KDF field contains 184 "none", then the long-lived key is used directly with this 185 algorithm, otherwise the derived short-lived key is used with 186 this algorithm. When the long-lived key is used to generate a 187 set of short-lived keys for use with the security protocol, the 188 AlgID field identifies a ciphersuite rather than a single 189 cryptographic algorithm. This document establishes an IANA 190 registry for the values in the AlgID field to simplify 191 references in future specifications. Protocols indicate which 192 algorithms are appropriate. 194 Key 195 The Key field contains a long-lived symmetric cryptographic key 196 in the format of a lower-case hexadecimal string. The size of 197 the Key depends on the KDF and the AlgID. For instance, a 198 KDF=none and AlgID=AES128 requires a 128-bit key, which is 199 represented by 32 hexadecimal digits. 201 Direction 202 The Direction field indicates whether this key may be used for 203 inbound traffic, outbound traffic, both, or whether the key 204 has been disabled and may not currently be used at all. The 205 supported values are "in", "out", "both", and "disabled", 206 respectively. The Protocol field will determine which of these 207 values are valid. 209 SendNotBefore 210 The NotBefore field specifies the earliest date and time in 211 Universal Coordinated Time (UTC) at which this key should be 212 considered for use when sending traffic. The format is 213 YYYYMMDDHHSSZ, where four digits specify the year, two digits 214 specify the month, two digits specify the day, two digits 215 specify the hour, two digits specify the minute, and two 216 digits specify the second. The "Z" is included as a clear 217 indication that the time is in UTC. 219 SendNotAfter 220 The SendNotAfter field specifies the latest date and time at 221 which this key should be considered for use when sending 222 traffic. The format is the same as the SendNotBefore field. 224 RcvNotBefore 225 The RcvNotBefore field specifies the earliest date and time in 226 Universal Coordinated Time (UTC) at which this key should be 227 considered for use when processing received traffic. The 228 format is YYYYMMDDHHSSZ, where four digits specify the year, 229 two digits specify the month, two digits specify the day, two 230 digits specify the hour, two digits specify the minute, and two 231 digits specify the second. The "Z" is included as a clear 232 indication that the time is in UTC. 234 RcvNotAfter 235 The RcvNotAfter field specifies the latest date and time at 236 which this key should be considered for use when processing 237 received traffic. The format of this field is identical to the 238 format of NotBefore. 240 3. Key Selection and Rollover 242 A protocol may directly consult the key table to find the key 243 to use on an outgoing packet. The protocol provides a protocol 244 (P) and a peer identifier (H) into the key selection function. 245 Optionally, an interface identifier (I) may also need to be 246 provided. Any key that satisfies the following conditions may 247 be selected: 249 (1) the Peers field includes H; 251 (2) the Protocol field matches P; 253 (3) If an interface is specified, the Interfaces field includes I 254 or "all"; 256 (4) the Direction field is either "out" or "both"; and 258 (5) SendNotBefore <= current time <= SendNotAfter. 260 During algorithm transition, multiple entries may simultaneously 261 exist associated with different cryptographic algorithms or 262 ciphersuites. Systems should support selection of keys based on 263 algorithm preference. 265 In addition, multiple entries with overlapping valid periods are 266 expected to be employed to provide orderly key rollover. In these 267 cases, the expectation is that systems will transition to the newest 268 key available. To meet this requirement, this specification 269 recommends supplementing the key selection algorithm with the 270 following differentiation: select the long-lived key specifying the 271 most recent time in the SendNotBefore field. 273 In order to look up a key for verifying an incoming packet, the 274 protocol provides its protocol (P), the peer identifier (H), the key 275 identifier (L), and optionally the interface (I). If one key matches 276 the following conditions it is selected: 278 (1) the Peer field includes H; 280 (2) the Protocol field matches P; 281 (3) if the Interface field is provided, it includes I or is 282 "all"; 284 (4) the Direction field is either "in" or "both"; 286 (5) the LocalKeyName is L; and 288 (5) RcvNotBefore <= current time <= RcvNotAfter. 290 Note that the key usage is loosely bound by the times specified in 291 the RcvNotBefore and RcvNotAfter fields. New security associations 292 should not be established except within the period of use specified 293 by these fields, while allowing some grace time for clock skew. 294 However, if a security association has already been established based 295 on a particular long-lived key, exceeding the lifetime does not have 296 any direct impact. The implementations of security protocols that 297 involve long-lived security association should be designed to 298 periodically interrogate the database and rollover to new keys 299 without tearing down the security association. 301 Rather than consulting the conceptual database, a security protocol 302 such as TCP-AO may update its own tables as keys are added and 303 removed. In this case, the protocol needs to maintain its own key 304 information. 306 4. Application of the Database in a Security Protocol 308 In order to use the key table database in a protocol specification, a 309 protocol needs to specify certain information. This section 310 enumerates items that a protocol must specify. 312 (1) The ways of mapping the information in a key table row to the 313 information needed to produce an outgoing packet; specified 314 either as an explanation of how to fill in authentication-related 315 fields in a packet based on key table information, or for 316 protocols such as TCP-AO how to construct Master Key Tuples (MKTs) 317 or other protocol-specific structures from a key table row 319 (2) The ways of locating the peer identifier (a member of the 320 Peers set) and the LocalKeyName inside an incoming packet 322 (3) The methods of verifying a packet given a key table row; this 323 may be stated directly or in terms of protocol-specific structures 324 such as MKTs 326 (4) The form and validation rules for LocalKeyName and 327 PeerKeyName; if either of these is an integer, the conventions in 328 Section 5.1 are used as a vendor-independent format 329 (5) The form and validation rules for members of the Peers set 331 (6) The algorithms and KDFs supported 333 (7) The form of the ProtocolSpecifics field 335 (8) The rules for canonicalizing LocalKeyName, PeerKeyName, 336 entries in the Peers set, or ProtocolSpecifics; this may include 337 normalizations such as lower-casing hexadecimal strings 339 (9) The Indication whether the support for Interfaces is required 340 by this protocol 342 5. Textual Conventions 344 5.1 Key Names 346 When a key for a given protocol is identified by an integer key 347 identifier, the associated key name will be represented as lower case 348 hexadecimal integers with the most significant octet first. This 349 integer is padded with leading 0's until the width of the key 350 identifier field in the protocol is reached. 352 5.2 Keys 354 A key is represented as a lower-case hexadecimal string with the most 355 significant octet of the key first. As discussed in Section 2, the 356 length of this string depends on the associated algorithm and KDF. 358 6. Operational Considerations 360 If the valid periods for long-lived keys do not overlap or the system 361 clocks are inconsistent, it is possible to construct scenarios where 362 systems cannot agree upon a long-lived key. When installing a series 363 of keys to be used one after another (sometimes called a key chain), 364 operators should configure the SendNotBefore field of the key to be 365 several days after the RcvNotBefore field of the key to address the 366 clock skew issue and guarantee there is some overlap. 368 7. Security Considerations 370 Management of encryption and authentication keys has been a 371 significant operational problem, both in terms of key synchronization 372 and key selection. For instance, the current guidance [RFC3562] 373 warns against sharing TCP MD5 keying material between systems, and 374 recommends changing keys according to a schedule. The same general 375 operational issues are relevant for the management of other 376 cryptographic keys. 378 It has been recognized in [RFC4107] that automated key management is 379 not viable in multiple scenarios. The conceptual database specified 380 in this document is designed to accommodate both manual key 381 management and automated key management. A future specification to 382 automatically populate rows in the database is envisioned. 384 Designers should recognize the warning provided in [RFC4107]: 386 Automated key management and manual key management provide very 387 different features. In particular, the protocol associated with 388 an automated key management technique will confirm the liveness of 389 the peer, protect against replay, authenticate the source of the 390 short-term session key, associate protocol state information with 391 the short-term session key, and ensure that a fresh short-term 392 session key is generated. Moreover, an automated key management 393 protocol can improve the interoperability by including negotiation 394 mechanisms for cryptographic algorithms. These valuable features 395 are impossible or extremely cumbersome to accomplish with manual 396 key management. 398 8. IANA Considerations 400 This specification defines three registries. 402 8.1. KeyTable Protocols 404 This document requests establishment of a registry called "KeyTable 405 Protocols". The following subsection describes the registry; the 406 second subsection provides initial values for IEEE 802.1X CAK. 408 8.1.1. KeyTable Protocols Registry Definition 410 All assignments to the KeyTable Protocols registry are made on a 411 specification required basis per Section 4.1 of [RFC5226]. 413 Each registration entry must contain the three fields: 415 - Protocol Name (unique within the registry); 416 - Specification; and 417 - Protocol Specific Values. 419 The specification needs to describe parameters required for using the 420 conceptual database as outlined in Section 4. For existing 421 protocols, this typically means that the specification will focus 422 more on the application of the protocol with the key tables rather 423 than being a general specification of the security protocol. New 424 protocols may of course combine information on how to use the key 425 tables database with the protocol specification. 427 8.1.2. KeyTable Protocols Registry Initial Values 429 Protocol Name: IEEE 802.1X CAK 431 Specification: IEEE Std 802.1X-2010, "IEEE Standard for Local 432 and Metropolitan Area Networks -- Port-Based Network Access 433 Control". 435 Protocol Specific Values: there are two: 437 - A Key Management Domain (KMD). 438 A string of up to 253 UTF-8 characters that names the 439 transmitting authenticator's key management domain. 441 - A Network Identifier (NID). 442 A string of up to 100 UTF-8 characters that identifies 443 a network service. The NID can also be null, indicating 444 the key is associated with a default service. 446 8.2. KeyTable KDFs 448 This document requests the establishment of a registry called 449 "KeyTable KDFs". The remainder of this section describes the 450 registry. 452 All assignments to the KeyTable KDFs registry are made on a First 453 Come First Served basis per Section 4.1 of RFC 5226. 455 8.3. KeyTable AlgIDs 457 This document requests establishment of a registry called "KeyTable 458 AlgIDs". The remainder of this section describes the registry. 460 All assignments to the KeyTable KDFs registry are made on a First 461 Come First Served basis per Section 4.1 of RFC 5226. 463 9. Acknowledgments 465 This document reflects many discussions with many different people 466 over many years. In particular, the authors thank Jari Arkko, Ran 467 Atkinson, Ron Bonica, Ross Callon, Lars Eggert, Pasi Eronen, Adrian 468 Farrel, Sam Hartman, Gregory Lebovitz, Sandy Murphy, Eric Rescorla, 469 Mike Shand, Dave Ward, and Brian Weis for their insights. 471 10. Informational References 473 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 474 Signature Option", RFC 3562, July 2003. 476 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 477 Key Management", RFC 4107, BCP 107, June 2005. 479 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 480 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 481 May 2008. 483 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 484 Authentication Option", RFC 5925, June 2010. 486 Authors' Addresses 488 Russell Housley 489 Vigil Security, LLC 490 918 Spring Knoll Drive 491 Herndon, VA 20170 492 USA 493 EMail: housley@vigilsec.com 495 Tim Polk 496 National Institute of Standards and Technology 497 100 Bureau Drive, Mail Stop 8930 498 Gaithersburg, MD 20899-8930 499 USA 500 EMail: tim.polk@nist.gov 502 Sam Hartman 503 Painless Security, LLC 504 USA 505 Email: hartmans@painless-security.com 507 Dacheng Zhang 508 Huawei 509 China 510 Email: zhangdacheng@huawei.com