draft-ietf-ipsecme-rfc4307bis-13.txt   draft-ietf-ipsecme-rfc4307bis-14.txt 
Network Working Group Y. Nir Network Working Group Y. Nir
Internet-Draft Check Point Internet-Draft Check Point
Obsoletes: 4307 (if approved) T. Kivinen Obsoletes: 4307 (if approved) T. Kivinen
Updates: 7296 (if approved) INSIDE Secure Updates: 7296 (if approved) INSIDE Secure
Intended status: Standards Track P. Wouters Intended status: Standards Track P. Wouters
Expires: March 16, 2017 Red Hat Expires: March 26, 2017 Red Hat
D. Migault D. Migault
Ericsson Ericsson
September 12, 2016 September 22, 2016
Algorithm Implementation Requirements and Usage Guidance for IKEv2 Algorithm Implementation Requirements and Usage Guidance for IKEv2
draft-ietf-ipsecme-rfc4307bis-13 draft-ietf-ipsecme-rfc4307bis-14
Abstract Abstract
The IPsec series of protocols makes use of various cryptographic The IPsec series of protocols makes use of various cryptographic
algorithms in order to provide security services. The Internet Key algorithms in order to provide security services. The Internet Key
Exchange (IKE) protocol is used to negotiate the IPsec Security Exchange (IKE) protocol is used to negotiate the IPsec Security
Association (IPsec SA) parameters, such as which algorithms should be Association (IPsec SA) parameters, such as which algorithms should be
used. To ensure interoperability between different implementations, used. To ensure interoperability between different implementations,
it is necessary to specify a set of algorithm implementation it is necessary to specify a set of algorithm implementation
requirements and usage guidance to ensure that there is at least one requirements and usage guidance to ensure that there is at least one
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 March 16, 2017. This Internet-Draft will expire on March 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 6, line 18 skipping to change at page 6, line 18
| ENCR_AES_CBC | MUST | No | (1) | | ENCR_AES_CBC | MUST | No | (1) |
| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | | | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | |
| ENCR_AES_GCM_16 | SHOULD | Yes | (1) | | ENCR_AES_GCM_16 | SHOULD | Yes | (1) |
| ENCR_AES_CCM_8 | SHOULD | Yes | (IoT) | | ENCR_AES_CCM_8 | SHOULD | Yes | (IoT) |
| ENCR_3DES | MAY | No | | | ENCR_3DES | MAY | No | |
| ENCR_DES | MUST NOT | No | | | ENCR_DES | MUST NOT | No | |
+------------------------+----------+-------+---------+ +------------------------+----------+-------+---------+
(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 SHOULD level.
192-bit and 256-bit keys are at the MAY level. 192-bit and 256-bit remain at the MAY level.
ENCR_AES_CBC is raised from SHOULD+ in [RFC4307] to MUST. It is the ENCR_AES_CBC is raised from SHOULD+ for 128-bit keys and MAY for
only shared mandatory-to-implement algorithm with RFC4307 and as a 256-bit keys in [RFC4307] to MUST. 192-bit keys remain at the MAY
result it is necessary for interoperability with IKEv2 implementation level. ENCR_AES_CBC is the only shared mandatory-to-implement
compatible with RFC4307. algorithm with RFC4307 and as a result it is necessary for
interoperability with IKEv2 implementation compatible with RFC4307.
ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of
RFC4307. It has been recommended by the CRFG and others as an RFC4307. It has been recommended by the CRFG as an alternative to
alternative to AES-CBC and AES-GCM. It is also being standardized AES-CBC and AES-GCM. It is also being standardized for IPsec for the
for IPsec for the same reasons. At the time of writing, there were same reasons. At the time of writing, there were not enough IKEv2
not enough IKEv2 implementations supporting ENCR_CHACHA20_POLY1305 to implementations supporting ENCR_CHACHA20_POLY1305 to be able to
be able to introduce it at the SHOULD+ level. introduce it at the SHOULD+ level.
ENCR_AES_GCM_16 was not considered in RFC4307. At the time RFC4307 ENCR_AES_GCM_16 was not considered in RFC4307. At the time RFC4307
was written, AES-GCM was not defined in an IETF document. AES-GCM was written, AES-GCM was not defined in an IETF document. AES-GCM
was defined for ESP in [RFC4106] and later for IKEv2 in [RFC5282]. was defined for ESP in [RFC4106] and later for IKEv2 in [RFC5282].
The main motivation for adopting AES-GCM for ESP is encryption The main motivation for adopting AES-GCM for ESP is encryption
performance and key longevity compared to AES-CBC. This resulted in performance and key longevity compared to AES-CBC. This resulted in
AES-GCM being widely implemented for ESP. As the computation load of AES-GCM being widely implemented for ESP. As the computation load of
IKEv2 is relatively small compared to ESP, many IKEv2 implementations IKEv2 is relatively small compared to ESP, many IKEv2 implementations
have not implemented AES-GCM. For this reason, AES-GCM is not have not implemented AES-GCM. For this reason, AES-GCM is not
promoted to a greater status than SHOULD. The reason for promotion promoted to a greater status than SHOULD. The reason for promotion
skipping to change at page 6, line 52 skipping to change at page 7, line 4
from MAY to SHOULD is to promote the slightly more secure AEAD method from MAY to SHOULD is to promote the slightly more secure AEAD method
over the traditional encrypt+auth method. Its status is expected to over the traditional encrypt+auth method. Its status is expected to
be raised once widely implemented. As the advantage of the shorter be raised once widely implemented. As the advantage of the shorter
(and weaker) ICVs is minimal, the 8 and 12 octet ICV's remain at the (and weaker) ICVs is minimal, the 8 and 12 octet ICV's remain at the
MAY level. MAY level.
ENCR_AES_CCM_8 was not considered in RFC4307. This document ENCR_AES_CCM_8 was not considered in RFC4307. This document
considers it as SHOULD be implemented in order to be able to interact considers it as SHOULD be implemented in order to be able to interact
with Internet of Things devices. As this case is not a general use with Internet of Things devices. As this case is not a general use
case for non-IoT VPNs, its status is expected to remain as SHOULD. case for non-IoT VPNs, its status is expected to remain as SHOULD.
The 8 octet size of the ICV is expected to be sufficient for most use The 8 octet size of the ICV is expected to be sufficient for most use
cases of IKEv2, as far less packets are exchanged on those cases, and cases of IKEv2, as far less packets are exchanged on those cases, and
IoT devices want to make packets as small as possible. When IoT devices want to make packets as small as possible. The SHOULD
implemented, ENCR_AES_CCM_8 MUST be implemented for key length 128 level is for 128-bit keys, 256-bit keys remains at MAY level.
and MAY be implemented for key length 256.
ENCR_3DES has been downgraded from RFC4307 MUST- to SHOULD NOT. All ENCR_3DES has been downgraded from RFC4307 MUST- to SHOULD NOT. All
IKEv2 implementation already implement ENCR_AES_CBC, so there is no IKEv2 implementation already implement ENCR_AES_CBC, so there is no
need to keep support for the much slower ENCR_3DES. In addition, need to keep support for the much slower ENCR_3DES. In addition,
ENCR_CHACHA20_POLY1305 provides a more modern alternative to AES. ENCR_CHACHA20_POLY1305 provides a more modern alternative to AES.
ENCR_DES can be brute-forced using of-the-shelves hardware. It ENCR_DES can be brute-forced using of-the-shelves hardware. It
provides no meaningful security whatsoever and therefor MUST NOT be provides no meaningful security whatsoever and therefor MUST NOT be
implemented. implemented.
3.2. Type 2 - IKEv2 Pseudo-random Function Transforms 3.2. Type 2 - IKEv2 Pseudo-random Function Transforms
Transform Type 2 algorithms are pseudo-random functions used to Transform Type 2 algorithms are pseudo-random functions used to
generate pseudo-random values when needed. generate pseudo-random values when needed.
If an algorithm is selected as the integrity algorithm, it SHOULD
also be used as the PRF. When using an AEAD cipher, a choice of PRF
needs to be made. The table below lists the recommended algorithms.
+-------------------+----------+---------+ +-------------------+----------+---------+
| Name | Status | Comment | | Name | Status | Comment |
+-------------------+----------+---------+ +-------------------+----------+---------+
| PRF_HMAC_SHA2_256 | MUST | | | PRF_HMAC_SHA2_256 | MUST | |
| PRF_HMAC_SHA2_512 | SHOULD+ | | | PRF_HMAC_SHA2_512 | SHOULD+ | |
| PRF_HMAC_SHA1 | MUST- | | | PRF_HMAC_SHA1 | MUST- | |
| PRF_AES128_XCBC | SHOULD | (IoT) | | PRF_AES128_XCBC | SHOULD | (IoT) |
| PRF_HMAC_MD5 | MUST NOT | | | PRF_HMAC_MD5 | MUST NOT | |
+-------------------+----------+---------+ +-------------------+----------+---------+
(IoT) - This requirement is for interoperability with IoT (IoT) - This requirement is for interoperability with IoT
PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2 based As no SHA2 based transforms were referenced in RFC4307,
transforms were mentioned. PRF_HMAC_SHA2_256 MUST be implemented in PRF_HMAC_SHA2_256 was not mentioned in RFC4307. PRF_HMAC_SHA2_256
order to replace SHA1 and PRF_HMAC_SHA1. MUST be implemented in order to replace SHA1 and PRF_HMAC_SHA1.
PRF_HMAC_SHA2_512 SHOULD be implemented as a future replacement for PRF_HMAC_SHA2_512 SHOULD be implemented as a future replacement for
PRF_HMAC_SHA2_256 or when stronger security is required. PRF_HMAC_SHA2_256 or when stronger security is required.
PRF_HMAC_SHA2_512 is preferred over PRF_HMAC_SHA2_384, as the PRF_HMAC_SHA2_512 is preferred over PRF_HMAC_SHA2_384, as the
additional overhead of PRF_HMAC_SHA2_512 is negligible. additional overhead of PRF_HMAC_SHA2_512 is negligible.
PRF_HMAC_SHA1 has been downgraded from MUST in RFC4307 to MUST- as PRF_HMAC_SHA1 has been downgraded from MUST in RFC4307 to MUST- as
their is an industry-wide trend to deprecate its usage. cryptographic attacks against SHA1 are increasing, resulting in an
industry-wide trend to deprecate its usage
PRF_AES128_XCBC is only recommended in the scope of IoT, as Internet PRF_AES128_XCBC is only recommended in the scope of IoT, as Internet
of Things deployments tend to prefer AES based pseudo-random of Things deployments tend to prefer AES based pseudo-random
functions in order to avoid implementing SHA2. For the non-IoT VPN functions in order to avoid implementing SHA2. For the non-IoT VPN
deployment it has been downgraded from SHOULD in RFC4307 to MAY as it deployment it has been downgraded from SHOULD in RFC4307 to MAY as it
has not seen wide adoption. has not seen wide adoption.
PRF_HMAC_MD5 has been downgraded from MAY in RFC4307 to MUST NOT. PRF_HMAC_MD5 has been downgraded from MAY in RFC4307 to MUST NOT.
There is an industry-wide trend to deprecate its usage as MD5 support Cryptographic attacks against MD5, such as collision attacks
is being removed from cryptographic libraries in general because its mentioned in [TRANSCRIPTION], are resulting in an industry-wide trend
non-HMAC use is known to be subject to collision attacks, for example to deprecate and remove MD5 (and thus HMAC-MD5) from cryptographic
as mentioned in [TRANSCRIPTION]. libraries.
3.3. Type 3 - IKEv2 Integrity Algorithm Transforms 3.3. Type 3 - IKEv2 Integrity Algorithm Transforms
The algorithms in the below table are negotiated in the SA payload The algorithms in the below table are negotiated in the SA payload
and used for the Encrypted Payload. References to the specification and used for the Encrypted Payload. References to the specification
defining these algorithms are in the IANA registry. When an AEAD defining these algorithms are in the IANA registry. When an AEAD
algorithm (see Section 3.1) is proposed, this algorithm transform algorithm (see Section 3.1) is proposed, this algorithm transform
type is not in use. type is not in use.
+------------------------+----------+---------+ +------------------------+----------+---------+
skipping to change at page 8, line 49 skipping to change at page 8, line 45
AUTH_HMAC_SHA2_256_128 was not mentioned in RFC4307, as no SHA2 based AUTH_HMAC_SHA2_256_128 was not mentioned in RFC4307, as no SHA2 based
transforms were mentioned. AUTH_HMAC_SHA2_256_128 MUST be transforms were mentioned. AUTH_HMAC_SHA2_256_128 MUST be
implemented in order to replace AUTH_HMAC_SHA1_96. implemented in order to replace AUTH_HMAC_SHA1_96.
AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement
of AUTH_HMAC_SHA2_256_128 or when stronger security is required. of AUTH_HMAC_SHA2_256_128 or when stronger security is required.
This value has been preferred over AUTH_HMAC_SHA2_384, as the This value has been preferred over AUTH_HMAC_SHA2_384, as the
additional overhead of AUTH_HMAC_SHA2_512 is negligible. additional overhead of AUTH_HMAC_SHA2_512 is negligible.
AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307 to MUST- AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307 to MUST-
as there is an industry-wide trend to deprecate its usage. as cryptographic attacks against SHA1 are increasing, resulting in an
industry-wide trend to deprecate its usage
AUTH_AES-XCBC is only recommended in the scope of IoT, as Internet of AUTH_AES_XCBC_96 is only recommended in the scope of IoT, as Internet
Things deployments tend to prefer AES based pseudo-random functions of Things deployments tend to prefer AES based pseudo-random
in order to avoid implementing SHA2. For the non-IoT VPN deployment, functions in order to avoid implementing SHA2. For the non-IoT VPN
it has been downgraded from SHOULD in RFC4307 to MAY as it has not deployment, it has been downgraded from SHOULD in RFC4307 to MAY as
been widely adopted. it has not been widely adopted.
AUTH_DES_MAC, AUTH_HMAC_MD5_96, and AUTH_KPDK_MD5 were not mentioned AUTH_DES_MAC, AUTH_HMAC_MD5_96, and AUTH_KPDK_MD5 were not mentioned
in RFC4307 so their default status ware MAY. They have been in RFC4307 so their default status ware MAY. They have been
downgraded to MUST NOT. There is an industry-wide trend to deprecate downgraded to MUST NOT. There is an industry-wide trend to deprecate
DES and MD5. MD5 support is being removed from cryptographic DES and MD5. MD5 support is being removed from cryptographic
libraries in general because its non-HMAC use is known to be subject libraries in general because its non-HMAC use is known to be subject
to collision attacks, for example as mentioned in [TRANSCRIPTION]. to collision attacks, for example as mentioned in [TRANSCRIPTION].
3.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms 3.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms
skipping to change at page 10, line 6 skipping to change at page 10, line 6
| | Order Subgroup | | | | Order Subgroup | |
| 24 | 2048-bit MODP Group with 256-bit Prime | SHOULD NOT | | 24 | 2048-bit MODP Group with 256-bit Prime | SHOULD NOT |
| | Order Subgroup | | | | Order Subgroup | |
+--------+---------------------------------------------+------------+ +--------+---------------------------------------------+------------+
Group 14 or 2048-bit MODP Group is raised from SHOULD+ in RFC4307 as Group 14 or 2048-bit MODP Group is raised from SHOULD+ in RFC4307 as
a replacement for 1024-bit MODP Group. Group 14 is widely a replacement for 1024-bit MODP Group. Group 14 is widely
implemented and considered secure. implemented and considered secure.
Group 19 or 256-bit random ECP group was not specified in RFC4307, as Group 19 or 256-bit random ECP group was not specified in RFC4307, as
this group were not specified at that time. Group 19 is widely this group were not defined at that time. Group 19 is widely
implemented and considered secure. implemented and considered secure.
Group 5 or 1536-bit MODP Group has been downgraded from MAY in Group 5 or 1536-bit MODP Group has been downgraded from MAY in
RFC4307 to SHOULD NOT. It was specified earlier, but is now RFC4307 to SHOULD NOT. It was specified earlier, but is now
considered to be vulnerable to be broken within the next few years by considered to be vulnerable to be broken within the next few years by
a nation state level attack, so its security margin is considered too a nation state level attack, so its security margin is considered too
narrow. narrow.
Group 2 or 1024-bit MODP Group has been downgraded from MUST- in Group 2 or 1024-bit MODP Group has been downgraded from MUST- in
RFC4307 to SHOULD NOT. It is known to be weak against sufficiently RFC4307 to SHOULD NOT. It is known to be weak against sufficiently
skipping to change at page 13, line 30 skipping to change at page 13, line 30
only if Digital Signature authentication method is implemented. only if Digital Signature authentication method is implemented.
+------------------------------------+----------+---------+ +------------------------------------+----------+---------+
| Description | Status | Comment | | Description | Status | Comment |
+------------------------------------+----------+---------+ +------------------------------------+----------+---------+
| RSASSA-PSS with SHA-256 | MUST | | | RSASSA-PSS with SHA-256 | MUST | |
| ecdsa-with-sha256 | SHOULD | | | ecdsa-with-sha256 | SHOULD | |
| sha1WithRSAEncryption | MUST NOT | | | sha1WithRSAEncryption | MUST NOT | |
| dsa-with-sha1 | MUST NOT | | | dsa-with-sha1 | MUST NOT | |
| ecdsa-with-sha1 | MUST NOT | | | ecdsa-with-sha1 | MUST NOT | |
| RSASSA-PSS with Empty Parameters | MUST NOT | | | RSASSA-PSS with Empty Parameters | MUST NOT | (*) |
| RSASSA-PSS with Default Parameters | MUST NOT | | | RSASSA-PSS with Default Parameters | MUST NOT | (*) |
+------------------------------------+----------+---------+ +------------------------------------+----------+---------+
(*) Empty or Default parameters means it is using SHA1, which is at
level MUST NOT.
5. Algorithms for Internet of Things 5. Algorithms for Internet of Things
Some algorithms in this document are marked for use with the Internet Some algorithms in this document are marked for use with the Internet
of Things (IoT). There are several reasons why IoT devices prefer a of Things (IoT). There are several reasons why IoT devices prefer a
different set of algorithms from regular IKEv2 clients. IoT devices different set of algorithms from regular IKEv2 clients. IoT devices
are usually very constrained, meaning the memory size and CPU power are usually very constrained, meaning the memory size and CPU power
is so limited, that these clients only have resources to implement is so limited, that these clients only have resources to implement
and run one set of algorithms. For example, instead of implementing and run one set of algorithms. For example, instead of implementing
AES and SHA, these devices typically use AES_XCBC as integrity AES and SHA, these devices typically use AES_XCBC as integrity
algorithm so SHA does not need to be implemented. algorithm so SHA does not need to be implemented.
 End of changes. 18 change blocks. 
39 lines changed or deleted 41 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/