draft-ietf-ipsecme-rfc4307bis-08.txt   draft-ietf-ipsecme-rfc4307bis-09.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: November 12, 2016 Red Hat Expires: November 14, 2016 Red Hat
D. Migault D. Migault
Ericsson Ericsson
May 11, 2016 May 13, 2016
Algorithm Implementation Requirements and Usage Guidance for IKEv2 Algorithm Implementation Requirements and Usage Guidance for IKEv2
draft-ietf-ipsecme-rfc4307bis-08 draft-ietf-ipsecme-rfc4307bis-09
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 November 12, 2016. This Internet-Draft will expire on November 14, 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 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Updating Algorithm Implementation Requirements and Usage 1.1. Updating Algorithm Implementation Requirements and Usage
Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3 Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3 1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3
1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4 1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 5 3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 5
3.1. Type 1 - IKEv2 Encryption Algorithm Transforms . . . . . 5 3.1. Type 1 - IKEv2 Encryption Algorithm Transforms . . . . . 5
3.2. Type 2 - IKEv2 Pseudo-random Function Transforms . . . . 6 3.2. Type 2 - IKEv2 Pseudo-random Function Transforms . . . . 7
3.3. Type 3 - IKEv2 Integrity Algorithm Transforms . . . . . . 7 3.3. Type 3 - IKEv2 Integrity Algorithm Transforms . . . . . . 8
3.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms . . . . . 8 3.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms . . . . . 9
4. IKEv2 Authentication . . . . . . . . . . . . . . . . . . . . 10 4. IKEv2 Authentication . . . . . . . . . . . . . . . . . . . . 10
4.1. IKEv2 Authentication Method . . . . . . . . . . . . . . . 10 4.1. IKEv2 Authentication Method . . . . . . . . . . . . . . . 10
4.1.1. Recommendations for RSA key length . . . . . . . . . 11 4.1.1. Recommendations for RSA key length . . . . . . . . . 11
4.2. Digital Signature Recommendations . . . . . . . . . . . . 11 4.2. Digital Signature Recommendations . . . . . . . . . . . . 12
5. Algorithms for Internet of Things . . . . . . . . . . . . . . 12 5. Algorithms for Internet of Things . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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
skipping to change at page 4, line 37 skipping to change at page 4, line 37
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.3. Document Audience 1.3. 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 as implementations need to meet both high security expectations as
well as high interoperability between various vendors and with well as high interoperability between various vendors and with
different versions. Interoperability requires a smooth move to more different versions. Interoperability requires a smooth move to more
secure cipher suites. This may differ from a user point of view that secure cipher suites. This may differ from a user point of view that
may deploy and configure IKEv2 with only the safest cipher suite. On may deploy and configure IKEv2 with only the safest cipher suite.
the other hand, comments from this document are also expected to be
useful for such users. This document does not give any recommendations for the use of
algorithms, it only gives implementation recommendations for
implementations. The use of algorithms by users is dictated by the
security policy requirements for that specific user, and are outside
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. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 11, line 38 skipping to change at page 12, line 15
The IKEv2 RFC7296 mandates support for the RSA keys of size 1024 or 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 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 there is industry-wide trend to deprecate key lengths less than 2048
bits. bits.
4.2. Digital Signature Recommendations 4.2. Digital Signature Recommendations
When Digital Signature authentication method is implemented, then the When Digital Signature authentication method is implemented, then the
following recommendations are applied for hash functions: following recommendations are applied for hash functions:
+--------+-------------+------------+---------+ +--------+-------------+----------+---------+
| Number | Description | Status | Comment | | Number | Description | Status | Comment |
+--------+-------------+------------+---------+ +--------+-------------+----------+---------+
| 1 | SHA1 | SHOULD 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 Digital Signature authentication method is used with RSA
signature algorithm, then RSASSA-PSS MUST be supported and RSASSA- signature algorithm, then 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 |
+------------------------------------+------------+---------+ +------------------------------------+----------+---------+
| RSASSA-PSS with SHA-256 | MUST | | | RSASSA-PSS with SHA-256 | MUST | |
| ecdsa-with-sha256 | SHOULD | | | ecdsa-with-sha256 | SHOULD | |
| sha1WithRSAEncryption | SHOULD NOT | | | sha1WithRSAEncryption | MUST NOT | |
| dsa-with-sha1 | SHOULD NOT | | | dsa-with-sha1 | MUST NOT | |
| ecdsa-with-sha1 | SHOULD NOT | | | ecdsa-with-sha1 | MUST NOT | |
| RSASSA-PSS with Empty Parameters | SHOULD NOT | | | RSASSA-PSS with Empty Parameters | MUST NOT | |
| RSASSA-PSS with Default Parameters | SHOULD NOT | | | RSASSA-PSS with Default Parameters | 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
 End of changes. 12 change blocks. 
34 lines changed or deleted 38 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/