idnits 2.17.1 draft-mcgrew-iv-gen-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2013) is 3845 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'CCM' -- Possible downref: Non-RFC (?) normative reference: ref. 'GCM' ** Downref: Normative reference to an Informational RFC: RFC 5647 -- Obsolete informational reference (is this intentional?): RFC 1361 (Obsoleted by RFC 1769) -- Obsolete informational reference (is this intentional?): RFC 3768 (Obsoleted by RFC 5798) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. McGrew 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track October 15, 2013 5 Expires: April 18, 2014 7 Generation of Deterministic Initialization Vectors (IVs) and Nonces 8 draft-mcgrew-iv-gen-03.txt 10 Abstract 12 Many cryptographic algorithms use deterministic IVs, including CTR, 13 GCM, CCM, GMAC. This type of IV is also called a (deterministic) 14 nonce. Deterministic IVs must be distinct, for each fixed key, to 15 guarantee the security of the algorithm. This note describes best 16 practices for the generation of such IVs, and summarizes how they are 17 generated and used in different protocols. Some problem areas are 18 highlighted, and test considerations are outlined. This note will be 19 useful to implementers of algorithms using deterministic IVs, and to 20 protocol or system designers using them. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 18, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 58 2. Deterministic IVs in Algorithms . . . . . . . . . . . . . . . 4 59 3. Deterministic IVs in Protocols . . . . . . . . . . . . . . . . 5 60 4. Deterministic IVs in Standards . . . . . . . . . . . . . . . . 7 61 4.1. Recommended IV/Nonce Format . . . . . . . . . . . . . . . 7 62 4.2. Partially Implicit IV/Nonce Format . . . . . . . . . . . . 8 63 4.3. Alternative IV/Nonce Format . . . . . . . . . . . . . . . 9 64 4.4. Unpredictable IV/Nonce Format . . . . . . . . . . . . . . 10 65 4.5. ESP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.6. IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.7. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.8. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.9. SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 14 72 5.1. IV Verification . . . . . . . . . . . . . . . . . . . . . 16 73 6. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 6.1. Internal IV Generator . . . . . . . . . . . . . . . . . . 17 75 7. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 7.1. Choice of Fixed-Distinct Field . . . . . . . . . . . . . . 18 77 7.2. Size of the Fixed-Distinct Field . . . . . . . . . . . . . 19 78 7.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 7.4. Bandwidth Use . . . . . . . . . . . . . . . . . . . . . . 20 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 87 1. Introduction 89 This note describes deterministic IVs and nonces and how they are 90 used in cryptographic algorithms (Section 2), then describes their 91 use in protocols (Section 3), and then their use in standards 92 (Section 4). Considerations for implementation (Section 5) and 93 testing (Section 6) are presented. Issues and potential problems are 94 discussed (Section 7). The focus is on network security protocols, 95 rather than on the security of data at rest, though many of the same 96 considerations apply in both areas. 98 1.1. Conventions Used In This Document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. Deterministic IVs in Algorithms 106 Many cryptographic algorithms use Initialization Vectors, or IVs. An 107 IV is provided to an algorithm along with a message to be processed; 108 the IV initializes the algorithm to process the message. Typically, 109 there will be many IVs that are used with a single key. Some 110 algorithms, such as the Cipher Block Chaining (CBC) encryption mode, 111 require that the IVs that it uses are completely unpredictable. Such 112 IVs are typically called random IVs, and they must be generated by a 113 cryptographically strong random or pseudorandom process [RFC4086]. 115 Another type of IVs are deterministic IVs. These IVs are generated 116 by a deterministic process. The classic example of an algorithm that 117 uses a deterministic IV is counter (CTR) mode encryption [CTR]. An 118 algorithm that uses deterministic IVs requires that each IV provided 119 as input to the algorithm be distinct, for a fixed key. 121 A deterministic IV is sometimes called a nonce, or a deterministic 122 nonce. In cryptography, a nonce is a value that is used only once. 123 Many cryptographic protocols include a nonce in a message to enable 124 its receiver to recognize whether or not the message has been 125 previously received and processed. From the point of view of a 126 cryptographic algorithm that uses deterministic IVs, calling the IV a 127 nonce emphasizes the role of the IV in the overall system or 128 protocol. Calling that value a deterministic IV emphasizes its role 129 in initializing the algorithm to process a new message. Nonetheless, 130 these are just different monikers for the same thing. 132 Authenticated Encryption is a symmetric encryption method that 133 provides for the authenticity and integrity of the data that it 134 protects, as well as its confidentiality [BN00] [R02]. An 135 authenticated encryption method that uses deterministic IVs will need 136 to make sure that the IVs used for encryption are distinct. However, 137 when performing the decryption operation, there is no need to ensure 138 that the IVs are distinct; the authenticated decryption operation 139 does not impose that requirement. The Authenticated Encryption 140 methods used in standards include Galois Counter Mode [GCM] and 141 Counter and CBC MAC mode [CCM]. 143 Some Message Authentication Code (MACs) use deterministic IVs, 144 including GMAC [GCM] and UMAC [RFC4118]. The considerations for 145 Authenticated Encryption also apply to these MAC algorithms: the IVs 146 used in the generation of an authentication tag must be distinct, but 147 there is no need to verify the distinctness of an IV prior to 148 inputting that IV to a tag verification algorithm. 150 3. Deterministic IVs in Protocols 152 The simplest way to implement a deterministic IV or nonce is to use a 153 counter: initialize an integer variable to zero, then each time that 154 an IV is needed, output the integer value, then store the incremented 155 value after checking to make sure that no integer overflow occurred, 156 so that no counter value is used twice. The simplicity of this 157 method has made it popular in practice, and recommended by standards. 159 The straightforward method of using a counter is not sufficient when 160 there are multiple encryption engines that are using the same 161 encryption key. This can be the case when encryption is distributed 162 across multiple processors, or across multiple software threads, 163 processes, or virtual machines. It can also happen in cases where a 164 protocol allows group keys. In these cases, some mechanism is needed 165 that ensures that IVs are distinct across all encryption engines that 166 use the same key. This is easily accomplished by including a fixed 167 field in the IV that is distinct for each distinct encrypter. (This 168 is detailed in Section 4.1.) 170 When a deterministic IV is used to encrypt and/or authenticate a 171 message, the receiver(s) of that message needs to know that IV in 172 order to decrypt it and/or verify its authenticity. A deterministic 173 IV can be sent along with a message, which makes it plain to the 174 receiver(s), or it can be left out of a message if the receiver(s) 175 have enough information to reconstruct it. Leaving the IV out of the 176 message reduces the amount of data that must be communicated, which 177 is advantageous. On the other hand, if the IV is included in the 178 message, the receiver(s) need not be aware of the method by which the 179 sender has chosen the IVs. 181 In practice, some protocols have split the difference between the 182 implicit method (in which the IV is absent and a receiver infers its 183 value) and the explicit method (in which the entire IV is included 184 with the message). The IV is constructed out of two fields: an 185 explicit field, which is conveyed along with the message, and an 186 implicit field, which is coordinated between the encrypter and the 187 decrypter using an "out of band" method. (This is detailed in 188 Section 4.2.) In most cases, the key management protocol that 189 establishes the encryption key can also establish the implicit field. 191 In a block cipher mode of operation that use deterministic IVs, the 192 inputs to each of the block cipher invocations during the encryption 193 process are determined by the IV provided to that process. It is 194 desirable to make the inputs to the block cipher unpredictable to an 195 attacker, to the extent that is possible, to make cryptanalytic 196 attacks more difficult and costly to attackers. This is true for 197 several types of attacks, including time-memory tradeoff attacks and 198 key collision attacks [MF00], which are generic attacks that can be 199 applied to any cipher, and cipher-specific attacks such as integral 200 cryptanalysis [KW02]. (It is worth noting that counter mode gives an 201 attacker exactly what they want for integral cryptanalysis: a 202 complete set of block cipher inputs that differ only in some bit 203 positions.) The cost of these attacks can be significantly increased 204 by making the deterministic IV unpredictable to potential attackers. 205 This security benefit is one motivation for why the implicit field of 206 the deterministic IV is kept secret in some protocols. 208 It is not hard to adapt the simple methods for constructing 209 deterministic IVs so that they produce IVs that are unpredictable. 210 An easy way to do that is to have a secret value that is bitwise 211 exclusive-ored into the IV after all of the other processing is done. 212 (This is detailed in Section 4.4.) This secret value must be known 213 to all encrypters and decrypters, and be established via some "out of 214 band" mechanism. In practice, it is typically established by the key 215 management system. 217 4. Deterministic IVs in Standards 219 Many different protocols use deterministic IVs, including ESP 220 [RFC4106], TLS [RFC5288], SSH [RFC5647], and SRTP [RFC3711]. The way 221 that these protocols define their IVs is outlined in this section and 222 is summarized in Table 1. 224 4.1. Recommended IV/Nonce Format 226 RFC 5116 defines the interface for Authenticated Encryption, which is 227 the most common use of deterministic IVs at present. That RFC 228 recommends an IV format that is used by ESP, IKE, TLS, and SSH. The 229 recommended format has a total length of 12 octets, and consists of a 230 Fixed Field and a Counter field, and is structured as in Figure 1. 231 (See Section 3.2 of [RFC5116] for the precise normative description.) 233 +-------------------------------+------------------------+ 234 | Fixed | Counter | 235 +-------------------------------+------------------------+ 237 Figure 1: Recommended IV/Nonce format. 239 Fixed Counter 240 <------><--------------> 241 1st 5DAD87F80000000000000001 242 2nd 5DAD87F80000000000000002 243 3rd 5DAD87F80000000000000003 244 4th 5DAD87F80000000000000004 245 5th 5DAD87F80000000000000005 246 ... ... 248 Figure 2: An example output of recommended IV/nonce format, showing 249 successive IVs where the Fixed field is 5DAD87F8. 251 The Fixed field remains constant for all nonces that are generated 252 for a given encryption device. If different devices are performing 253 encryption with a single key, then each distinct device MUST use a 254 distinct value for the Fixed field, to ensure the uniqueness of the 255 nonces that it generates. 257 This format is suggested, but not required, by [CTR]. 259 With this format, the Counter fields of successive nonces form a 260 monotonically increasing sequence, when those fields are regarded as 261 unsigned integers in network byte order. 263 4.2. Partially Implicit IV/Nonce Format 265 The case in which the recommended format is used with Partially 266 Implicit Nonces has further details. In that case, the IV is 267 structured as in Figure 3. 269 +--------------+----------------+------------------------+ 270 | Fixed-Common | Fixed-Distinct | Counter | 271 +--------------+----------------+------------------------+ 272 <- implicit -> <--------------- explicit --------------> 274 Figure 3: Partially implicit IV/Nonce format 276 Fixed Fixed 277 Common Distinct Counter 278 <------><--><----------> 279 1st 5DAD87F81E0E000000000001 280 2nd 5DAD87F81E0E000000000002 281 3rd 5DAD87F81E0E000000000003 282 4th 5DAD87F81E0E000000000004 283 5th 5DAD87F81E0E000000000005 284 ... ... 286 Figure 4: An example output of Partially Implicit IV/Nonce format, 287 showing successive IVs where the Fixed-Common field is 5DAD87F8 and 288 the Fixed-Distinct field is 1E0E. 290 The portion of the IV that is stored or sent with the ciphertext is 291 the explicit part. The portion of the IV that is not sent with the 292 ciphertext is the implicit part. 294 The Fixed field is divided into two sub-fields: a Fixed-Common field 295 and a Fixed-Distinct field. 297 If different devices are performing encryption with a single key, 298 then each distinct device MUST use a distinct Fixed-Distinct field. 299 The Fixed-Common field is common to all IVs. The Fixed-Distinct 300 field and the Counter field MUST be in the explicit part of the IV. 301 The Fixed-Common field MAY be in the implicit part of the IV. 303 ESP, IKE, TLS, and SSH conform to the alternative IV/nonce format, 304 though in practice the partially implicit format is often used. 305 Those standards do not require that the "Changing" field actually be 306 a counter (instead, "anything that guarantees uniqueness can be 307 used"), but in practice a counter is convenient. 309 The partially implicit format can save on bandwidth or data storage 310 requirements, because it avoids sending or storing the implicit part 311 of the IV. However, it limits the number of IVs that can be 312 generated, because the implicit part is fixed, and it adds complexity 313 to the system, by making the system coordinate the implicit part 314 through out-of-band means. Thus, new protocol and system designs 315 SHOULD NOT use the partially implicit format unless a review of all 316 of the issues shows that the bandwidth or storage savings are worth 317 the complexity. (An alternative strategy for bandwidth savings is 318 discussed in Section 7.4.) 320 4.3. Alternative IV/Nonce Format 322 In some cases, it may be desirable to avoid the use of a network byte 323 order monotonically increasing counter. This would be especially 324 true in a protocol that has the security goal of obscuring the 325 relationship between messages, so that an attacker cannot infer that 326 particular messages belong to the same flow, and cannot infer the 327 order of messages within a flow. In other cases, there may be a data 328 element available that meets the requirement of being distinct for 329 each invocation of the encryption operation, but is not monotonically 330 increasing in network byte order. In such situations, it makes sense 331 to use an alternative nonce format that replaces the Counter field, 332 as it is used above, with a field that is distinct for each IV/nonce 333 that is generated, but which is not a counter. We call this field 334 the Changing field. The alternative format is shown in Figure 5, and 335 an example output is shown in Figure 6. 337 IVs/Nonces that are in the partially implicit format also happen to 338 conform to the alternative format as well. 340 +--------------+----------------+------------------------+ 341 | Fixed-Common | Fixed-Distinct | Changing | 342 +--------------+----------------+------------------------+ 343 <- implicit -> <--------------- explicit --------------> 345 Figure 5: Alternative IV/Nonce format 346 Fixed 347 Common Changing 348 <------><--------------> 349 1st 88be20d4600ced63f924ff5b 350 2nd 88be20d458a0169be27d661f 351 3rd 88be20d43ece0f6a4061eca8 352 4th 88be20d46016f0a41c1cbc27 353 5th 88be20d4ba7f697eb00aee67 354 ... ... 356 Figure 6: An example output of Alternative IV/Nonce format, showing 357 successive IVs where the Fixed-Common field is 5DAD87F8 and the 358 Fixed-Distinct field is zero length (or equivalently, is not 359 present). 361 4.4. Unpredictable IV/Nonce Format 363 This method is shown in Figure 7, in which the symbol (+) denotes the 364 bitwise exclusive-or operation. (Here the Fixed field consists of 365 the Fixed-Common field followed by the Fixed-Distinct field.) This 366 format uses a Randomizer, which is an octet string that is combined 367 with the other fields to make the IVs unpredictable. The length of 368 the Randomizer must be no greater than the sum of the lengths of the 369 Fixed and Counter fields. 371 The next IV in sequence is computed as follows. The Fixed field and 372 the Counter field are concatenated. If the length of the Randomizer 373 is less than the combined length of the Fixed and Counter fields, 374 then the Randomizer is padded on the right with enough zeros so that 375 the padded value has a length that exactly matches that of the Fixed 376 and Counter fields together. The concatenated Fixed and Counter 377 field is bitwise exclusive-ored with the padded Randomizer, and the 378 resulting value is the IV. The Counter is incremented, treating it 379 as an unsigned integer with the most significant byte on the left, 380 and the stored Counter field is set to the incremented value. Then 381 the IV is returned. This is the method used by SRTP [RFC3711], 382 wherein the Randomizer field is called "Salt". (We use the term 383 Randomizer instead of Salt, because the latter term is used with 384 slightly different meanings in some other specifications, such as 385 [RFC4309].) 386 +-----------------+-----------------+ 387 | Fixed | Counter |---+ 388 +-----------------+-----------------+ | 389 | 390 +-----------------------------------+ v 391 | Randomizer |->(+) 392 +-----------------------------------+ | 393 | 394 +-----------------------------------+ | 395 | Initialization Vector |<--+ 396 +-----------------------------------+ 398 Figure 7: Unpredictable IV/Nonce Format. 400 Fixed Fixed 401 Common Distinct Counter IV 402 <--><------><----------> <----------------------> 403 1st 000097B4AE8F000000000001 0C81C77A5DDB678EE16FA2D0 404 2nd 000097B4AE8F000000000002 0C81C77A5DDB678EE16FA2D3 405 3rd 000097B4AE8F000000000003 0C81C77A5DDB678EE16FA2D2 406 4th 000097B4AE8F000000000004 0C81C77A5DDB678EE16FA2D5 407 5th 000097B4AE8F000000000005 0C81C77A5DDB678EE16FA2D4 408 ... ... 410 Figure 8: An example output of the Unpredictable IV/nonce format, 411 showing successive IVs where the Fixed-Distinct field has the value 412 97B4AE8F and the Salt has value 0C8150CEF354678EE16FA2D1. 414 4.5. ESP 416 In the IP Encapsulating Security Payload (ESP) 417 [RFC3686][RFC4106][RFC4309] the implicit and explicit parts are four 418 and eight bytes long, respectively. The exception is [RFC4309], for 419 which the implicit part is three bytes in length. The Fixed-Common 420 field is four bytes, and its value is set by the Internet Key 421 Exchange (IKE). (This field is named inconsistently, being called 422 Nonce in [RFC3686], and Salt in [RFC4106] and [RFC4309].) When ESP 423 is used with IKE, there is exactly one entity performing encryption, 424 and the Fixed-Distinct part is usually not present (or equivalently, 425 is has a length of zero bytes). When ESP is used with a group key 426 management protocol such as GDOI, the Fixed-Distinct field may be two 427 or four bytes in length, and the value of the Fixed-Distinct field to 428 be used by an encrypter is established by the group key management 429 protocol [RFC6054]. The case in which IKE is used with ESP and there 430 are multiple encryption engines is not specifically addressed by the 431 standards, but it can be handled by the use of a nonzero Fixed- 432 Distinct field. 434 4.6. IKE 436 The Internet Key Exchange (IKE) [RFC5282] uses the recommended IV/ 437 nonce format. The Fixed-Common field is four bytes in length, and 438 its value is set from the IKE Keying Material. The Fixed-Distinct 439 part is usually zero bytes, but it may be any number of bytes if 440 there are multiple encrypters in use. 442 4.7. TLS 444 In Transport Layer Security (TLS) [RFC5288], the Fixed-Common field 445 is four bytes in length, and the Fixed-Distinct part is usually zero 446 bytes, but it may be any number of bytes when there are multiple 447 encrypters in use. Section 6.2 of [RFC5288] gives an example of TLS 448 deterministic IV formation. 450 4.8. SSH 452 In the Secure Shell (SSH) protocol [RFC5647] the Fixed-Common field 453 is not present, the Fixed-Distinct field is four bytes long, and the 454 Counter field is eight bytes in length. The implicit part is not 455 present, and the explicit part contains the entire 12 byte IV. 457 4.9. SRTP 459 The Secure Real-time Transport Protocol (SRTP) [RFC3711] and 460 draft-ietf-avt-srtp-aes-gcm-01 use the unpredictable format, which is 461 a bit more complex than RFC 5116. It is essentially RFC 5116 format 462 with the additional step of performing a bitwise exclusive-or 463 operation with a Randomizer value. (This step provides additional 464 strength against cryptographic attacks that rely on predicting all or 465 most of the IV.) draft-ietf-avt-srtp-aes-gcm-01 uses a 12-byte IV, 466 though RFC 3711 uses a 14-byte IV. 468 4.10. Summary 470 The following table gives a synopsis of how standard protocols use 471 deterministic IVs. 473 +-----------+---------+--------------+----------------+-------------+ 474 | Protocol | IV | Fixed-Common | Fixed-Distinct | Counter | 475 | | (bytes) | (bytes) | (bytes) | (bytes) | 476 +-----------+---------+--------------+----------------+-------------+ 477 | ESP | 12 | 4 | 0,1,2,[4] | 8,7,6,[4] | 478 | | | | | | 479 | | | Not on wire | On wire | On wire | 480 | | | | | | 481 | | | Set by IKE | | | 482 | | | | | | 483 | ESP | 11 | 3 | 0,1,2,[4] | 8,7,6,[4] | 484 | | | | | | 485 | [RFC4309] | | Not on wire | On wire | On wire | 486 | | | | | | 487 | | | Set by IKE | | | 488 | | | | | | 489 | IKE | 12 | 4 | Unspecified | Unspecified | 490 | | | | | | 491 | | | Not on wire | On wire | On wire | 492 | | | | | | 493 | | | Set from KM | | | 494 | | | | | | 495 | TLS | 12 | 4 | 0-8 | 8-0 | 496 | | | | | | 497 | | | Not on wire | On wire | On wire | 498 | | | | | | 499 | | | Set by TLS | | | 500 | | | | | | 501 | SSH | 12 | 0 | 4 | 8 | 502 | | | | | | 503 | | | | On wire | On wire | 504 | | | | | | 505 | | | | Unspecified | | 506 | | | | | | 507 | SRTP-CTR | 14 | 4 | 4 | 6 | 508 | | | | | | 509 | | | Not on wire | Not on wire | Not on wire | 510 | | | | | | 511 | | | Set by KM | | | 512 | | | | | | 513 | SRTP-GCM | 12 | 2 | 4 | 6 | 514 | | | | | | 515 | | | Not on wire | Not on wire | Not on wire | 516 | | | | | | 517 | | | Set by KM | | | 518 +-----------+---------+--------------+----------------+-------------+ 520 Table 1: Fields in Deterministic IVs, by Protocol. 522 5. Implementation 524 A cryptographic implementation typically consists of a self-contained 525 and testable module that implements all of the essential 526 functionality that it needs. This functionality should include the 527 generation of deterministic IVs. 529 Because of the variety of ways in which IVs are formed in different 530 protocols, implementers may be tempted to put the generation of the 531 IV under the control of the protocol implementation. That is, from 532 the point of view of the application making use of the encryption 533 algorithm, the IV is an input to that algorithm, as shown in 534 Figure 9. Regardless, it is not good for security to have the IV be 535 generated outside the crypto module. It is possible to implement an 536 IV Generator that can be used with all of the protocols outlined 537 above and use it inside of a cryptographic module. In the following 538 we outline how that can be done. 540 +----------------------+ 541 | +--------------+ | IV +-------------+ 542 | | |<-------------------| | 543 | | Encryption | | Plaintext | | 544 | | Algorithm |<-------------------| Application | 545 | | | | Ciphertext | | 546 | | |------------------->| | 547 | +--------------+ | +-------------+ 548 | | 549 | Cryptographic Module | 550 +----------------------+ 552 Figure 9: Architecture with IV generation outside of the 553 cryptographic module, showing how the IV is entered into the 554 cryptographic module during an encryption operation. 556 The internal IV generator architecture is illustrated in Figure 10. 557 The cryptographic module contains an IV Generator sub-module that 558 understands the IV formats outlined in Section 3. To initialize the 559 IV generator, the application inputs the parameter values to be used. 560 Once initialized, the IV generator will produce successive IVs on 561 request, and send these values to the algorithm and to the calling 562 application. The encryption algorithm will need the entire IV, but 563 if the partially implicit IV format is in use, only the explicit part 564 of the IV needs to be provided to the application. The IV generator 565 is responsible for ensuring the distinctness of all of the IVs that 566 it generates. 568 +----------------------+ 569 | +--------------+ | 570 | | IV Generator |-----------+ 571 | +--------------+ | | IV (explicit part) 572 | | IV | | 573 | v | | 574 | +--------------+ | | +-------------+ 575 | | | +------->| | 576 | | Encryption | | Plaintext | | 577 | | Algorithm |<-------------------| Application | 578 | | | | Ciphertext | | 579 | | |------------------->| | 580 | +--------------+ | +-------------+ 581 | | 582 | Cryptographic Module | 583 +----------------------+ 585 Figure 10: Architecture with IV generation inside of the 586 cryptographic module, showing how the IV is generated internally 587 during an encryption operation. 589 More formally, an IV generator supports the operations of Initialize 590 and Output Next IV. The Initialize operation prepares an IV 591 Generator for use with a particular set of parameters. It takes the 592 following inputs: 594 A nonnegative integer indicating the number of bytes in the IV to 595 be generated. All of the IVs output from the Generator will have 596 the same length. 598 An octet string indicating the Fixed part of the IV; this value 599 will be used as the initial part in each IV that is generated. 601 A nonnegative integer indicating the number of bytes in the Fixed 602 part of the IV. This value must be no greater than the number of 603 bytes in the IV. 605 An octet string indicating the salt value to be exclusive-ored 606 with the other fields of the IV. If no salt is to be used when 607 Generating IVs, then this parameter must not be present. 609 A nonnegative integer indicating the number of bytes in the salt 610 value. If no salt value is used, this parameter must be zero. If 611 a salt value is used, this parameter must be no greater than the 612 number of bytes in the IV. 614 The Fixed field consists of the Fixed-Common field, followed by the 615 Fixed-Distinct field. The Fixed field and Salt field are stored when 616 the IV generator is initialized; at that time, the Counter field is 617 initialized to zero. The length of the Counter field is equal to the 618 length of the IV less the length of the Fixed field. If the Salt 619 field is shorter than the IV, then it is padded on the right with 620 zeroes. If no Salt is to be used, this is conceptually equivalent to 621 having a Salt value that is the all-zero value. 623 The Output Next IV operation returns the next IV in sequence, or it 624 returns an indication that there are no more IVs that are available. 625 During that operation, the IV is computed as follows. First, the 626 stored Counter value MUST be checked to determine if an IV can be 627 generated; an IV can only be generated if the value of Counter + 1 628 does not exceed the maximum allowable value of the Counter field. If 629 an IV cannot be generated, then the operation returns an indication 630 that there are no more IVs that are available. Otherwise, the Fixed 631 field and the Counter field are concatenated, then they are bitwise 632 exclusive-ored with the Salt field, and the resulting value is the 633 IV. The Counter is incremented, treating it as an unsigned integer 634 with the most significant byte on the left, and the stored Counter 635 field is set to the incremented value. Then the IV is returned. 637 The IV generator should also be able to output the length of the 638 explicit field, so that an algorithm can output only the explicit 639 part, when that is appropriate. 641 5.1. IV Verification 643 In some protocols, the IV is constructed out of fields in the 644 protocol in such a way that it is difficult to have the IVs generated 645 inside of the cryptographic module, without requiring that module to 646 contain protocol-specific logic. In this case, assurance of the 647 uniqueness of IVs can be provided by having the IVs be generated by 648 the protocol, but checked by the cryptographic module. 650 This approach is taken by many implementations of Secure RTP 651 [RFC3711]. The IV in that protocol is constructed in a way that 652 incorporates a sender identifier (the SSRC field) and the protocol's 653 sequence number. To check the sequence number for uniqueness, an 654 implementation can make use of the anti-replay checking that the 655 protocol uses to check inbound packet. An encrypter can use this 656 approach as well, to make sure that the sequence number used to 657 construct the IV is unique. (Of course, it is necessary to have an 658 IV construction method such that the uniqueness of the sequence 659 number ensures the uniqueness of the IV.) Since many cryptographic 660 protocols contain a function to perform anti-replay check based on a 661 sequence number, this is a convenient strategy. 663 6. Testing 665 The testing of a cryptographic module is an important step in 666 assessing the assurance of that module. The IV Generator defined in 667 Section 5 can be tested by an external system to verify that it is 668 operating correctly. 670 Any IV format can be tested by verifying that all of the IVs are 671 distinct. There are many ways that this can be done; for instance, 672 the command "sort | uniq -d" on POSIX systems can be used to detect 673 repeated lines in a file. 675 The recommended format can be tested by verifying that the Counter 676 field consists of monotonically increasing values. 678 An important aspect of an IV generator is that, when it has an N byte 679 Counter or Changing field, it should not generate more than (256)^N 680 IVs. This property should be tested for small values of N (at least 681 1, 2, and 3), by calling the Output Next IV operation M times, for 682 some M > (256)^N. Note that some implementations may produce fewer 683 than (256)^N IVs, e.g. due to their handling of the all-zero IV. 684 That would not affect security. 686 6.1. Internal IV Generator 688 When a cryptographic module uses an internal IV generator, only the 689 explicit part of the IV needs to be output from the module. It is 690 possible to test this use of the IV generator by interacting with an 691 encryption algorithm that uses it (or an Authenticated Encryption 692 algorithm, or a MAC). 694 The encryption operation takes as input a plaintext, and returns a 695 ciphertext and the explicit part of the IV. To test that the IV 696 generator is working properly, call the encryption operation 697 repeatedly, each time with the same plaintext value, and verify that 698 1) all of the ciphertexts returned are distinct, and 2) all of the 699 explicit parts that are returned are distinct. The plaintext must be 700 at least 32 bytes long, in order to avoid false positives. 702 7. Issues 704 7.1. Choice of Fixed-Distinct Field 706 When considering what data should go into a Fixed-Distinct field, it 707 is tempting to use system values such as network addresses because 708 they appear to meet the criteria of uniqueness. However, there are 709 several significant problems with this idea. System values that are 710 taken from outside the cryptographic module may not actually be 711 distinct, especially if an attacker can influence the system. System 712 values can also change over time; even if they are actually distinct, 713 they may not be fixed. Lastly, the cryptographic system should have 714 the freedom to put distinct data into the Fixed-Distinct fields, so 715 that it can accommodate multiple encryption engines when they occur. 717 Internet Protocol (IP) version four addresses are four bytes in 718 length, and thus can fit into the Fixed-Distinct field of a 12-byte 719 IV. However, an IP address is highly unsuitable for this purpose. 720 Most networked devices use dynamically assigned IP addresses, with 721 address assignment via an automatic configuration protocol such as 722 the Dynamic Host Configuration Protocol (DHCP). The addresses are 723 determined by an external system and are communicated over an 724 insecure protocol; furthermore, a DHCP address is only valid for a 725 particular period of time, and may change after that lease has 726 expired. Even when an automatic configuration protocol is not in 727 use, IP addresses are determined by the networking subsystem, and are 728 not under the control of the cryptographic module. Network Address 729 Translation (NAT, [RFC1361]) is commonly used to modify the IP 730 addresses of packets as they traverse a network boundary, for 731 instance between a private address space [RFC1918] and the Internet. 732 Because of NAT, the IP address associated with a particular device 733 will not be consistent throughout the network. Multiple devices can 734 use the same addresses; this technique is utilized in order to 735 provide redundancy or load sharing (see the Virtual Router Redundancy 736 Protocol [RFC3768] for instance). Lastly, IPv4 is currently being 737 replaced by version six of that protocol. IPv6 addresses are sixteen 738 bytes long; this is too long for inclusion in an IV, and the 739 coexistence of both versions on the Internet is likely to increase 740 the use of NAT for protocol translation [RFC6146]. In summary, IP 741 addresses are neither fixed nor distinct, and should not be used in a 742 Fixed-Distinct field. 744 Similar considerations hold for link layer addresses, Domain Name 745 System (DNS) names, and TCP, UDP, and SCTP ports. 747 A much better solution is to have the Fixed-Distinct field be 748 assigned by the security system. For instance, if a cryptographic 749 module has multiple encrypters, it can assign that field 750 appropriately for each encrypter. 752 7.2. Size of the Fixed-Distinct Field 754 Deterministic IVs typically have an explicit part that is eight bytes 755 in length. (This size is natural to use with a block cipher that has 756 a 16 byte block width, because no more than (256)^8 packets can be 757 encrypted under a single key without encountering security 758 degradation due to the birthday paradox.) Because the Fixed-Distinct 759 field must appear in the explicit part, larger Fixed-Distinct fields 760 will reduce the number of IVs that can be generated. This can be 761 problematic, especially for high throughput situations. For 762 instance, the ESP protocol allows for up to 2^64 packets to be 763 encrypted under a single key, so it is desirable to use a Counter 764 field that is close to eight bytes in length; this is why [RFC6054] 765 encourages the use of short values in the Fixed-Distinct field. 766 Table 2 presents the lifetimes of a single key that can encrypt 2^32 767 packets, i.e. a key being used with a four-byte Counter field. At 768 high data rates, keys must be replaced quickly. 770 +----------+-------------------+------------------+-----------------+ 771 | | Best Case | Typical Case | Worst Case | 772 +----------+-------------------+------------------+-----------------+ 773 | | 9000 byte packets | 850 byte packets | 64 byte packets | 774 | | | | | 775 | 1 Gbps | 3 days | 8.6 hours | 66 minutes | 776 | | | | | 777 | 10 Gbps | 8.6 hours | 52 minutes | 6.6 minutes | 778 | | | | | 779 | 40 Gbps | 22 minutes | 13 minutes | 1.6 minutes | 780 | | | | | 781 | 100 Gbps | 8.9 minutes | 5.2 minutes | 0.7 minutes | 782 +----------+-------------------+------------------+-----------------+ 784 Table 2: Key Lifetimes with a four-byte Counter field 786 7.3. Security 788 As long as each deterministic IV is distinct, for each key, then 789 security is assured. However, when deterministic IVs are not 790 distinct, security suffers. 792 The number of deterministic IVs is limited, regardless of how those 793 IVs are generated. What does an encrypter do when no more IVs are 794 available? It should retire the key that it is currently using, and 795 establish another one. This is the reason that the IETF Guidelines 796 for Cryptographic Key Management [RFC4107] require that automated key 797 management be used for algorithms with deterministic IVs. For 798 network security protocols, this has proven to be an effective 799 strategy. 801 Particular care must be taken in Virtual Machine (VM) environments, 802 because the VM cloning and rollback processes can cause inadvertent 803 re-use of deterministic IVs. This is just one of many security 804 problems that can result from uncritical application of VM mechanisms 805 when cryptography is in use [GR05]. 807 7.4. Bandwidth Use 809 An implicit or partially implicit IV uses less bandwidth than a full- 810 sized IV. But as noted above, the (partially) implicit IV format 811 reduces the number of IVs that can be generated and adds complexity 812 to the system. 814 An alternative approach to bandwidth savings in a protocol design is 815 to use a predictable IV format, such as that of Section 4.1, and then 816 apply header compression to the IV. Header compression is often used 817 on bandwidth-constrained links, and it can be applied to encrypted 818 packets [RFC3095]. The format of Section 4.1 can easily be handled 819 by header compression. This approach has several benefits: it makes 820 IV generation simpler, it allows bandwidth savings for environments 821 in which it matters while putting the complexity burden onto the 822 systems that opt to realize those savings, and it increases the 823 number of IVs that can be used. Specifications that use this design 824 alternative SHOULD require the use of the IV format in Section 4.1. 826 8. Security Considerations 828 Cryptographic algorithms that rely on deterministic IVs or nonces 829 must ensure the uniqueness of those values. The recommendations in 830 this note aim to help implementers achieve that goal. 832 Implementations should use the nonce formats described in Section 3. 833 The way in which these formats are used in standards is summarized in 834 Table 1. 836 Implementations should use the internal IV generator described in 837 Section 5. 839 Almost all cryptographic systems can implement counter-based 840 deterministic IVs. In many cases, it is straightforward to generate 841 deterministic IVs associated with a short-term key in use by a single 842 encrypter, as in a typical point-to-point protocol. Complications 843 can arise, however, when there are multiple encrypters, or when a key 844 is used for an extended period of time. Cryptographic systems that 845 cannot ensure IV distinctness should not use deterministic IVs, and 846 should instead use a misuse-resistant mode of operation such as the 847 Synthetic Initialization Vector (SIV) Authenticated Encryption mode 848 of operation [RFC5295], or a randomized algorithm such as the CBC 849 mode of operation (though an additional authentication mechanism must 850 be used with that option). If authentication but not encryption is 851 required, then it is possible to use an algorithm that does not 852 require an IV, such as HMAC [RFC2104]. 854 9. Acknowledgments 856 Thanks to Greg Zaverucha and Peter Gutmann for comments. 858 10. References 860 10.1. Normative References 862 [CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM 863 Mode for Authentication and Confidentiality", U.S. 864 National Institute of Standards and Technology http:// 865 csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf. 867 [GCM] Dworkin, M., "NIST Special Publication 800-38D: 868 Recommendation for Block Cipher Modes of Operation: 869 Galois/Counter Mode (GCM) and GMAC.", U.S. National 870 Institute of Standards and Technology http:// 871 csrc.nist.gov/publications/nistpubs/800-38D/SP800-38D.pdf. 873 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 874 Requirement Levels", BCP 14, RFC 2119, March 1997. 876 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 877 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 878 RFC 3711, March 2004. 880 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 881 (GCM) in IPsec Encapsulating Security Payload (ESP)", 882 RFC 4106, June 2005. 884 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 885 Encryption", RFC 5116, January 2008. 887 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 888 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 889 August 2008. 891 [RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the 892 Secure Shell Transport Layer Protocol", RFC 5647, 893 August 2009. 895 10.2. Informative References 897 [BN00] Bellare, M. and C. Namprempre, "Authenticated encryption: 898 Relations among notions and analysis of the generic 899 composition paradigm", Proceedings of ASIACRYPT 2000, 900 Springer-Verlag, LNCS 1976, pp. 531-545 http:// 901 www-cse.ucsd.edu/users/mihir/papers/oem.html. 903 [CTR] Dworkin, M., "NIST Special Publication 800-38: 904 Recommendation for Block Cipher Modes of Operation", U.S. 905 National Institute of Standards and Technology http:// 906 csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. 908 [GR05] Garfinkel, T. and M. Rosenblum, "When Virtual is Harder 909 than Real: Security Challenges in Virtual Machine Based 910 Computing Environments", Proceedings of the 10th Workshop 911 on Hot Topics in Operating Systems http:// 912 www.stanford.edu/~talg/papers/HOTOS05/ 913 virtual-harder-hotos05.pdf. 915 [KW02] Knudsen, L. and D. Wagner, "Integral Cryptanalysis", 9th 916 International Workshop on Fast Software Encryption (FSE 917 '02) http://eprint.iacr.org/2004/193, December 2001. 919 [MF00] McGrew, D. and S. Fluhrer, "Attacks on Additive Encryption 920 of Redundant Plaintext and Implications on Internet 921 Security", Proceedings of the Seventh Annual Workshop on 922 Selected Areas in Cryptography (SAC 2000) Spinger-Verlag. 924 [R02] Rogaway, P., "Authenticated encryption with Associated- 925 Data", ACM Conference on Computer and Communication 926 Security (CCS'02), pp. 98-107, ACM Press, 927 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.html. 929 [RFC1361] Mills, D., "Simple Network Time Protocol (SNTP)", 930 RFC 1361, August 1992. 932 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 933 E. Lear, "Address Allocation for Private Internets", 934 BCP 5, RFC 1918, February 1996. 936 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 937 Hashing for Message Authentication", RFC 2104, 938 February 1997. 940 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 941 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 942 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 943 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 944 Compression (ROHC): Framework and four profiles: RTP, UDP, 945 ESP, and uncompressed", RFC 3095, July 2001. 947 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 948 Counter Mode With IPsec Encapsulating Security Payload 949 (ESP)", RFC 3686, January 2004. 951 [RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", 952 RFC 3768, April 2004. 954 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 955 Requirements for Security", BCP 106, RFC 4086, June 2005. 957 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 958 Key Management", BCP 107, RFC 4107, June 2005. 960 [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy 961 for Control and Provisioning of Wireless Access Points 962 (CAPWAP)", RFC 4118, June 2005. 964 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 965 Mode with IPsec Encapsulating Security Payload (ESP)", 966 RFC 4309, December 2005. 968 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 969 Algorithms with the Encrypted Payload of the Internet Key 970 Exchange version 2 (IKEv2) Protocol", RFC 5282, 971 August 2008. 973 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 974 "Specification for the Derivation of Root Keys from an 975 Extended Master Session Key (EMSK)", RFC 5295, 976 August 2008. 978 [RFC6054] McGrew, D. and B. Weis, "Using Counter Modes with 979 Encapsulating Security Payload (ESP) and Authentication 980 Header (AH) to Protect Group Traffic", RFC 6054, 981 November 2010. 983 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 984 NAT64: Network Address and Protocol Translation from IPv6 985 Clients to IPv4 Servers", RFC 6146, April 2011. 987 Author's Address 989 David A. McGrew 990 Cisco Systems, Inc. 991 13600 Dulles Technology Drive 992 Herndon, VA 20171 993 US 995 Phone: (408) 525 8651 996 Email: mcgrew@cisco.com 997 URI: http://www.mindspring.com/~dmcgrew/dam.htm