Network Working Group D. Migault
Internet-Draft J. Mattsson
Obsoletes: 7321 (if approved) Ericsson
Intended status: Standards Track P. Wouters
Expires: February 3, 2017 Red Hat
Y. Nir
Check Point
T. Kivinen
INSIDE Secure
August 2, 2016

Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
draft-mglt-ipsecme-rfc7321bis-01

Abstract

This document updates the Cryptographic Algorithm Implementation Requirements for ESP and AH. The goal of these 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 on the cryptographic recommendations only.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any 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 February 3, 2017.

Copyright Notice

Copyright (c) 2016 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) 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

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 with a cryptographic algorithms that are up to date. The challenge of such document is to make sure that over the time 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 evolves continuously. New stronger algorithms appear and existing algorithms are found to be less secure then 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 from high end bulk encryption devices to small low-power 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 main IKEv2 specification 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 or algorithms too weak that are recommended not to be implemented. As a result, any algorithm listed at the IPsec IANA registry not mentioned in this document MAY be implemented. As [RFC7321] omitted most of the algorithms mentioned by the IPsec IANA repository, which makes it difficult to define whether non mentioned algorithms are optional to implement or must not be implemented as they are too weak. This document provides explicit guidance for all of them. It is expected that this document will be updated over time and next versions will only mention algorithms which status has evolved. For clarification 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 as Internet of Things (IoT).

It is expected that deprecation of an algorithm is 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 MUST NOT. Similarly, an algorithm that has not been mentioned as mandatory-to-implement is expected to be introduced with a SHOULD instead of a MUST.

The current trend toward Internet of Things and its adoption of AH/ESP requires this specific use case to be taken into account as well. IoT devices are resource constrained devices and their choice of algorithms are motivated by minimizing the footprint of the code, the computation effort 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 gives implementation recommendations for implementations. The use of algorithms by users is dictated by the security policy requirements for that specific user, and are outside the scope of this document.

The algorithms considered here are listed by the IANA as part of the IKEv2 parameters. IKEv1 is out of scope of this document. IKEv1 is deprecated and the recommendations of this document must not be considered for IKEv1, nor IKEv1 parameters be considered by this document.

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].

Following [RFC4835], we define some additional key words:

MUST-
This term means the same as MUST. However, we expect that at some point in the future this algorithm will no longer be a MUST.
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.

3. 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_RC5 MUST NOT No [RFC2451]
ENCR_IDEA MUST NOT No [RFC2451]
ENCR_CAST MUST 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 Yes [RFC4309][1][IoT]
ENCR_AES_CCM_16 SHOULD Yes [RFC4309][1]
ENCR_AES_GCM_16 MUST Yes [RFC4106][1]
Reserved for IEEE P1619 XTS-AES MUST NOT No [Matt_Ball] Non IPsec
ENCR_CHACHA20_POLY1305 SHOULD Yes [RFC7634]

[1] - This requirement level is for 128-bit keys. 256-bit keys are at SHOULD. 192-bit keys can safely be ignored. [IoT] - This requirement is for interoperability with IoT.

IPsec sessions may have very long life time, and carry multiple packets, so there is a need to move 256-bit keys in the long term. For that purpose requirement level is for 128 bit keys and 256 bit keys are at SHOULD (when applicable). In that sense 256 bit keys status has been raised from MAY in RFC7321 to SHOULD.

IANA has allocated codes for cryptographic algorithms that have not been specified by the IETF. Such algorithms are noted as UNSPECIFIED. Usually, the use of theses algorithms is limited to specific cases, and the absence of specification makes interoperability difficult for IPsec communications. These algorithms were not been mentioned in [RFC7321] and this document clarify that such algorithms MUST NOT be implemented for IPsec communications.

Similarly IANA also allocated code points for algorithms that are not expected to be used to secure IPsec communications. Such algorithms are noted as Non IPsec. As a result, these algorithms MUST NOT be implemented.

Various older and not well tested and never widely implemented ciphers have been changed to MUST NOT.

ENCR_3DES status has been downgraded from MAY in RFC7321 to SHOULD NOT. ENCR_CHACHA20_POLY1305 is a more modern approach alternative for ENCR_3DES than ENCR_AES_CBC and so it expected to be favored to replace ENCR_3DES.

ENCR_NULL status was set to MUST in [RFC7321] and remains a MUST to enable the use of ESP with only authentication which is preferred over AH due to NAT traversal. ENCR_NULL is expected to remain MUST by protocol requirements.

ENCR_AES_CBC status remains to MUST. ENCR_AES_CBC MUST be implemented in order to enable interoperability between implementation that followed RFC7321. However, there is a trend for the industry to move to AEAD encryption, and the overhead of ENCR_AES_CBC remains quite large so it is expected to be replaced by AEAD algorithms in the long term.

ENCR_AES_CTR status was set to MAY [RFC7321], and remains to MAY. ENCR_AES_CTR, does not present specific known vulnerabilities. On the other hand, it is not especially considered for interoperability, and is not AEAD. As a result, it implementation remains optional.

ENCR_AES_CCM_* status was set to MAY in [RFC7321]. ENCR_AES_CCM_8 status has been raised from MAY to SHOULD. This document considers it SHOULD be implemented in order to be able to interact with Internet of Things devices. As this case is not a general use case for VPNs, its status is expected to remain to SHOULD. In addition, as ENCR_AES_CCM_12 and ENCR_AES_CCM_16 are not a general use case for VPNs, their status remains optional and MAY be implemented.

ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order to favor the use of authenticated encryption and AEAD algorithms. The main motivation for adopting ENCR_AES_GCM_* for ESP is performance as well as key longevity compared to for example ENCR_AES_CBC. This resulted in ENCR_AES_GCM_* being widely implemented for ESP. ENCR_AES_GCM_12 or ENCR_AES_GCM_8 are not mentioned in [RFC7321] and their status remains optional and MAY be implemented.

ENCR_NULL_AUTH_AES_GMAC was not mentioned in [RFC7321]. It only provides authentication. As using IPsec for non-encrypted traffic is not current practise, this algorithm remains optional and MAY be implemented.

ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of RFC7321. It has been recommended by the CRFG and others as an alternative to ENCR_AES_XCBC and ENCR_AES_GCM_*. It is also being standardized for IPsec 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.

4. ESP and AH Authentication Algorithms

Encryption without authentication MUST NOT be used. As a result, authentication algorithm recommendations in this section are targeting two types of communications: Firstly authenticated only communications without encryption. Such communications can be ESP with NULL encryption or AH communications. Secondly, communications that are encrypted with non AEAD encryption algorithms mentioned above. In this case, they MUST be combined with an authentication algorithm.

Name Status Comment
AUTH_NONE MUST / MUST NOT [RFC7296] AEAD
AUTH_HMAC_MD5_96 MUST NOT [RFC2403][RFC7296]
AUTH_HMAC_SHA1_96 MUST- [RFC2404][RFC7296]
AUTH_DES_MAC MUST NOT [UNSPECIFIED]
AUTH_KPDK_MD5 MUST NOT [UNSPECIFIED]
AUTH_AES_XCBC_96 SHOULD [RFC3566][RFC7296] [IoT]
AUTH_HMAC_MD5_128 MUST NOT [RFC4595] Non IPsec
AUTH_HMAC_SHA1_160 MUST NOT [RFC4595] Non IPsec
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 with IoT

AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The only reason NULL is acceptable is when authenticated encryption algorithms are selected from Section 3. In any other case, NULL MUST NOT be selected. As ESP and AH provides both authentication, one may be tempted to combine these protocol to provide authentication. As mentioned by RFC7321, it is NOT RECOMMENDED to use ESP with NULL authentication - with non authenticated encryption - in conjunction with AH; some configurations of this combination of services have been shown to be insecure [PD10]. In addition, ESP NULL authentication cannot be combined with ESP NULL encryption.

AUTH_HMAC_MD5_96 and AUTH_KPDK_MD5 were not mentioned in RFC7321. As MD5 is known to be vulnerable to collisions, it MUST NOT be used.

AUTH_HMAC_SHA1_96 status has been downgraded from MUST in RFC7321 to MUST- as there is an industry-wide trend to deprecate its usage.

AUTH_DES_MAC was not mentioned in RFC7321. As DES is known to be vulnerable, it MUST NOT be used.

AUTH_AES_XCBC_96 is only recommended in the scope of IoT, as Internet of Things deployments tend to prefer AES based 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 in RFC4307 to MAY.

AUTH_AES_CMAC_96 was not mentioned in RFC7321. It is not known to be vulnerable, but it has not been widely been used. As a result, its implementation remains optional and it MAY be implemented.

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 not for ESP. If using ENCR_NULL, AUTH_HMAC_SHA2_256_128 is recommended for integrity. If using GMAC without authentication, ENCR_NULL_AUTH_AES_GMAC is recommended. Therefore, these ciphers are kept at MAY.

AUTH_HMAC_SHA2_256_128 was not mentioned in RFC7321, as no SHA2 based authentication was mentioned. AUTH_HMAC_SHA2_256_128 SHOULD be implemented in order to replace AUTH_HMAC_SHA1_96. Note that due to a long standing common implementation bug in this algorithm, it is recommended that implementations prefer AUTH_HMAC_SHA2_512_256 over AUTH_HMAC_SHA2_256_128.

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 overhead of AUTH_HMAC_SHA2_512 is negligible.

5. ESP and AH Compression Algorithms

Name Status Comment
IPCOMP_OUI MUST NOT UNSPECIFIED
IPCOMP_DEFLATE MAY [RFC2393]
IPCOMP_LZS MAY [RFC2395]
IPCOMP_LZJH MAY [RFC3051]

[IoT] - This requirement is for interoperability with IoT

Compression was not mentioned in RFC7321. As it is not widely used, when specified, it remains optional and MAY be implemented.

6. Acknowledgements

7. IANA Considerations

None.

8. Security Considerations

9. References

9.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.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005.
[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.
[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.

9.2. Informative References

[PD10] Paterson, K. and J. Degabriele, "On the (in)security of IPsec in MAC-then-encrypt configurations (ACM Conference on Computer and Communications Security, ACM CCS)", 2010.
[RFC2393] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, DOI 10.17487/RFC2393, December 1998.
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998.
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, DOI 10.17487/RFC2403, November 1998.
[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.
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, DOI 10.17487/RFC2405, November 1998.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, November 1998.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, DOI 10.17487/RFC2451, November 1998.
[RFC3051] Heath, J. and J. Border, "IP Payload Compression Using ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051, January 2001.
[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.
[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.
[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.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, DOI 10.17487/RFC4309, December 2005.
[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.
[RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel Security Association Management Protocol", RFC 4595, DOI 10.17487/RFC4595, July 2006.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, DOI 10.17487/RFC4835, April 2007.
[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.
[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.

Authors' Addresses

Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC , H4P 2N2 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
Paul Wouters Red Hat EMail: pwouters@redhat.com
Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim st. Tel Aviv, 6789735 Israel EMail: ynir.ietf@gmail.com
Tero Kivinen INSIDE Secure Eerikinkatu 28 HELSINKI, FI-00180 FI EMail: kivinen@iki.fi