idnits 2.17.1 draft-mcgrew-auth-enc-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 812. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 796. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 802. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 23, 2006) is 6394 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'MODES' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 2202 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' Summary: 5 errors (**), 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 Expires: April 26, 2007 October 23, 2006 6 An Interface and Algorithms for Authenticated Encryption 7 draft-mcgrew-auth-enc-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 26, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This draft defines algorithms for authenticated encryption with 41 additional authenticated data (AEAD), and defines a uniform interface 42 and a registry for such algorithms. The interface and registry can 43 be used as an application independent set of cryptoalgorithm suites. 44 This approach provides advantages in efficiency and security, and 45 promotes the reuse of crypto implementations. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.4 Conventions Used In This Document . . . . . . . . . . . . 4 54 2. AEAD Interface . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.1 Authenticated Encryption . . . . . . . . . . . . . . . . . 5 56 2.2 Authenticated Decryption . . . . . . . . . . . . . . . . . 7 57 2.3 Data Formatting . . . . . . . . . . . . . . . . . . . . . 7 58 3. Recommended Nonce Formation . . . . . . . . . . . . . . . . . 8 59 4. Requirements on the use of AEAD algorithms . . . . . . . . . . 10 60 5. Requirements on AEAD algorithms . . . . . . . . . . . . . . . 11 61 6. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . . 12 62 6.1 AEAD_AES_128_GCM . . . . . . . . . . . . . . . . . . . . . 12 63 6.1.1 AEAD_AES_256_GCM . . . . . . . . . . . . . . . . . . . 12 64 6.2 AEAD_AES_128_CCM . . . . . . . . . . . . . . . . . . . . . 12 65 6.2.1 AEAD_AES_256_CCM . . . . . . . . . . . . . . . . . . . 13 66 6.3 AEAD_AES_128_HMAC_SHA1 . . . . . . . . . . . . . . . . . . 13 67 6.3.1 Test Cases . . . . . . . . . . . . . . . . . . . . . . 15 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 69 8. Open Questions . . . . . . . . . . . . . . . . . . . . . . . . 17 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 71 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 73 11.1 Normative References . . . . . . . . . . . . . . . . . . . 21 74 11.2 Informative References . . . . . . . . . . . . . . . . . . 21 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22 76 Intellectual Property and Copyright Statements . . . . . . . . 23 78 1. Introduction 80 Authenticated encryption is a form of encryption that, in addition to 81 providing confidentiality for the plaintext that is encrypted, 82 provides a way to check its integrity and authenticity. 83 Authenticated encryption with Associated Data, or AEAD, adds the 84 ability to check the integrity and authenticity of some additional 85 "associated data" that is not encrypted. 87 1.1 Background 89 Many cryptographic applications require both confidentiality and 90 message authentication. Often an encryption method and a message 91 authentication code (MAC) are used to provide those security 92 services, with each algorithm using an independent key. More 93 recently, the idea of providing both security services using a single 94 cryptoalgorithm has become accepted. In this concept, the cipher and 95 MAC are replaced by an Authenticated Encryption with Associated Data 96 (AEAD) algorithm. Several crypto algorithms that implement AEAD 97 algorithms have been defined, including block cipher modes of 98 operation and dedicated algorithms. Some of these algorithms have 99 been adopted and proven useful in practice. Additionally, AEAD is 100 close to an 'idealized' view of encryption, such as those used in the 101 automated analysis of cryptographic protocols. 103 1.2 Scope 105 In this document we define an AEAD algorithm as an abstraction, by 106 specifying an interface to an AEAD and defining an IANA registry for 107 AEAD algorithms. We populate this registry with five AEAD 108 algorithms: AES in Galois/Counter Mode [GCM] with 128 and 256 bit 109 keys, AES in Counter and CBC MAC mode [CCM] with 128 and 256 bit 110 keys, and an algorithm that composes AES-128 CBC and HMAC-SHA1. This 111 approach enables applications that need cryptographic security 112 services to more easily adopt those services. 114 In the following, we define the AEAD interface (Section 2), and then 115 outline the requirements that each AEAD algorithm must meet 116 (Section 5) and provide guidance on the use of AEAD algorithms 117 (Section 4). Then we define five AEAD algorithms (Section 6), and 118 establish an IANA registry for AEAD algorithms (Section 7). Lastly, 119 we discuss some open questions (Section 8). 121 The AEAD interface specification does not address security protocol 122 issues such as anti-replay services or access control decisions that 123 are made on authenticated data. Instead, the specification aims to 124 abstract the cryptography away from those issues. The interface, and 125 the guidance about how to use it, are consistent with the 126 recommendations from [EEM04]. 128 1.3 Benefits 130 The approach benefits the application designer by allowing them to 131 focus on the important issues of security services, canonicalization, 132 and data marshaling, and relieving them of the need to design crypto 133 mechanisms that meet their security goals. Importantly, the security 134 of an AEAD algorithm can be analyzed independent from its use in a 135 particular application. This property frees the user of the AEAD of 136 the need to consider security aspects such as the relative order of 137 authentication and encryption and the security of the particular 138 combination of cipher and MAC, such as the potential loss of 139 confidentiality through the MAC. The application designer that uses 140 the AEAD interface need not select a particular AEAD algorithm during 141 the design stage. Additionally, the interface to the AEAD is 142 relatively simple, since it requires only a single key as input and 143 it requires only a single identifier to indicate the algorithm in use 144 in a particular case. 146 The AEAD approach benefits the implementer of the crypto algorithms 147 by making available optimizations that are otherwise not possible to 148 reduce the amount of computation, the implementation cost, and/or the 149 storage requirements. The simpler interface makes testing easier; 150 this is a considerable benefit for a crypto algorithm implementation. 151 By providing a uniform interface to access cryptographic services, 152 the AEAD approach allows a single crypto implementation to easily 153 support multiple applications. For example, a hardware module that 154 supports the AEAD interface can easily provide crypto acceleration to 155 any application using that interface, even to applications that had 156 not been designed when the module was built. 158 1.4 Conventions Used In This Document 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 2. AEAD Interface 166 An AEAD algorithm has two operations, authenticated encryption and 167 authenticated decryption. The inputs and outputs of these algorithms 168 are defined in terms of octet strings. 170 An implementation MAY accept additional inputs. For example, an 171 input could be provided to allow the user to select between different 172 implementation strategies. However, such extensions MUST NOT affect 173 interoperability. 175 2.1 Authenticated Encryption 177 The authenticated encryption operation has four inputs, each of which 178 is an octet string: 180 A secret key K, which MUST be generated in a way that is uniformly 181 random or pseudorandom. 183 An nonce N. Each nonce provided to distinct invocations of the 184 Authenticated Encryption operation MUST be distinct, for any 185 particular value of the key; applications SHOULD use the nonce 186 formation method defined in Section 3, and MAY use any other 187 method that meets this requirement. 189 A plaintext P, which contains the data to be encrypted and 190 authenticated, 192 The additional authenticated data A, which contains the data to be 193 authenticated, but not encrypted. 195 There is a single output: 197 A ciphertext C, which is as least as long as the plaintext, or 199 an indication that the requested encryption operation could not be 200 performed. 202 All of the inputs and outputs are variable-length octet strings, 203 whose lengths obey the following restrictions: 205 The number of octets in the key K is between one and 256. For 206 each AEAD algorithm, the length of K MUST be fixed. 208 The number of octets in the nonce is between one and 2^64 - 1, 209 inclusive. However, the length SHOULD be twelve (12) octets. 211 The number of octets in the plaintext P is between zero and 2^64 - 212 1, inclusive. 214 The number of octets in the additional authenticated data AAD is 215 between zero and 2^64 - 1, inclusive. 217 The number of octets in the ciphertext C is between zero and 2^64 218 + 255. 220 An AEAD algorithm MAY further restrict the lengths of its inputs and 221 outputs. A particular AEAD implementation MAY further restrict the 222 lengths of its inputs and outputs. If a particular implementation of 223 an AEAD algorithm is requested to process an input that is outside 224 the range of admissible lengths, or an input that is outside the 225 range of lengths supported by that implementation, it MUST return an 226 error code and it MUST NOT output any other information. In 227 particular, partially encrypted or partially decrypted data MUST NOT 228 be returned. 230 Both confidentiality and message authentication is provided on the 231 plaintext P. When the length of P is zero, the AEAD algorithm acts as 232 a Message Authentication Code on the input A. 234 The additional authenticated data A is used to protect information 235 that needs to be authenticated, but which does not need to be kept 236 confidential. When using an AEAD to secure a network protocol, for 237 example, this input could include addresses, ports, sequence numbers, 238 protocol version numbers, and other fields that indicate how the 239 plaintext or ciphertext should be handled, forwarded, or processed. 240 In many situations, it is desirable to authenticate these fields, 241 though they must be left in the clear to allow the network or system 242 to function properly. When this data is included in the input A, 243 authentication is provided without copying the data into the 244 ciphertext. 246 The nonce is authenticated internally to the algorithm, and it is not 247 necessary to include it in the AAD input. The nonce MAY be included 248 in P or A if it convenient to the application. 250 The nonce MAY be transported along with the plaintext. The entire IV 251 need not be transmitted; it is sufficient to provide the receiver 252 with enough information to allow the nonce to be reconstructed. 253 Because the authenticated decryption process detects incorrect nonce 254 values, no security failure results when a receiver incorrectly 255 reconstructs an IV. Any such reconstruction method will need to take 256 into account the possible loss or reorder of ciphertexts between the 257 encryption and decryption processes. 259 Applications MUST NOT assume any particular structure or formatting 260 of the ciphertext. 262 2.2 Authenticated Decryption 264 The authenticated decryption operation has four inputs: K, IV , A and 265 C, as defined above. It has only a single output, either a plaintext 266 value P or a special symbol FAIL that indicates that the inputs are 267 not authentic. A ciphertext C , nonce N , and additional 268 authenticated data A are authentic for key K when IV, and C is 269 generated by the encrypt operation with inputs K, IV, P and A, for 270 some values of IV, P, and A. The authenticated decrypt operation 271 will, with high probability, return FAIL whenever its inputs were not 272 created by the encrypt operation with the identical key (assuming 273 that the AEAD algorithm is secure). 275 2.3 Data Formatting 277 This document does not specify any particular encoding for the AEAD 278 inputs and outputs, since the encoding does not affect the security 279 services provided by an AEAD algorithm. 281 When formatting a ciphertext, an application SHOULD position the 282 ciphertext C so that it appears after any other data that is needed 283 to construct the other inputs to the Authenticated Decryption 284 operation. For example, if the nonce and ciphertext both appear in a 285 packet, the former value should precede the latter. This rule 286 facilitates efficient and simple implementations of AEAD algorithms. 288 3. Recommended Nonce Formation 290 It is essential for security that the nonces be constructed in a 291 manner that respects the requirements that each nonce value be 292 distinct for each invocation of the Authenticated Encryption 293 operation, for any fixed value of the key. Special attention must be 294 paid to the case in which there are multiple encryption devices using 295 a single key. 297 The following method to construct nonces is RECOMMENDED. The nonce 298 is formatted as illustrated in Figure 1, with the initial octets 299 consisting of a Fixed field, and the final octets consisting of a 300 Counter field. Both fields have variable lengths. 301 <----- variable ----> <----------- variable -----------> 302 +---------------------+----------------------------------+ 303 | Fixed | Counter | 304 +---------------------+----------------------------------+ 306 Figure 1: Recommended nonce format. 308 The Counter field is regarded as an unsigned integer in network byte 309 order. The Counter part is equal to one for the first nonce, and it 310 increments by one for each successive nonce that is generated. The 311 integer part is never equal to the all-zero value. Thus at most 312 2^(8*C) - 1 nonces can be generated when the Counter field is C 313 octets in length. 315 The Fixed field MUST remain constant for all nonces that are 316 generated for a given encryption device. However, if different 317 devices are performing encryption with a single key, then each 318 distinct device MUST use a distinct Fixed field, to ensure the 319 uniqueness of the nonces. Thus at most 2^(8*F) distinct senders can 320 share a key when the Fixed field is F octets in length. When the 321 number of encrypters is less than this value, the initial octets of 322 the Fixed fields MUST be chosen so that they are common across all 323 encrypters. The final octets of the Fixed field will need to be 324 distinct across all encrypters. This substructure is shown in 325 Figure 2. 327 In some cases it is desirable to not transmit or store an entire 328 nonce, but instead to reconstruct that value immediately prior to 329 decryption. In these cases, it is RECOMMENDED that the distinct 330 final octets of the Fixed field, and the Counter field, be explicitly 331 transmitted or stored, while the common initial octets of the Fixed 332 field be stored with the key. The explicit information is shown in 333 Figure 2. However, applications MAY use any method of reconstructing 334 nonces that is convenient. 336 <------------- Fixed field ------------> 337 +-------------------+--------------------+---------------+ 338 | Fixed (common) : Fixed (distinct) | Counter | 339 +-------------------+--------------------+---------------+ 340 <------------ explicit -------------> 342 Figure 2: Nonce structure and reconstruction 344 Rationale. This method of nonce construction incorporates the 345 best known practice, and facilitates the reconstruction of nonces 346 from partial explicit information. It is used by both GCM ESP 347 [RFC4106] and CCM ESP [RFC4309], in which the Fixed field contains 348 the Salt value and the lowest eight octets of the nonce are 349 explicitly carried in the ESP packet. In GCM ESP, the Fixed field 350 must be at least four octets long, so that it can contain the Salt 351 value. In CCM ESP, the Fixed field must be at least three octets 352 long for the same reason. This nonce generation method is also 353 used by several counter mode variants including CTR ESP. 355 4. Requirements on the use of AEAD algorithms 357 This section provides advice that must be followed in order to use an 358 AEAD algorithm securely. 360 If the AAD input is constructed out of multiple data elements, then 361 it is essential that it be unambiguously parseable into its 362 constituent elements, without the use of any unauthenticated data in 363 the parsing process. This requirement ensures that an attacker 364 cannot fool a receiver into accepting a bogus set of data elements as 365 authentic by altering a set of data elements that were used to 366 construct an AAD input in an authenticated encryption operation in 367 such a way that the data elements are different, but the AAD input is 368 unchanged. This requirement is trivially met if the AAD is composed 369 of fixed-width elements. If the AAD contains a variable-length 370 string, for example, this requirement can be met by also including 371 the length of the string in the AAD. 373 Similarly, if the plaintext is constructed out of multiple data 374 elements, then it is essential that it be unambiguously parseable 375 into its constituent elements, without using any unauthenticated data 376 in the parsing process. Note that data that included in the AAD may 377 be used when parsing the plaintext, though of course since the AAD is 378 not encrypted there is a potential loss of confidentiality when 379 information about the plaintext is included in the AAD. 381 5. Requirements on AEAD algorithms 383 Each AEAD algorithm MUST only accept keys with a fixed key length 384 K_LEN, and MUST NOT require any particular data format for the keys 385 provided as input. An algorithm that requires such structure 386 internally (e.g. one with subkeys in a particular parity-check 387 format) will need to provide it internally. 389 Each AEAD algorithm MUST accept any plaintext with a length between 390 zero and P_MAX octets, where the value P_MAX is specific to that 391 algorithm. 393 Each AEAD algorithm MUST accept any additional authenticated data 394 with a length between zero and A_MAX octets, where the value A_MAX is 395 specific to that algorithm. 397 Each AEAD algorithm MUST accept any IV with a length between N_MIN 398 and N_MAX octets, where the values of N_MIN and N_MAX are specific to 399 that algorithm. Each algorithm SHOULD accept an IV with a length of 400 twelve (12) octets. 402 An AEAD algorithm MAY structure its ciphertext output in any way; for 403 example, the ciphertext can incorporate an authentication tag. Each 404 algorithm SHOULD choose a structure that is amenable to efficient 405 processing. 407 An Authenticated Encryption algorithm MAY incorporate a random 408 source, e.g. for the generation of an internal initialization vector 409 that is incorporated into the ciphertext output. An algorithm that 410 uses an internal random initialization vector in this manner MAY have 411 a value of N_MAX that is equal to zero. 413 The specification of an AEAD algorithm MUST include the values of 414 K_LEN, P_MAX, A_MAX, N_MIN, and N_MAX defined above. Additionally, 415 it MUST specify the number of octets in the largeset possible 416 ciphertext, which we denote C_MAX. 418 Each AEAD algorithm MUST provide a description relating the length of 419 the plaintext to that of the ciphertext. 421 6. AEAD Algorithms 423 This section defines five AEAD algorithms; two are based on AES GCM, 424 two are based on AES CCM, and one is based on a composition of AES 425 CBC and HMAC SHA1. Each pair includes an algorithm with a key size 426 of 128 bits and one with a key size of 256 bits. 428 6.1 AEAD_AES_128_GCM 430 The AEAD_AES_128_GCM authenticated encryption algorithm works as 431 specified in [GCM], by providing the key, nonce, and plaintext, and 432 additional authenticated data to that mode of operation. An 433 authentication tag with a length of 16 octets (128 bits) is used. 434 The AEAD_AES_128_GCM ciphertext is formed by appending the 435 authentication tag provided as an output to the GCM encryption 436 operation to the ciphertext that is output by that operation. Test 437 cases are provided in the appendix of [GCM]. The input and output 438 lengths are as follows: 440 K_LEN is 16 octets, 442 P_MAX is 2^36 - 31 octets, 444 A_MAX is 2^61 - 1 octets, 446 N_MIN is 1 (one) octet and N_MAX is 2^61 -1 octets; applications 447 SHOULD use an nonce length of 12 octets, since GCM is optimized 448 for that length, 450 C_MAX is 2^36 - 15 octets. 452 6.1.1 AEAD_AES_256_GCM 454 This algorithm is identical to AEAD_AES_128_GCM, but with the 455 following differences: 457 K_LEN is 32 octets, instead of 16 octets, and 459 AES-256 GCM is used instead of AES-128 GCM. 461 6.2 AEAD_AES_128_CCM 463 The AEAD_AES_128_CCM authenticated encryption algorithm works as 464 specified in [CCM], by providing the key, nonce, additional 465 authenticated data, and plaintext to that mode of operation. The 466 formatting and counter generation function are as specified in 467 Appendix A of that reference, and the values of the parameters 468 identified in that appendix are as follows: 470 the nonce length n is 12, 472 the tag length t is 16, and 474 the value q is 3. 476 An authentication tag with a length of 16 octets (128 bits) is used. 477 The AEAD_AES_128_CCM ciphertext is formed by appending the 478 authentication tag provided as an output to the CCM encryption 479 operation to the ciphertext that is output by that operation. Test 480 cases are provided in [CCM]. The input and output lengths are as 481 follows: 483 K_LEN is 16 octets, 485 P_MAX is 2^24 - 1 octets, 487 A_MAX is 2^64 - 1 octets, 489 N_MIN and N_MAX are both 12 octets, and 491 C_MAX is 2^24 + 15 octets. 493 6.2.1 AEAD_AES_256_CCM 495 This algorithm is identical to AEAD_AES_128_CCM, but with the 496 following differences: 498 K_LEN is 32 octets, instead of 16, and 500 AES-256 CCM is used instead of AES-128 CCM. 502 6.3 AEAD_AES_128_HMAC_SHA1 504 This algorithm random and stateless. It is based on the "generic 505 composition" of CBC encryption with HMAC authentication, with the the 506 encrypt-then-MAC method [AE]. It uses the HMAC message 507 authentication code [RFC2104] with the SHA-1 hash function [SHA1] to 508 provide message authentication. Test cases for HMAC_SHA1 are 509 provided in [RFC2202]. For encryption, it uses AES-128 in the cipher 510 block chaining (CBC) mode of operation as defined in Section 6.2 of 511 [MODES], with the padding method defined by Appendix A of the same 512 reference. The input key is 128 bits long, and the CBC IV is 513 generated uniformly at random, and is also 128 bits long. 515 The authenticated encryption algorithm is as follows, or uses an 516 equivalent set of steps: 518 1. Generate the secondary keys MAC_KEY and ENC_KEY from the input 519 key K as follows: 521 MAC_KEY = HMAC_SHA1(K, "MAC"); 523 ENC_KEY = leftmost(HMAC_SHA1(K, "ENC"), 128); 525 where the function leftmost(X, m) accepts a bitstring X and a 526 non-negative integer m and returns the bitstring containing the 527 leftmost m bits of X. MAC_KEY is 160 bits long, and ENC_KEY is 528 128 bits long. 530 2. Generate a 128-bit IV uniformly at random. (A pseudorandom 531 process MAY be used if its strength is equivalent to AES-128.) 532 Note that this IV is distinct from the nonce provided as an input 533 to the authenticated encryption operation. 535 3. Pad the plaintext by appending a single '1' bit to that data and 536 then appending to the resulting string as few '0' bits as are 537 necessary to make the number of bits in the plaintext into a 538 multiple of 128. Note that padding MUST be added to the data; if 539 the number of octets in the payload data is a multiple of 16, 540 then 16 octets of padding will be added. 542 4. Encrypt the payload using AES-128 in CBC mode, using the ENC_KEY 543 and the random IV. Form the ciphertext by prepending the IV to 544 the CBC ciphertext outputs. 546 5. Compute the authentication tag by applying HMAC_SHA1 to the AAD, 547 the length of the AAD expressed as a 64-bit unsigned integer in 548 network byte order, the IV, and the ciphertext, in that order, 549 using the MAC_KEY. 551 6. Return the ciphertext and the authentication tag. 553 The authenticated decryption algorithm is as follows, or uses an 554 equivalent set of steps: 556 1. Generate the secondary keys MAC_KEY and ENC_KEY from the input 557 key K as follows: 559 MAC_KEY = HMAC_SHA1(K, "MAC"); 560 ENC_KEY = leftmost(HMAC_SHA1(K, "ENC"), 128); 562 2. Compute the MAC value by applying HMAC_SHA1 to the AAD, he length 563 of the AAD expressed as a 64-bit unsigned integer in network byte 564 order, the IV, and the ciphertext, in that order, using the 565 MAC_KEY. Compare this value to the authentication tag. If they 566 match, then continue with the processing. Otherwise, discard the 567 data and return FAIL. 569 3. Decrypt the payload using AES-128 in CBC mode, with the ENC_KEY, 570 using the first 128 bits of the ciphertext as the random IV. 572 4. Remove padding by deleting the final '1' bit and all of the 573 following '0' bits. The remaining data forms the payload data. 575 5. Return the plaintext. 577 The length of the ciphertext can be inferred from that of the 578 plaintext. The number L of octets in the ciphertext is given by 580 L = 16 * ( floor(M / 16) + 2) 582 where M denotes the number of octets in the payload, and the function 583 floor() rounds its argument down to the nearest integer. This fact 584 is needed by the encoding function, since the length of the 585 ciphertext, rather than the length of the payload, must be 586 authenticated. 588 The lengths of the inputs are restricted as follows: 590 K_LEN is 16 octets, 592 P_MAX is 2^32 - 1 octets, 594 A_MAX is 2^64 - 1 octets, 596 N_MIN and N_MAX are both zero octets, and 598 C_MAX is 2^32 + 19 octets. 600 6.3.1 Test Cases 602 A future version of this document will include test cases for 603 AEAD_AES_128_HMAC_SHA1. 605 7. IANA Considerations 607 IANA will define the "AEAD Registry" described below. Additions and 608 changes to the AEAD Registry are by expert review. Each entry in the 609 registry contains the following elements: 611 a short name, such as "AEAD_AES_128_GCM", that starts with the 612 string "AEAD", 614 a positive number, and 616 a reference to a specification that completely defines an AEAD 617 algorithm and provides test cases that can be used to verify the 618 correctness of an implementation. 620 Requests to add an entry to the registry MUST include the name and 621 the reference. The number is assigned by IANA. These number 622 assignments SHOULD use the smallest available positive number. 624 IANA will add the following five entries to the AEAD Registry: 626 +----------------------------+---------------+--------------------+ 627 | Name | Reference | Numeric Identifier | 628 +----------------------------+---------------+--------------------+ 629 | AEAD_AES_128_GCM | Section 6.1 | 1 | 630 | | | | 631 | AEAD_AES_256_GCM | Section 6.1.1 | 2 | 632 | | | | 633 | AEAD_AES_128_CCM | Section 6.2 | 3 | 634 | | | | 635 | AEAD_AES_256_CCM | Section 6.2.1 | 4 | 636 | | | | 637 | AEAD_AES_128_CBC_HMAC_SHA1 | Section 6.3 | 5 | 638 +----------------------------+---------------+--------------------+ 640 8. Open Questions 642 The additional authenticated data input is well suited to 643 authenticating headers. Some cryptographic protocols have trailers 644 that should be authenticated. For example, in the Secure RTP 645 protocol the authenticated data consists of the RTP header, the 646 ciphertext containing the encrypted payload, and some additional 647 data, in that order. It is impossible for an AEAD to accommodate 648 both the authenticated header and authenticated trailer without 649 adding an additional input for the trailer. Because none of the 650 specified AEAD algorithms can handle both a trailer and a footer, 651 this specification does not include a trailer in its interface. We 652 expect that protocols like SRTP will need to define different 653 processing rules that include all of the authenticated-only data into 654 a single AAD input in order to make use of this specification. 655 However, new rules would need to be defined in order to use either 656 GCM or CCM or any other AEAD transforms, so this need is not 657 especially onerous. 659 The TLS protocol as currently defined assumes that authentication 660 will precede encryption. Thus, in order to accommodate this 661 specification, new processing rules would need to be written that 662 make no assumptions about the relative ordering of the cryptographic 663 services. However, as above, these new rules would need to be 664 defined anyway in order to use any AEAD algorithm. 666 The AEAD algorithms selected reflect those that have been already 667 adopted by standards. It is an open question as to what other AEAD 668 algorithms should be added. Many variations on basic algorithms are 669 possible, each with its own advantages. While it is desirable to 670 admit any algorithms that are found to be useful in practice, it is 671 also desirable to limit the total number of registered algorithms. 672 The current specification requires that a registered algorithm 673 provide a complete specification and a set of validation data; it is 674 hoped that these prerequisites set the admission criteria 675 appropriately. 677 Some users may view an IANA assignment as a recommendation or an 678 endorsement of a particular AEAD algorithm. Other users may desire 679 to register an AEAD algorithm in order to allow for experimental or 680 specialized use. Because of these conflicting perspectives, it may 681 be desirable to allocate a second IANA registry for experimental use. 683 It may be desirable to replace HMAC-SHA1 with AES CMAC [CMAC] in the 684 generic composition algorithm, or to introduce an additional 685 algorithm that does so. 687 Directly testing a randomized AEAD encryption algorithm using a test 688 cases with fixed inputs and outputs is not possible, since the 689 encryption process is non-deterministic. However, it is easy to test 690 a randomized AEAD algorithm against fixed test cases. The 691 authenticated decryption algorithm is deterministic, and it can be 692 directly tested. The authenticated encryption algorithm can be 693 tested by encrypting a plaintext, decrypting the resulting 694 ciphertext, and comparing the original plaintext to the post- 695 decryption plaintext. 697 Some of the terminology in this specification is unwieldy, and could 698 perhaps be improved. For example, "AEAD algorithm" could be replaced 699 with "crypto transform", which would be meaningful to a broader 700 community, but is less precise. 702 9. Security Considerations 704 A future version of this document will define the security services 705 that must be provided by an AEAD algorithm. 707 10. Acknowledgments 709 Many reviewers provided valuable comments on earlier drafts of this 710 document. 712 11. References 714 11.1 Normative References 716 [CCM] "NIST Special Publication 800-38C: The CCM Mode for 717 Authentication and Confidentiality", 718 http://csrc.nist.gov/publications/nistpubs/SP800-38C.pdf. 720 [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of 721 Operation (GCM)", Submission to NIST. http:// 722 csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/ 723 gcm-spec.pdf, January 2004. 725 [MODES] "NIST Special Publication 800-38", Reccomendation for 726 Block Cipher Modes of Operation http://csrc.nist.gov/ 727 publications/nistpubs/800-38a/sp800-38a.pdf. 729 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 730 Hashing for Message Authentication", RFC 2104, 731 February 1997. 733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 734 Requirement Levels", BCP 14, RFC 2119, March 1997. 736 [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- 737 SHA-1", RFC 2202, September 1997. 739 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 740 (GCM) in IPsec Encapsulating Security Payload (ESP)", 741 RFC 4106, June 2005. 743 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 744 Mode with IPsec Encapsulating Security Payload (ESP)", 745 RFC 4309, December 2005. 747 [SHA1] "FIPS 180-1: Secure Hash Standard,", Federal Information 748 Processing Standard 749 (FIPS) http://www.itl.nist.gov/fipspubs/fip180-1.htm. 751 11.2 Informative References 753 [AE] "Authenticated encryption: Relations among notions and 754 analysis of the generic composition paradigm", Proceedings 755 of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 756 531-545 http://www. 758 [CMAC] "NIST Special Publication 800-38B", http://csrc.nist.gov/ 759 CryptoToolkit/modes/800-38_Series_Publications/ 760 SP800-38B.pdf. 762 [EEM04] "Breaking and provably repairing the SSH authenticated 763 encryption scheme: A case study of the Encode-then-Encrypt- 764 and-MAC paradigm", ACM Transactions on Information and 765 System Security, http://www-cse.ucsd.edu/users/tkohno/ 766 papers/TISSEC04/. 768 Author's Address 770 David A. McGrew 771 Cisco Systems, Inc. 772 510 McCarthy Blvd. 773 Milpitas, CA 95035 774 US 776 Phone: (408) 525 8651 777 Email: mcgrew@cisco.com 778 URI: http://www.mindspring.com/~dmcgrew/dam.htm 780 Intellectual Property Statement 782 The IETF takes no position regarding the validity or scope of any 783 Intellectual Property Rights or other rights that might be claimed to 784 pertain to the implementation or use of the technology described in 785 this document or the extent to which any license under such rights 786 might or might not be available; nor does it represent that it has 787 made any independent effort to identify any such rights. Information 788 on the procedures with respect to rights in RFC documents can be 789 found in BCP 78 and BCP 79. 791 Copies of IPR disclosures made to the IETF Secretariat and any 792 assurances of licenses to be made available, or the result of an 793 attempt made to obtain a general license or permission for the use of 794 such proprietary rights by implementers or users of this 795 specification can be obtained from the IETF on-line IPR repository at 796 http://www.ietf.org/ipr. 798 The IETF invites any interested party to bring to its attention any 799 copyrights, patents or patent applications, or other proprietary 800 rights that may cover technology that may be required to implement 801 this standard. Please address the information to the IETF at 802 ietf-ipr@ietf.org. 804 Disclaimer of Validity 806 This document and the information contained herein are provided on an 807 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 808 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 809 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 810 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 811 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 812 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 814 Copyright Statement 816 Copyright (C) The Internet Society (2006). This document is subject 817 to the rights, licenses and restrictions contained in BCP 78, and 818 except as set forth therein, the authors retain all their rights. 820 Acknowledgment 822 Funding for the RFC Editor function is currently provided by the 823 Internet Society.