idnits 2.17.1 draft-mcgrew-auth-enc-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 895. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 906. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 913. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 919. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: AEAD algorithms that rely on distinct nonces MAY NOT be appropriate for some applications or for some scenarios. Application designers should understand the requirements outlined in Section 3.1. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2007) is 6138 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' -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 11 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 July 6, 2007 5 Expires: January 7, 2008 7 An Interface and Algorithms for Authenticated Encryption 8 draft-mcgrew-auth-enc-03.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 7, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document defines algorithms for authenticated encryption with 42 additional authenticated data (AEAD), and defines a uniform interface 43 and a registry for such algorithms. The interface and registry can 44 be used as an application independent set of cryptoalgorithm suites. 45 This approach provides advantages in efficiency and security, and 46 promotes the reuse of crypto implementations. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.4. Conventions Used In This Document . . . . . . . . . . . . 4 55 2. AEAD Interface . . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.1. Authenticated Encryption . . . . . . . . . . . . . . . . . 5 57 2.2. Authenticated Decryption . . . . . . . . . . . . . . . . . 7 58 2.3. Data Formatting . . . . . . . . . . . . . . . . . . . . . 7 59 3. Guidance on the use of AEAD algorithms . . . . . . . . . . . . 8 60 3.1. Requirements on Nonce Generation . . . . . . . . . . . . . 8 61 3.2. Recommended Nonce Formation . . . . . . . . . . . . . . . 9 62 3.2.1. Partially Implicit Nonces . . . . . . . . . . . . . . 9 63 3.3. Construction of AEAD Inputs . . . . . . . . . . . . . . . 10 64 3.4. Example Usage . . . . . . . . . . . . . . . . . . . . . . 11 65 4. Requirements on AEAD algorithms . . . . . . . . . . . . . . . 12 66 5. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . . 14 67 5.1. AEAD_AES_128_GCM . . . . . . . . . . . . . . . . . . . . . 14 68 5.1.1. Nonce Reuse . . . . . . . . . . . . . . . . . . . . . 14 69 5.2. AEAD_AES_256_GCM . . . . . . . . . . . . . . . . . . . . . 15 70 5.3. AEAD_AES_128_CCM . . . . . . . . . . . . . . . . . . . . . 15 71 5.3.1. Nonce Reuse . . . . . . . . . . . . . . . . . . . . . 16 72 5.4. AEAD_AES_256_CCM . . . . . . . . . . . . . . . . . . . . . 16 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 7. Other Considerations . . . . . . . . . . . . . . . . . . . . . 19 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 81 Intellectual Property and Copyright Statements . . . . . . . . . . 25 83 1. Introduction 85 Authenticated encryption [BN00] is a form of encryption that, in 86 addition to providing confidentiality for the plaintext that is 87 encrypted, provides a way to check its integrity and authenticity. 88 Authenticated encryption with Associated Data, or AEAD, adds the 89 ability to check the integrity and authenticity of some additional 90 authenticated data (also called "associated data") that is not 91 encrypted. 93 1.1. Background 95 Many cryptographic applications require both confidentiality and 96 message authentication. Confidentiality is a security service that 97 ensures that data is available only to those authorized to obtain it; 98 usually it is realized through encryption. Message authentication is 99 the service that ensures that data has not been altered or forged by 100 unauthorized entities; it can be achieved by using a Message 101 Authentication Code (MAC). This service is also called data 102 integrity. Many applications use an encryption method and a MAC 103 together to provide both of those security services, with each 104 algorithm using an independent key. More recently, the idea of 105 providing both security services using a single cryptoalgorithm has 106 become accepted. In this concept, the cipher and MAC are replaced by 107 an Authenticated Encryption with Associated Data (AEAD) algorithm. 109 Several crypto algorithms that implement AEAD algorithms have been 110 defined, including block cipher modes of operation and dedicated 111 algorithms. Some of these algorithms have been adopted and proven 112 useful in practice. Additionally, AEAD is close to an 'idealized' 113 view of encryption, such as those used in the automated analysis of 114 cryptographic protocols (see, for example, Section 2.5 of [BOYD]). 116 1.2. Scope 118 In this document we define an AEAD algorithm as an abstraction, by 119 specifying an interface to an AEAD and defining an IANA registry for 120 AEAD algorithms. We populate this registry with four AEAD algorithms 121 based on AES in Galois/Counter Mode [GCM] with 128 and 256 bit keys, 122 and AES in Counter and CBC MAC mode [CCM] with 128 and 256 bit keys. 124 In the following, we define the AEAD interface (Section 2), and then 125 provide guidance on the use of AEAD algorithms (Section 3), and 126 outline the requirements that each AEAD algorithm must meet 127 (Section 4). Then we define several AEAD algorithms (Section 5), and 128 establish an IANA registry for AEAD algorithms (Section 6). Lastly, 129 we discuss some other considerations (Section 7). 131 The AEAD interface specification does not address security protocol 132 issues such as anti-replay services or access control decisions that 133 are made on authenticated data. Instead, the specification aims to 134 abstract the cryptography away from those issues. The interface, and 135 the guidance about how to use it, are consistent with the 136 recommendations from [EEM04]. 138 1.3. Benefits 140 The AEAD approach enables applications that need cryptographic 141 security services to more easily adopt those services. It benefits 142 the application designer by allowing them to focus on the important 143 issues such as security services, canonicalization, and data 144 marshaling, and relieving them of the need to design crypto 145 mechanisms that meet their security goals. Importantly, the security 146 of an AEAD algorithm can be analyzed independent from its use in a 147 particular application. This property frees the user of the AEAD of 148 the need to consider security aspects such as the relative order of 149 authentication and encryption and the security of the particular 150 combination of cipher and MAC, such as the potential loss of 151 confidentiality through the MAC. The application designer that uses 152 the AEAD interface need not select a particular AEAD algorithm during 153 the design stage. Additionally, the interface to the AEAD is 154 relatively simple, since it requires only a single key as input and 155 it requires only a single identifier to indicate the algorithm in use 156 in a particular case. 158 The AEAD approach benefits the implementer of the crypto algorithms 159 by making available optimizations that are otherwise not possible to 160 reduce the amount of computation, the implementation cost, and/or the 161 storage requirements. The simpler interface makes testing easier; 162 this is a considerable benefit for a crypto algorithm implementation. 163 By providing a uniform interface to access cryptographic services, 164 the AEAD approach allows a single crypto implementation to more 165 easily support multiple applications. For example, a hardware module 166 that supports the AEAD interface can easily provide crypto 167 acceleration to any application using that interface, even to 168 applications that had not been designed when the module was built. 170 1.4. Conventions Used In This Document 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [RFC2119]. 176 2. AEAD Interface 178 An AEAD algorithm has two operations, authenticated encryption and 179 authenticated decryption. The inputs and outputs of these algorithms 180 are defined in terms of octet strings. 182 An implementation MAY accept additional inputs. For example, an 183 input could be provided to allow the user to select between different 184 implementation strategies. However, such extensions MUST NOT affect 185 interoperability with other implementations. 187 2.1. Authenticated Encryption 189 The authenticated encryption operation has four inputs, each of which 190 is an octet string: 192 A secret key K, which MUST be generated in a way that is uniformly 193 random or pseudorandom. 195 A nonce N. Each nonce provided to distinct invocations of the 196 Authenticated Encryption operation MUST be distinct, for any 197 particular value of the key; applications SHOULD use the nonce 198 formation method defined in Section 3.2, and MAY use any other 199 method that meets this requirement. 201 A plaintext P, which contains the data to be encrypted and 202 authenticated, 204 The additional authenticated data A, which contains the data to be 205 authenticated, but not encrypted. 207 There is a single output: 209 A ciphertext C, which is as least as long as the plaintext, or 211 an indication that the requested encryption operation could not be 212 performed. 214 All of the inputs and outputs are variable-length octet strings, 215 whose lengths obey the following restrictions: 217 The number of octets in the key K is between one and 255. For 218 each AEAD algorithm, the length of K MUST be fixed. 220 The number of octets in the nonce MAY be zero, but SHOULD be 221 twelve (12) octets. Randomized AEAD algorithms, which are defined 222 in Section 4, are suitable for use with zero-length nonces. In 223 this case the earlier nonce uniqueness requirement is relaxed. 225 The number of octets in the plaintext P MAY be zero. 227 The number of octets in the additional authenticated data A MAY be 228 zero. 230 The number of octets in the ciphertext C MAY be zero. 232 This specification does not put a maximum length on the nonce, the 233 plaintext, the ciphertext, nor the additional authenticated data. 234 However, a particular AEAD algorithm MAY further restrict the lengths 235 of those inputs and outputs. A particular AEAD implementation MAY 236 further restrict the lengths of its inputs and outputs. If a 237 particular implementation of an AEAD algorithm is requested to 238 process an input that is outside the range of admissible lengths, or 239 an input that is outside the range of lengths supported by that 240 implementation, it MUST return an error code and it MUST NOT output 241 any other information. In particular, partially encrypted or 242 partially decrypted data MUST NOT be returned. 244 Both confidentiality and message authentication is provided on the 245 plaintext P. When the length of P is zero, the AEAD algorithm acts as 246 a Message Authentication Code on the input A. 248 The additional authenticated data A is used to protect information 249 that needs to be authenticated, but which does not need to be kept 250 confidential. When using an AEAD to secure a network protocol, for 251 example, this input could include addresses, ports, sequence numbers, 252 protocol version numbers, and other fields that indicate how the 253 plaintext or ciphertext should be handled, forwarded, or processed. 254 In many situations, it is desirable to authenticate these fields, 255 though they must be left in the clear to allow the network or system 256 to function properly. When this data is included in the input A, 257 authentication is provided without copying the data into the 258 ciphertext. 260 The nonce is authenticated internally to the algorithm, and it is not 261 necessary to include it in the AAD input. The nonce MAY be included 262 in P or A if it is convenient to the application. 264 The nonce MAY be stored or transported with the plaintext, or it MAY 265 be reconstructed immediately prior to the authenticated decryption 266 operation. It is sufficient to provide the decryption module with 267 enough information to allow it to construct the nonce. (For example, 268 a system could use a nonce consisting of a sequence number in a 269 particular format, in which case it could be inferred from the order 270 of the ciphertexts.) Because the authenticated decryption process 271 detects incorrect nonce values, no security failure will result if a 272 nonce is incorrectly reconstructed and fed into an authenticated 273 decryption operation. Any nonce reconstruction method will need to 274 take into account the possibility of loss or reorder of ciphertexts 275 between the encryption and decryption processes. 277 Applications MUST NOT assume any particular structure or formatting 278 of the ciphertext. 280 2.2. Authenticated Decryption 282 The authenticated decryption operation has four inputs: K, N , A and 283 C, as defined above. It has only a single output, either a plaintext 284 value P or a special symbol FAIL that indicates that the inputs are 285 not authentic. A ciphertext C, a nonce N, and additional 286 authenticated data A are authentic for key K when C is generated by 287 the encrypt operation with inputs K, N, P and A, for some values of 288 N, P, and A. The authenticated decrypt operation will, with high 289 probability, return FAIL whenever its inputs were not created by the 290 encrypt operation with the identical key (assuming that the AEAD 291 algorithm is secure). 293 2.3. Data Formatting 295 This document does not specify any particular encoding for the AEAD 296 inputs and outputs, since the encoding does not affect the security 297 services provided by an AEAD algorithm. 299 When choosing the format of application data, an application SHOULD 300 position the ciphertext C so that it appears after any other data 301 that is needed to construct the other inputs to the authenticated 302 decryption operation. For instance, if the nonce and ciphertext both 303 appear in a packet, the former value should precede the latter. This 304 rule facilitates efficient and simple hardware implementations of 305 AEAD algorithms. 307 3. Guidance on the use of AEAD algorithms 309 This section provides advice that must be followed in order to use an 310 AEAD algorithm securely. 312 If an application is unable to meet the requirements on nonce 313 generation, then it MUST use a zero-length nonce. Randomized AEAD 314 algorithms, which are defined below, are suitable for use with such 315 applications. Otherwise, an application SHOULD use nonces with a 316 length of twelve octets. Since algorithms are encouraged to support 317 that length, applications should use that length to aid 318 interoperability. 320 3.1. Requirements on Nonce Generation 322 It is essential for security that the nonces be constructed in a 323 manner that respects the requirement that each nonce value be 324 distinct for each invocation of the authenticated encryption 325 operation, for any fixed value of the key. In this section we call 326 attention to some consequences of this requirement in different 327 scenarios. 329 When there are multiple devices performing encryption using a single 330 key, those devices must coordinate to ensure that the nonces are 331 unique. A simple way to do this is to use a nonce format that 332 contains a field that is distinct for each one of the devices, as 333 described in Section 3.2. Note that there is no need to coordinate 334 the details of the nonce format between the encrypter and the 335 decrypter, as long the entire nonce is sent or stored with the 336 ciphertext and is thus available to the decrypter. If the complete 337 nonce is not available to the decrypter, then the decrypter will need 338 to know how the nonce is structured so that it can reconstruct it. 339 Applications SHOULD provide encryption engines with some freedom in 340 choosing their nonces; for example, a nonce could contain both a 341 counter and a field that is set by the encrypter but is not processed 342 by the receiver. This freedom allows a set of encryption devices to 343 more readily coordinate to ensure the distinctness of their nonces. 345 If a secret key will be used for a long period of time, e.g. across 346 multiple reboots, then the nonce will need to be stored in non- 347 volatible memory. In such cases it is essential to use checkpointing 348 of the nonce, that is, the current nonce value should be stored to 349 provide the state information needed to resume encryption in case of 350 unexpected failure. One simple way to provide a high assurance that 351 a nonce value will not be used repeatedly is to wait until the 352 encryption process receives confirmation from the storage process 353 indicating that the succeeding nonce value has already been stored. 354 Because this method may add significant latency, it may be desirable 355 to store a nonce value that is several values ahead in the sequence. 356 As an example, the nonce 100 could be stored, after which the nonces 357 1 through 99 could be used for encryption. The nonce value 200 could 358 be stored at the same time that nonces 1 through 99 are being used, 359 and so on. 361 Many problems with nonce re-use can be avoided by changing a key in a 362 situation in which nonce coordination is difficult. 364 Each AEAD algorithm SHOULD describe what security degradation would 365 result from an inadvertent re-use of a nonce value. 367 3.2. Recommended Nonce Formation 369 The following method to construct nonces is RECOMMENDED. The nonce 370 is formatted as illustrated in Figure 1, with the initial octets 371 consisting of a Fixed field, and the final octets consisting of a 372 Counter field. 374 <----- variable ----> <----------- variable -----------> 375 +---------------------+----------------------------------+ 376 | Fixed | Counter | 377 +---------------------+----------------------------------+ 379 Figure 1: Recommended nonce format. 381 The Counter field is regarded as an unsigned integer in network byte 382 order. The length of the Counter field MUST remain constant for all 383 nonces that are generated for a given encryption device. The Counter 384 part is equal to zero for the first nonce, and it increments by one 385 for each successive nonce that is generated. The initial zero value 386 MAY be omitted if it is convenient. Thus at most 2^(8*C) nonces can 387 be generated when the Counter field is C octets in length. 389 The Fixed field MUST remain constant for all nonces that are 390 generated for a given encryption device. If different devices are 391 performing encryption with a single key, then each distinct device 392 MUST use a distinct Fixed field, to ensure the uniqueness of the 393 nonces. Thus at most 2^(8*F) distinct encrypters can share a key 394 when the Fixed field is F octets in length. 396 3.2.1. Partially Implicit Nonces 398 In some cases it is desirable to not transmit or store an entire 399 nonce, but instead to reconstruct that value from contextual 400 information immediately prior to decryption. As an example, 401 ciphertexts could be stored in sequence on a disk, and the nonce for 402 a particular ciphertext could be inferred from its location, as long 403 as the rule for generating the nonces is known by the decrypter. We 404 call the portion of the nonce that is stored or sent with the 405 ciphertext the explicit part. We call the portion of the nonce that 406 is inferred the implicit part. When part of the nonce is implicit, 407 the following specialization of the above format is RECOMMENDED. The 408 Fixed field is divided into two sub-fields: a Fixed-Common field and 409 a Fixed-Distinct field. This format is shown in Figure 2. If 410 different devices are performing encryption with a single key, then 411 each distinct device MUST use a distinct Fixed-Distinct field. The 412 Fixed-Common field is common to all nonces. The Fixed-Distinct field 413 and the Counter field MUST be in the explicit part of the nonce. The 414 Fixed-Common field MAY be in the implicit part of the nonce. These 415 conventions ensure that nonce is easy to reconstruct from the 416 explicit data. 418 +-------------------+--------------------+---------------+ 419 | Fixed-Common | Fixed-Distinct | Counter | 420 +-------------------+--------------------+---------------+ 421 <---- implicit ---> <------------ explicit ------------> 423 Figure 2: Partially implicit nonce format 425 The rationale for the partially implicit nonce format is as 426 follows. This method of nonce construction incorporates the best 427 known practice; it is used by both GCM ESP [RFC4106] and CCM ESP 428 [RFC4309], in which the Fixed field contains the Salt value and 429 the lowest eight octets of the nonce are explicitly carried in the 430 ESP packet. In GCM ESP, the Fixed field must be at least four 431 octets long, so that it can contain the Salt value. In CCM ESP, 432 the Fixed field must be at least three octets long for the same 433 reason. This nonce generation method is also used by several 434 counter mode variants including CTR ESP. 436 3.3. Construction of AEAD Inputs 438 If the AAD input is constructed out of multiple data elements, then 439 it is essential that it be unambiguously parseable into its 440 constituent elements, without the use of any unauthenticated data in 441 the parsing process. This requirement ensures that an attacker 442 cannot fool a receiver into accepting a bogus set of data elements as 443 authentic by altering a set of data elements that were used to 444 construct an AAD input in an authenticated encryption operation in 445 such a way that the data elements are different, but the AAD input is 446 unchanged. This requirement is trivially met if the AAD is composed 447 of fixed-width elements. If the AAD contains a variable-length 448 string, for example, this requirement can be met by also including 449 the length of the string in the AAD. 451 Similarly, if the plaintext is constructed out of multiple data 452 elements, then it is essential that it be unambiguously parseable 453 into its constituent elements, without using any unauthenticated data 454 in the parsing process. Note that data that included in the AAD may 455 be used when parsing the plaintext, though of course since the AAD is 456 not encrypted there is a potential loss of confidentiality when 457 information about the plaintext is included in the AAD. 459 3.4. Example Usage 461 To make use of an AEAD algorithm, an application must define how the 462 encryption algorithm's inputs are defined in terms of application 463 data, and how the ciphertext and nonce are conveyed. The clearest 464 way to do this is to express each input in terms of the data that 465 form it, then to express the application data in terms of the outputs 466 of the AEAD encryption operation. 468 For example, AES-GCM ESP [RFC4106] can be expressed as follows. The 469 AEAD inputs are 471 P = RestOfPayloadData || TFCpadding || Padding || PadLength || 472 NextHeader 474 N = Salt || IV 476 A = SPI || SequenceNumber 478 where the symbol "||" denotes the concatenation operation, and the 479 fields RestOfPayloadData, TFCpadding, Padding, PadLength, NextHeader, 480 SPI, and SequenceNumber are as defined in [RFC4303] and the fields 481 Salt and IV are as defined in [RFC4106]. The field RestOfPayloadData 482 contains the plaintext data that is described by the NextHeader 483 field, and no other data. (Recall that the PayloadData field 484 contains both the IV and the RestOfPayloadData; see Figure 2 of 485 [RFC4303] for an illustration.) 487 The format of the ESP packet can be expressed as 489 ESP = SPI || SequenceNumber || IV || C 491 where C is the AEAD ciphertext (which in this case incorporates the 492 authentication tag). Please note that here we have not described the 493 use of the ESP Extended Sequence Number. 495 4. Requirements on AEAD algorithms 497 Each AEAD algorithm MUST only accept keys with a fixed key length 498 K_LEN, and MUST NOT require any particular data format for the keys 499 provided as input. An algorithm that requires such structure (e.g. 500 one with subkeys in a particular parity-check format) will need to 501 provide it internally. 503 Each AEAD algorithm MUST accept any plaintext with a length between 504 zero and P_MAX octets, inclusive, where the value P_MAX is specific 505 to that algorithm. 507 Each AEAD algorithm MUST accept any additional authenticated data 508 with a length between zero and A_MAX octets, inclusive, where the 509 value A_MAX is specific to that algorithm. 511 Each AEAD algorithm MUST accept any nonce with a length between N_MIN 512 and N_MAX octets, inclusive, where the values of N_MIN and N_MAX are 513 specific to that algorithm. Each algorithm SHOULD accept a nonce 514 with a length of twelve (12) octets, unless it is a randomized 515 algorithm (as described below). 517 An AEAD algorithm MAY structure its ciphertext output in any way; for 518 example, the ciphertext can incorporate an authentication tag. Each 519 algorithm SHOULD choose a structure that is amenable to efficient 520 processing. 522 An Authenticated Encryption algorithm MAY incorporate or make use of 523 a random source, e.g. for the generation of an internal 524 initialization vector that is incorporated into the ciphertext 525 output. An algorithm that uses an internal random initialization 526 vector in this manner MAY have a value of N_MAX that is equal to 527 zero. An AEAD algorithm of this sort is called randomized; though 528 note that only encryption is random, and decryption is always 529 deterministic. 531 The specification of an AEAD algorithm MUST include the values of 532 K_LEN, P_MAX, A_MAX, N_MIN, and N_MAX defined above. Additionally, 533 it MUST specify the number of octets in the largest possible 534 ciphertext, which we denote C_MAX. 536 Each AEAD algorithm MUST provide a description relating the length of 537 the plaintext to that of the ciphertext. 539 EACH AEAD algorithm specification SHOULD describe what security 540 degradation would result from an inadvertent re-use of a nonce value. 542 Each AEAD algorithm specification SHOULD provide a reference to a 543 detailed security analysis. This document does not specify a 544 particular security model, because several different models have been 545 used in the literature. The security analysis SHOULD define or 546 reference a security model. 548 5. AEAD Algorithms 550 This section defines four AEAD algorithms; two are based on AES GCM, 551 two are based on AES CCM. Each pair includes an algorithm with a key 552 size of 128 bits and one with a key size of 256 bits. 554 5.1. AEAD_AES_128_GCM 556 The AEAD_AES_128_GCM authenticated encryption algorithm works as 557 specified in [GCM], by providing the key, nonce, and plaintext, and 558 additional authenticated data to that mode of operation. An 559 authentication tag with a length of 16 octets (128 bits) is used. 560 The AEAD_AES_128_GCM ciphertext is formed by appending the 561 authentication tag provided as an output to the GCM encryption 562 operation to the ciphertext that is output by that operation. Test 563 cases are provided in the appendix of [GCM]. The input and output 564 lengths are as follows: 566 K_LEN is 16 octets, 568 P_MAX is 2^36 - 31 octets, 570 A_MAX is 2^61 - 1 octets, 572 N_MIN and N_MAX are both 12 octets, and 574 C_MAX is 2^36 - 15 octets. 576 An AEAD_AES_128_GCM ciphertext is exactly 16 octets longer than its 577 corresponding plaintext. 579 A security analysis of GCM is available in [MV04]. 581 5.1.1. Nonce Reuse 583 Inadvertent reuse of the same nonce by two invocations of the GCM 584 encryption operation, with the same key, undermines the security of 585 all of the subsequent uses of that key. For this reason, GCM should 586 only be used whenever nonce uniqueness can be provided with 587 assurance. The design feature that GCM uses to achieve minimal 588 latency causes the vulnerabilities on the subsequent uses of the key. 589 Note that it is acceptable to input the same nonce value multiple 590 times to the decryption operation. 592 The security consequences are quite serious if an attacker observes 593 two ciphertexts that were created using the same nonce and key 594 values, unless the plaintext and AAD values in both invocations of 595 the encrypt operation were identical. First, a loss of 596 confidentiality ensues because he will be able to reconstruct the 597 bitwise exclusive-or of the two plaintext values. Second, a loss of 598 integrity ensues because the attacker will be able to recover the 599 internal hash key used to provide data integrity. Knowledge of this 600 key makes subsequent forgeries trivial. 602 5.2. AEAD_AES_256_GCM 604 This algorithm is identical to AEAD_AES_128_GCM, but with the 605 following differences: 607 K_LEN is 32 octets, instead of 16 octets, and 609 AES-256 GCM is used instead of AES-128 GCM. 611 5.3. AEAD_AES_128_CCM 613 The AEAD_AES_128_CCM authenticated encryption algorithm works as 614 specified in [CCM], by providing the key, nonce, additional 615 authenticated data, and plaintext to that mode of operation. The 616 formatting and counter generation function are as specified in 617 Appendix A of that reference, and the values of the parameters 618 identified in that appendix are as follows: 620 the nonce length n is 12, 622 the tag length t is 16, and 624 the value of q is 3. 626 An authentication tag with a length of 16 octets (128 bits) is used. 627 The AEAD_AES_128_CCM ciphertext is formed by appending the 628 authentication tag provided as an output to the CCM encryption 629 operation to the ciphertext that is output by that operation. Test 630 cases are provided in [CCM]. The input and output lengths are as 631 follows: 633 K_LEN is 16 octets, 635 P_MAX is 2^24 - 1 octets, 637 A_MAX is 2^64 - 1 octets, 639 N_MIN and N_MAX are both 12 octets, and 641 C_MAX is 2^24 + 15 octets. 643 An AEAD_AES_128_CCM ciphertext is exactly 16 octets longer than its 644 corresponding plaintext. 646 A security analysis of AES CCM is available in [J02]. 648 5.3.1. Nonce Reuse 650 Inadvertent reuse of the same nonce by two invocations of the CCM 651 encryption operation, with the same key, undermines the security for 652 the messages processed with those invocations. A loss of 653 confidentiality ensues because he will be able to reconstruct the 654 bitwise exclusive-or of the two plaintext values. 656 5.4. AEAD_AES_256_CCM 658 This algorithm is identical to AEAD_AES_128_CCM, but with the 659 following differences: 661 K_LEN is 32 octets, instead of 16, and 663 AES-256 CCM is used instead of AES-128 CCM. 665 6. IANA Considerations 667 The Internet Assigned Numbers Authority (IANA) will define the "AEAD 668 Registry" described below. An algorithm designer MAY register an 669 algorithms in order to facilitiate its use. Additions to the AEAD 670 Registry require that a specification be documented in an Internet 671 RFC or another permanent and readily available reference, in 672 sufficient detail that interoperability between independent 673 implementations is possible. Each entry in the registry contains the 674 following elements: 676 a short name, such as "AEAD_AES_128_GCM", that starts with the 677 string "AEAD", 679 a positive number, and 681 a reference to a specification that completely defines an AEAD 682 algorithm and provides test cases that can be used to verify the 683 correctness of an implementation. 685 Requests to add an entry to the registry MUST include the name and 686 the reference. The number is assigned by IANA. These number 687 assignments SHOULD use the smallest available positive number. 688 Submitters SHOULD have their requests reviewed by the IRTF Crypto 689 Forum Research Group (CFRG) at cfrg@ietf.org. Interested applicants 690 that are unfamiliar with IANA processes should visit 691 http://www.iana.org. 693 The numbers between 32,768 (binary 1000000000000000) and 65,535 694 (binary 1111111111111111) inclusive, will not be assigned by IANA, 695 and are reserved for private use; no attempt will be made to prevent 696 multiple sites from using the same value in different (and 697 incompatible) ways [RFC2434]. 699 IANA will add the following entries to the AEAD Registry: 701 +------------------+-------------+--------------------+ 702 | Name | Reference | Numeric Identifier | 703 +------------------+-------------+--------------------+ 704 | AEAD_AES_128_GCM | Section 5.1 | 1 | 705 | | | | 706 | AEAD_AES_256_GCM | Section 5.2 | 2 | 707 | | | | 708 | AEAD_AES_128_CCM | Section 5.3 | 3 | 709 | | | | 710 | AEAD_AES_256_CCM | Section 5.4 | 4 | 711 +------------------+-------------+--------------------+ 713 An IANA registration of an AEAD does not constitute an endorsement of 714 that algorithm or its security. 716 7. Other Considerations 718 Directly testing a randomized AEAD encryption algorithm using test 719 cases with fixed inputs and outputs is not possible, since the 720 encryption process is non-deterministic. However, it is possible to 721 test a randomized AEAD algorithm using the following technique. The 722 authenticated decryption algorithm is deterministic, and it can be 723 directly tested. The authenticated encryption algorithm can be 724 tested by encrypting a plaintext, decrypting the resulting 725 ciphertext, and comparing the original plaintext to the post- 726 decryption plaintext. Combining both of these tests covers both the 727 encryption and decryption algorithms. 729 The AEAD algorithms selected reflect those that have been already 730 adopted by standards. It is an open question as to what other AEAD 731 algorithms should be added. Many variations on basic algorithms are 732 possible, each with its own advantages. While it is desirable to 733 admit any algorithms that are found to be useful in practice, it is 734 also desirable to limit the total number of registered algorithms. 735 The current specification requires that a registered algorithm 736 provide a complete specification and a set of validation data; it is 737 hoped that these prerequisites set the admission criteria 738 appropriately. 740 It may be desirable to define an AEAD algorithm that uses the generic 741 composition with the encrypt-then-MAC method [BN00], combining a 742 common encryption algorithm, such as CBC [MODES], with a common 743 message authentication code, such as HMAC-SHA1 [RFC2104] or AES CMAC 744 [CMAC]. An AEAD algorithm of this sort would reflect the best 745 current practice, and might be more easily supported by crypto 746 modules that lack support for other AEAD algorithms. 748 8. Security Considerations 750 This document describes authenticated encryption algorithms, and 751 provides guidance on their use. While these algorithms make it 752 easier, in some ways, to design a cryptographic application, it 753 should be borne in mind that strong cryptographic security is 754 difficult to achieve. While AEAD algorithms are quite useful, they 755 do nothing to address the issues of key generation [RFC4086] and key 756 management [RFC4107]. 758 AEAD algorithms that rely on distinct nonces MAY NOT be appropriate 759 for some applications or for some scenarios. Application designers 760 should understand the requirements outlined in Section 3.1. 762 A software implementation of the AEAD encryption operation in a 763 Virtual Machine (VM) environment could inadvertently re-use a nonce 764 due to a "rollback" of the VM to an earlier state [GR05]. 765 Applications are encouraged to document potential issues to help the 766 user of the application and the VM avoid unintentional mistakes of 767 this sort. The possibility exists that an attacker can cause a VM 768 rollback; threats and mitigations in that scenario are an area of 769 active research. For perspective, we note that an attacker who can 770 trigger such a rollback may have already succeeded in subverting the 771 security of the system, e.g. by causing an accounting error. 773 An IANA registration of an AEAD algorithm MUST NOT be regarded as an 774 endorsement of its security. Furthermore, the perceived security 775 level of an algorithm can degrade over time, due to cryptanalytic 776 advances or to "Moore's Law", that is, the diminishing cost of 777 computational resources over time. 779 9. Acknowledgments 781 Many reviewers provided valuable comments on earlier drafts of this 782 document. Some fruitful discussions took place on the email list of 783 the Crypto Forum Research Group in 2006. 785 10. References 787 10.1. Normative References 789 [CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM 790 Mode for Authentication and Confidentiality", U.S. 791 National Institute of Standards and Technology http:// 792 csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf. 794 [GCM] Dworkin, M., "NIST Special Publication 800-38D: 795 Recommendation for Block Cipher Modes of Operation: 796 Galois/Counter Mode (GCM) and GMAC.", U.S. National 797 Institute of Standards and Technology http:// 798 csrc.nist.gov/publications/nistpubs/800-38D/SP800-38D.pdf. 800 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 801 Requirement Levels", BCP 14, RFC 2119, March 1997. 803 10.2. Informative References 805 [BN00] "Authenticated encryption: Relations among notions and 806 analysis of the generic composition paradigm", Proceedings 807 of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 531- 808 545 http://www-cse.ucsd.edu/users/mihir/papers/oem.html. 810 [BOYD] Boyd, C. and A. Mathuria, "Protocols for Authentication 811 and Key Establishment", Springer, 2003 . 813 [CMAC] "NIST Special Publication 800-38B", http://csrc.nist.gov/ 814 CryptoToolkit/modes/800-38_Series_Publications/ 815 SP800-38B.pdf. 817 [EEM04] "Breaking and provably repairing the SSH authenticated 818 encryption scheme: A case study of the Encode-then- 819 Encrypt-and-MAC paradigm", ACM Transactions on Information 820 and System Security, http://www-cse.ucsd.edu/users/tkohno/ 821 papers/TISSEC04/. 823 [GR05] Garfinkel, T. and M. Rosenblum, "When Virtual is Harder 824 than Real: Security Challenges in Virtual Machine Based 825 Computing Environments", Proceedings of the 10th Workshop 826 on Hot Topics in Operating Systems http:// 827 www.stanford.edu/~talg/papers/HOTOS05/ 828 virtual-harder-hotos05.pdf. 830 [J02] Jonsson, J., "On the Security of CTR + CBC-MAC", 831 Proceedings of the 9th Annual Workshop on Selected Areas 832 on Cryptography, http://csrc.nist.gov/CryptoToolkit/modes/ 833 proposedmodes/ccm/ccm-ad1.pdf, 2002. 835 [MODES] Dworkin, M., "NIST Special Publication 800-38: 836 Recommendation for Block Cipher Modes of Operation", U.S. 837 National Institute of Standards and Technology http:// 838 csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. 840 [MV04] McGrew, D. and J. Viega, "The Security and Performance of 841 the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT 842 '04, http://eprint.iacr.org/2004/193, December 2004. 844 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 845 Hashing for Message Authentication", RFC 2104, 846 February 1997. 848 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 849 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 850 October 1998. 852 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 853 Requirements for Security", BCP 106, RFC 4086, June 2005. 855 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 856 (GCM) in IPsec Encapsulating Security Payload (ESP)", 857 RFC 4106, June 2005. 859 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 860 Key Management", BCP 107, RFC 4107, June 2005. 862 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 863 RFC 4303, December 2005. 865 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 866 Mode with IPsec Encapsulating Security Payload (ESP)", 867 RFC 4309, December 2005. 869 Author's Address 871 David A. McGrew 872 Cisco Systems, Inc. 873 510 McCarthy Blvd. 874 Milpitas, CA 95035 875 US 877 Phone: (408) 525 8651 878 Email: mcgrew@cisco.com 879 URI: http://www.mindspring.com/~dmcgrew/dam.htm 881 Full Copyright Statement 883 Copyright (C) The IETF Trust (2007). 885 This document is subject to the rights, licenses and restrictions 886 contained in BCP 78, and except as set forth therein, the authors 887 retain all their rights. 889 This document and the information contained herein are provided on an 890 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 891 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 892 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 893 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 894 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 895 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 897 Intellectual Property 899 The IETF takes no position regarding the validity or scope of any 900 Intellectual Property Rights or other rights that might be claimed to 901 pertain to the implementation or use of the technology described in 902 this document or the extent to which any license under such rights 903 might or might not be available; nor does it represent that it has 904 made any independent effort to identify any such rights. Information 905 on the procedures with respect to rights in RFC documents can be 906 found in BCP 78 and BCP 79. 908 Copies of IPR disclosures made to the IETF Secretariat and any 909 assurances of licenses to be made available, or the result of an 910 attempt made to obtain a general license or permission for the use of 911 such proprietary rights by implementers or users of this 912 specification can be obtained from the IETF on-line IPR repository at 913 http://www.ietf.org/ipr. 915 The IETF invites any interested party to bring to its attention any 916 copyrights, patents or patent applications, or other proprietary 917 rights that may cover technology that may be required to implement 918 this standard. Please address the information to the IETF at 919 ietf-ipr@ietf.org. 921 Acknowledgment 923 Funding for the RFC Editor function is provided by the IETF 924 Administrative Support Activity (IASA).