draft-ietf-ipsecme-rfc4307bis-05.txt   draft-ietf-ipsecme-rfc4307bis-06.txt 
Network Working Group Y. Nir Network Working Group Y. Nir
Internet-Draft Check Point Internet-Draft Check Point
Intended status: Standards Track T. Kivinen Obsoletes: 4307 (if approved) T. Kivinen
Expires: October 7, 2016 INSIDE Secure Updates: 7296 (if approved) INSIDE Secure
P. Wouters Intended status: Standards Track P. Wouters
Red Hat Expires: October 8, 2016 Red Hat
D. Migault D. Migault
Ericsson Ericsson
April 5, 2016 April 6, 2016
Algorithm Implementation Requirements and Usage Guidance for IKEv2 Algorithm Implementation Requirements and Usage Guidance for IKEv2
draft-ietf-ipsecme-rfc4307bis-05 draft-ietf-ipsecme-rfc4307bis-06
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 45 skipping to change at page 1, line 45
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 October 7, 2016. This Internet-Draft will expire on October 8, 2016.
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 3, line 7 skipping to change at page 3, line 7
1. Introduction 1. Introduction
The Internet Key Exchange (IKE) protocol [RFC7296] is used to The Internet Key Exchange (IKE) protocol [RFC7296] is used to
negotiate the parameters of the IPsec SA, such as the encryption and negotiate the parameters of the IPsec SA, such as the encryption and
authentication algorithms and the keys for the protected authentication algorithms and the keys for the protected
communications between the two endpoints. The IKE protocol itself is communications between the two endpoints. The IKE protocol itself is
also protected by cryptographic algorithms which are negotiated also protected by cryptographic algorithms which are negotiated
between the two endpoints using IKE. Different implementations of between the two endpoints using IKE. Different implementations of
IKE may negotiate different algorithms based on their individual IKE may negotiate different algorithms based on their individual
local policy. To ensure interoperability, a set of "mandatory-to- local policy. To ensure interoperability, a set of "mandatory-to-
implement" IKE cryptograhic algorithms is defined. implement" IKE cryptographic algorithms is defined.
This document describes the parameters of the IKE protocol. It does This document describes the parameters of the IKE protocol and
updates the IKEv2 specification because it changes the mandatory to
implement authentication algorithms of the section 4 of the RFC7296
by saying RSA key lengths of less than 2048 are SHOULD NOT. It does
not describe the cryptographic parameters of the AH or ESP protocols. not describe the cryptographic parameters of the AH or ESP protocols.
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 then 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.
skipping to change at page 6, line 49 skipping to change at page 6, line 49
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 pseudorandom values when needed. generate pseudo-random values when needed.
If an algorithm is selected as the integrity algorithm, it SHOULD 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 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. 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+ | |
skipping to change at page 10, line 32 skipping to change at page 10, line 32
mandatory to implement is provided by the PKIX Community. This mandatory to implement is provided by the PKIX Community. This
document is mostly concerned on signature verification and generation document is mostly concerned on signature verification and generation
for the authentication. for the authentication.
4.1. IKEv2 Authentication Method 4.1. IKEv2 Authentication Method
+--------+---------------------------------------+------------+ +--------+---------------------------------------+------------+
| Number | Description | Status | | Number | Description | Status |
+--------+---------------------------------------+------------+ +--------+---------------------------------------+------------+
| 1 | RSA Digital Signature | MUST | | 1 | RSA Digital Signature | MUST |
| 2 | Shared Key Message Integrity Code | MUST |
| 3 | DSS Digital Signature | SHOULD NOT | | 3 | DSS Digital Signature | SHOULD NOT |
| 9 | ECDSA with SHA-256 on the P-256 curve | SHOULD | | 9 | ECDSA with SHA-256 on the P-256 curve | SHOULD |
| 10 | ECDSA with SHA-384 on the P-384 curve | SHOULD | | 10 | ECDSA with SHA-384 on the P-384 curve | SHOULD |
| 11 | ECDSA with SHA-512 on the P-521 curve | SHOULD | | 11 | ECDSA with SHA-512 on the P-521 curve | SHOULD |
| 14 | Digital Signature | SHOULD | | 14 | Digital Signature | SHOULD |
+--------+---------------------------------------+------------+ +--------+---------------------------------------+------------+
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]. RSA Digital Signature is not Digital Signature method of [RFC7427]. RSA Digital Signature is not
recommended for keys smaller then 2048, but since these signatures recommended for keys smaller then 2048, but since these signatures
only have value in real-time, and need no future protection, smaller only have value in real-time, and need no future protection, smaller
keys was kept at SHOULD NOT instead of MUST NOT. keys was kept at SHOULD NOT instead of MUST NOT.
Shared Key Message Integrity Code is widely deployed and mandatory to
implement in the IKEv2 in the RFC7296.
ECDSA based Authentication Methods are also expected to be downgraded ECDSA based Authentication Methods are also expected to be downgraded
as it does not provide hash function agility. Instead, ECDSA (like as it does 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.
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 expected to be downgraded to MUST
NOT in the future. 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.
4.1.1. Recommendations for RSA key length 4.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 smaler than 2048 | SHOULD NOT | | RSA with key length smaller than 2048 | SHOULD NOT |
+-------------------------------------------+------------+ +-------------------------------------------+------------+
The IKEv2 RFC7296 mandates support for the RSA keys of size 1024 or
2048 bits, but here we make key sizes less than 2048 SHOULD NOT as
there is industry-wide trend to deprecate key lengths less than 2048
bits.
4.2. Digital Signature Recommendations 4.2. Digital Signature Recommendations
Recommendations for when a hash function is involved in a signature: Recommendations for when a hash function is involved in a signature:
+--------+-------------+------------+---------+ +--------+-------------+------------+---------+
| Number | Description | Status | Comment | | Number | Description | Status | Comment |
+--------+-------------+------------+---------+ +--------+-------------+------------+---------+
| 1 | SHA1 | SHOULD NOT | | | 1 | SHA1 | SHOULD NOT | |
| 2 | SHA2-256 | MUST | | | 2 | SHA2-256 | MUST | |
| 3 | SHA2-384 | MAY | | | 3 | SHA2-384 | MAY | |
skipping to change at page 12, line 26 skipping to change at page 12, line 26
| sha384WithRSAEncryption | MAY | | | sha384WithRSAEncryption | MAY | |
| sha512WithRSAEncryption | MAY | | | sha512WithRSAEncryption | MAY | |
| sha512WithRSAEncryption | MAY | | | sha512WithRSAEncryption | MAY | |
| dsa-with-sha256 | MAY | | | dsa-with-sha256 | MAY | |
| ecdsa-with-sha384 | MAY | | | ecdsa-with-sha384 | MAY | |
| ecdsa-with-sha512 | MAY | ?SHOULD | | ecdsa-with-sha512 | MAY | ?SHOULD |
+------------------------------------+------------+---------+ +------------------------------------+------------+---------+
5. Algorithms for Internet of Things 5. Algorithms for Internet of Things
Some algorithms in this document are marked for the Internet of Some algorithms in this document are marked for use with the Internet
Things (IoT). There are several reasons why the IoT devices want of Things (IoT). There are several reasons why IoT devices prefer a
have different set of algorithms than other users of IKEv2. Those different set of algorithms from regular IKEv2 clients. IoT devices
devices are usually very constrained, meaning the memory size and cpu are usually very constrained, meaning the memory size and CPU power
power is so limited, that they want to implement just minimal set of is so limited, that these clients only have resources to implement
algorithms. This means they quite often only implement one algorithm and run one set of algorithms. For example, instead of implementing
and pick it so that the same algorithm is already implemented in AES and SHA, these devices typically use AES_XCBC as integrity
software or hardware for other users. algorithm so SHA does not need to be implemented.
For example IEEE Std 802.15.4 [IEEE-802-15-4] devices has mandatory For example, IEEE Std 802.15.4 [IEEE-802-15-4] devices have a
to implement link level security using AES-CCM with 128 bit keys. mandatory to implement link level security using AES-CCM with 128 bit
The IEEE Recommended Practice for Transport of Key Management keys. The IEEE Recommended Practice for Transport of Key Management
Protocol (KMP) Datagrams [IEEE-802-15-9] already provides a way to Protocol (KMP) Datagrams [IEEE-802-15-9] already provide a way to use
use Minimal IKEv2 [RFC7815] over 802.15.4 to provide link keys for Minimal IKEv2 [RFC7815] over 802.15.4 to provide link keys for the
the 802.15.4. 802.15.4 layer.
Those devices might want to use AES-CCM as their IKEv2 algorithm, so These devices might want to use AES-CCM as their IKEv2 algorithm, so
they can reuse the hardware implementing it. They cannot use the they can reuse the hardware implementing it. They cannot use the
AES-CBC, as the hardware quite often do not include support for AES AES-CBC algorithm, as the hardware quite often do not include support
decryption needed for it. So even when AES-CCM algorithm support for AES decryption needed to support the CBC mode. So despite the
requires support for the AEAD [RFC5282] support for IKEv2, the AES-CCM algorithm requiring AEAD [RFC5282] support, the benefit of
benefit of reusing crypto hardware makes it worthwhile. reusing the crypto hardware makes AES-CCM the preferred algorithm.
Other important aspects of the IoT devices, that their transfer rates Another important aspect of IoT devices is that their transfer rates
are usually quite low (in order of tens of kbits/s), and each bit are usually quite low (in order of tens of kbits/s), and each bit
they transmit costs a lot in energy consumption (shortening the they transmit has an energy consumption cost associated with it and
battery life). Because of this they usually want to use options shortens their battery life. Therefore, shorter packets are
which support shorter packets. I.e., using 8 octet ICV instead of preferred. This is the reason for recommending the 8 octet ICV over
16. the 16 octet ICV.
Also as each of those IoT devices have different constraints, we Because different IoT devices will have different constraints, this
cannot specify one exact profile for them. This document points out document cannot specify the one mandatory profile for IoT. Instead,
some algorithms commonly used in the IoT devices, but there might be this document points out commonly used algorithms with IoT devices.
devices using different set of algorithms, because of requirements
for the environment.
6. Security Considerations 6. Security Considerations
The security of cryptographic-based systems depends on both the The security of cryptographic-based systems depends on both the
strength of the cryptographic algorithms chosen and the strength of strength of the cryptographic algorithms chosen and the strength of
the keys used with those algorithms. The security also depends on the keys used with those algorithms. The security also depends on
the engineering of the protocol used by the system to ensure that the engineering of the protocol used by the system to ensure that
there are no non-cryptographic ways to bypass the security of the there are no non-cryptographic ways to bypass the security of the
overall system. overall system.
 End of changes. 18 change blocks. 
40 lines changed or deleted 50 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/