idnits 2.17.1 draft-black-ipsec-ikev2-aead-modes-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 845. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 858. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4306, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC4306, updated by this document, for RFC5378 checks: 2001-11-16) -- 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 (April 22, 2008) is 5848 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 normative reference: RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Individual Submission D. Black 2 Internet Draft EMC 3 Intended status: Proposed Standard D. McGrew 4 Expires: October 2008 Cisco Systems 5 Updates: 4306 April 22, 2008 7 Using Authenticated Encryption Algorithms with the Encrypted Payload 8 of the Internet Key Exchange version 2 (IKEv2) Protocol 10 draft-black-ipsec-ikev2-aead-modes-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that 15 any applicable patent or other IPR claims of which he or she is 16 aware have been or will be disclosed, and any of which he or she 17 becomes aware will be disclosed, in accordance with Section 6 of 18 BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on October 22, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 An authenticated encryption algorithm combines encryption and 45 integrity into a single operation; such algorithms may also be 46 referred to as combined modes of an encryption cipher or as combined 47 mode algorithms. This document describes the use of authenticated 48 encryption algorithms with the Encrypted Payload of the Internet Key 49 Exchange version 2 (IKEv2) protocol. 51 The use of two specific authenticated encryption algorithms with the 52 IKEv2 Encrypted Payload is also described; these two algorithms are 53 the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES 54 GCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional 55 documents may describe the use of other authenticated encryption 56 algorithms with the IKEv2 Encrypted Payload. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in [RFC2119]. 64 The symbols or variables that designate authenticated encryption and 65 decryption operation inputs and outputs (K, N, P, A, and C) are 66 defined in [RFC5116]. The SK_* symbols or variables that designate 67 specific IKEv2 keys are defined in [RFC4306]. 69 Table of Contents 71 1. Introduction...................................................3 72 2. Structure of this Document.....................................4 73 3. IKEv2 Encrypted Payload Data...................................4 74 3.1. AES GCM and AES CCM Initialization Vector (IV)............6 75 3.2. AES GCM and AES CCM Ciphertext (C) Construction...........7 76 4. AES GCM and AES CCM Nonce (N) Format...........................7 77 5. IKEv2 Associated Data (A)......................................8 78 5.1. Associated Data (A) Construction..........................8 79 5.2. Data Integrity Coverage...................................9 80 6. AES GCM and AES CCM Encrypted Payload Expansion................9 81 7. IKEv2 Conventions for AES GCM and AES CCM......................9 82 7.1. Keying Material and Salt Values...........................9 83 7.2. IKEv2 Identifiers........................................10 84 7.3. Key Length...............................................11 85 8. IKEv2 Algorithm Selection.....................................11 86 9. Test Vectors..................................................11 87 10. RFC 5116 AEAD_* Algorithms...................................12 88 10.1. AES GCM algorithms with 8 and 12 octet ICVs.............12 89 10.1.1. AEAD_AES_128_GCM_8.................................12 90 10.1.2. AEAD_AES_256_GCM_8.................................12 91 10.1.3. AEAD_AES_128_GCM_12................................13 92 10.1.4. AEAD_AES_256_GCM_12................................13 93 10.2. AES CCM Algorithms with an 11 octet Nonce...............13 94 10.2.1. AEAD_AES_128_CCM_SHORT.............................13 95 10.2.2. AEAD_AES_256_CCM_SHORT.............................14 96 10.2.3. AEAD_AES_128_CCM_SHORT_8...........................14 97 10.2.4. AEAD_AES_256_CCM_SHORT_8...........................14 98 10.2.5. AEAD_AES_128_CCM_SHORT_12..........................15 99 10.2.6. AEAD_AES_256_CCM_SHORT_12..........................15 100 10.3. AEAD_* Algorithms and IKEv2.............................15 101 11. Security Considerations......................................16 102 12. IANA Considerations..........................................16 103 13. References...................................................17 104 13.1. Normative References....................................17 105 13.2. Informative References..................................18 106 Intellectual Property Statement..................................19 107 Disclaimer of Validity...........................................19 109 1. Introduction 111 An authenticated encryption algorithm combines encryption and 112 integrity into a single operation on plaintext data to produce 113 ciphertext that includes an integrity check [RFC5116]. The integrity 114 check may be an Integrity Check Value (ICV) that is logically 115 distinct from the encrypted data or the integrity check may be 116 incorporated into the encrypted data that is produced. Authenticated 117 encryption algorithms may also be referred to as combined modes of 118 operation of a block cipher or as combined mode algorithms. 120 An authenticated encryption with associated data (AEAD) algorithm 121 also provides integrity protection for additional data that is 122 associated with the plaintext, but which is left unencrypted. This 123 document describes the use of AEAD algorithms with the Encrypted 124 Payload of the Internet Key Exchange version 2 (IKEv2) protocol. The 125 use of two specific AEAD algorithms with the IKEv2 Encrypted Payload 126 is also described; the two algorithms are the Advanced Encryption 127 Standard (AES) in Galois/Counter Mode (AES GCM) [GCM] and AES in 128 Counter with CBC-MAC Mode (AES CCM) [CCM]. 130 Version 1 of the Internet Key Exchange protocol (IKEv1) [RFC2409] is 131 based on the Internet Security Association and Key Management 132 Protocol (ISAKMP) [RFC2408]. The E (Encryption) bit in the ISAKMP 133 header specifies that all payloads following the header are 134 encrypted, but any data integrity verification of those payloads is 135 handled by a separate Hash Payload or Signature Payload (see Sections 136 3.1, 3.11 and 3.12 of [RFC2408]). This separation of encryption from 137 data integrity protection prevents the use of authenticated 138 encryption with IKEv1, thus limiting initial specifications of AES 139 combined mode usage for IPsec to the Encapsulating Security Payload 140 (ESP) [RFC2406]. The current version of ESP is version 2, ESPv2 141 [RFC4303]. 143 Version 2 of the Internet Key Exchange Protocol (IKEv2) [RFC4306] 144 employs an Encrypted Payload that is based on the design of ESP. The 145 IKEv2 Encrypted Payload associates encryption and data integrity 146 protection in a fashion that makes it possible to use AEAD 147 algorithms. 149 2. Structure of this Document 151 This document is based on the RFCs that describe the usage of AES GCM 152 [RFC4106] and AES CCM [RFC4309] with ESP, and hence the introductory 153 material and specification of the modes in those documents are not 154 repeated here. The structure of this document follows the structure 155 of those documents; many sections of this document indicate which 156 sections of those two documents correspond and call out any 157 significant differences that implementers should be aware of. 158 Significant portions of the text of this document have been adapted 159 from those two documents. 161 This document is based on the authenticated encryption interfaces, 162 notation and terminology described in [RFC5116]. An important 163 departure from [RFC4106] and [RFC4309] is that these two RFCs 164 describe separate ciphertext and integrity check outputs of the 165 encryption operation, whereas [RFC5116] specifies a single Ciphertext 166 (C) output that includes an integrity check. The latter more general 167 approach encompasses authenticated encryption algorithms that produce 168 a single expanded ciphertext output into which the integrity check is 169 incorporated, rather than producing separate ciphertext and integrity 170 check outputs. 172 For AES GCM and AES CCM, the [RFC5116] Ciphertext (C) output of 173 encryption consists of the [RFC4106] or [RFC4309] ciphertext output 174 concatenated with the [RFC4106] or [RFC4309] Integrity Check Value 175 (ICV) output. This document does not modify the AES GCM and AES CCM 176 authenticated encryption algorithms specified in [RFC4106] and 177 [RFC4309]. 179 3. IKEv2 Encrypted Payload Data 181 This section is based on [RFC5116] and Section 3.14 of [RFC4306]. 183 For the use of authenticated encryption algorithms with the IKEv2 184 Encrypted Payload, this section updates [RFC4306] to replace Figure 185 21 in Section 3.14 and the text that follows it through the end of 186 that section with the contents of this section. In addition, Section 187 3.14 of [RFC4306] is also updated to allow the use of a single 188 authenticated encryption algorithm instead of a block cipher and a 189 separate integrity check algorithm. In contrast, Sections 3.1 and 190 3.2 of this document are specific to the AES GCM and AES CCM 191 algorithms and hence do not update [RFC4306]. The updates to 192 [RFC4306] made by this document have no effect when authenticated 193 encryption algorithms are neither proposed nor used. 195 The IKEv2 Encrypted Payload Data structure applies to all 196 authenticated encryption algorithms, and it is the same structure 197 that is used with ESP. When an authenticated encryption algorithm is 198 used, the IKEv2 Encrypted Payload is composed of the payload header 199 fields, followed by an Initialization Vector (IV) field and a 200 Ciphertext (C) field that includes an integrity check as shown in 201 Figure 1. 203 1 2 3 204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 ! Next Payload !C! RESERVED ! Payload Length ! 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 ! Initialization Vector ! 209 ! (length is specified by authenticated encryption algorithm) ! 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 ~ Ciphertext ~ 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Figure 1. IKEv2 Encrypted Payload Data for Authenticated Encryption 216 The Next Payload field, C bit and Payload length fields are unchanged 217 from [RFC4306]. 219 The contents of the Initialization Vector (IV) field are specified by 220 the authenticated encryption algorithm; see Sections 3.1 and 4 221 (below) for AES GCM and AES CCM. 223 The Ciphertext field is the output of an authenticated encryption 224 operation (see Section 2.1 of [RFC5116]) on the following inputs: 226 o The secret key (K) is the cipher key obtained from the SK_ei or 227 SK_er key, whichever is appropriate, see [RFC4306]. The 228 authenticated encryption algorithm describes how to obtain the 229 cipher key from SK_ei or SK_er; for AES GCM and AES CCM, see 230 Section 7.1 (below). 232 o The nonce (N) is specified by the authenticated encryption 233 algorithm; for AES GCM and AES CCM, see Section 4 (below). When 234 decrypting an Encrypted Payload, a receiver constructs the nonce 235 based on the IV in the Encrypted Payload, using rules that are 236 specific to the authenticated encryption algorithm; see Sections 237 3.1 and 4 (below) for AES GCM and AES CCM. 239 o The plaintext (P) consists of the concatenation of the IKE 240 Payloads to be encrypted with the Padding (if any) and the Pad 241 Length, as shown in Figure 2 (below). The plaintext structure in 242 Figure 2 applies to all encryption algorithms used with the IKEv2 243 Encrypted Payload, and is unchanged from [RFC4306]. 245 o The associated data (A) is described in Section 5 (below). 247 1 2 3 248 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 ~ IKE Payloads to be Encrypted ~ 251 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 ! ! Padding (0-255 octets) ! 253 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 254 ! ! Pad Length ! 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 2. IKEv2 Encrypted Payload Plaintext (P) 259 The IKE Payloads are as specified in [RFC4306]. 261 Padding MAY contain any value chosen by the sender. 263 Pad Length is the number of octets in the Padding field. There are 264 no alignment requirements on the length of the Padding field; the 265 recipient MUST accept any amount of Padding up to 255 octets. 267 The Ciphertext output of authenticated encryption algorithms, as 268 defined by [RFC5116], incorporates data that allows for checks on the 269 integrity and authenticity of the Ciphertext and associated data 270 check data. Thus, there is no need for a separate Integrity Check 271 Value (ICV) field in the IKEv2 Encrypted Payload Data structure. 273 3.1. AES GCM and AES CCM Initialization Vector (IV) 275 This section is based on Section 3.1 of [RFC4106] and Section 3.1 of 276 [RFC4309]. The Initialization Vector requirements are common to AES 277 GCM and AES CCM, and are the same as the requirements for ESP. 279 The Initialization Vector (IV) MUST be eight octets. The IV MUST be 280 chosen by the encryptor in a manner that ensures that the same IV 281 value is used only once for a given key. The encryptor MAY generate 282 the IV in any manner that ensures uniqueness. Common approaches to 283 IV generation include incrementing a counter for each packet and 284 linear feedback shift registers (LFSRs). 286 3.2. AES GCM and AES CCM Ciphertext (C) Construction 288 This section is based on Section 6 of [RFC4106] and Section 3.1 of 289 [RFC4309] with generalizations to match the interfaces specified in 290 [RFC5116]. The constructions for AES GCM and AES CCM are different, 291 but in each case, the construction is the same as used for ESP. 293 For AES GCM and AES CCM, the Ciphertext field consists of the output 294 of the authenticated encryption algorithm. (Note that this field 295 incorporates integrity-check data.) 297 The AES GCM ICV consists solely of the AES GCM Authentication Tag. 298 Implementations MUST support a full-length 16 octet ICV, MAY support 299 8 or 12 octet ICVs, and MUST NOT support other ICV lengths. 301 AES CCM provides an encrypted ICV. Implementations MUST support ICV 302 sizes of 8 octets and 16 octets. Implementations MAY also support 12 303 octet ICVs and MUST NOT support other ICV lengths. 305 4. AES GCM and AES CCM Nonce (N) Format 307 Specific authenticated encryption algorithms MAY use different nonce 308 formats, but they SHOULD use the default nonce format specified in 309 this section. 311 The default nonce format uses partially implicit nonces (see Section 312 3.2.1 of [RFC5116]) as follows: 314 o The implicit portion of the nonce is the salt that is part of the 315 IKEv2 Keying Material shared by the encryptor and decryptor (see 316 Section 7.1); the salt is not included in the IKEv2 Encrypted 317 Payload. 319 o The explicit portion of the nonce is the IV that is included in 320 the IKEv2 Encrypted Payload. 322 When this default nonce format is used, both the encryptor and 323 decryptor construct the nonce by concatenating the salt with the IV 324 in that order. 326 For the use of AES GCM with the IKEv2 Encrypted Payload, this default 327 nonce format MUST be used and a 12 octet nonce MUST be used. Note 328 that this format matches the one specified in Section 4 of [RFC4106], 329 providing compatibility between the use of AES GCM in IKEv2 and ESP. 330 All of the requirements of Section 4 of [RFC4106] apply to the use of 331 AES GCM with the IKEv2 Encrypted Payload. 333 For the use of AES CCM with the IKEv2 Encrypted Payload, this default 334 nonce format MUST be used and an 11 octet nonce MUST be used. Note 335 that this format matches the one specified in Section 4 of [RFC4309], 336 providing compatibility between the use of AES CCM in IKEv2 and ESP. 337 All of the requirements of Section 4 of [RFC4309] apply to the use of 338 AES CCM with the IKEv2 Encrypted Payload. 340 5. IKEv2 Associated Data (A) 342 This section is based on Section 3.1 of [RFC4106] and Section 3.1 of 343 [RFC4309], both of which refer to associated data as Additional 344 Authenticated Data (AAD). The associated data construction described 345 in this section applies to all authenticated encryption algorithms, 346 but differs from the construction used with ESP because IKEv2 347 requires different data integrity coverage. 349 5.1. Associated Data (A) Construction 351 The associated data (A) MUST consist of the partial contents of the 352 IKEv2 message starting from the first octet of the Fixed IKE Header 353 through the last octet of the Payload Header of the Encrypted Payload 354 (i.e., the fourth octet of the Encrypted Payload), as shown in Figure 355 3. This includes any Payloads that are between the Fixed IKE Header 356 and the Encrypted Payload. 358 1 2 3 359 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 ~ IKEv2 Header ~ 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 ~ Unencrypted IKE Payloads ~ 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 ! Next Payload !C! RESERVED ! Payload Length ! 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 Figure 3. IKEv2 Encrypted Payload Associated Data (A) for 369 Authenticated Encryption 371 The Initialization Vector and Ciphertext fields shown in Figure 1 372 (above) MUST NOT be included in the associated data. 374 5.2. Data Integrity Coverage 376 The data integrity coverage of the IKEv2 Encrypted Payload 377 encompasses the entire IKEv2 message that contains the Encrypted 378 Payload. When an authenticated encryption algorithm is used with the 379 Encrypted Payload, this coverage is realized as follows: 381 1. The associated data (A) covers the portion of the IKEv2 message 382 starting from the first octet of the Fixed IKE Header through the 383 last octet of the Payload Header of the Encrypted Payload (fourth 384 octet of the Encrypted Payload). This includes any Payloads 385 between the Fixed IKE Header and the Encrypted Payload. The 386 Encrypted Payload is always the last payload in an IKEv2 message 387 [RFC4306]. 389 2. The IV is an input to the authenticated encryption algorithm's 390 integrity check. A successful integrity check at the receiver 391 verifies that the correct IV was used, providing data integrity 392 coverage for the IV. 394 3. The plaintext (IKE Payloads, Padding and Pad Length) is covered by 395 the authenticated encryption algorithm's integrity check. 397 6. AES GCM and AES CCM Encrypted Payload Expansion 399 The expansion described in Section 7 of [RFC4106] and Section 6 of 400 [RFC4309] applies to the use of the AES GCM and AES CCM combined 401 modes with the IKEv2 Encrypted Payload. See Section 7 of [RFC4106] 402 and Section 6 of [RFC4309]. 404 7. IKEv2 Conventions for AES GCM and AES CCM 406 This section describes the conventions used to generate keying 407 material and salt values for use with AES GCM and AES CCM using the 408 IKEv2 [RFC4306] protocol. The identifiers and attributes needed to 409 use AES GCM and AES CCM with the IKEv2 Encrypted Payload are also 410 specified. 412 7.1. Keying Material and Salt Values 414 This section is based on Section 8.1 of [RFC4106] and Section 7.1 of 415 [RFC4309]. The Keying Material and Salt Values for AES GCM and AES 416 CCM are different, but have the same structure as the Keying Material 417 and Salt Values used with ESP. 419 IKEv2 makes the use of a pseudo-random function (PRF) to derive 420 keying material. The PRF is used iteratively to derive keying 421 material of arbitrary size, from which keying material for specific 422 uses is extracted without regard to PRF output boundaries, see 423 Section 2.14 of [RFC4306]. 425 This subsection describes how the key derivation specified in Section 426 2.14 of [RFC4306] is used to obtain keying material for AES GCM and 427 AES CCM. When AES GCM or AES CCM is used with the IKEv2 Encrypted 428 Payload, the SK_ai and SK_ar integrity protection keys are not used; 429 each key MUST be treated as having a size of zero (0) octets. The 430 size of each of the SK_ei and SK_er encryption keys includes 431 additional salt bytes. The size and format of each of the SK_ei and 432 SK_er encryption keys MUST be: 434 o For AES GCM, each encryption key has the size and format of the 435 "KEYMAT requested" material specified in Section 8.1 of [RFC4106] 436 for the AES key size being used. For example, if the AES key size 437 is 128 bits, each encryption key is 20 octets, consisting of a 16 438 octet AES cipher key followed by 4 octets of salt. 440 o For AES CCM, each key has the size and format of the "KEYMAT 441 requested" material specified in Section 7.1 of [RFC4309] for the 442 AES key size being used. For example, if the AES key size is 128 443 bits, each encryption key is 19 octets, consisting of a 16 octet 444 AES cipher key followed by 3 octets of salt. 446 7.2. IKEv2 Identifiers 448 This section is unique to IKEv2 Encrypted Payload usage of AES GCM 449 and AES CCM. It reuses the identifiers used to negotiate ESP usage 450 of AES GCM and AES CCM. 452 The following identifiers previously allocated by IANA are used to 453 negotiate the use of AES GCM and AES CCM as the Encryption (ENCR) 454 Transform for IKEv2 (i.e., for use with the IKEv2 Encrypted Payload): 456 14 for AES CCM with an 8 octet ICV; 457 15 for AES CCM with a 12 octet ICV; 458 16 for AES CCM with a 16 octet ICV; 460 18 for AES GCM with an 8 octet ICV; 461 19 for AES GCM with a 12 octet ICV; and 462 20 for AES GCM with a 16 octet ICV. 464 A 16 octet ICV size SHOULD be used with IKEv2, as the higher level of 465 security that it provides by comparison to smaller ICV sizes is 466 appropriate to IKEv2's key exchange and related functionality. 468 In general, the use of 12-octet ICVs (values 15 and 19) is NOT 469 RECOMMENDED in order to reduce the number of options for ICV size. 470 If an ICV size larger than 8 octets is appropriate, 16 octet ICVs 471 SHOULD be used. 473 7.3. Key Length 475 This section is based on Section 8.4 of [RFC4106] and Section 7.4 of 476 [RFC4309]. The Key Length requirements are common to AES GCM and AES 477 CCM and are identical to the key length requirements for ESP. 479 Because the AES supports three key lengths, the Key Length attribute 480 MUST be specified when any of the identifiers for AES GCM or AES CCM 481 specified in Section 7.2 of this document is used. The Key Length 482 attribute MUST have a value of 128, 192 or 256. The use of the value 483 192 is NOT RECOMMENDED. If an AES key larger than 128 bits is 484 appropriate, a 256 bit AES key SHOULD be used. This reduces the 485 number of options for AES key length. 487 8. IKEv2 Algorithm Selection 489 This section applies to the use of any authenticated encryption 490 algorithm with the IKEv2 Encrypted Payload and is unique to that 491 usage. 493 IKEv2 (Section 3.3.3 of [RFC4306]) specifies that both an encryption 494 algorithm and an integrity checking algorithm are required for an IKE 495 SA (Security Association). This document updates [RFC4306] by 496 qualifying that statement to say that when an authenticated 497 encryption algorithm is selected as the encryption algorithm for any 498 SA (IKE or ESP), an integrity algorithm MUST NOT be selected for that 499 SA. This document further updates [RFC4306] to require that if all 500 of the encryption algorithms in any proposal are authenticated 501 encryption algorithms, then the proposal MUST NOT propose any 502 integrity transforms. 504 9. Test Vectors 506 See Section 9 of [RFC4106] and Section 8 of [RFC4309] for references 507 that provide AES GCM and AES CCM test vectors. 509 10. RFC 5116 AEAD_* Algorithms 511 This section adds new algorithms to the AEAD_* algorithm framework 512 defined in [RFC5116] to encompass the usage of AES GCM and AES CCM 513 with IKEv2. An AEAD_* algorithm does not have any attributes or 514 parameters; each AEAD_* algorithm identifier defined in this document 515 completely specifies the AES key size and the ICV size to be used 516 (e.g., AEAD_AES_128_GCM uses a 128 bit AES key and a 16 octet ICV). 518 AEAD_* algorithm coverage of the AES GCM and AES CCM authenticated 519 encryption algorithms used with IKEv2 requires specification of eight 520 additional AEAD_* algorithms beyond the four algorithms specified in 521 [RFC5116]: 523 o Four AEAD_* algorithms are specified to allow 8 and 12 octet ICVs 524 to be used with the AES GCM and AEAD_* algorithms specified in 525 [RFC5116]. 527 o The version of AES CCM used with IPsec (see [RFC4309]) uses an 11 528 octet nonce instead of the 12 octet nonce used by the version of 529 AES CCM specified in [RFC5116]. Six AEAD_* algorithms are 530 specified for this short nonce version of AES CCM. 532 This document recommends against the use of 192 bit AES keys and 533 therefore does not specify AEAD_* algorithms for 192 bit AES keys. 535 10.1. AES GCM algorithms with 8 and 12 octet ICVs 537 The following four AEAD_* algorithms are identical to the 538 AEAD_*algorithms specified in [RFC5116] except that an 8 octet ICV is 539 used instead of a 16 octet ICV. 541 10.1.1. AEAD_AES_128_GCM_8 543 This algorithm is identical to AEAD_AES_128_GCM (see Section 5.1 of 544 [RFC5116], except that an authentication tag with a length of 8 545 octets (64 bits) is used. 547 An AEAD_AES_128_GCM_8 ciphertext is exactly 8 octets longer than its 548 corresponding plaintext. 550 10.1.2. AEAD_AES_256_GCM_8 552 This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of 553 [RFC5116], except that an authentication tag with a length of 8 554 octets (64 bits) is used. 556 An AEAD_AES_256_GCM_8 ciphertext is exactly 8 octets longer than its 557 corresponding plaintext. 559 10.1.3. AEAD_AES_128_GCM_12 561 This algorithm is identical to AEAD_AES_128_GCM (see Section 5.1 of 562 [RFC5116], except that the tag length, t, is 12 and an authentication 563 tag with a length of 12 octets (64 bits) is used. 565 An AEAD_AES_128_CCM_12 ciphertext is exactly 12 octets longer than 566 its corresponding plaintext. 568 10.1.4. AEAD_AES_256_GCM_12 570 This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of 571 [RFC5116], except that the tag length, t, is 12 and an authentication 572 tag with a length of 12 octets (64 bits) is used. 574 An AEAD_AES_256_CCM_12 ciphertext is exactly 12 octets longer than 575 its corresponding plaintext. 577 10.2. AES CCM Algorithms with an 11 octet Nonce 579 The following four AEAD algorithms employ the AES CCM algorithms with 580 an 11 octet nonce as specified in [RFC4309]. 582 10.2.1. AEAD_AES_128_CCM_SHORT 584 The AEAD_AES_128_CCM_SHORT authenticated encryption algorithm is 585 identical to the AEAD_AES_128_CCM algorithm (see Section 5.3 of 586 [RFC5116]), except that it uses a nonce that is one octet shorter. 587 AEAD_AES_128_CCM_SHORT works as specified in [CCM], using AES-128 as 588 the block cipher, by providing the key, nonce, associated data, and 589 plaintext to that mode of operation. The formatting and counter 590 generation function are as specified in Appendix A of that reference, 591 and the values of the parameters identified in that appendix are as 592 follows: 594 the nonce length n is 11, 596 the tag length t is 16, and 598 the value of q is 3. 600 An authentication tag with a length of 16 octets (128 bits) is used. 601 The AEAD_AES_128_CCM_SHORT ciphertext is formed by appending the 602 authentication tag provided as an output to the CCM encryption 603 operation to the ciphertext that is output by that operation. Test 604 cases are provided in [CCM]. The input and output lengths are as 605 follows: 607 K_LEN is 16 octets, 609 P_MAX is 2^24 - 1 octets, 611 A_MAX is 2^64 - 1 octets, 613 N_MIN and N_MAX are both 11 octets, and 615 C_MAX is 2^24 + 15 octets. 617 An AEAD_AES_128_CCM_SHORT ciphertext is exactly 16 octets longer than 618 its corresponding plaintext. 620 10.2.2. AEAD_AES_256_CCM_SHORT 622 This algorithm is identical to AEAD_AES_128_CCM_SHORT, but with the 623 following differences: 625 K_LEN is 32 octets, instead of 16, and 627 AES-256 CCM is used instead of AES-128 CCM. 629 An AEAD_AES_128_CCM_SHORT ciphertext is exactly 16 octets longer than 630 its corresponding plaintext. 632 10.2.3. AEAD_AES_128_CCM_SHORT_8 634 This algorithm is identical to AEAD_AES_128_CCM_SHORT, except that 635 the tag length, t, is 8 and an authentication tag with a length of 8 636 octets (64 bits) is used. 638 An AEAD_AES_128_CCM_SHORT_8 ciphertext is exactly 8 octets longer 639 than its corresponding plaintext. 641 10.2.4. AEAD_AES_256_CCM_SHORT_8 643 This algorithm is identical to AEAD_AES_256_CCM_SHORT, except that 644 the tag length, t, is 8 and an authentication tag with a length of 8 645 octets (64 bits) is used. 647 An AEAD_AES_256_CCM_SHORT_8 ciphertext is exactly 8 octets longer 648 than its corresponding plaintext. 650 10.2.5. AEAD_AES_128_CCM_SHORT_12 652 This algorithm is identical to AEAD_AES_128_CCM_SHORT, except that 653 the tag length, t, is 12 and an authentication tag with a length of 654 12 octets (64 bits) is used. 656 An AEAD_AES_128_CCM_SHORT_12 ciphertext is exactly 12 octets longer 657 than its corresponding plaintext. 659 10.2.6. AEAD_AES_256_CCM_SHORT_12 661 This algorithm is identical to AEAD_AES_256_CCM_SHORT, except that 662 the tag length, t, is 12 and an authentication tag with a length of 8 663 octets (64 bits) is used. 665 An AEAD_AES_256_CCM_SHORT_12 ciphertext is exactly 12 octets longer 666 than its corresponding plaintext. 668 10.3. AEAD_* Algorithms and IKEv2 670 The following table lists the AES CCM and AES GCM AEAD_* algorithms 671 that can be negotiated by IKEv2 and provides the IKEv2 Encryption 672 (ENCR) Transform Identifier and Key Length Attribute combination that 673 is used to negotiate each algorithm. 675 +--------------------------+------------------+-------------+ 676 | AEAD algorithm | ENCR Identifier | Key Length | 677 +--------------------------+------------------+-------------+ 678 | AEAD_AES_128_GCM | 20 | 128 | 679 | AEAD_AES_256_GCM | 20 | 256 | 680 | AEAD_AES_128_GCM_8 | 18 | 128 | 681 | AEAD_AES_256_GCM_8 | 18 | 256 | 682 | AEAD_AES_128_GCM_12 | 19 | 128 | 683 | AEAD_AES_256_GCM_12 | 19 | 256 | 684 | AEAD_AES_128_CCM_SHORT | 16 | 128 | 685 | AEAD_AES_256_CCM_SHORT | 16 | 256 | 686 | AEAD_AES_128_CCM_SHORT_8 | 14 | 128 | 687 | AEAD_AES_256_CCM_SHORT_8 | 14 | 256 | 688 | AEAD_AES_128_CCM_SHORT_12| 15 | 128 | 689 | AEAD_AES_256_CCM_SHORT_12| 15 | 256 | 690 +--------------------------+------------------+-------------+ 692 Each of the above AEAD_* algorithms is identical to the algorithm 693 designated by the combination of the IKEv2 ENCR Identifier and Key 694 Length Attribute shown on the same line of the table. 696 11. Security Considerations 698 For authenticated encryption security considerations, see the 699 entirety of [RFC5116], not just its security considerations section; 700 there are important security considerations that are discussed 701 outside the security considerations section of that document. 703 The security considerations for the use of AES GCM and AES CCM with 704 ESP apply to the use of these algorithms with the IKEv2 Encrypted 705 Payload, see Section 10 of [RFC4106] and Section 9 of [RFC4309]. Use 706 of AES GCM and AES CCM with IKEv2 does not create additional security 707 considerations beyond those for the use of AES GCM and AES CCM with 708 ESP. 710 For IKEv2 security considerations, see Section 5 of [RFC4306]. 712 12. IANA Considerations 714 The Encryption Transform identifiers specified in Section 7.2 have 715 been previously assigned by IANA for use with ESP. This document 716 extends their usage to IKEv2 for the Encrypted Payload. No IANA 717 actions are required for this usage extension. 719 IANA is requested to add the following entries to the Authenticated 720 Encryption with Associated Data (AEAD) Parameters Registry: 722 +--------------------------+----------------+--------------------+ 723 | Name | Reference | Numeric Identifier | 724 +--------------------------+----------------+--------------------+ 725 | AEAD_AES_128_GCM_8 | Section 10.1.1 | 5 | 726 | AEAD_AES_256_GCM_8 | Section 10.1.2 | 6 | 727 | AEAD_AES_128_GCM_12 | Section 10.1.3 | 7 | 728 | AEAD_AES_256_GCM_12 | Section 10.1.4 | 8 | 729 | AEAD_AES_128_CCM_SHORT | Section 10.2.1 | 9 | 730 | AEAD_AES_256_CCM_SHORT | Section 10.2.2 | 10 | 731 | AEAD_AES_128_CCM_SHORT_8 | Section 10.2.3 | 11 | 732 | AEAD_AES_256_CCM_SHORT_8 | Section 10.2.4 | 12 | 733 | AEAD_AES_128_CCM_SHORT_12| Section 10.2.5 | 13 | 734 | AEAD_AES_256_CCM_SHORT_12| Section 10.2.6 | 14 | 735 +--------------------------+----------------+--------------------+ 737 An IANA registration of an AEAD algorithm does not constitute an 738 endorsement of that algorithm or its security. 740 Acknowledgments 742 See Section 13 of [RFC4106] and Section 12 of [RFC4309] for AES GCM 743 and AES CCM acknowledgments. 745 Also, we thank Charlie Kaufman, Pasi Eronen, Tero Kivinen, Steve Kent 746 and Alfred Hoenes for their comprehensive reviews of this document. 748 This document was prepared using 2-Word-v2.0.template.dot, created by 749 Joe Touch. 751 13. References 753 13.1. Normative References 755 [CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM 756 Mode for Authentication and Confidentiality", U.S. 757 National Institute of Standards and Technology, 758 , updated July 2007. 761 [GCM] Dworkin, M., "NIST Special Publication 800-38D: 762 Recommendation for Block Cipher Modes of Operation: 763 Galois/Counter Mode (GCM) and GMAC.", U.S. National 764 Institute of Standards and Technology, November 2007, 765 , November 2007. 768 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 769 Requirement Levels", BCP 14, RFC 2119, March 1997. 771 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 772 (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 773 4106, June 2005. 775 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 776 4303, December 2005. 778 [RFC4306] Kaufman, C. (Editor), "Internet Key Exchange (IKEv2) 779 Protocol", RFC 4306, December 2005. 781 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 782 Mode with IPsec Encapsulating Security Payload (ESP)", RFC 783 4309, December 2005. 785 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 786 Encryption", RFC 5116, January 2008. 788 13.2. Informative References 790 [RFC2406] Kent, S. and Atkinson, R., "IP Encapsulating Security 791 Payload (ESP)", RFC 2406, November 1998. 793 [RFC2408] Maughan, D., M. Schertler, M. Schneider and J. Turner, " 794 Internet Security Association and Key Management Protocol 795 (ISAKMP)", RFC 2408, November 1998. 797 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 798 (IKE)", RFC 2409, November 1998. 800 Change Log 802 RFC Editor - please remove this section before publication 804 -00: First version 806 Changes for version -01: 807 - Allow 8-octet ICVs, 12-octet ICVs and 192 bit AES keys, but 808 recommend against the use of 192 bit keys in general and 809 recommend against both 8 and 12 octet ICVs for IKEv2. 810 - Remove alignment requirements on Padding and Pad Length. 811 - Added material on relationship to AEAD_* algorithms, plus 812 specification and IANA registration of additional AEAD_* 813 algorithms to encompass IPsec usage. 814 - Clarified nonce format specification in Section 4 815 - Add [CCM] and [GCM] references. 816 - Numerous editorial corrections and improvements. 818 Author's Addresses 820 David L. Black 821 EMC Corporation 822 176 South Street 823 Hopkinton, MA 10748 825 Phone: +1 (508) 293-7953 826 Email: black_david@emc.com 828 David A. McGrew 829 Cisco Systems, Inc. 830 510 McCarthy Blvd. 831 Milpitas, CA 95035 833 Phone: +1 (408) 525-8651 834 Email: mcgrew@cisco.com 836 Intellectual Property Statement 838 The IETF takes no position regarding the validity or scope of any 839 Intellectual Property Rights or other rights that might be claimed to 840 pertain to the implementation or use of the technology described in 841 this document or the extent to which any license under such rights 842 might or might not be available; nor does it represent that it has 843 made any independent effort to identify any such rights. Information 844 on the procedures with respect to rights in RFC documents can be 845 found in BCP 78 and BCP 79. 847 Copies of IPR disclosures made to the IETF Secretariat and any 848 assurances of licenses to be made available, or the result of an 849 attempt made to obtain a general license or permission for the use of 850 such proprietary rights by implementers or users of this 851 specification can be obtained from the IETF on-line IPR repository at 852 http://www.ietf.org/ipr. 854 The IETF invites any interested party to bring to its attention any 855 copyrights, patents or patent applications, or other proprietary 856 rights that may cover technology that may be required to implement 857 this standard. Please address the information to the IETF at 858 ietf-ipr@ietf.org. 860 Disclaimer of Validity 862 This document and the information contained herein are provided on an 863 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 864 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 865 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 866 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 867 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 868 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 870 Copyright Statement 872 Copyright (C) The IETF Trust (2008). 874 This document is subject to the rights, licenses and restrictions 875 contained in BCP 78, and except as set forth therein, the authors 876 retain all their rights. 878 Acknowledgment 880 Funding for the RFC Editor function is currently provided by the 881 Internet Society.