idnits 2.17.1 draft-ietf-karp-crypto-key-table-09.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 are 2 instances of too long lines in the document, the longest one being 6 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 54 has weird spacing: '...routing proto...' == Line 130 has weird spacing: '...defines the f...' == Line 144 has weird spacing: '...defines the f...' == Line 335 has weird spacing: '...provide integ...' == Line 477 has weird spacing: '...how the proto...' -- The document date (22 October 2013) is 3810 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 (~~), 6 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 2014 22 October 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 routing protocols for message security. The database is designed to 55 support both manual and automated key management. In addition to 56 describing the schema for the database, this document describes the 57 operations that can be performed on the database as well as the 58 requirements for the routing protocols that wish to use the database. 59 In many typical scenarios, the protocols do not directly use the 60 long-lived key, but rather a key derivation function is used to 61 derive a short-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 cryptographic authentication for routing protocols. 68 This conceptual database is designed to separate protocol-specific 69 aspects from both manual and automated key management. The intent is 70 to allow many different implementation approaches to the specified 71 cryptographic key database, while simplifying specification and 72 heterogeneous deployments. This conceptual database avoids the need 73 to build knowledge of any security protocol into key management 74 protocols. It minimizes protocol-specific knowledge in 75 operational/management interfaces, but it constrains where that 76 knowledge can appear. Textual conventions are provided for the 77 representation of keys and other identifiers. These conventions 78 should be used when presenting keys and identifiers to 79 operational/management interfaces or reading keys/identifiers from 80 these interfaces. It is an operational requirement that all 81 implementations represent the keys and key identifiers in the same 82 way so that cross-vendor configuration instructions can be provided. 84 Routing protocols can employ the services of more generic security 85 protocols such as TCP-AO [RFC5925]. Implementations of routing 86 protocols may need to supply keys to databases specific to these 87 security protocols as the associated entries in this document's 88 conceptual database are manipulated. 90 In many instances, the long-lived keys are not used directly in 91 security protocols, but rather a key derivation function is used to 92 derive short-lived key from the long-lived keys in the database. In 93 other instances, security protocols will directly use the long-lived 94 key from the database. The database design supports both use cases. 96 1.1. Requirements Notation 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 2. Conceptual Database Structure 104 The database is characterized as a table, where each row represents a 105 single long-lived symmetric cryptographic key. Normally, each key 106 should only have one row. Only in the (hopefully) very rare cases 107 where a key is used for more than one purpose, or where the same key 108 is used with multiple key derivation functions (KDFs) will multiple 109 rows contain the same key value. The columns in the table represent 110 the key value and attributes of the key. 112 To accommodate manual key management, the format of the fields has 113 been purposefully chosen to allow updates with a plain text editor 114 and to provide equivalent display on multiple systems. 116 The columns that the table consists of are listed as follows: 118 AdminKeyName 119 The AdminKeyName field contains a string identifying the key by 120 humans. The same string can be used on the local system and 121 peer systems, but this is not required. Protocols do not make 122 use of this string; protocols use the LocalKeyName and the 123 PeerKeyName. Implementations can use this field to uniquely 124 identify rows in the key table. 126 LocalKeyName 127 The LocalKeyName field contains a string identifying the key. 128 It can be used to retrieve the key in the local database when 129 received in a message. As discussed in Section 4, the 130 protocol defines the form of this field. For example, many 131 routing protocols restrict the format of their key names to 132 integers that can be represented in 16 or 32 bits. Typically 133 this field does not contain data in human character sets 134 requiring internationalization. If there ever are any 135 Protocols with key names requiring internationalization, those 136 specifications need to address issues of canonicalization and 137 normalization so that key names can be compared using binary 138 comparison. 140 PeerKeyName 141 For unicast communication, the PeerKeyName of a key on a system 142 matches the LocalKeyName of the identical key that is 143 maintained on one or multiple peer systems. Similar to 144 LocalKeyName, a protocol defines the form of this identifier 145 and will often restrict it to be an integer. For group keys, 146 the protocol will typically require this field be an empty 147 string as the sending and the receiving key names need to be 148 the same. 150 Peers 151 Typically for unicast keys, this field lists the peer systems 152 that have this key in their database. For group keys this field 153 names the groups for which the key is appropriate. For example, 154 this might name a routing area for a multicast routing 155 protocol. Formally, this field provides a protocol-specific set 156 of restrictions on the scope in which the key is appropriate. 157 The format of the identifiers in the Peers field is specified 158 by the protocol. 160 Interfaces 161 The Interfaces field identifies the set of physical and/or 162 virtual interfaces for which it is appropriate to use this key. 163 When the long-lived value in the Key field is intended for use 164 on any interface, this field is set to "all". The interfaces 165 field consists of a set of strings; the form of these strings 166 is specified by the implementation and is independent of the 167 protocol in question. Protocols may require support for the 168 interfaces field or may indicate that support for constraining 169 keys based on interface is not required. As an example, TCP-AO 170 implementations are unlikely to make the decision of what 171 interface to use prior to key selection. In this case, the 172 implementations are expected to use the same keying material 173 across all of the interfaces and then require the "all" 174 setting. 176 Protocol 177 The Protocol field identifies a single security protocol where 178 this key may be used to provide cryptographic protection. This 179 specification establishes a registry for this field; the 180 registry also specifies the format of the following field, 181 ProtocolSpecificInfo, for each registered protocol. 183 ProtocolSpecificInfo 184 This field contains the protocol-specified information which 185 may be useful for a protocol to apply the key correctly. Note 186 that such information must not be required for a protocol to 187 locate an appropriate key. When a protocol does not need the 188 information in ProtocolSpecificInfo, it will require this field 189 be empty. Key table rows MAY specify a direction of "both". 190 As a result, the encoding of this field needs to support 191 encoding protocol specific information for sending and 192 receiving in the same row. 194 KDF 195 The KDF field indicates the key derivation function which is 196 used to generate short-lived keys from the long-lived value in 197 the Key field. When the long-lived value in the Key field is 198 intended for direct use, the KDF field is set to "none". A key 199 derivation function is a one-way function that provides 200 cryptographic separation of key material. The KDF MAY use 201 inputs from the row in the key table and the message being sent 202 or received but MUST NOT depend on other configuration state. 203 This document establishes an IANA registry for the values in 204 the KDF field to simplify references in future specifications. 205 The protocol indicates what (if any) KDFs are valid. 207 AlgID 208 The AlgID field indicates which cryptographic algorithm to be 209 used with the security protocol for the specified peer or 210 peers. Such an algorithm can be an encryption algorithm and 211 mode (e.g., AES-128-CBC), an authentication algorithm (e.g., 212 HMAC-SHA1-96 or AES-128-CMAC), or any other symmetric 213 cryptographic algorithm needed by a security protocol. If the 214 KDF field contains "none", then the long-lived key is used 215 directly with this algorithm, otherwise the derived short-lived 216 key is used with this algorithm. When the long-lived key is 217 used to generate a set of short-lived keys for use with the 218 security protocol, the AlgID field identifies a ciphersuite 219 rather than a single cryptographic algorithm. This document 220 establishes an IANA registry for the values in the AlgID field 221 to simplify references in future specifications. Protocols 222 indicate which algorithms are appropriate. 224 Key 225 The Key field contains a long-lived symmetric cryptographic key 226 in the format of a lower-case hexadecimal string. The size of 227 the Key depends on the KDF and the AlgID. For instance, a 228 KDF=none and AlgID=AES128 requires a 128-bit key, which is 229 represented by 32 hexadecimal digits. 231 Direction 232 The Direction field indicates whether this key may be used for 233 inbound traffic, outbound traffic, both, or whether the key 234 has been disabled and may not currently be used at all. The 235 supported values are "in", "out", "both", and "disabled", 236 respectively. The Protocol field will determine which of these 237 values are valid. 239 SendLifetimeStart 240 The SendLifetimeStart field specifies the earliest date and 241 time in Coordinated Universal Time (UTC) at which this key 242 should be considered for use when sending traffic. The format 243 is YYYYMMDDHHSSZ, where four digits specify the year, two 244 digits specify the month, two digits specify the day, two 245 digits specify the hour, two digits specify the minute, and 246 two digits specify the second. The "Z" is included as a clear 247 indication that the time is in UTC. 249 SendLifeTimeEnd 250 The SendLifeTimeEnd field specifies the latest date and time at 251 which this key should be considered for use when sending 252 traffic. The format is the same as the SendLifetimeStart 253 field. 255 AcceptLifeTimeStart 256 The AcceptLifeTimeStart field specifies the earliest date and 257 time in Coordinated Universal Time (UTC) at which this key 258 should be considered for use when processing received traffic. 259 The format is YYYYMMDDHHSSZ, where four digits specify the 260 year, two digits specify the month, two digits specify the day, 261 two digits specify the hour, two digits specify the minute, and 262 two digits specify the second. The "Z" is included as a clear 263 indication that the time is in UTC. 265 AcceptLifeTimeEnd 266 The AcceptLifeTimeEnd field specifies the latest date and time 267 at which this key should be considered for use when processing 268 the received traffic. The format of this field is identical to 269 the format of AcceptLifeTimeStart. 271 3. Key Selection and Rollover 273 A protocol may directly consult the key table to find the key to use 274 on an outgoing message. The protocol provides a protocol (P) and a 275 peer identifier (H) into the key selection function. Optionally, an 276 interface identifier (I) may also need to be provided. Any key that 277 satisfies the following conditions may be selected: 279 (1) the Peers field includes H; 281 (2) the Protocol field matches P; 282 (3) If an interface is specified by the protocol, the Interfaces 283 field in the key table row includes I or "all"; 285 (4) the Direction field is either "out" or "both"; and 287 (5) SendLifetimeStart <= current time <= SendLifeTimeEnd. 289 During key selection, multiple entries may simultaneously exist 290 associated with different cryptographic algorithms or ciphersuites. 291 Systems should support selection of keys based on algorithm 292 preference to facilitate algorithm transition. 294 In addition, multiple entries with overlapping valid periods are 295 expected to be available for orderly key rollover. In these cases, 296 the expectation is that systems will transition to the newest key 297 available. To meet this requirement, this specification recommends 298 supplementing the key selection algorithm with the following 299 differentiation: select the long-lived key specifying the most recent 300 time in the SendLifetimeStart field. 302 In order to look up a key for verifying an incoming message, the 303 protocol provides its protocol (P), the peer identifier (H), the key 304 identifier (L), and optionally the interface (I). If one key matches 305 the following conditions it is selected: 307 (1) the Peer field includes H; 309 (2) the Protocol field matches P; 311 (3) if the Interface field is provided, it includes I or is 312 "all"; 314 (4) the Direction field is either "in" or "both"; 316 (5) the LocalKeyName is L; and 318 (6) AcceptLifeTimeStart <= current time <= AcceptLifeTimeEnd. 320 Note that the key usage is loosely bound by the times specified in 321 the AcceptLifeTimeStart and AcceptLifeTimeEnd fields. New security 322 associations should not be established except within the period of 323 use specified by these fields, while allowing some grace time for 324 clock skew. However, if a security association has already been 325 established based on a particular long-lived key, exceeding the 326 lifetime does not have any direct impact. The implementations of 327 security protocols that involve long-lived security association 328 should be designed to periodically interrogate the database and 329 rollover to new keys without tearing down the security association. 331 Rather than consulting the conceptual database, a security protocol 332 such as TCP-AO may update its own tables as keys are added and 333 removed. In this case, the protocol needs to maintain its own key 334 information. Some routing protocols use IP Security (IPsec) to 335 provide integrity. If a specification describes how to use the 336 conceptual database described in this document to configure keys for 337 these routing protocols, similar concerns apply. The specification 338 mapping those routing protocols onto this conceptual database needs 339 to describe how the Security Policy Database is manipulated as rows 340 are added and removed from the conceptual database. 342 4. Application of the Database in a Security Protocol 344 In order to use the key table database in a protocol specification, a 345 protocol needs to specify certain information. This section 346 enumerates items that a protocol must specify. 348 (1) The ways of mapping the information in a key table row to the 349 information needed to produce an outgoing message; specified 350 either as an explanation of how to fill in authentication-related 351 fields in a message based on key table information, or for 352 protocols such as TCP-AO how to construct Master Key Tuples (MKTs) 353 or other protocol-specific structures from a key table row 355 (2) The ways of locating the peer identifier (a member of the 356 Peers set) and the LocalKeyName inside an incoming message 358 (3) The methods of verifying a message given a key table row; 359 this may be stated directly or in terms of protocol-specific 360 structures such as MKTs 362 (4) The form and validation rules for LocalKeyName and 363 PeerKeyName; if either of these is an integer, the conventions in 364 Section 5.1 are used as a vendor-independent format 366 (5) The form and validation rules for members of the Peers set 368 (6) The algorithms and KDFs supported 370 (7) The form of the ProtocolSpecifics field 372 (8) The rules for canonicalizing LocalKeyName, PeerKeyName, 373 entries in the Peers set, or ProtocolSpecifics; this may include 374 normalizations such as lower-casing hexadecimal strings 376 (9) The Indication whether the support for Interfaces is required 377 by this protocol 379 The form of the interfaces field is not protocol-specific but instead 380 is shared among all protocols on an implementation. If a protocol 381 needs to distinguish instances running over the same interface, this 382 is included in the specification of peers. Generally it is desirable 383 to define the specification of peers so that an operator can use the 384 interfaces field to refer to all instances of a protocol on a link 385 without having to specify both generic interfaces information and 386 protocol-specific peer information. 388 5. Textual Conventions 390 5.1 Key Names 392 When a key for a given protocol is identified by an integer key 393 identifier, the associated key name will be represented as lower case 394 hexadecimal integers with the most significant octet first. This 395 integer is padded with leading 0's until the width of the key 396 identifier field in the protocol is reached. 398 5.2 Keys 400 A key is represented as a lower-case hexadecimal string with the most 401 significant octet of the key first. As discussed in Section 2, the 402 length of this string depends on the associated algorithm and KDF. 404 6. Operational Considerations 406 If the valid periods for long-lived keys do not overlap or the system 407 clocks are inconsistent, it is possible to construct scenarios where 408 systems cannot agree upon a long-lived key. When installing a series 409 of keys to be used one after another, operators should configure the 410 SendLifetimeStart field of the key to be several hours after the 411 AcceptLifeTimeStart field of the key to guarantee there is some 412 overlap. This overlap is intended to address the clock skew issue and 413 allow for basic operational considerations. Operators may choose to 414 specify a longer overlap (e.g., several days) to allow for 415 exceptional circumstances. 417 7. Security Considerations 419 Management of encryption and authentication keys has been a 420 significant operational problem, both in terms of key synchronization 421 and key selection. For instance, the current guidance [RFC3562] 422 warns against sharing TCP MD5 keying material between systems, and 423 recommends changing keys according to a schedule. The same general 424 operational issues are relevant for the management of other 425 cryptographic keys. 427 It has been recognized in [RFC4107] that automated key management is 428 not viable in multiple scenarios. The conceptual database specified 429 in this document is designed to accommodate both manual key 430 management and automated key management. A future specification to 431 automatically populate rows in the database is envisioned. 433 Designers should recognize the warning provided in [RFC4107]: 435 Automated key management and manual key management provide very 436 different features. In particular, the protocol associated with 437 an automated key management technique will confirm the liveness of 438 the peer, protect against replay, authenticate the source of the 439 short-term session key, associate protocol state information with 440 the short-term session key, and ensure that a fresh short-term 441 session key is generated. Moreover, an automated key management 442 protocol can improve the interoperability by including negotiation 443 mechanisms for cryptographic algorithms. These valuable features 444 are impossible or extremely cumbersome to accomplish with manual 445 key management. 447 8. IANA Considerations 449 This specification defines three registries. 451 8.1. KeyTable Protocols 453 This document requests establishment of a registry called "KeyTable 454 Protocols". 456 All assignments to the KeyTable Protocols registry are made on a 457 specification required basis per Section 4.1 of [RFC5226]. 459 Each registration entry must contain the three fields: 461 - Protocol Name (unique within the registry); 462 - Protocol Specific Info; and 463 - Specification. 465 The specification needs to describe parameters required for using the 466 conceptual database as outlined in Section 4. This typically means 467 that the specification focuses more on the application of security 468 protocols with the key tables rather than being a new security 469 protocol specification for general purposes. New protocols may of 470 course combine information on how to use the key tables database with 471 the protocol specification. 473 The registry has three columns. The first column is a string of UTF-8 474 characters representing the name protocol. The second column is a 475 string of UTF-8 characters providing a brief description of Protocol 476 Specific Info. The third column is a reference to a specification 477 defining how the protocol is used with the key table. 479 There are no initial registrations. 481 8.2. KeyTable KDFs 483 This document requests the establishment of a registry called 484 "KeyTable KDFs". The remainder of this section describes the 485 registry. 487 All assignments to the KeyTable KDFs registry are made on a First 488 Come First Served basis per Section 4.1 of RFC 5226. 490 The registry has three columns. The first column is a string of UTF-8 491 characters representing the name of a KDF. The second column is a 492 string of UTF-8 characters providing a brief description of the KDF. 493 The third column is a reference to a specification defining the KDF, 494 if available. 496 KDF Description Reference 497 --- ----------- --------- 498 none No KDF is used with this key 499 802.1X-01 IEEE 802.1X Table 9.1 [IEEE802.1X-2010] 501 8.3. KeyTable AlgIDs 503 This document requests establishment of a registry called "KeyTable 504 AlgIDs". The remainder of this section describes the registry. 506 All assignments to the KeyTable AlgIDs registry are made on a First 507 Come First Served basis per Section 4.1 of RFC 5226. 509 The registry has three columns. The first column is a string of UTF-8 510 characters representing the name of an AlgID. The second column is a 511 string of UTF-8 characters providing a brief description of the 512 AlgID. The third column is a reference to a specification defining 513 the AlgID, if available. 515 AlgID Description Reference 516 ----- ----------- --------- 517 AES-128-CMAC AES-CMAC using 128-bit keys [RFC4493] 519 9. Acknowledgments 521 This document reflects many discussions with many different people 522 over many years. In particular, the authors thank Jari Arkko, Ran 523 Atkinson, Ron Bonica, Ross Callon, Lars Eggert, Pasi Eronen, Adrian 524 Farrel, Gregory Lebovitz, Acee Lindem, Sandy Murphy, Eric Rescorla, 525 Mike Shand, Dave Ward, and Brian Weis for their insights. The 526 authors additionally thank Brian Weis for supplying text to address 527 IANA concerns and for help with formatting. 529 Sam Hartman's work on this draft is funded by Huawei. 531 10. Normative References 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, March 1997. 536 11. Informational References 538 [IEEE802.1X-2010] IEEE Standard for Local and Metropolitan Area Networks -- 539 Port-Based Network Access Control", February 2010. 541 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 542 Signature Option", RFC 3562, July 2003. 544 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 545 Key Management", RFC 4107, BCP 107, June 2005. 547 [RFC4493] Song, J., Lee, J., Poovendran, R., and T. Iwata, "The AES-CMAC 548 Algorithm", RFC 4493, June 2006. 550 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 551 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 552 May 2008. 554 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 555 Authentication Option", RFC 5925, June 2010. 557 Authors' Addresses 559 Russell Housley 560 Vigil Security, LLC 561 918 Spring Knoll Drive 562 Herndon, VA 20170 563 USA 564 EMail: housley@vigilsec.com 566 Tim Polk 567 National Institute of Standards and Technology 568 100 Bureau Drive, Mail Stop 8930 569 Gaithersburg, MD 20899-8930 570 USA 571 EMail: tim.polk@nist.gov 573 Sam Hartman 574 Painless Security, LLC 575 USA 576 Email: hartmans@painless-security.com 578 Dacheng Zhang 579 Huawei 580 China 581 Email: zhangdacheng@huawei.com