draft-ietf-ipsecme-rfc4307bis-17.txt   draft-ietf-ipsecme-rfc4307bis-18.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: August 20, 2017 Red Hat Expires: September 30, 2017 Red Hat
D. Migault D. Migault
Ericsson Ericsson
February 16, 2017 March 29, 2017
Algorithm Implementation Requirements and Usage Guidance for IKEv2 Algorithm Implementation Requirements and Usage Guidance for IKEv2
draft-ietf-ipsecme-rfc4307bis-17 draft-ietf-ipsecme-rfc4307bis-18
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 August 20, 2017. This Internet-Draft will expire on September 30, 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 5, line 13 skipping to change at page 5, line 13
computation effort and the size of the messages to send. This computation effort and the size of the messages to send. This
document indicates "(IoT)" when a specified algorithm is specifically document indicates "(IoT)" when a specified algorithm is specifically
listed for IoT devices. Requirement levels that are marked as "IoT" listed for IoT devices. Requirement levels that are marked as "IoT"
apply to IoT devices and to server-side implementations that might apply to IoT devices and to server-side implementations that might
presumably need to interoperate with them, including any general- presumably need to interoperate with them, including any general-
purpose VPN gateways. purpose VPN gateways.
1.4. Document Audience 1.4. Document Audience
The recommendations of this document mostly target IKEv2 implementers The recommendations of this document mostly target IKEv2 implementers
as implementations need to meet both high security expectations as who need to create implementations that meet both high security
well as high interoperability between various vendors and with expectations as well as high interoperability between various vendors
different versions. Interoperability requires a smooth move to more and with different versions. Interoperability requires a smooth move
secure cipher suites. This may differ from a user point of view that to more secure cipher suites. This may differ from a user point of
may deploy and configure IKEv2 with only the safest cipher suite. view that may deploy and configure IKEv2 with only the safest cipher
suite.
This document does not give any recommendations for the use of This document does not give any recommendations for the use of
algorithms, it only gives implementation recommendations for algorithms, it only gives implementation recommendations regarding
implementations. The use of algorithms by users is dictated by the implementations. The use of algorithms by users is dictated by the
security policy requirements for that specific user, and are outside security policy requirements for that specific user, and are outside
the scope of this document. the scope of this document.
IKEv1 is out of scope of this document. IKEv1 is deprecated and the IKEv1 is out of scope of this document. IKEv1 is deprecated and the
recommendations of this document must not be considered for IKEv1, as recommendations of this document must not be considered for IKEv1, as
most IKEv1 implementations have been "frozen" and will not be able to most IKEv1 implementations have been "frozen" and will not be able to
update the list of mandatory-to-implement algorithms. update the list of mandatory-to-implement algorithms.
2. Algorithm Selection 2. Algorithm Selection
skipping to change at page 7, line 10 skipping to change at page 7, line 10
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 in those cases, and cases of IKEv2, as far less packets are exchanged in those cases, and
IoT devices want to make packets as small as possible. The SHOULD IoT devices want to make packets as small as possible. The SHOULD
level is for 128-bit keys, 256-bit keys remains at MAY level. level is for 128-bit keys, 256-bit keys remains at MAY level.
ENCR_3DES has been downgraded from RFC4307 MUST- to SHOULD NOT. All ENCR_3DES has been downgraded from RFC4307 MUST- to MAY. All IKEv2
IKEv2 implementations already implement ENCR_AES_CBC, so there is no implementations already implement ENCR_AES_CBC, so there is no need
need to keep support for the much slower ENCR_3DES. In addition, 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 off-the-shelf hardware. It ENCR_DES can be brute-forced using off-the-shelf hardware. It
provides no meaningful security whatsoever and therefore MUST NOT be provides no meaningful security whatsoever and therefore MUST NOT be
implemented. implemented.
2.2. Type 2 - IKEv2 Pseudo-random Function Transforms 2.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.
skipping to change at page 9, line 47 skipping to change at page 9, line 47
| 2 | 1024-bit MODP Group | SHOULD NOT | | 2 | 1024-bit MODP Group | SHOULD NOT |
| 1 | 768-bit MODP Group | MUST NOT | | 1 | 768-bit MODP Group | MUST NOT |
| 22 | 1024-bit MODP Group with 160-bit Prime | MUST NOT | | 22 | 1024-bit MODP Group with 160-bit Prime | MUST NOT |
| | Order Subgroup | | | | Order Subgroup | |
| 23 | 2048-bit MODP Group with 224-bit Prime | SHOULD NOT | | 23 | 2048-bit MODP Group with 224-bit Prime | SHOULD NOT |
| | 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 to
a replacement for 1024-bit MODP Group. Group 14 is widely MUST as 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 was not defined at that time. Group 19 is widely this group was not defined at that time. Group 19 is widely
implemented and considered secure. implemented and considered secure and therefore has been promoted to
the SHOULD level.
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 being broken within the next few years considered to be vulnerable to being broken within the next few years
by a nation state level attack, so its security margin is considered by a nation state level attack, so its security margin is considered
too narrow. too 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
funded attackers using commercially available mass-computing funded attackers using commercially available mass-computing
resources, so its security margin is considered too narrow. It is resources, so its security margin is considered too narrow. It is
expected in the near future to be downgraded to MUST NOT. expected in the near future to be downgraded to MUST NOT.
Group 1 or 768-bit MODP Group was not mentioned in RFC4307 and so its Group 1 or 768-bit MODP Group was not mentioned in RFC4307 and so its
status was MAY. It can be broken within hours using cheap of-the- status was MAY. It can be broken within hours using cheap of-the-
shelves hardware. It provides no security whatsoever. shelves hardware. It provides no security whatsoever. It has
therefore been downgraded to MUST NOT.
Group 22, 23 and 24 are MODP Groups with Prime Order Subgroups that Group 22, 23 and 24 are MODP Groups with Prime Order Subgroups that
are not safe-primes. The seeds for these groups have not been are not safe-primes. The seeds for these groups have not been
publicly released, resulting in reduced trust in these groups. These publicly released, resulting in reduced trust in these groups. These
groups were proposed as alternatives for group 2 and 14 but never saw groups were proposed as alternatives for group 2 and 14 but never saw
wide deployment. It has been shown that Group 22 with 1024-bit MODP wide deployment. It has been shown that Group 22 with 1024-bit MODP
is too weak and academia have the resources to generate malicious is too weak and academia have the resources to generate malicious
values at this size. This has resulted in Group 22 to be demoted to values at this size. This has resulted in Group 22 to be demoted to
MUST NOT. Group 23 and 24 have been demoted to SHOULD NOT and are MUST NOT. Group 23 and 24 have been demoted to SHOULD NOT and are
expected to be further downgraded in the near future to MUST NOT. expected to be further downgraded in the near future to MUST NOT.
skipping to change at page 12, line 8 skipping to change at page 12, line 8
+--------+---------------------------------------+------------+ +--------+---------------------------------------+------------+
RSA Digital Signature is widely deployed and therefore kept for RSA Digital Signature is widely deployed and therefore kept for
interoperability. It is expected to be downgraded in the future as interoperability. It is expected to be downgraded in the future as
its signatures are based on the older RSASSA-PKCS1-v1.5 which is no its signatures are based on the older RSASSA-PKCS1-v1.5 which is no
longer recommended. RSA authentication, as well as other specific longer recommended. RSA authentication, as well as other specific
Authentication Methods, are expected to be replaced with the generic Authentication Methods, are expected to be replaced with the generic
Digital Signature method of [RFC7427]. Digital Signature method of [RFC7427].
Shared Key Message Integrity Code is widely deployed and mandatory to Shared Key Message Integrity Code is widely deployed and mandatory to
implement in the IKEv2 in the RFC7296. implement in the IKEv2 in the RFC7296. The status remains MUST.
ECDSA based Authentication Methods are also expected to be downgraded ECDSA based Authentication Methods are also expected to be downgraded
as these do not provide hash function agility. Instead, ECDSA (like as these do not provide hash function agility. Instead, ECDSA (like
RSA) is expected to be performed using the generic Digital Signature RSA) is expected to be performed using the generic Digital Signature
method. method. It's status is SHOULD.
DSS Digital Signature is bound to SHA-1 and has the same level of DSS Digital Signature is bound to SHA-1 and has the same level of
security as 1024-bit RSA. It is expected to be downgraded to MUST security as 1024-bit RSA. It is currently at SHOULD NOT and is
NOT in the future. expected to be downgraded to MUST NOT in the future.
Digital Signature [RFC7427] is expected to be promoted as it provides Digital Signature [RFC7427] is expected to be promoted as it provides
hash function, signature format and algorithm agility. hash function, signature format and algorithm agility.Its current
status is SHOULD.
3.1.1. Recommendations for RSA key length 3.1.1. Recommendations for RSA key length
+-------------------------------------------+------------+ +-------------------------------------------+------------+
| Description | Status | | Description | Status |
+-------------------------------------------+------------+ +-------------------------------------------+------------+
| RSA with key length 2048 | MUST | | RSA with key length 2048 | MUST |
| RSA with key length 3072 and 4096 | SHOULD | | RSA with key length 3072 and 4096 | SHOULD |
| RSA with key length between 2049 and 4095 | MAY | | RSA with key length between 2049 and 4095 | MAY |
| RSA with key length smaller than 2048 | SHOULD NOT | | RSA with key length smaller than 2048 | SHOULD NOT |
skipping to change at page 13, line 14 skipping to change at page 13, line 14
+--------+-------------+----------+---------+ +--------+-------------+----------+---------+
| Number | Description | Status | Comment | | Number | Description | Status | Comment |
+--------+-------------+----------+---------+ +--------+-------------+----------+---------+
| 1 | SHA1 | MUST NOT | | | 1 | SHA1 | MUST NOT | |
| 2 | SHA2-256 | MUST | | | 2 | SHA2-256 | MUST | |
| 3 | SHA2-384 | MAY | | | 3 | SHA2-384 | MAY | |
| 4 | SHA2-512 | SHOULD | | | 4 | SHA2-512 | SHOULD | |
+--------+-------------+----------+---------+ +--------+-------------+----------+---------+
When Digital Signature authentication method is used with RSA When the Digital Signature authentication method is used with RSA
signature algorithm, RSASSA-PSS MUST be supported and RSASSA- signature algorithm, RSASSA-PSS MUST be supported and RSASSA-
PKCS1-v1.5 MAY be supported. PKCS1-v1.5 MAY be supported.
The following table lists recommendations for authentication methods The following table lists recommendations for authentication methods
in RFC7427 [RFC7427] notation. These recommendations are applied in RFC7427 [RFC7427] notation. These recommendations are applied
only if Digital Signature authentication method is implemented. only if Digital Signature authentication method is implemented.
+------------------------------------+----------+---------+ +------------------------------------+----------+---------+
| Description | Status | Comment | | Description | Status | Comment |
+------------------------------------+----------+---------+ +------------------------------------+----------+---------+
 End of changes. 15 change blocks. 
23 lines changed or deleted 27 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/