idnits 2.17.1 draft-mcgrew-auth-enc-00.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 764. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 741. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 748. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 754. ** 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 (July 2006) is 6495 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: January 2, 2007 July 2006 6 Authenticated Encryption 7 draft-mcgrew-auth-enc-00.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 January 2, 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 Conventions Used In This Document . . . . . . . . . . . . 4 51 2. AEAD Interface . . . . . . . . . . . . . . . . . . . . . . . . 5 52 2.1 Authenticated Encryption . . . . . . . . . . . . . . . . . 5 53 2.2 Authenticated Decryption . . . . . . . . . . . . . . . . . 7 54 2.3 Data Formatting . . . . . . . . . . . . . . . . . . . . . 7 55 3. Requirements on AEAD algorithms . . . . . . . . . . . . . . . 8 56 3.1 Example IV Formation . . . . . . . . . . . . . . . . . . . 8 57 4. Requirements on the use of AEAD algorithms . . . . . . . . . . 9 58 5. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . . 10 59 5.1 AEAD_AES_128_GCM . . . . . . . . . . . . . . . . . . . . . 10 60 5.1.1 AEAD_AES_256_GCM . . . . . . . . . . . . . . . . . . . 10 61 5.2 AEAD_AES_128_CCM . . . . . . . . . . . . . . . . . . . . . 10 62 5.2.1 AEAD_AES_256_CCM . . . . . . . . . . . . . . . . . . . 10 63 5.3 AEAD_AES_128_HMAC_SHA1 . . . . . . . . . . . . . . . . . . 11 64 5.3.1 Test Cases . . . . . . . . . . . . . . . . . . . . . . 12 65 5.3.2 AEAD_AES_256_HMAC_SHA1 . . . . . . . . . . . . . . . . 12 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 7. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 15 68 8. Open Questions . . . . . . . . . . . . . . . . . . . . . . . . 17 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 70 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 72 11.1 Normative References . . . . . . . . . . . . . . . . . . . 21 73 11.2 Informative References . . . . . . . . . . . . . . . . . . 21 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22 75 Intellectual Property and Copyright Statements . . . . . . . . 23 77 1. Introduction 79 Many cryptographic protocols provide both confidentiality and message 80 authentication. Often an encryption method and a message 81 authentication code (MAC) are used to provide those security 82 services, with each algorithm using an independent key. More 83 recently, the idea of providing both security services using a single 84 cryptoalgorithm has become accepted. In this concept, the cipher and 85 MAC are replaced by an Authenticated Encryption with Associated Data 86 (AEAD) algorithm. Many crypto algorithms that implement AEAD 87 algorithms have been defined, including block cipher modes of 88 operation and dedicated algorithms. Several of these algorithms have 89 been adopted and proven useful in practice. In this document we 90 define an AEAD algorithm as an abstraction, by specifying an 91 interface to an AEAD and defining an IANA registry for AEAD 92 algorithms. We populate this registry with six AEAD algorithms: AES 93 in Galois/Counter Mode [GCM], AES in Counter and CBC MAC mode [CCM], 94 and an algorithm that composes AES CBC and HMAC-SHA1, with key sizes 95 of 128 and 256. This approach enables applications that need 96 cryptographic security services to more easily adopt those services. 98 The approach benefits the application designer by allowing them to 99 focus on the important issues of security services, canonicalization, 100 and data marshaling, and relieving them of the need to design crypto 101 mechanisms that meet their security goals. Importantly, the security 102 of an AEAD algorithm can be analyzed independent from its use in a 103 particular application. This property frees the user of the AEAD of 104 the need to consider security aspects such as the relative order of 105 authentication and encryption and the security of the particular 106 combination of cipher and MAC, such as the potential loss of 107 confidentiality through the MAC. The application designer that uses 108 the AEAD interface need not select a particular AEAD algorithm during 109 the design stage. Additionally, the interface to the AEAD is 110 relatively simple, since it requires only a single key as input and 111 it requires only a single identifier to indicate the algorithm in use 112 in a particular case. 114 The AEAD approach benefits the implementer of the crypto algorithms 115 by making available optimizations that are otherwise not possible to 116 reduce the amount of computation, the implementation cost, and/or the 117 storage requirements. The simpler interface makes testing easier; 118 this is a considerable benefit for a crypto algorithm implementation. 119 By providing a uniform interface to access cryptographic services, 120 the AEAD approach allows a single crypto implementation to easily 121 support multiple applications. For example, a hardware module that 122 supports the AEAD interface can easily provide crypto acceleration to 123 any application using that interface, even to applications that had 124 not been designed when the module was built. 126 The AEAD specification does not address security protocol issues such 127 as anti-replay services or access control decisions that are made on 128 authenticated data. Instead, the specification aims to abstract the 129 cryptography away from those issues. The interface, and the guidance 130 about how to use it, are consistent with the recommendations from 131 [EEM04]. 133 In the following, we define the AEAD interface (Section 2), and then 134 outline the requirements that each AEAD algorithm must meet 135 (Section 3) and provide guidance on the use of AEAD algorithms 136 (Section 4). Then we define six AEAD algorithms (Section 5), and 137 establish an IANA registry for AEAD algorithms (Section 6). Lastly, 138 we describe an example usage of the interface (Section 7) and discuss 139 some open questions (Section 8). 141 1.1 Conventions Used In This Document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 2. AEAD Interface 149 An AEAD algorithm has two operations, authenticated encryption and 150 authenticated decryption. The inputs and outputs of these algorithms 151 are defined in terms of bit strings. However, an implementation MAY 152 choose to accept only inputs whose bit-lengths are multiples of 8; 153 that is, it may accept only octet strings. 155 Each AEAD algorithm uses an Initialization Vector, or IV, to 156 initialize the algorithm for processing a particular message. The IV 157 is generated by the authenticated encryption algorithm, and it is 158 provided as an input to the authenticated decryption algorithm. The 159 IV is an output of the AEAD algorithm, rather than an input to it, so 160 that it is under the control of the crypto module implementing that 161 algorithm. 163 Rationale. Proper IV generation is a crucial for security, and 164 the requirements on how IVs are generated are different for 165 different algorithms. Giving the AEAD algorithm the 166 responsibility of generating its own IV hides that dependency from 167 the user, better reflects the interface between a crypto module 168 and an application, and promotes the testability of 169 implementations. 171 Each AEAD algorithm MUST specify the way in which its IVs are 172 generated, to allow for external testing of the IV generation 173 component of the encryption algorithm. 175 An AEAD algorithm is called deterministic if the outputs of the 176 encryption algorithm are a deterministic function of its inputs. 177 Otherwise, the AEAD algorithm is called random. 179 An AEAD algorithm MAY be stateful, that is, it may require that state 180 is maintained between each invocation of the authenticated encryption 181 operation, and/or between each invocation of the authenticated 182 decryption operation. 184 2.1 Authenticated Encryption 186 The authenticated encryption operation has three inputs, each of 187 which is a bit string: 189 a secret key K, 191 a plaintext P, which is to be encrypted, 193 additional authenticated data (AAD), which is denoted as A. This 194 data is authenticated, but not encrypted. 196 A deterministic AEAD encryption algorithm MUST accept an additional 197 input, and that value MUST be included verbatim in the IV. This 198 input is called the IV contribution. 200 There are three outputs: 202 an initialization vector IV, 204 a ciphertext C, 206 an authentication tag T. 208 For each AEAD algorithm, the length of the key is fixed. The lengths 209 of the other inputs and outputs may vary, and may include zero. The 210 length of the ciphertext is equal to, or greater than, the length of 211 the plaintext. The length of the tag is denoted as t. 213 Both confidentiality and message authentication is provided on the 214 plaintext. The strength of the authentication of P, IV and A is 215 attenuated by the length t of the authentication tag. When the 216 length of P is zero, the AEAD algorithm acts as a message 217 authentication code on the input A. 219 The additional authenticated data A is used to protect information 220 that needs to be authenticated, but which must be left unencrypted. 221 When using an AEAD to secure a network protocol, this input could 222 include addresses, ports, sequence numbers, protocol version numbers, 223 and other fields that indicate how the plaintext should be handled, 224 forwarded, or processed. In many situations, it is desirable to 225 authenticate these fields, though they must be left in the clear to 226 allow the network or system to function properly. When this data is 227 included in the AAD, authentication is provided without copying the 228 data into the ciphertext. 230 The IV is authenticated internally to the algorithm, and it is not 231 necessary to include it in the AAD input. The IV MAY be included in 232 the AAD if it convenient to the application. 234 The IV MAY be transported along with the plaintext. The entire IV 235 need not be transmitted; it is sufficient to provide the receiver 236 with enough information to allow the IV to be reconstructed. Because 237 the authenticated decryption process detects incorrect IV values, no 238 security failure results when a receiver incorrectly reconstructs an 239 IV. 241 2.2 Authenticated Decryption 243 The authenticated decryption operation has five inputs: K, IV , C , 244 A, and T, as defined above. It has only a single output, either the 245 plaintext value P or a special symbol FAIL that indicates that the 246 inputs are not authentic. A ciphertext C , initialization vector IV 247 , additional authenticated data A and tag T are authentic for key K 248 when IV, C, and T are generated by the encrypt operation with inputs 249 K, A and P, for some plaintext P. The authenticated decrypt operation 250 will, with high probability, return FAIL whenever its inputs were not 251 created by the encrypt operation with the identical key (assuming 252 that the AEAD algorithm is secure). 254 2.3 Data Formatting 256 This document does not specify any particular encoding for the AEAD 257 inputs and outputs, since the encoding does not affect the security 258 services provided by an AEAD algorithm. 260 An application using an AEAD SHOULD use the following rules for 261 ordering the AEAD outputs (e.g. within a packet) , in order to 262 facilitate efficient and simple implementations of AEAD algorithms: 264 The Authentication Tag SHOULD follow all other fields. 266 The Ciphertext SHOULD follow all fields other than the 267 Authentication Tag. 269 3. Requirements on AEAD algorithms 271 As described above, a deterministic AEAD algorithm MUST accept an IV 272 contribution input to its encryption operation. This input MUST be 273 included, verbatim, in the IV that is generated by that operation. A 274 deterministic algorithm MAY use the IV formation method defined in 275 Section 3.1, or any other method that meets this requirement. 277 3.1 Example IV Formation 279 One method to construct IVs that include a contribution, and which 280 conforms to many different methods of IV construction, is as follows. 281 The leftmost bits of the IV consist of the contribution. For any 282 fixed key, the length of the IV contribution is fixed. The rightmost 283 bits of the IV consist of an unsigned integer in network byte order. 284 The length of the integer part is chosen so that the total length of 285 the IV is the desired value. The integer part of the IV is equal to 286 one for the first IV, and increments by one for each successive IV 287 that is generated. The integer part is never equal to the all-zero 288 value. 290 Rationale. This method is used by both GCM ESP [RFC4106] and CCM 291 ESP [RFC4309], in which the IV contribution contains the Salt 292 value and the lowest eight octets of the IV are explicitly carried 293 in the ESP packet. In GCM ESP, the IV contribution must be at 294 least four octets long, so that it can contain the Salt value. In 295 CCM ESP, the IV contribution must be at least three octets long 296 for the same reason. This IV generation method is also used by 297 several counter mode variants including CTR ESP. 299 4. Requirements on the use of AEAD algorithms 301 This section provides advice that must be followed in order to use an 302 AEAD algorithm securely. 304 If the AAD input is constructed out of multiple data elements, then 305 it is essential that it be unambiguously parseable into its 306 constituent elements, without the use of any unauthenticated data in 307 the parsing process. This requirement ensures that an attacker 308 cannot fool a receiver into accepting a bogus set of data elements as 309 authentic by altering a set of data elements that were used to 310 construct an AAD input in an authenticated encryption operation in 311 such a way that the data elements are different, but the AAD input is 312 unchanged. This requirement is trivially met if the AAD is composed 313 of fixed-width elements. If the AAD contains a variable-length 314 string, for example, this requirement can be met by also including 315 the length of the string in the AAD. 317 Similarly, if the plaintext is constructed out of multiple data 318 elements, then it is essential that it be unambiguously parseable 319 into its constituent elements, without using any unauthenticated data 320 in the parsing process. Note that data that included in the AAD may 321 be used when parsing the plaintext, though of course since the AAD is 322 not encrypted there is a potential loss of confidentiality when 323 information about the plaintext is included in the AAD. 325 5. AEAD Algorithms 327 This section defines six AEAD algorithms; two are based on AES GCM, 328 two are based on AES CCM, and two are based on a composition of AES 329 CBC and HMAC SHA1. Each pair includes an algorithm with a key size 330 of 128 bits and one with a key size of 256 bits. 332 5.1 AEAD_AES_128_GCM 334 This algorithm is deterministic and stateful. An IV contribution 335 with a length of between zero and eight octets is accepted, and the 336 IV is constructed as described in Section 3.1. The IV is 12 octets 337 in length, and the secret key is 128 bits long. 339 The AEAD_AES_128_GCM authenticated encryption algorithm works as 340 specified in [GCM], by providing the key, IV, and plaintext to that 341 mode of operation. Test cases are provided in that reference. 343 5.1.1 AEAD_AES_256_GCM 345 This algorithm is identical to AEAD_AES_128_GCM, but with the 346 following differences: 348 the secret key is 256 bits long, instead of 128 bits in length, 349 and 351 AES-256 GCM is used instead of AES-128 GCM. 353 5.2 AEAD_AES_128_CCM 355 This algorithm is deterministic and stateful. An IV contribution 356 with a length of between zero and seven octets is accepted, and the 357 IV is constructed as described in Section 3.1. The IV is eleven 358 octets long, and the secret key is 128 bits in length. 360 The AEAD_AES_128_CCM authenticated encryption algorithm works as 361 specified in [CCM], by providing the key, IV, and plaintext to that 362 mode of operation. Test cases are provided in that reference. 364 5.2.1 AEAD_AES_256_CCM 366 This algorithm is identical to AEAD_AES_128_CCM, but with the 367 following differences: 369 the secret key is 256 bits long, instead of 128 bits in length, 370 and 371 AES-256 CCM is used instead of AES-128 CCM. 373 5.3 AEAD_AES_128_HMAC_SHA1 375 This algorithm random and stateless. It is based on the "generic 376 composition" of CBC encryption with HMAC authentication, with the the 377 encrypt-then-MAC method [AE]. It uses the HMAC message 378 authentication code [RFC2104] with the SHA-1 hash function [SHA1] to 379 provide message authentication. Test cases for HMAC_SHA1 are 380 provided in [RFC2202]. For encryption, it uses AES-128 in the cipher 381 block chaining (CBC) mode of operation as defined in Section 6.2 of 382 [MODES], with the padding method defined by Appendix A of the same 383 reference. The input key is 128 bits long, and the IV is generated 384 uniformly at random, and is also 128 bits long. 386 The authenticated encryption algorithm is as follows, or uses an 387 equivalent set of steps: 389 1. Generate the secondary keys MAC_KEY and ENC_KEY from the input 390 key K as follows: 392 MAC_KEY = HMAC_SHA1(K, "MAC"); 394 ENC_KEY = leftmost(HMAC_SHA1(K, "ENC"), 128); 396 where the function leftmost(X, m) accepts a bitstring X and a 397 non-negative integer m and returns the bitstring containing the 398 leftmost m bits of X. MAC_KEY is 160 bits long, and ENC_KEY is 399 128 bits long. 401 2. Generate a 128-bit IV uniformly at random. (A pseudorandom 402 process MAY be used if its strength is equivalent to AES-128.) 404 3. Pad the plaintext by appending a single '1' bit to that data and 405 then appending to the resulting string as few '0' bits as are 406 necessary to make the number of bits in the plaintext into a 407 multiple of 128. Note that padding MUST be added to the data; if 408 the number of octets in the payload data is a multiple of 16, 409 then 16 octets of padding will be added. 411 4. Encrypt the payload using AES-128 in CBC mode, using the ENC_KEY 412 and the random IV. Form the ciphertext by prepending the IV to 413 the CBC ciphertext outputs. 415 5. Compute the authentication tag by applying HMAC_SHA1 to the AAD, 416 the IV, and the ciphertext, using the MAC_KEY. 418 6. Return the ciphertext and the authentication tag. 420 The authenticated decryption algorithm is as follows, or uses an 421 equivalent set of steps: 423 1. Generate the secondary keys MAC_KEY and ENC_KEY from the input 424 key K as follows: 426 MAC_KEY = HMAC_SHA1(K, "MAC"); 428 ENC_KEY = leftmost(HMAC_SHA1(K, "ENC"), 128); 430 2. Compute the MAC value by applying HMAC_SHA1 to the clear data, 431 the IV, and the ciphertext, using the MAC_KEY. Compare this 432 value to the authentication tag. If they match, then continue 433 with the processing. Otherwise, discard the data and return 434 FAIL. 436 3. Decrypt the payload using AES-128 in CBC mode, with the ENC_KEY, 437 using the first 128 bits of the ciphertext as the random IV. 439 4. Remove padding by deleting the final '1' bit and all of the 440 following '0' bits. The remaining data forms the payload data. 442 5. Return the plaintext. 444 The length of the ciphertext can be inferred from that of the 445 plaintext. The number L of octets in the ciphertext is given by 447 L = 16 * ( floor(M / 16) + 2) 449 where M denotes the number of octets in the payload, and the function 450 floor() rounds its argument down to the nearest integer. This fact 451 is needed by the encoding function, since the length of the 452 ciphertext, rather than the length of the payload, must be 453 authenticated. 455 5.3.1 Test Cases 457 A future version of this document will include test cases for 458 AEAD_AES_128_HMAC_SHA1. 460 5.3.2 AEAD_AES_256_HMAC_SHA1 462 This algorithm is identical to AEAD_AES_128_HMAC_SHA1, but with the 463 following differences: 465 the secret key is 256 bits long, instead of 128 bits in length, 467 AES-256 CBC is used instead of AES-128 CBC, and 469 if a pseudorandom process is used to generate the IVs, that 470 process must have a cryptographic strength equivalent to that of 471 AES-256. 473 6. IANA Considerations 475 IANA will define the "AEAD Registry" described below. Additions and 476 changes to the AEAD Registry are by expert review. Each entry in the 477 registry contains the following elements: 479 a short name, such as "AEAD_AES_128_GCM", that starts with the 480 string "AEAD", 482 a positive number, and 484 a reference to a specification that completely defines an AEAD 485 algorithm and provides test cases that can be used to verify the 486 correctness of an implementation. 488 Requests to add an entry to the registry MUST include the name and 489 the reference. The number is assigned by IANA. These number 490 assignments SHOULD use the smallest available positive number. 492 IANA will add the following six entries to the AEAD Registry: 494 +----------------------------+---------------+--------------------+ 495 | Name | Reference | Numeric Identifier | 496 +----------------------------+---------------+--------------------+ 497 | AEAD_AES_128_GCM | Section 5.1 | 1 | 498 | | | | 499 | AEAD_AES_256_GCM | Section 5.1.1 | 2 | 500 | | | | 501 | AEAD_AES_128_CCM | Section 5.2 | 3 | 502 | | | | 503 | AEAD_AES_256_CCM | Section 5.2.1 | 4 | 504 | | | | 505 | AEAD_AES_128_CBC_HMAC_SHA1 | Section 5.3 | 5 | 506 | | | | 507 | AEAD_AES_256_CBC_HMAC_SHA1 | Section 5.3.2 | 6 | 508 +----------------------------+---------------+--------------------+ 510 7. Example Usage 512 ESP support is easy to achieve, and can interoperate with existing 513 ESP implementations of ESP GCM [RFC4106] and ESP CCM [RFC4309]. The 514 ESP sender-side processing is illustrated in Figure 1, which shows 515 how the fields of an ESP packet correspond to the authenticated 516 encryption inputs and outputs. Note that the only the rightmost 517 eight octets of the IV are explicitly carried in the packet. ESP 518 receiver-side processing is shown in Figure 2. 520 The conventional algorithms used in "generic composition" within ESP 521 include HMAC-SHA1 and AES in CBC mode. Unfortunately, the CBC 522 padding method used in ESP is not suitable for generic use, since it 523 interposes the padding and the pad length inside of the plaintext. 524 Thus the AES_128_CBC_HMAC_SHA1 AEAD algorithm is very close to, but 525 slightly different from, the equivalent generic composition method 526 for ESP. 528 K IV Contribution 529 | | 530 +-----------------------+ -+ v v 531 | SPI | | +-------+ 532 +-----------------------+ +--> AAD ->| | 533 | Sequence Number | | | a | 534 +-----------------------+ -+ | u e | 535 | IV | <---- IV ---| t n a | 536 | | | h c l | 537 +-----------------------+ -+ | e r g | 538 | | | | n y o | 539 ~ ESP Payload ~ | | t p r | 540 | | +--> P --->| i t i | 541 +-----------+-----+-----+ | | c i t | 542 | Padding | PL | NH | | | a o m | 543 +-----------+-----+-----+ -+ | t n | 544 | Integrity | | e | 545 ~ Check ~ <---- T ----| d | 546 | Value | +-------+ 547 +-----------------------+ 549 Figure 1: ESP AEAD encryption processing. 551 K 552 | 553 +-----------------------+ -+ V 554 | SPI | | +-------+ 555 +-----------------------+ +--> AAD ->| | 556 | Sequence Number | | | a | 557 +-----------------------+ -+ | u d | 558 | IV | ----- IV -->| t e a | 559 | | | h c l | 560 +-----------------------+ | e r g | 561 | | <-+ | n y o | 562 ~ ESP Payload ~ | | t p r | 563 | | +-- P ----| i t i | 564 +-----------+-----+-----+ | | c i t | 565 | Padding | PL | NH | <-+ | a o m | 566 +-----------+-----+-----+ | t n | 567 | Integrity | | e | 568 ~ Check ~ ----- T --->| d | 569 | Value | +-------+ 570 +-----------------------+ 572 Figure 2: ESP AEAD decryption processing. 574 8. Open Questions 576 The additional authenticated data input is well suited to 577 authenticating headers. Some cryptographic protocols have trailers 578 that should be authenticated. For example, in the Secure RTP 579 protocol the authenticated data consists of the RTP header, the 580 ciphertext containing the encrypted payload, and some additional 581 data, in that order. It is impossible for an AEAD to accommodate 582 both the authenticated header and authenticated trailer without 583 adding an additional input for the trailer. Because none of the 584 specified AEAD algorithms can handle both a trailer and a footer, 585 this specification does not include a trailer in its interface. We 586 expect that protocols like SRTP will need to define different 587 processing rules that include all of the authenticated-only data into 588 a single AAD input in order to make use of this specification. 589 However, new rules would need to be defined in order to use either 590 GCM or CCM or any other AEAD transforms, so this need is not 591 especially onerous. 593 The TLS protocol as currently defined assumes that authentication 594 will precede encryption. Thus, in order to accommodate this 595 specification, new processing rules would need to be written that 596 make no assumptions about the relative ordering of the cryptographic 597 services. However, as above, these new rules would need to be 598 defined anyway in order to use any AEAD algorithm. 600 The AEAD algorithms selected reflect those that have been already 601 adopted by standards. Both random and deterministic algorithms have 602 been provided. It is an open question as to what other AEAD 603 algorithms should be added. Many variations on basic algorithms are 604 possible, each with its own advantages. While it is desirable to 605 admit any algorithms that are found to be useful in practice, it is 606 also desirable to limit the total number of registered algorithms. 607 The current specification requires that a registered algorithm 608 provide a complete specification and a set of validation data; it is 609 hoped that these prerequisites set the admission criteria 610 appropriately. 612 Some users may view an IANA assignment as a recommendation or an 613 endorsement of a particular AEAD algorithm. Other users may desire 614 to register an AEAD algorithm in order to allow for experimental or 615 specialized use. Because of these conflicting perspectives, it may 616 be desirable to allocate a second IANA registry for experimental use. 618 It may be desirable to replace HMAC-SHA1 with AES CMAC [CMAC] in the 619 generic composition algorithm, or to introduce an additional 620 algorithm that does so. 622 Directly testing a randomized AEAD encryption algorithm using a test 623 cases with fixed inputs and outputs is not possible, since the 624 encryption process is non-deterministic. However, it is easy to test 625 a randomized AEAD algorithm against fixed test cases. The 626 authenticated decryption algorithm is deterministic, and it can be 627 directly tested. The authenticated encryption algorithm can be 628 tested by encrypting a plaintext, decrypting the resulting 629 ciphertext, and comparing the original plaintext to the post- 630 decryption plaintext. 632 This specification is incomplete regarding the subject of 633 authentication tag lengths. A future version will need to provide 634 clarification. One alternative is to have each AEAD algorithm use a 635 fixed tag length, though if the specification is inflexible, we are 636 faced with the need to choose that length carefully. If backwards 637 compatibility is desirable, a length of 12 octets would be best; if 638 security is considered paramount, then the longest is the best. One 639 way to add flexibility would be to have each AEAD return a fixed- 640 length authentication tag, but then to define a standard mechanism by 641 which that tag can be truncated when it is desirable to do so. 643 The authentication tag could be included in the ciphertext, which 644 would simplify the interface slightly, but would remove some 645 flexibility. Most existing security protocols include a separate 646 integrity check field to carry a message authentication code, so a 647 separate output for that tag was included in the AEAD interface. 649 Some of the terminology in this specification is unwieldy, and could 650 perhaps be improved. For example, "AEAD algorithm" could be replaced 651 with "crypto transform", which would be meaningful to a broader 652 community, but is less precise. 654 9. Security Considerations 656 A future version of this document will define the security services 657 that must be provided by an AEAD algorithm. 659 10. Acknowledgments 661 Eric Rescorla and Yoshi Kohno provided valuable comments on early 662 versions of this document. 664 11. References 666 11.1 Normative References 668 [CCM] "NIST Special Publication 800-38C: The CCM Mode for 669 Authentication and Confidentiality", 670 http://csrc.nist.gov/publications/nistpubs/SP800-38C.pdf. 672 [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of 673 Operation (GCM)", Submission to NIST. http:// 674 csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/ 675 gcm-spec.pdf, January 2004. 677 [MODES] "NIST Special Publication 800-38", Reccomendation for 678 Block Cipher Modes of Operation http://csrc.nist.gov/ 679 publications/nistpubs/800-38a/sp800-38a.pdf. 681 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 682 Hashing for Message Authentication", RFC 2104, 683 February 1997. 685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", BCP 14, RFC 2119, March 1997. 688 [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- 689 SHA-1", RFC 2202, September 1997. 691 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 692 (GCM) in IPsec Encapsulating Security Payload (ESP)", 693 RFC 4106, June 2005. 695 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 696 Mode with IPsec Encapsulating Security Payload (ESP)", 697 RFC 4309, December 2005. 699 [SHA1] "FIPS 180-1: Secure Hash Standard,", Federal Information 700 Processing Standard 701 (FIPS) http://www.itl.nist.gov/fipspubs/fip180-1.htm. 703 11.2 Informative References 705 [AE] "Authenticated encryption: Relations among notions and 706 analysis of the generic composition paradigm", Proceedings 707 of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 708 531-545 http://www. 710 [CMAC] "NIST Special Publication 800-38B", http://csrc.nist.gov/ 711 CryptoToolkit/modes/800-38_Series_Publications/ 712 SP800-38B.pdf. 714 [EEM04] "Breaking and provably repairing the SSH authenticated 715 encryption scheme: A case study of the Encode-then-Encrypt- 716 and-MAC paradigm", ACM Transactions on Information and 717 System Security, http://www-cse.ucsd.edu/users/tkohno/ 718 papers/TISSEC04/. 720 Author's Address 722 David A. McGrew 723 Cisco Systems, Inc. 724 510 McCarthy Blvd. 725 Milpitas, CA 95035 726 US 728 Phone: (408) 525 8651 729 Email: mcgrew@cisco.com 730 URI: http://www.mindspring.com/~dmcgrew/dam.htm 732 Intellectual Property Statement 734 The IETF takes no position regarding the validity or scope of any 735 Intellectual Property Rights or other rights that might be claimed to 736 pertain to the implementation or use of the technology described in 737 this document or the extent to which any license under such rights 738 might or might not be available; nor does it represent that it has 739 made any independent effort to identify any such rights. Information 740 on the procedures with respect to rights in RFC documents can be 741 found in BCP 78 and BCP 79. 743 Copies of IPR disclosures made to the IETF Secretariat and any 744 assurances of licenses to be made available, or the result of an 745 attempt made to obtain a general license or permission for the use of 746 such proprietary rights by implementers or users of this 747 specification can be obtained from the IETF on-line IPR repository at 748 http://www.ietf.org/ipr. 750 The IETF invites any interested party to bring to its attention any 751 copyrights, patents or patent applications, or other proprietary 752 rights that may cover technology that may be required to implement 753 this standard. Please address the information to the IETF at 754 ietf-ipr@ietf.org. 756 Disclaimer of Validity 758 This document and the information contained herein are provided on an 759 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 760 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 761 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 762 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 763 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 764 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 766 Copyright Statement 768 Copyright (C) The Internet Society (2006). This document is subject 769 to the rights, licenses and restrictions contained in BCP 78, and 770 except as set forth therein, the authors retain all their rights. 772 Acknowledgment 774 Funding for the RFC Editor function is currently provided by the 775 Internet Society.