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