draft-ietf-ipsecme-rfc7321bis-01.txt   draft-ietf-ipsecme-rfc7321bis-02.txt 
Network Working Group D. Migault Network Working Group D. Migault
Internet-Draft J. Mattsson Internet-Draft J. Mattsson
Obsoletes: 7321 (if approved) Ericsson Obsoletes: 7321 (if approved) Ericsson
Intended status: Standards Track P. Wouters Intended status: Standards Track P. Wouters
Expires: July 12, 2017 Red Hat Expires: August 03, 2017 Red Hat
Y. Nir Y. Nir
Check Point Check Point
T. Kivinen T. Kivinen
INSIDE Secure INSIDE Secure
January 08, 2017 January 30, 2017
Cryptographic Algorithm Implementation Requirements and Usage Guidance Cryptographic Algorithm Implementation Requirements and Usage Guidance
for Encapsulating Security Payload (ESP) and Authentication Header (AH) for Encapsulating Security Payload (ESP) and Authentication Header (AH)
draft-ietf-ipsecme-rfc7321bis-01 draft-ietf-ipsecme-rfc7321bis-02
Abstract Abstract
This document updates the Cryptographic Algorithm Implementation This document updates the Cryptographic Algorithm Implementation
Requirements for ESP and AH. The goal of these document is to enable 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 ESP and AH to benefit from cryptography that is up to date while
making IPsec interoperable. making IPsec interoperable.
This document obsoletes RFC 7321 on the cryptographic recommendations This document obsoletes RFC 7321 on the cryptographic recommendations
only. only.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 9 skipping to change at page 3, line 9
This document provides guidance and recommendations so that ESP and This document provides guidance and recommendations so that ESP and
AH can be used with a cryptographic algorithms that are up to date. 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 The challenge of such document is to make sure that over the time
IPsec implementations can use secure and up-to-date cryptographic IPsec implementations can use secure and up-to-date cryptographic
algorithms while keeping IPsec interoperable. algorithms while keeping IPsec interoperable.
1.1. Updating Algorithm Implementation Requirements and Usage Guidance 1.1. Updating Algorithm Implementation Requirements and Usage Guidance
The field of cryptography evolves continuously. New stronger The field of cryptography evolves continuously. New stronger
algorithms appear and existing algorithms are found to be less secure 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 requirements and usage guidance need to be updated from time to time
to reflect the new reality. The choices for algorithms must be to reflect the new reality. The choices for algorithms must be
conservative to minimize the risk of algorithm compromise. conservative to minimize the risk of algorithm compromise.
Algorithms need to be suitable for a wide variety of CPU Algorithms need to be suitable for a wide variety of CPU
architectures and device deployments ranging from high end bulk architectures and device deployments ranging from high end bulk
encryption devices to small low-power IoT devices. encryption devices to small low-power IoT devices.
The algorithm implementation requirements and usage guidance may need The algorithm implementation requirements and usage guidance may need
to change over time to adapt to the changing world. For this reason, to change over time to adapt to the changing world. For this reason,
the selection of mandatory-to-implement algorithms was removed from the selection of mandatory-to-implement algorithms was removed from
skipping to change at page 3, line 34 skipping to change at page 3, line 34
The mandatory-to-implement algorithm of tomorrow should already be The mandatory-to-implement algorithm of tomorrow should already be
available in most implementations of AH/ESP by the time it is made available in most implementations of AH/ESP by the time it is made
mandatory. This document attempts to identify and introduce those mandatory. This document attempts to identify and introduce those
algorithms for future mandatory-to-implement status. There is no algorithms for future mandatory-to-implement status. There is no
guarantee that the algorithms in use today may become mandatory in guarantee that the algorithms in use today may become mandatory in
the future. Published algorithms are continuously subjected to the future. Published algorithms are continuously subjected to
cryptographic attack and may become too weak or could become cryptographic attack and may become too weak or could become
completely broken before this document is updated. completely broken before this document is updated.
This document only provides recommendations for the mandatory-to- 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 to be implemented. As a result, any algorithm listed at the IPsec
IANA registry not mentioned in this document MAY be implemented. As IANA registry not mentioned in this document MAY be implemented. As
[RFC7321] omitted most of the algorithms mentioned by the IPsec IANA [RFC7321] omitted most of the algorithms mentioned by the IPsec IANA
repository, which makes it difficult to define whether non mentioned repository, which makes it difficult to define whether non mentioned
algorithms are optional to implement or must not be implemented as algorithms are optional to implement or must not be implemented as
they are too weak. This document provides explicit guidance for all they are too weak. This document provides explicit guidance for all
of them. It is expected that this document will be updated over time of them. It is expected that this document will be updated over time
and next versions will only mention algorithms which status has and next versions will only mention algorithms which status has
evolved. For clarification when an algorithm has been mentioned in evolved. For clarification when an algorithm has been mentioned in
[RFC7321], this document states explicitly the update of the status. [RFC7321], this document states explicitly the update of the status.
skipping to change at page 5, line 19 skipping to change at page 5, line 19
Following [RFC4835], we define some additional key words: Following [RFC4835], we define some additional key words:
MUST- This term means the same as MUST. However, we expect that at 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. 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 SHOULD+ This term means the same as SHOULD. However, it is likely
that an algorithm marked as SHOULD+ will be promoted at some that an algorithm marked as SHOULD+ will be promoted at some
future time to be a MUST. future time to be a MUST.
3. Manual Keying 3. Manual Keying
Manual Keying is not be used as it is inherently dangerous. Without Manual Keying is not to be used as it is inherently dangerous.
any keying protocol, it does not offer Perfect Forward Secrecy Without any keying protocol, it does not offer Perfect Forward
("PFS") protection. Deployments tend to never be reconfigured with Secrecy ("PFS") protection. Deployments tend to never be
fresh session keys. It also fails to scale and keeping SPI's unique reconfigured with fresh session keys. It also fails to scale and
amongst many servers is impractical. This document was written for keeping SPI's unique amongst many servers is impractical. This
deploying ESP/AH using IKE (RFC7298) and assumes that keying happens document was written for deploying ESP/AH using IKE (RFC7298) and
using IKEv2. assumes that keying happens using IKEv2.
If manual keying is used anyway, ENCR_AES_CBC MUST be used, and 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 ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be
used as these algorithms require IKE. used as these algorithms require IKE.
4. ESP Encryption Algorithms 4. ESP Encryption Algorithms
+-------------------------+------------+---------+---------------+ +-------------------------+------------+---------+---------------+
| Name | Status | AEAD | Comment | | Name | Status | AEAD | Comment |
+-------------------------+------------+---------+---------------+ +-------------------------+------------+---------+---------------+
skipping to change at page 6, line 13 skipping to change at page 6, line 13
+-------------------------+------------+---------+---------------+ +-------------------------+------------+---------+---------------+
[1] - This requirement level is for 128-bit and 256-bit keys. [1] - This requirement level is for 128-bit and 256-bit keys.
192-bit keys remain at MAY level. [IoT] - This requirement is for 192-bit keys remain at MAY level. [IoT] - This requirement is for
interoperability with IoT. Only 128-bit keys are at MUST level. interoperability with IoT. Only 128-bit keys are at MUST level.
192-bit and 256-bit keys are at the MAY level. 192-bit and 256-bit keys are at the MAY level.
Table 1 Table 1
IPsec sessions may have very long life time, and carry multiple 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. packets, so there is a need to move to 256-bit keys in the long term.
For that purpose requirement level is for 128 bit keys and 256 bit For that purpose the requirement level for 128 bit keys and 256 bit
keys are at SHOULD (when applicable). In that sense 256 bit keys keys are at MUST (when applicable). In that sense 256 bit keys
status has been raised from MAY in RFC7321 to SHOULD. status has been raised from MAY in RFC7321 to MUST.
IANA has allocated codes for cryptographic algorithms that have not IANA has allocated codes for cryptographic algorithms that have not
been specified by the IETF. Such algorithms are noted as been specified by the IETF. Such algorithms are noted as
UNSPECIFIED. Usually, the use of theses algorithms is limited to UNSPECIFIED. Usually, the use of theses algorithms is limited to
specific cases, and the absence of specification makes specific cases, and the absence of specification makes
interoperability difficult for IPsec communications. These interoperability difficult for IPsec communications. These
algorithms were not been mentioned in [RFC7321] and this document algorithms were not been mentioned in [RFC7321] and this document
clarify that such algorithms MUST NOT be implemented for IPsec clarify that such algorithms MUST NOT be implemented for IPsec
communications. communications.
skipping to change at page 6, line 42 skipping to change at page 6, line 42
Various older and not well tested and never widely implemented Various older and not well tested and never widely implemented
ciphers have been changed to MUST NOT. ciphers have been changed to MUST NOT.
ENCR_3DES status has been downgraded from MAY in RFC7321 to SHOULD ENCR_3DES status has been downgraded from MAY in RFC7321 to SHOULD
NOT. ENCR_CHACHA20_POLY1305 is a more modern approach alternative 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 for ENCR_3DES than ENCR_AES_CBC and so it expected to be favored to
replace ENCR_3DES. replace ENCR_3DES.
ENCR_BLOWFISH has been downgraded to MUST NOT as it has been ENCR_BLOWFISH has been downgraded to MUST NOT as it has been
deprecated for years by TWOFISH, which is not standarized for ESP and 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. TWOFISH using a private range number.
ENCR_NULL status was set to MUST in [RFC7321] and remains a MUST to 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 enable the use of ESP with only authentication which is preferred
over AH due to NAT traversal. ENCR_NULL is expected to remain MUST over AH due to NAT traversal. ENCR_NULL is expected to remain MUST
by protocol requirements. 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 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 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 ENCR_AES_CBC remains quite large so it is expected to be replaced by
AEAD algorithms in the long term. AEAD algorithms in the long term.
ENCR_AES_CCM_8 status was set to MAY in [RFC7321] and has been raised 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 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 devices. As this case is not a general use case for VPNs, its status
is expected to remain as SHOULD. is expected to remain as SHOULD.
ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order
skipping to change at page 8, line 12 skipping to change at page 8, line 12
| AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] | | AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] |
| AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] | | AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] |
+----------------------------+-------------+------------------------+ +----------------------------+-------------+------------------------+
[IoT] - This requirement is for interoperability with IoT [IoT] - This requirement is for interoperability with IoT
Table 2 Table 2
AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The
only reason NULL is acceptable is when authenticated encryption only reason NULL is acceptable is when authenticated encryption
algorithms are selected from Section 4. In all other case, NULL MUST algorithms are selected from Section 4. In all other cases, NULL
NOT be selected. As ESP and AH provides both authentication, one may MUST NOT be selected. As ESP and AH both provides authentication,
be tempted to combine these protocol to provide authentication. As one may be tempted to combine these protocols to provide
mentioned by RFC7321, it is NOT RECOMMENDED to use ESP with NULL authentication. As mentioned by RFC7321, it is NOT RECOMMENDED to
authentication - with non authenticated encryption - in conjunction use ESP with NULL authentication - with non authenticated encryption
with AH; some configurations of this combination of services have - in conjunction with AH; some configurations of this combination of
been shown to be insecure [PD10]. In addition, NULL authentication services have been shown to be insecure [PD10]. In addition, NULL
cannot be combined with ESP NULL encryption. authentication cannot be combined with ESP NULL encryption.
AUTH_HMAC_MD5_96 and AUTH_KPDK_MD5 were not mentioned in RFC7321. As 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 MD5 is known to be vulnerable to collisions, these algorithms MUST
NOT be used. NOT be used.
AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC7321 to MUST- AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC7321 to MUST-
as there is an industry-wide trend to deprecate its usage. 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 AUTH_DES_MAC was not mentioned in RFC7321. As DES is known to be
vulnerable, it MUST NOT be used. vulnerable, it MUST NOT be used.
AUTH_AES_XCBC_96 is only recommended in the scope of IoT, as Internet AUTH_AES_XCBC_96 is set as SHOULD only in the scope of IoT, as
of Things deployments tend to prefer AES based HMAC functions in Internet of Things deployments tend to prefer AES based HMAC
order to avoid implementing SHA2. For the wide VPN deployment, as it functions in order to avoid implementing SHA2. For the wide VPN
has not been widely adopted, it has been downgraded from SHOULD to deployment, as it has not been widely adopted, it has been downgraded
MAY. from SHOULD to MAY.
AUTH_AES_128_GMAC status 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 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, 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 GMAC AUTH_HMAC_SHA2_256_128 is recommended for integrity. If using AES-
without authentication, ENCR_NULL_AUTH_AES_GMAC is recommended. GMAC in ESP without authentication, ENCR_NULL_AUTH_AES_GMAC is
Therefore, these ciphers are kept at MAY. recommended. Therefore, these ciphers are kept at MAY.
AUTH_HMAC_SHA2_256_128 was not mentioned in RFC7321, as no SHA2 based AUTH_HMAC_SHA2_256_128 was not mentioned in RFC7321, as no SHA2 based
authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST be authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST be
implemented in order to replace AUTH_HMAC_SHA1_96. Note that due to implemented in order to replace AUTH_HMAC_SHA1_96. Note that due to
a long standing common implementation bug of this algorithm that a long standing common implementation bug of this algorithm that
truncates the hash at 96-bits instead of 128-bits, it is recommended truncates the hash at 96-bits instead of 128-bits, it is recommended
that implementations prefer AUTH_HMAC_SHA2_512_256 over 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_256_128 if they implement AUTH_HMAC_SHA2_512_256.
AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement
 End of changes. 14 change blocks. 
37 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/