idnits 2.17.1 draft-ietf-ipsecme-rfc7321bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 27, 2017) is 2615 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) -- Looks like a reference, but probably isn't: '1' on line 272 == Missing Reference: 'UNSPECIFIED' is mentioned on line 356, but not defined ** Obsolete normative reference: RFC 7321 (Obsoleted by RFC 8221) -- Obsolete informational reference (is this intentional?): RFC 2393 (Obsoleted by RFC 3173) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Migault 3 Internet-Draft J. Mattsson 4 Obsoletes: 7321 (if approved) Ericsson 5 Intended status: Standards Track P. Wouters 6 Expires: August 31, 2017 Red Hat 7 Y. Nir 8 Check Point 9 T. Kivinen 10 INSIDE Secure 11 February 27, 2017 13 Cryptographic Algorithm Implementation Requirements and Usage Guidance 14 for Encapsulating Security Payload (ESP) and Authentication Header (AH) 15 draft-ietf-ipsecme-rfc7321bis-05 17 Abstract 19 This document updates the Cryptographic Algorithm Implementation 20 Requirements for ESP and AH. The goal of these document is to enable 21 ESP and AH to benefit from cryptography that is up to date while 22 making IPsec interoperable. 24 This document obsoletes RFC 7321 on the cryptographic recommendations 25 only. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 31, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Updating Algorithm Implementation Requirements and Usage 63 Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3 65 1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 67 3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Encryption must be Authenticated . . . . . . . . . . . . . . 5 69 5. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 6 70 6. ESP and AH Authentication Algorithms . . . . . . . . . . . . 8 71 7. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 9 72 8. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 10 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 78 12.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 The Encapsulating Security Payload (ESP) [RFC4303] and the 84 Authentication Header (AH) [RFC4302] are the mechanisms for applying 85 cryptographic protection to data being sent over an IPsec Security 86 Association (SA) [RFC4301]. 88 This document provides guidance and recommendations so that ESP and 89 AH can be used with a cryptographic algorithms that are up to date. 90 The challenge of such document is to make sure that over the time 91 IPsec implementations can use secure and up-to-date cryptographic 92 algorithms while keeping IPsec interoperable. 94 1.1. Updating Algorithm Implementation Requirements and Usage Guidance 96 The field of cryptography evolves continuously. New stronger 97 algorithms appear and existing algorithms are found to be less secure 98 than originally thought. Therefore, algorithm implementation 99 requirements and usage guidance need to be updated from time to time 100 to reflect the new reality. The choices for algorithms must be 101 conservative to minimize the risk of algorithm compromise. 102 Algorithms need to be suitable for a wide variety of CPU 103 architectures and device deployments ranging from high end bulk 104 encryption devices to small low-power IoT devices. 106 The algorithm implementation requirements and usage guidance may need 107 to change over time to adapt to the changing world. For this reason, 108 the selection of mandatory-to-implement algorithms was removed from 109 the main IKEv2 specification and placed in a separate document. 111 1.2. Updating Algorithm Requirement Levels 113 The mandatory-to-implement algorithm of tomorrow should already be 114 available in most implementations of AH/ESP by the time it is made 115 mandatory. This document attempts to identify and introduce those 116 algorithms for future mandatory-to-implement status. There is no 117 guarantee that the algorithms in use today may become mandatory in 118 the future. Published algorithms are continuously subjected to 119 cryptographic attack and may become too weak or could become 120 completely broken before this document is updated. 122 This document only provides recommendations for the mandatory-to- 123 implement algorithms and algorithms too weak that are recommended not 124 to be implemented. As a result, any algorithm listed at the IPsec 125 IANA registry not mentioned in this document MAY be implemented. It 126 is expected that this document will be updated over time and next 127 versions will only mention algorithms which status has evolved. For 128 clarification when an algorithm has been mentioned in [RFC7321], this 129 document states explicitly the update of the status. 131 Although this document updates the algorithms to keep the AH/ESP 132 communication secure over time, it also aims at providing 133 recommendations so that AH/ESP implementations remain interoperable. 134 AH/ESP interoperability is addressed by an incremental introduction 135 or deprecation of algorithms. In addition, this document also 136 considers the new use cases for AH/ESP deployment, such as Internet 137 of Things (IoT). 139 It is expected that deprecation of an algorithm is performed 140 gradually. This provides time for various implementations to update 141 their implemented algorithms while remaining interoperable. Unless 142 there are strong security reasons, an algorithm is expected to be 143 downgraded from MUST to MUST- or SHOULD, instead of MUST NOT. 144 Similarly, an algorithm that has not been mentioned as mandatory-to- 145 implement is expected to be introduced with a SHOULD instead of a 146 MUST. 148 The current trend toward Internet of Things and its adoption of AH/ 149 ESP requires this specific use case to be taken into account as well. 150 IoT devices are resource constrained devices and their choice of 151 algorithms are motivated by minimizing the footprint of the code, the 152 computation effort and the size of the messages to send. This 153 document indicates "(IoT)" when a specified algorithm is specifically 154 listed for IoT devices. Requirement levels that are marked as "IoT" 155 apply to IoT devices and to server-side implementations that might 156 presumably need to interoperate with them, including any general- 157 purpose VPN gateways. 159 1.3. Document Audience 161 The recommendations of this document mostly target AH/ESP 162 implementers as implementations need to meet both high security 163 expectations as well as high interoperability between various vendors 164 and with different versions. Interoperability requires a smooth move 165 to more secure cipher suites. This may differ from a user point of 166 view that may deploy and configure AH/ESP with only the safest cipher 167 suite. 169 This document does not give any recommendations for the use of 170 algorithms, it only gives implementation recommendations for 171 implementations. The use of algorithms by users is dictated by the 172 security policy requirements for that specific user, and are outside 173 the scope of this document. 175 The algorithms considered here are listed by the IANA as part of the 176 IKEv2 parameters. IKEv1 is out of scope of this document. IKEv1 is 177 deprecated and the recommendations of this document must not be 178 considered for IKEv1, nor IKEv1 parameters be considered by this 179 document. 181 The IANA registry for Internet Key Exchange Version 2 (IKEv2) 182 Parameters contains some entries that are not for use with ESP or AH. 183 This document does not modify the status of those algorithms. 185 2. Requirements Language 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 189 "OPTIONAL" in this document are to be interpreted as described in 190 [RFC2119]. 192 We define some additional terms here: 194 SHOULD+ This term means the same as SHOULD. However, it is likely 195 that an algorithm marked as SHOULD+ will be promoted at 196 some future time to be a MUST. 197 SHOULD- This term means the same as SHOULD. However, an algorithm 198 marked as SHOULD- may be deprecated to a MAY in a future 199 version of this document. 200 MUST- This term means the same as MUST. However, we expect at 201 some point that this algorithm will no longer be a MUST in 202 a future document. Although its status will be determined 203 at a later time, it is reasonable to expect that if a 204 future revision of a document alters the status of a MUST- 205 algorithm, it will remain at least a SHOULD or a SHOULD- 206 level. 207 IoT stands for Internet of Things. 209 3. Manual Keying 211 Manual Keying is not to be used as it is inherently dangerous. 212 Without any keying protocol, it does not offer Perfect Forward 213 Secrecy ("PFS") protection. Deployments tend to never be 214 reconfigured with fresh session keys. It also fails to scale and 215 keeping SPI's unique amongst many servers is impractical. This 216 document was written for deploying ESP/AH using IKE ([RFC7296]) and 217 assumes that keying happens using IKEv2. 219 If manual keying is used anyway, ENCR_AES_CBC MUST be used, and 220 ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be 221 used as these algorithms require IKE. 223 4. Encryption must be Authenticated 225 Encryption without authentication is not effective and MUST NOT be 226 used. IPsec offers three ways to provide both encryption and 227 authentication: 229 o ESP with an AEAD cipher 230 o ESP with a non-AEAD cipher + authentication 231 o ESP with a non-AEAD cipher + AH with authentication 233 The fastest and most modern method is to use ESP with a combined mode 234 cipher such as an AEAD cipher that handles encryption/decryption and 235 authentication in a single step. In this case, the AEAD cipher is 236 set as the encryption algorithm and the authentication algorithm is 237 set to none. Examples of this are ENCR_AES_GCM_16 and 238 ENCR_CHACHA20_POLY1305. 240 A more traditional approach is to use ESP with an encryption and an 241 authentication algorithm. This approach is slower, as the data has 242 to be processed twice, once for encryption/decryption and once for 243 authentication. An example of this is ENCR_AES_CBC combined with 244 AUTH_HMAC_SHA2_512_256. 246 The last method that can be used is ESP+AH. This method is NOT 247 RECOMMENDED. It is the slowest method and also takes up more octets 248 due to the double header of ESP+AH, resulting in a smaller effective 249 MTU for the encrypted data. With this method, ESP is only used for 250 confidentiality without an authentication algorithm and a second 251 IPsec protocol of type AH is used for authentication. An example of 252 this is ESP with ENCR_AES_CBC with AH with AUTH_HMAC_SHA2_512_256. 254 5. ESP Encryption Algorithms 256 +-------------------------+-------------+---------+--------------+ 257 | Name | Status | AEAD | Comment | 258 +-------------------------+-------------+---------+--------------+ 259 | ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED | 260 | ENCR_DES | MUST NOT | No | [RFC2405] | 261 | ENCR_3DES | SHOULD NOT | No | [RFC2451] | 262 | ENCR_BLOWFISH | MUST NOT | No | [RFC2451] | 263 | ENCR_3IDEA | MUST NOT | No | UNSPECIFIED | 264 | ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED | 265 | ENCR_NULL | MUST | No | [RFC2410] | 266 | ENCR_AES_CBC | MUST | No | [RFC3602][1] | 267 | ENCR_AES_CCM_8 | SHOULD(IoT) | Yes | [RFC4309] | 268 | ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] | 269 | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] | 270 +-------------------------+-------------+---------+--------------+ 272 [1] - This requirement level is for 128-bit and 256-bit keys. 273 192-bit keys remain at MAY level. (IoT) - This requirement is for 274 interoperability with IoT. Only 128-bit keys are at the given level. 276 IPsec sessions may have very long life time, and carry multiple 277 packets, so there is a need to move to 256-bit keys in the long term. 278 For that purpose the requirement level for 128 bit keys and 256 bit 279 keys are at MUST (when applicable). In that sense 256 bit keys 280 status has been raised from MAY in RFC7321 to MUST. 282 IANA has allocated codes for cryptographic algorithms that have not 283 been specified by the IETF. Such algorithms are noted as 284 UNSPECIFIED. Usually, the use of theses algorithms is limited to 285 specific cases, and the absence of specification makes 286 interoperability difficult for IPsec communications. These 287 algorithms were not been mentioned in [RFC7321] and this document 288 clarify that such algorithms MUST NOT be implemented for IPsec 289 communications. 291 Similarly IANA also allocated code points for algorithms that are not 292 expected to be used to secure IPsec communications. Such algorithms 293 are noted as Non IPsec. As a result, these algorithms MUST NOT be 294 implemented. 296 Various older and not well tested and never widely implemented 297 ciphers have been changed to MUST NOT. 299 ENCR_3DES status has been downgraded from MAY in RFC7321 to SHOULD 300 NOT. ENCR_CHACHA20_POLY1305 is a more modern approach alternative 301 for ENCR_3DES than ENCR_AES_CBC and so it expected to be favored to 302 replace ENCR_3DES. 304 ENCR_BLOWFISH has been downgraded to MUST NOT as it has been 305 deprecated for years by TWOFISH, which is not standarized for ESP and 306 therefore not listed in this document. Some implementations support 307 TWOFISH using a private range number. 309 ENCR_NULL status was set to MUST in [RFC7321] and remains a MUST to 310 enable the use of ESP with only authentication which is preferred 311 over AH due to NAT traversal. ENCR_NULL is expected to remain MUST 312 by protocol requirements. 314 ENCR_AES_CBC status remains at MUST. ENCR_AES_CBC MUST be 315 implemented in order to enable interoperability between 316 implementations that followed RFC7321. However, there is a trend for 317 the industry to move to AEAD encryption, and the overhead of 318 ENCR_AES_CBC remains quite large so it is expected to be replaced by 319 AEAD algorithms in the long term. 321 ENCR_AES_CCM_8 status was set to MAY in [RFC7321] and has been raised 322 from MAY to SHOULD in order to interact with Internet of Things 323 devices. As this case is not a general use case for VPNs, its status 324 is expected to remain as SHOULD. 326 ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order 327 to favor the use of authenticated encryption and AEAD algorithms. 328 ENCR_AES_GCM_16 has been widely implemented for ESP due to its 329 increased performance and key longevity compared to ENCR_AES_CBC. 331 ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of 332 RFC7321. It has been recommended by the CRFG and others as an 333 alternative to AES-CBC and AES-GCM. It is also being standardized 334 for ESP for the same reasons. At the time of writing, there are not 335 enough ESP implementations of ENCR_CHACHA20_POLY1305 to be able to 336 introduce it at the SHOULD+ level. Its status has been set to SHOULD 337 and is expected to become MUST in the long term. 339 6. ESP and AH Authentication Algorithms 341 Authentication algorithm recommendations in this section are 342 targeting two types of communications: 344 o Authenticated only communications without encryption, such as ESP 345 with NULL encryption or AH communications. 346 o Communications that are encrypted with non-AEAD algorithm which 347 MUST be combined with an authentication algorithm. 349 +------------------------+------------------+-----------------------+ 350 | Name | Status | Comment | 351 +------------------------+------------------+-----------------------+ 352 | AUTH_NONE | MUST / MUST NOT | [RFC7296] AEAD | 353 | AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] | 354 | AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] | 355 | AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] | 356 | AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] | 357 | AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] | 358 | | | (IoT) | 359 | AUTH_AES_128_GMAC | MAY | [RFC4543] | 360 | AUTH_AES_256_GMAC | MAY | [RFC4543] | 361 | AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] | 362 | AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] | 363 +------------------------+------------------+-----------------------+ 365 (IoT) - This requirement is for interoperability with IoT 367 AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The 368 only reason NULL is acceptable is when authenticated encryption 369 algorithms are selected from Section 5. In all other cases, NULL 370 MUST NOT be selected. As ESP and AH both provide authentication, one 371 may be tempted to combine these protocols to provide authentication. 372 As mentioned by RFC7321, it is NOT RECOMMENDED to use ESP with NULL 373 authentication - with non authenticated encryption - in conjunction 374 with AH; some configurations of this combination of services have 375 been shown to be insecure [PD10]. In addition, NULL authentication 376 cannot be combined with ESP NULL encryption. 378 AUTH_HMAC_MD5_96 and AUTH_KPDK_MD5 were not mentioned in RFC7321. As 379 MD5 is known to be vulnerable to collisions, these algorithms MUST 380 NOT be used. 382 AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC7321 to MUST- 383 as there is an industry-wide trend to deprecate its usage. 385 AUTH_DES_MAC was not mentioned in RFC7321. As DES is known to be 386 vulnerable, it MUST NOT be used. 388 AUTH_AES_XCBC_96 is set as SHOULD only in the scope of IoT, as 389 Internet of Things deployments tend to prefer AES based HMAC 390 functions in order to avoid implementing SHA2. For the wide VPN 391 deployment, as it has not been widely adopted, it has been downgraded 392 from SHOULD to MAY. 394 AUTH_AES_128_GMAC status has been downgraded from SHOULD+ to MAY. 395 Along with AUTH_AES_192_GMAC and AUTH_AES_256_GMAC, these algorithms 396 should only be used for AH and not for ESP. If using ENCR_NULL, 397 AUTH_HMAC_SHA2_256_128 is recommended for integrity. If using AES- 398 GMAC in ESP without authentication, ENCR_NULL_AUTH_AES_GMAC is 399 recommended. Therefore, these ciphers are kept at MAY. 401 AUTH_HMAC_SHA2_256_128 was not mentioned in RFC7321, as no SHA2 based 402 authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST be 403 implemented in order to replace AUTH_HMAC_SHA1_96. Note that due to 404 a long standing common implementation bug of this algorithm that 405 truncates the hash at 96-bits instead of 128-bits, it is recommended 406 that implementations prefer AUTH_HMAC_SHA2_512_256 over 407 AUTH_HMAC_SHA2_256_128 if they implement AUTH_HMAC_SHA2_512_256. 409 AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement 410 of AUTH_HMAC_SHA2_256_128 or when stronger security is required. 411 This value has been preferred to AUTH_HMAC_SHA2_384, as the 412 additional overhead of AUTH_HMAC_SHA2_512 is negligible. 414 7. ESP and AH Compression Algorithms 416 +----------------+----------+-------------+ 417 | Name | Status | Comment | 418 +----------------+----------+-------------+ 419 | IPCOMP_OUI | MUST NOT | UNSPECIFIED | 420 | IPCOMP_DEFLATE | MAY | [RFC2393] | 421 | IPCOMP_LZS | MAY | [RFC2395] | 422 | IPCOMP_LZJH | MAY | [RFC3051] | 423 +----------------+----------+-------------+ 425 (IoT) - This requirement is for interoperability with IoT 427 Compression was not mentioned in RFC7321. As it is not widely 428 deployed, it remains optional and at the MAY-level. 430 8. Summary of Changes from RFC 7321 432 The following table summarizes the changes from RFC 7321. 434 RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH AND REPLACE XXXX IN THE 435 TABLE BELOW WITH THE NUMBER OF THIS RFC 437 +-------------------+----------+-----------------+ 438 | Algorithm | RFC 7321 | RFC XXXX | 439 +-------------------+----------+-----------------+ 440 | ENCR_AES_GCM_16 | SHOULD+ | MUST | 441 | ENCR_AES_CCM_8 | MAY | SHOULD | 442 | ENCR_AES_CTR | MAY | (*) | 443 | ENCR_3DES | MAY | SHOULD NOT | 444 | AUTH_HMAC_SHA1_96 | MUST | MUST- | 445 | AUTH_AES_128_GMAC | SHOULD+ | MAY | 446 | AUTH_NONE | MAY | MUST / MUST NOT | 447 +-------------------+----------+-----------------+ 449 (*) This algorithm is not mentioned in the above sections, so it 450 defaults to MAY. 452 9. Acknowledgements 454 Some of the wording in this document was adapted from [RFC7321], the 455 document that this one obsoletes, which was written by D. McGrew and 456 P. Hoffman. 458 10. IANA Considerations 460 This document has no IANA actions. 462 11. Security Considerations 464 The security of a system that uses cryptography depends on both the 465 strength of the cryptographic algorithms chosen and the strength of 466 the keys used with those algorithms. The security also depends on 467 the engineering and administration of the protocol used by the system 468 to ensure that there are no non-cryptographic ways to bypass the 469 security of the overall system. 471 This document concerns itself with the selection of cryptographic 472 algorithms for the use of ESP and AH, specifically with the selection 473 of mandatory-to-implement algorithms. The algorithms identified in 474 this document as "MUST implement" or "SHOULD implement" are not known 475 to be broken at the current time, and cryptographic research to date 476 leads us to believe that they will likely remain secure into the 477 foreseeable future. However, this is not necessarily forever. 479 Therefore, we expect that revisions of that document will be issued 480 from time to time to reflect the current best practice in this area. 482 12. References 484 12.1. Normative References 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, 488 DOI 10.17487/RFC2119, March 1997, 489 . 491 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 492 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 493 December 2005, . 495 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 496 DOI 10.17487/RFC4302, December 2005, 497 . 499 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 500 RFC 4303, DOI 10.17487/RFC4303, December 2005, 501 . 503 [RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm 504 Implementation Requirements and Usage Guidance for 505 Encapsulating Security Payload (ESP) and Authentication 506 Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014, 507 . 509 12.2. Informative References 511 [PD10] Paterson, K. and J. Degabriele, "On the (in)security of 512 IPsec in MAC-then-encrypt configurations (ACM Conference 513 on Computer and Communications Security, ACM CCS)", 2010. 515 [RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP 516 Payload Compression Protocol (IPComp)", RFC 2393, 517 DOI 10.17487/RFC2393, December 1998, 518 . 520 [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using 521 LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998, 522 . 524 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 525 ESP and AH", RFC 2403, DOI 10.17487/RFC2403, November 526 1998, . 528 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 529 ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 530 1998, . 532 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 533 Algorithm With Explicit IV", RFC 2405, 534 DOI 10.17487/RFC2405, November 1998, 535 . 537 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 538 Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, 539 November 1998, . 541 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 542 Algorithms", RFC 2451, DOI 10.17487/RFC2451, November 543 1998, . 545 [RFC3051] Heath, J. and J. Border, "IP Payload Compression Using 546 ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051, 547 January 2001, . 549 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 550 and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566, 551 September 2003, . 553 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 554 Algorithm and Its Use with IPsec", RFC 3602, 555 DOI 10.17487/RFC3602, September 2003, 556 . 558 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 559 (GCM) in IPsec Encapsulating Security Payload (ESP)", 560 RFC 4106, DOI 10.17487/RFC4106, June 2005, 561 . 563 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 564 Mode with IPsec Encapsulating Security Payload (ESP)", 565 RFC 4309, DOI 10.17487/RFC4309, December 2005, 566 . 568 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 569 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 570 DOI 10.17487/RFC4543, May 2006, 571 . 573 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 574 384, and HMAC-SHA-512 with IPsec", RFC 4868, 575 DOI 10.17487/RFC4868, May 2007, 576 . 578 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 579 Kivinen, "Internet Key Exchange Protocol Version 2 580 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 581 2014, . 583 [RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the 584 Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634, 585 DOI 10.17487/RFC7634, August 2015, 586 . 588 Authors' Addresses 590 Daniel Migault 591 Ericsson 592 8400 boulevard Decarie 593 Montreal, QC H4P 2N2 594 Canada 596 Phone: +1 514-452-2160 597 Email: daniel.migault@ericsson.com 599 John Mattsson 600 Ericsson AB 601 SE-164 80 Stockholm 602 Sweden 604 Email: john.mattsson@ericsson.com 606 Paul Wouters 607 Red Hat 609 Email: pwouters@redhat.com 611 Yoav Nir 612 Check Point Software Technologies Ltd. 613 5 Hasolelim st. 614 Tel Aviv 6789735 615 Israel 617 Email: ynir.ietf@gmail.com 618 Tero Kivinen 619 INSIDE Secure 620 Eerikinkatu 28 621 HELSINKI FI-00180 622 FI 624 Email: kivinen@iki.fi