idnits 2.17.00 (12 Aug 2021) /tmp/idnits57511/draft-ietf-karp-crypto-key-table-05.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (14 February 2013) is 3382 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: 1 error (**), 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: 14 August 2013 14 February 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 246 to use on an outgoing packet. The protocol provides a protocol 247 (P) and a peer identifier (H) into the key selection function. 248 Optionally, an interface identifier (I) may also need to be 249 provided. Any key that satisfies the following conditions may 250 be selected: 252 (1) the Peers field includes H; 254 (2) the Protocol field matches P; 256 (3) If an interface is specified, the Interfaces field includes I 257 or "all"; 259 (4) the Direction field is either "out" or "both"; and 261 (5) SendLifetimeStart <= current time <= SendLifeTimeEnd. 263 During key selection, multiple entries may simultaneously exist 264 associated with different cryptographic algorithms or ciphersuites. 265 Systems should support selection of keys based on algorithm 266 preference to facilitate algorithm transition. 268 In addition, multiple entries with overlapping valid periods are 269 expected to be available for orderly key rollover. In these cases, 270 the expectation is that systems will transition to the newest key 271 available. To meet this requirement, this specification recommends 272 supplementing the key selection algorithm with the following 273 differentiation: select the long-lived key specifying the most recent 274 time in the SendLifetimeStart field. 276 In order to look up a key for verifying an incoming packet, the 277 protocol provides its protocol (P), the peer identifier (H), the key 278 identifier (L), and optionally the interface (I). If one key matches 279 the following conditions it is selected: 281 (1) the Peer field includes H; 283 (2) the Protocol field matches P; 285 (3) if the Interface field is provided, it includes I or is 286 "all"; 288 (4) the Direction field is either "in" or "both"; 290 (5) the LocalKeyName is L; and 292 (5) AcceptLifeTimeStart <= current time <= AcceptLifeTimeEnd. 294 Note that the key usage is loosely bound by the times specified in 295 the AcceptLifeTimeStart and AcceptLifeTimeEnd fields. New security 296 associations should not be established except within the period of 297 use specified by these fields, while allowing some grace time for 298 clock skew. However, if a security association has already been 299 established based on a particular long-lived key, exceeding the 300 lifetime does not have any direct impact. The implementations of 301 security protocols that involve long-lived security association 302 should be designed to periodically interrogate the database and 303 rollover to new keys without tearing down the security association. 305 Rather than consulting the conceptual database, a security protocol 306 such as TCP-AO may update its own tables as keys are added and 307 removed. In this case, the protocol needs to maintain its own key 308 information. 310 4. Application of the Database in a Security Protocol 312 In order to use the key table database in a protocol specification, a 313 protocol needs to specify certain information. This section 314 enumerates items that a protocol must specify. 316 (1) The ways of mapping the information in a key table row to the 317 information needed to produce an outgoing packet; specified 318 either as an explanation of how to fill in authentication-related 319 fields in a packet based on key table information, or for 320 protocols such as TCP-AO how to construct Master Key Tuples (MKTs) 321 or other protocol-specific structures from a key table row 323 (2) The ways of locating the peer identifier (a member of the 324 Peers set) and the LocalKeyName inside an incoming packet 326 (3) The methods of verifying a packet given a key table row; this 327 may be stated directly or in terms of protocol-specific structures 328 such as MKTs 329 (4) The form and validation rules for LocalKeyName and 330 PeerKeyName; if either of these is an integer, the conventions in 331 Section 5.1 are used as a vendor-independent format 333 (5) The form and validation rules for members of the Peers set 335 (6) The algorithms and KDFs supported 337 (7) The form of the ProtocolSpecifics field 339 (8) The rules for canonicalizing LocalKeyName, PeerKeyName, 340 entries in the Peers set, or ProtocolSpecifics; this may include 341 normalizations such as lower-casing hexadecimal strings 343 (9) The Indication whether the support for Interfaces is required 344 by this protocol 346 5. Textual Conventions 348 5.1 Key Names 350 When a key for a given protocol is identified by an integer key 351 identifier, the associated key name will be represented as lower case 352 hexadecimal integers with the most significant octet first. This 353 integer is padded with leading 0's until the width of the key 354 identifier field in the protocol is reached. 356 5.2 Keys 358 A key is represented as a lower-case hexadecimal string with the most 359 significant octet of the key first. As discussed in Section 2, the 360 length of this string depends on the associated algorithm and KDF. 362 6. Operational Considerations 364 If the valid periods for long-lived keys do not overlap or the system 365 clocks are inconsistent, it is possible to construct scenarios where 366 systems cannot agree upon a long-lived key. When installing a series 367 of keys to be used one after another (sometimes called a key chain), 368 operators should configure the SendLifetimeStart field of the key to 369 be several hours after the AcceptLifeTimeStart field of the key to 370 guarantee there is some overlap. This overlap is intended to address 371 the clock skew issue and allow for basic operational considerations. 372 Operators may choose to specify a longer overlap (e.g., several 373 hours) to allow for exceptional circumstances. 375 7. Security Considerations 376 Management of encryption and authentication keys has been a 377 significant operational problem, both in terms of key synchronization 378 and key selection. For instance, the current guidance [RFC3562] 379 warns against sharing TCP MD5 keying material between systems, and 380 recommends changing keys according to a schedule. The same general 381 operational issues are relevant for the management of other 382 cryptographic keys. 384 It has been recognized in [RFC4107] that automated key management is 385 not viable in multiple scenarios. The conceptual database specified 386 in this document is designed to accommodate both manual key 387 management and automated key management. A future specification to 388 automatically populate rows in the database is envisioned. 390 Designers should recognize the warning provided in [RFC4107]: 392 Automated key management and manual key management provide very 393 different features. In particular, the protocol associated with 394 an automated key management technique will confirm the liveness of 395 the peer, protect against replay, authenticate the source of the 396 short-term session key, associate protocol state information with 397 the short-term session key, and ensure that a fresh short-term 398 session key is generated. Moreover, an automated key management 399 protocol can improve the interoperability by including negotiation 400 mechanisms for cryptographic algorithms. These valuable features 401 are impossible or extremely cumbersome to accomplish with manual 402 key management. 404 8. IANA Considerations 406 This specification defines three registries. 408 8.1. KeyTable Protocols 410 This document requests establishment of a registry called "KeyTable 411 Protocols". The following subsection describes the registry; the 412 second subsection provides initial values for IEEE 802.1X CAK. 414 8.1.1. KeyTable Protocols Registry Definition 416 All assignments to the KeyTable Protocols registry are made on a 417 specification required basis per Section 4.1 of [RFC5226]. 419 Each registration entry must contain the three fields: 421 - Protocol Name (unique within the registry); 422 - Specification; and 423 - Protocol Specific Values. 425 The specification needs to describe parameters required for using the 426 conceptual database as outlined in Section 4. This typically means 427 that the specification focuses more on the application of security 428 protocols with the key tables rather than being a new security 429 protocol specification for general purposes. New protocols may of 430 course combine information on how to use the key tables database with 431 the protocol specification. 433 8.1.2. KeyTable Protocols Registry Initial Values 435 Protocol Name: IEEE 802.1X CAK 437 Specification: IEEE Std 802.1X-2010, "IEEE Standard for Local 438 and Metropolitan Area Networks -- Port-Based Network Access 439 Control". 441 Protocol Specific Values: there are two: 443 - A Key Management Domain (KMD). 444 A string of up to 253 UTF-8 characters that names the 445 transmitting authenticator's key management domain. 447 - A Network Identifier (NID). 448 A string of up to 100 UTF-8 characters that identifies 449 a network service. The NID can also be null, indicating 450 the key is associated with a default service. 452 8.2. KeyTable KDFs 454 This document requests the establishment of a registry called 455 "KeyTable KDFs". The remainder of this section describes the 456 registry. 458 All assignments to the KeyTable KDFs registry are made on a First 459 Come First Served basis per Section 4.1 of RFC 5226. 461 8.3. KeyTable AlgIDs 463 This document requests establishment of a registry called "KeyTable 464 AlgIDs". The remainder of this section describes the registry. 466 All assignments to the KeyTable AlgIDs registry are made on a First 467 Come First Served basis per Section 4.1 of RFC 5226. 469 9. Acknowledgments 471 This document reflects many discussions with many different people 472 over many years. In particular, the authors thank Jari Arkko, Ran 473 Atkinson, Ron Bonica, Ross Callon, Lars Eggert, Pasi Eronen, Adrian 474 Farrel, Gregory Lebovitz, Sandy Murphy, Eric Rescorla, Mike Shand, 475 Dave Ward, and Brian Weis for their insights. 477 10. Informational References 479 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 480 Signature Option", RFC 3562, July 2003. 482 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 483 Key Management", RFC 4107, BCP 107, June 2005. 485 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 486 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 487 May 2008. 489 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 490 Authentication Option", RFC 5925, June 2010. 492 Authors' Addresses 494 Russell Housley 495 Vigil Security, LLC 496 918 Spring Knoll Drive 497 Herndon, VA 20170 498 USA 499 EMail: housley@vigilsec.com 501 Tim Polk 502 National Institute of Standards and Technology 503 100 Bureau Drive, Mail Stop 8930 504 Gaithersburg, MD 20899-8930 505 USA 506 EMail: tim.polk@nist.gov 508 Sam Hartman 509 Painless Security, LLC 510 USA 511 Email: hartmans@painless-security.com 513 Dacheng Zhang 514 Huawei 515 China 516 Email: zhangdacheng@huawei.com