< draft-ietf-ipsecme-rfc4307bis-15.txt   draft-ietf-ipsecme-rfc4307bis-16.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: April 23, 2017 Red Hat Expires: August 20, 2017 Red Hat
D. Migault D. Migault
Ericsson Ericsson
October 20, 2016 February 16, 2017
Algorithm Implementation Requirements and Usage Guidance for IKEv2 Algorithm Implementation Requirements and Usage Guidance for IKEv2
draft-ietf-ipsecme-rfc4307bis-15 draft-ietf-ipsecme-rfc4307bis-16
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 April 23, 2017. This Internet-Draft will expire on August 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 6, line 38 skipping to change at page 6, line 38
RFC4307. It has been recommended by the CRFG as an alternative to RFC4307. It has been recommended by the CRFG as an alternative to
AES-CBC and AES-GCM. It is also being standardized for IPsec for the AES-CBC and AES-GCM. It is also being standardized for IPsec for the
same reasons. At the time of writing, there were not enough IKEv2 same reasons. At the time of writing, there were not enough IKEv2
implementations supporting ENCR_CHACHA20_POLY1305 to be able to implementations supporting ENCR_CHACHA20_POLY1305 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 compared to AES-CBC. This resulted in AES-GCM being
AES-GCM being widely implemented for ESP. As the computation load of widely implemented for ESP. As the computation load of IKEv2 is
IKEv2 is relatively small compared to ESP, many IKEv2 implementations relatively small compared to ESP, many IKEv2 implementations have not
have not implemented AES-GCM. For this reason, AES-GCM is not implemented AES-GCM. For this reason, AES-GCM is not promoted to a
promoted to a greater status than SHOULD. The reason for promotion greater status than SHOULD. The reason for promotion from MAY to
from MAY to SHOULD is to promote the slightly more secure AEAD method SHOULD is to promote the slightly more secure AEAD method over the
over the traditional encrypt+auth method. Its status is expected to traditional encrypt+auth method. Its status is expected to be raised
be raised once widely implemented. As the advantage of the shorter once widely implemented. As the advantage of the shorter (and
(and weaker) ICVs is minimal, the 8 and 12 octet ICV's remain at the weaker) ICVs is minimal, the 8 and 12 octet ICV's remain at the MAY
MAY level. 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. 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.
skipping to change at page 9, line 22 skipping to change at page 9, line 22
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
There are several Modular Exponential (MODP) groups and several There are several Modular Exponential (MODP) groups and several
Elliptic Curve groups (ECC) that are defined for use in IKEv2. These Elliptic Curve groups (ECC) that are defined for use in IKEv2. These
groups are defined in both the [RFC7296] base document and in groups are defined in both the [RFC7296] base document and in
extensions documents and are identified by group number. Note that extensions documents and are identified by group number. Note that
it is critical to enforce a secure Diffie-Hellman exchange as this it is critical to enforce a secure Diffie-Hellman exchange as this
exchange provides keys for the session. If an attacker can retrieve exchange provides keys for the session. If an attacker can retrieve
the private numbers (a, or b) and the public values (g**a, and g**b), one of the private numbers (a or b) and the complementary public
then the attacker can compute the secret and the keys used and value (g**a or g**b), then the attacker can compute the secret and
decrypt the exchange and IPsec SA created inside the IKEv2 SA. Such the keys used and decrypt the exchange and IPsec SA created inside
an attack can be performed off-line on a previously recorded the IKEv2 SA. Such an attack can be performed off-line on a
communication, years after the communication happened. This differs previously recorded communication, years after the communication
from attacks that need to be executed during the authentication which happened. This differs from attacks that need to be executed during
must be performed online and in near real-time. the authentication which must be performed online and in near real-
time.
+--------+---------------------------------------------+------------+ +--------+---------------------------------------------+------------+
| Number | Description | Status | | Number | Description | Status |
+--------+---------------------------------------------+------------+ +--------+---------------------------------------------+------------+
| 14 | 2048-bit MODP Group | MUST | | 14 | 2048-bit MODP Group | MUST |
| 19 | 256-bit random ECP group | SHOULD | | 19 | 256-bit random ECP group | SHOULD |
| 5 | 1536-bit MODP Group | SHOULD NOT | | 5 | 1536-bit MODP Group | SHOULD NOT |
| 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 |
 End of changes. 7 change blocks. 
22 lines changed or deleted 23 lines changed or added

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