Network Working GroupInternet Engineering Task Force (IETF) P. WoutersInternet-DraftRequest for Comments: 8221 Red Hat Obsoletes: 7321(if approved)D. MigaultIntended status:Category: Standards Track J. MattssonExpires: December 21, 2017ISSN: 2070-1721 Ericsson Y. Nir Check Point T. KivinenINSIDE Secure June 19,September 2017 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)draft-ietf-ipsecme-rfc7321bis-06Abstract This documentupdates the Cryptographicreplaces "Cryptographic Algorithm Implementation Requirements and Usage Guidance forESPEncapsulating Security Payload (ESP) andAH.Authentication Header (AH)". The goal ofthesethis document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. This document obsoletes RFC 7321. Status of This Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 ofsix monthsRFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 21, 2017.https://www.rfc-editor.org/info/rfc8221. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents(http://trustee.ietf.org/license-info)(https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Updating Algorithm Implementation Requirements and Usage Guidance . . . . . . . . . . . . . . . . . . . . . . . .32 1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3 1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Encryptionmust beMust Be Authenticated . . . . . . . . . . . . . . 5 5. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 6 6. ESP and AH Authentication Algorithms . . . . . . . . . . . . 8 7. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 9 8. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 10 9.Acknowledgements .IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10.IANASecurity Considerations . . . . . . . . . . . . . . . . . . .. .10 11.Security Considerations .References . . . . . . . . . . . . . . . . . .10 12. References. . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 1112.1. Normative11.2. Informative References . . . . . . . . . . . . . . . . ..1112.2. Informative ReferencesAcknowledgements . . . . . . . . . . . . . . . . .11. . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The Encapsulating Security Payload (ESP) [RFC4303] and the Authentication Header (AH) [RFC4302] are the mechanisms for applying cryptographic protection to data being sent over an IPsec Security Association (SA) [RFC4301]. This document provides guidance and recommendations so that ESP and AH can be used withacryptographic algorithms that are up to date. The challenge of suchdocumentdocuments isto makemaking surethatthat, overthe timetime, IPsec implementations can use secure and up-to-date cryptographic algorithms while keeping IPsec interoperable. 1.1. Updating Algorithm Implementation Requirements and Usage Guidance The field of cryptography evolvescontinuously. Newcontinuously: new, stronger algorithmsappearappear, and existing algorithms are found to be less secure than originally thought. Therefore, algorithm implementation requirements and usage guidance need to be updated from time to time to reflect the new reality. The choices for algorithms must be conservative to minimize the risk of algorithm compromise. Algorithms need to be suitable for a wide variety of CPU architectures and device deployments ranging fromhigh endhigh-end bulk encryption devices tosmallsmall, low-powerIoTInternet of Things (IoT) devices. The algorithm implementation requirements and usage guidance may need to change over time to adapt to the changing world. For this reason, the selection of mandatory-to-implement algorithms was removed from the mainIKEv2Internet Key Exchange Protocol Version 2 (IKEv2) specification [RFC7296] and placed in a separate document. 1.2. Updating Algorithm Requirement Levels The mandatory-to-implement algorithm of tomorrow should already be available in most implementations of AH/ESP by the time it is made mandatory. This document attempts to identify and introduce those algorithms for future mandatory-to-implement status. There is no guarantee that the algorithms in use today may become mandatory in the future. Published algorithms are continuously subjected to cryptographic attack and may become too weak or could become completely broken before this document is updated. This document only provides recommendations for the mandatory-to- implement algorithms and "too weak" algorithmstoo weakthat are recommended not to be implemented. As a result, any algorithm listed at the IPsec IANA registry that is not mentioned in this document MAY be implemented. It is expected that this document will be updated over time andnextfuture versions will only mention algorithmswhich status has evolved.that have evolved in status. Forclarificationclarification, when an algorithm has been mentioned in [RFC7321], this document states explicitly the update of the status. Although this document updates the algorithms to keep the AH/ESP communication secure over time, it also aims at providing recommendations so that AH/ESP implementations remain interoperable. AH/ESP interoperability is addressed by an incremental introduction or deprecation of algorithms. In addition, this document also considers the new use cases for AH/ESP deployment, such asInternet of Things (IoT).IoT. It is expected that deprecation of an algorithmisbe performed gradually. This provides time for various implementations to update their implemented algorithms while remaining interoperable. Unless there are strong security reasons, an algorithm is expected to be downgraded from MUST to MUST- or SHOULD, instead of MUSTNOT.NOT (see Section 2). Similarly, an algorithm that has not been mentioned asmandatory-to- implementmandatory-to-implement is expected to be introduced with a SHOULD instead of a MUST. The current trend towardInternet of ThingsIoT and its adoption ofAH/ ESPAH/ESP requires this specific use case to be taken into account as well. IoT devices areresource constrained devicesresource-constrained devices, and their choice of algorithmsareis motivated by minimizing the footprint of the code, the computationefforteffort, and the size of the messages to send. This document indicates "(IoT)" when a specified algorithm is specifically listed for IoT devices. Requirement levels that are marked as "IoT" apply to IoT devices and to server-side implementations that might presumably need to interoperate with them, including any general- purpose VPN gateways. 1.3. Document Audience The recommendations of this document mostly target AH/ESP implementers as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth move to more secure cipher suites. This may differ from a user point of view that may deploy and configure AH/ESP with only the safest cipher suite. This document does not give any recommendations for the use of algorithms, it only givesimplementationrecommendations for implementations. The use of algorithms byusersa specific user is dictated bythetheir own security policyrequirements for that specific user, andrequirements, which are outside the scope of this document. The algorithms considered here are listed bytheIANA as part of the IKEv2 parameters. IKEv1 is out of scope of this document. IKEv1 isdeprecated anddeprecated; the recommendations of this document must not be considered for IKEv1, nor may IKEv1 parameters be considered by this document. The IANA registry forInternet"Internet Key Exchange Version 2 (IKEv2)ParametersParameters" contains some entries that are not for use with ESP or AH. This document does not modify the status of those algorithms. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in[RFC2119].BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. We define some additional terms here: SHOULD+ This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD+ will be promoted at some future time to be a MUST. SHOULD- This term means the same as SHOULD. However, an algorithm marked as SHOULD- may be deprecated to a MAY in a future version of this document. MUST- This term means the same as MUST. However, we expect at some point that this algorithm will no longer be a MUST in a future document. Although its status will be determined at a later time, it is reasonable to expect that if a future revision of a document alters the status of a MUST- algorithm, it will remain at least a SHOULD or a SHOULD- level. IoTstands forThe Internet of Things. 3. Manual Keying ManualKeyingkeying SHOULD NOT beusedused, as it is inherently dangerous. Without any secure keyingprotocolprotocol, suchaas IKE, IPsec does not offer Perfect Forward Secrecy("PFS") protection and(PFS) protection; there is no entity to ensure the refreshing of session keys, the trackingSPI uniquenessof Security Parameter Index (SPI) uniqueness, andensuringthe single use of nonces,IVsInitialization Vectors (IVs), andcounters are never re-used.counters. This document was written for deploying ESP/AH using IKE([RFC7296])[RFC7296] and assumes that keying happens usingIKE version 2IKEv2 or higher. IfManual Keyingmanual keying is used regardless, Counter Mode algorithms such as ENCR_AES_CTR, ENCR_AES_CCM,ENCR_AES_GCMENCR_AES_GCM, and ENCR_CHACHA20_POLY1305 MUST NOT beusedused, as it is incompatible with a secure and persistent handling of thecounter, ascounter (as explained in the Security ConsiderationsSectionsection of[RFC3686].[RFC3686]). This particularly applies to IoT devices that have no state across reboots.As of publication dateAt the time ofthis document,writing, ENCR_AES_CBC is the onlyMandatory-To-Implementmandatory-to-implement encryption algorithm suitable forManual Keying.manual keying. 4. Encryptionmust beMust Be Authenticated Encryption without authentication is not effective and MUST NOT be used. IPsec offers three ways to provide both encryption and authentication: o ESP with anAEADAuthenticated Encryption with Associated Data (AEAD) cipher o ESP with a non-AEAD cipher + authentication o ESP with a non-AEAD cipher + AH with authentication The fastest and most modern method is to use ESP with a combined modeciphercipher, such as an AEADciphercipher, that handles encryption/decryption and authentication in a single step. In this case, the AEAD cipher is set as the encryptionalgorithmalgorithm, and the authentication algorithm is set to none. Examples of this are ENCR_AES_GCM_16 and ENCR_CHACHA20_POLY1305. A more traditional approach is to use ESP with an encryption and an authentication algorithm. This approach is slower, as the data has to be processedtwice,twice: once for encryption/decryption and once for authentication. An example of this is ENCR_AES_CBC combined with AUTH_HMAC_SHA2_512_256. The last method that can be used is ESP+AH. This method is NOT RECOMMENDED. It is the slowest method and also takes up more octets due to the double header ofESP+AH, resultingESP+AH. This results in a smaller effective MTU for the encrypted data. With this method, ESP is only used for confidentiality without an authenticationalgorithmalgorithm, and a second IPsec protocol of type AH is used for authentication. An example of this is ESP with ENCR_AES_CBC with AH with AUTH_HMAC_SHA2_512_256. 5. ESP Encryption Algorithms+-------------------------+-------------+---------+--------------++-------------------------+------------+---------+----------------+ | Name | Status | AEAD | Comment |+-------------------------+-------------+---------+--------------++-------------------------+------------+---------+----------------+ | ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED | | ENCR_DES | MUST NOT | No | [RFC2405] | | ENCR_3DES | SHOULD NOT | No | [RFC2451] | | ENCR_BLOWFISH | MUST NOT | No | [RFC2451] | | ENCR_3IDEA | MUST NOT | No | UNSPECIFIED | | ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED | | ENCR_NULL | MUST | No | [RFC2410] | | ENCR_AES_CBC | MUST | No | [RFC3602][1] | | ENCR_AES_CCM_8 |SHOULD(IoT)SHOULD | Yes |[RFC4309][RFC4309](IoT) | | ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] | | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] |+-------------------------+-------------+---------+--------------++-------------------------+------------+---------+----------------+ [1] - This requirement level is for 128-bit and 256-bit keys. 192-bit keys remain at the MAY level. (IoT) - This requirement is for interoperability with IoT. Only 128-bit keys are at the given level. IPsec sessions may have very longlife time,lifetime and carry multiple packets, so there is a need to move to 256-bit keys in the long term. For thatpurposepurpose, the requirement level for128 bit128-bit keys and256 bit256-bit keysare atis MUST (when applicable). In thatsense 256 bit keyssense, the status for 256-bit keys has been raised from MAY inRFC7321[RFC7321] to MUST. IANA has allocated codes for cryptographic algorithms that have not been specified by the IETF. Such algorithms are noted as UNSPECIFIED. Usually, the use ofthesesthese algorithms is limited to specific cases, and the absence of specification makes interoperability difficult for IPsec communications. These algorithms were notbeenmentioned in[RFC7321][RFC7321], and this documentclarifyclarifies that such algorithms MUST NOT be implemented for IPsec communications.SimilarlySimilarly, IANA also allocated code points for algorithms that are not expected to be used to secure IPsec communications. Such algorithms are noted asNon IPsec.non-IPsec. As a result, these algorithms MUST NOT be implemented. Variousolder andciphers that are older, not welltestedtested, and never widely implementedciphershave been changed to MUST NOT. ENCR_3DES status has been downgraded from MAY inRFC7321[RFC7321] to SHOULD NOT. ENCR_CHACHA20_POLY1305 is a more modern approach and alternative for ENCR_3DES thanENCR_AES_CBCENCR_AES_CBC, and so it is expected to be favored to replace ENCR_3DES. ENCR_BLOWFISH has been downgraded to MUST NOT as it has been deprecated for years by TWOFISH, which is notstandarizedstandardized for ESP and therefore not listed in this document. Some implementations support TWOFISH using a private range number. ENCR_NULL status was set to MUST in [RFC7321] and remains a MUST to enable the use of ESP with onlyauthenticationauthentication, which is preferred over AH due to NAT traversal. ENCR_NULL is expected to remain MUST by protocol requirements. ENCR_AES_CBC status remains at MUST. ENCR_AES_CBC MUST be implemented in order to enable interoperability between implementations that followedRFC7321.[RFC7321]. However, there is a trend for the industry to move to AEAD encryption, and the overhead of ENCR_AES_CBC remains quitelargelarge, so it is expected to be replaced by AEAD algorithms in the long term. ENCR_AES_CCM_8 status was set to MAY in [RFC7321] and has been raised from MAY to SHOULD in order to interact withInternet of ThingsIoT devices. As this case is not a general use case for VPNs, its status is expected to remain as SHOULD. ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order to favor the use of authenticated encryption and AEAD algorithms. ENCR_AES_GCM_16 has been widely implemented for ESP due to its increased performance and key longevity compared to ENCR_AES_CBC. ENCR_CHACHA20_POLY1305 was not ready to be considered at the time ofRFC7321.[RFC7321]. It has been recommended by theCRFGCrypto Forum Research Group (CFRG) and others as an alternative to AES-CBC and AES-GCM.It is also being standardized for ESP for the same reasons.At the time of writing, there are not enough ESP implementations of ENCR_CHACHA20_POLY1305 to be able to introduce it at the SHOULD+ level. Its status has been set to SHOULD and is expected to become MUST in the long term. 6. ESP and AH Authentication Algorithms Authentication algorithm recommendations in this section are targeting two types of communications: oAuthenticated onlyAuthenticated-only communications without encryption, such as ESP with NULL encryption or AH communications. o Communications that are encrypted with a non-AEAD algorithmwhichthat MUST be combined with an authentication algorithm.+------------------------+------------------+-----------------------++------------------------+----------------+-------------------------+ | Name | Status | Comment |+------------------------+------------------+-----------------------++------------------------+----------------+-------------------------+ | AUTH_NONE | MUST / | [RFC7296][RFC5282] | | | MUST NOT |[RFC7296] AEADAEAD-only | | AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] | | AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] | | AUTH_DES_MAC | MUST NOT |[UNSPECIFIED]UNSPECIFIED | | AUTH_KPDK_MD5 | MUST NOT |[UNSPECIFIED]UNSPECIFIED | | AUTH_AES_XCBC_96 | SHOULD / MAY | [RFC3566][RFC7296] | | | | (IoT) | | AUTH_AES_128_GMAC | MAY | [RFC4543] | | AUTH_AES_256_GMAC | MAY | [RFC4543] | | AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] | | AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] |+------------------------+------------------+-----------------------++------------------------+----------------+-------------------------+ (IoT) - This requirement is for interoperability withIoTIoT. AUTH_NONE has been downgraded from MAY inRFC7321[RFC7321] to MUST NOT. The only case where AUTH_NONE is acceptable is when authenticated encryption algorithms are selected from Section 5. In all other cases, AUTH_NONE MUST NOT be selected. As ESP and AH both provide authentication, one may be tempted to combine these protocols to provide authentication. As mentioned byRFC7321,[RFC7321], it is NOT RECOMMENDED to use ESP with NULL authentication- with non(with non- authenticatedencryption -encryption) in conjunction with AH; some configurations of this combination of services have been shown to be insecure [PD10]. In addition, AUTH_NONE authentication cannot be combined with ESP NULL encryption. AUTH_HMAC_MD5_96 and AUTH_KPDK_MD5 were not mentioned inRFC7321.[RFC7321]. As MD5 is known to be vulnerable to collisions, these algorithms MUST NOT be used. AUTH_HMAC_SHA1_96 has been downgraded from MUST inRFC7321[RFC7321] to MUST- as there is an industry-wide trend to deprecate its usage. AUTH_DES_MAC was not mentioned inRFC7321.[RFC7321]. As DES is known to be vulnerable, it MUST NOT be used. AUTH_AES_XCBC_96 is set as SHOULD only in the scope of IoT, asInternet of ThingsIoT deployments tend to preferAES based HMACAES-based Hashed Message Authentication Code (HMAC) functions in order to avoid implementing SHA2. For the wide VPN deployment, as it has not been widely adopted, it has been downgraded from SHOULD to MAY. AUTH_AES_128_GMAC status has been downgraded from SHOULD+ to MAY. Along with AUTH_AES_192_GMAC and AUTH_AES_256_GMAC, these algorithms should only be used for AH and not for ESP. If using ENCR_NULL, AUTH_HMAC_SHA2_256_128 is recommended for integrity. If using AES- GMAC in ESP without authentication, ENCR_NULL_AUTH_AES_GMAC is recommended. Therefore, theseciphersalgorithms are kept at MAY. AUTH_HMAC_SHA2_256_128 was not mentioned inRFC7321,[RFC7321], as noSHA2 basedSHA2-based authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST be implemented in order to replace AUTH_HMAC_SHA1_96. Note that due to a long standing common implementation bug of this algorithm that truncates the hash at96-bits96 bits instead of128-bits,128 bits, it is recommended that implementations prefer AUTH_HMAC_SHA2_512_256 over AUTH_HMAC_SHA2_256_128 if they implement AUTH_HMAC_SHA2_512_256. AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement of AUTH_HMAC_SHA2_256_128 or when stronger security is required. This value has been preferred to AUTH_HMAC_SHA2_384, as the additional overhead of AUTH_HMAC_SHA2_512 is negligible. 7. ESP and AH Compression Algorithms +----------------+----------+-------------+ | Name | Status | Comment | +----------------+----------+-------------+ | IPCOMP_OUI | MUST NOT | UNSPECIFIED | | IPCOMP_DEFLATE | MAY |[RFC2393][RFC3173] | | IPCOMP_LZS | MAY | [RFC2395] | | IPCOMP_LZJH | MAY | [RFC3051] | +----------------+----------+-------------+(IoT) - This requirement is for interoperability with IoTCompression was not mentioned inRFC7321.[RFC7321]. As it is not widely deployed, it remains optional and at theMAY-level.MAY level. 8. Summary of Changes from RFC 7321 The following table summarizes the changes from RFC 7321.RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH AND REPLACE XXXX IN THE TABLE BELOW WITH THE NUMBER OF THIS RFC+-------------------+----------+-----------------+ | Algorithm | RFC 7321 | RFCXXXX8221 | +-------------------+----------+-----------------+ | ENCR_AES_GCM_16 | SHOULD+ | MUST | | ENCR_AES_CCM_8 | MAY | SHOULD | | ENCR_AES_CTR | MAY |(*)MAY(*) | | ENCR_3DES | MAY | SHOULD NOT | | AUTH_HMAC_SHA1_96 | MUST | MUST- | | AUTH_AES_128_GMAC | SHOULD+ | MAY | | AUTH_NONE | MAY | MUST / MUST NOT | +-------------------+----------+-----------------+ (*) This algorithm is not mentioned in the above sections, so it defaults to MAY. 9.Acknowledgements Some of the wording in this document was adapted from [RFC7321], the document that this one obsoletes, which was written by D. McGrew and P. Hoffman. 10.IANA Considerations This documenthas nodoes not require any IANA actions.11.10. Security Considerations The security of a system that uses cryptography depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering and administration of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system. This document concerns itself with the selection of cryptographic algorithms for the use of ESP and AH, specifically with the selection of mandatory-to-implement algorithms. The algorithms identified in this document as "MUST implement" or "SHOULD implement" are not known to be broken at the current time, and cryptographic research to date leads us to believe that they will likely remain secure into the foreseeable future. However, this is not necessarily forever. Therefore, we expect that revisions of that document will be issued from time to time to reflect the current best practice in this area.12.11. References12.1.11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,<http://www.rfc-editor.org/info/rfc2119>.<https://www.rfc-editor.org/info/rfc2119>. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005,<http://www.rfc-editor.org/info/rfc4301>.<https://www.rfc-editor.org/info/rfc4301>. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005,<http://www.rfc-editor.org/info/rfc4302>.<https://www.rfc-editor.org/info/rfc4302>. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005,<http://www.rfc-editor.org/info/rfc4303>.<https://www.rfc-editor.org/info/rfc4303>. [RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014,<http://www.rfc-editor.org/info/rfc7321>. 12.2.<https://www.rfc-editor.org/info/rfc7321>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. 11.2. Informative References [PD10] Paterson, K. and J. Degabriele, "On the (in)security of IPsec in MAC-then-encryptconfigurations (ACMconfigurations", Proceedings of the 17th ACM Conference on Computer and CommunicationsSecurity, ACM CCS)", 2010. [RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393,Security (ACM CCS), DOI10.17487/RFC2393, December 1998, <http://www.rfc-editor.org/info/rfc2393>.10.1145/1866307.1866363, 2010. [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998,<http://www.rfc-editor.org/info/rfc2395>.<https://www.rfc-editor.org/info/rfc2395>. [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, DOI 10.17487/RFC2403, November 1998,<http://www.rfc-editor.org/info/rfc2403>.<https://www.rfc-editor.org/info/rfc2403>. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 1998,<http://www.rfc-editor.org/info/rfc2404>.<https://www.rfc-editor.org/info/rfc2404>. [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, DOI 10.17487/RFC2405, November 1998,<http://www.rfc-editor.org/info/rfc2405>.<https://www.rfc-editor.org/info/rfc2405>. [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, November 1998,<http://www.rfc-editor.org/info/rfc2410>.<https://www.rfc-editor.org/info/rfc2410>. [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, DOI 10.17487/RFC2451, November 1998,<http://www.rfc-editor.org/info/rfc2451>.<https://www.rfc-editor.org/info/rfc2451>. [RFC3051] Heath, J. and J. Border, "IP Payload Compression Using ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051, January 2001,<http://www.rfc-editor.org/info/rfc3051>.<https://www.rfc-editor.org/info/rfc3051>. [RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, DOI 10.17487/RFC3173, September 2001, <https://www.rfc-editor.org/info/rfc3173>. [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566, September 2003,<http://www.rfc-editor.org/info/rfc3566>.<https://www.rfc-editor.org/info/rfc3566>. [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, DOI 10.17487/RFC3602, September 2003,<http://www.rfc-editor.org/info/rfc3602>.<https://www.rfc-editor.org/info/rfc3602>. [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004,<http://www.rfc-editor.org/info/rfc3686>.<https://www.rfc-editor.org/info/rfc3686>. [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, DOI 10.17487/RFC4106, June 2005,<http://www.rfc-editor.org/info/rfc4106>.<https://www.rfc-editor.org/info/rfc4106>. [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, DOI 10.17487/RFC4309, December 2005,<http://www.rfc-editor.org/info/rfc4309>.<https://www.rfc-editor.org/info/rfc4309>. [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, DOI 10.17487/RFC4543, May 2006,<http://www.rfc-editor.org/info/rfc4543>.<https://www.rfc-editor.org/info/rfc4543>. [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007,<http://www.rfc-editor.org/info/rfc4868>.<https://www.rfc-editor.org/info/rfc4868>. [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, DOI 10.17487/RFC5282, August 2008, <https://www.rfc-editor.org/info/rfc5282>. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014,<http://www.rfc-editor.org/info/rfc7296>.<https://www.rfc-editor.org/info/rfc7296>. [RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634, DOI 10.17487/RFC7634, August 2015,<http://www.rfc-editor.org/info/rfc7634>.<https://www.rfc-editor.org/info/rfc7634>. Acknowledgements Some of the wording in this document was adapted from [RFC7321], the document that this one obsoletes, which was written by D. McGrew and P. Hoffman. Authors' Addresses Paul Wouters Red Hat Email: pwouters@redhat.com Daniel Migault Ericsson8400 boulevard Decarie Montreal,8275 Trans Canada Route Saint-Laurent, QCH4P 2N2H4S 0B6 Canada Phone: +1 514-452-2160 Email: daniel.migault@ericsson.com John Mattsson Ericsson AB SE-164 80 Stockholm Sweden Email: john.mattsson@ericsson.com Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelimst.St. Tel Aviv 6789735 Israel Email: ynir.ietf@gmail.com Tero KivinenINSIDE Secure Eerikinkatu 28 HELSINKI FI-00180 FIEmail: kivinen@iki.fi