--- 1/draft-ietf-ipsecme-rfc7321bis-01.txt 2017-01-30 18:13:08.922296023 -0800 +++ 2/draft-ietf-ipsecme-rfc7321bis-02.txt 2017-01-30 18:13:08.954296781 -0800 @@ -1,25 +1,25 @@ Network Working Group D. Migault Internet-Draft J. Mattsson Obsoletes: 7321 (if approved) Ericsson Intended status: Standards Track P. Wouters -Expires: July 12, 2017 Red Hat +Expires: August 03, 2017 Red Hat Y. Nir Check Point T. Kivinen INSIDE Secure - January 08, 2017 + January 30, 2017 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) - draft-ietf-ipsecme-rfc7321bis-01 + draft-ietf-ipsecme-rfc7321bis-02 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. @@ -32,21 +32,21 @@ 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 July 12, 2017. + This Internet-Draft will expire on August 03, 2017. 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) in effect on the date of publication of this document. Please review these documents @@ -87,21 +87,21 @@ 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 + 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 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 @@ -112,21 +112,21 @@ 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 + implement algorithms and 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. @@ -194,27 +194,27 @@ 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. Manual Keying - Manual Keying is not be used as it is inherently dangerous. Without - any keying protocol, it does not offer Perfect Forward Secrecy - ("PFS") protection. Deployments tend to never be reconfigured with - fresh session keys. It also fails to scale and keeping SPI's unique - amongst many servers is impractical. This document was written for - deploying ESP/AH using IKE (RFC7298) and assumes that keying happens - using IKEv2. + Manual Keying is not to be used as it is inherently dangerous. + Without any keying protocol, it does not offer Perfect Forward + Secrecy ("PFS") protection. Deployments tend to never be + reconfigured with fresh session keys. It also fails to scale and + keeping SPI's unique amongst many servers is impractical. This + document was written for deploying ESP/AH using IKE (RFC7298) and + assumes that keying happens using IKEv2. If manual keying is used anyway, ENCR_AES_CBC MUST be used, and ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be used as these algorithms require IKE. 4. ESP Encryption Algorithms +-------------------------+------------+---------+---------------+ | Name | Status | AEAD | Comment | +-------------------------+------------+---------+---------------+ @@ -232,24 +232,24 @@ +-------------------------+------------+---------+---------------+ [1] - This requirement level is for 128-bit and 256-bit keys. 192-bit keys remain at MAY level. [IoT] - This requirement is for interoperability with IoT. Only 128-bit keys are at MUST level. 192-bit and 256-bit keys are at the MAY level. Table 1 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. + packets, so there is a need to move to 256-bit keys in the long term. + For that purpose the requirement level for 128 bit keys and 256 bit + keys are at MUST (when applicable). In that sense 256 bit keys + status has been raised from MAY in 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 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. @@ -261,31 +261,31 @@ 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_BLOWFISH has been downgraded to MUST NOT as it has been deprecated for years by TWOFISH, which is not standarized for ESP and - therefor not listed in this document. Some implementations support + 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 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 + ENCR_AES_CBC status remains at MUST. ENCR_AES_CBC MUST be implemented in order to enable interoperability between - implementation that followed RFC7321. However, there is a trend for + implementations 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_CCM_8 status was set to MAY in [RFC7321] and has been raised from MAY to SHOULD in order to interact with Internet of Things 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 @@ -328,51 +328,51 @@ | AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] | | AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] | +----------------------------+-------------+------------------------+ [IoT] - This requirement is for interoperability with IoT Table 2 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 4. In all 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, NULL authentication - cannot be combined with ESP NULL encryption. + algorithms are selected from Section 4. In all other cases, NULL + MUST NOT be selected. As ESP and AH both provides authentication, + one may be tempted to combine these protocols 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, 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, these algorithms MUST NOT be used. AUTH_HMAC_SHA1_96 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 to - MAY. + AUTH_AES_XCBC_96 is set as SHOULD only 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 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 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. + 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, 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 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 at 96-bits instead of 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