draft-ietf-ipsecme-rfc4307bis-02.txt   draft-ietf-ipsecme-rfc4307bis-03.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 Intended status: Standards Track T. Kivinen
Expires: July 07, 2016 INSIDE Secure Expires: August 13, 2016 INSIDE Secure
P. Wouters P. Wouters
Red Hat Red Hat
D. Migault D. Migault
Ericsson Ericsson
January 04, 2016 February 10, 2016
Algorithm Implementation Requirements and Usage Guidance for IKEv2 Algorithm Implementation Requirements and Usage Guidance for IKEv2
draft-ietf-ipsecme-rfc4307bis-02 draft-ietf-ipsecme-rfc4307bis-03
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 protocol provides a mechanism to negotiate which algorithms Exchange protocol provides a mechanism to negotiate which algorithms
should be used in any given Security Association. To ensure should be used in any given Security Association. To ensure
interoperability between different implementations, it is necessary interoperability between different implementations, it is necessary
to specify a set of algorithm implementation requirements and Usage to specify a set of algorithm implementation requirements and Usage
guidance to ensure that there is at least one algorithm that all guidance to ensure that there is at least one algorithm that all
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 July 07, 2016. This Internet-Draft will expire on August 13, 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
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
skipping to change at page 2, line 30 skipping to change at page 2, line 33
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 . . . . . . . . . . . . . . 4
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 . . . . 6
3.3. Type 3 - IKEv2 Integrity Algorithm Transforms . . . . . . 7 3.3. Type 3 - IKEv2 Integrity Algorithm Transforms . . . . . . 7
3.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms . . . . . 8 3.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms . . . . . 8
4. IKEv2 Authentication . . . . . . . . . . . . . . . . . . . . 9 4. IKEv2 Authentication . . . . . . . . . . . . . . . . . . . . 10
4.1. IKEv2 Authentication Method . . . . . . . . . . . . . . . 9 4.1. IKEv2 Authentication Method . . . . . . . . . . . . . . . 10
4.2. Digital Signature Recommendation . . . . . . . . . . . . 10 4.2. Digital Signature Recommendation . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The Internet Key Exchange protocol [RFC7296] is used to negotiate the The Internet Key Exchange protocol [RFC7296] is used to negotiate the
IPsec parameters, such as encryption algorithms and keys, for IPsec parameters, such as encryption algorithms and keys, for
protected communications between two endpoints. The IKEv2 protocol protected communications between two endpoints. The IKEv2 protocol
itself is also protected by encryption, which is also negotiated itself is also protected by encryption, which is also negotiated
between the two endpoints. Negotiation is performed by IKEv2 itself. between the two endpoints. Negotiation is performed by IKEv2 itself.
This document describes the encryption parameters of the IKE This document describes the encryption parameters of the IKE
protocol, not the encryption parameters of the ESP (IPsec) protocol. protocol, not the encryption parameters of the ESP (IPsec) protocol.
Different implementations of IKEv2 may negotiate different encryption Different implementations of IKEv2 may negotiate different encryption
algorithms based on their individual local policy. To ensure algorithms based on their individual local policy. To ensure
interoperability, a set of "mandatory-to-implement" IKEv2 encryption interoperability, a set of "mandatory-to-implement" IKEv2 encryption
algorithms is defined. algorithms is defined.
1.1. Updating Algorithm Implementation Requirements and Usage Guidance 1.1. Updating Algorithm Implementation Requirements and Usage Guidance
The field of cryptography evolves continiously. New stronger The field of cryptography evolves continiously. 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
skipping to change at page 4, line 32 skipping to change at page 4, line 24
The current trend toward Internet of Things and its adoption of IKEv2 The current trend toward Internet of Things and its adoption of IKEv2
requires this specific use case to be taken into account as well. requires this specific use case to be taken into account as well.
IoT devices are resource constrainted devices and their choice of IoT devices are resource constrainted devices and their choice of
algorithms are motivated by minimizing the fooprint of the code, the algorithms are motivated by minimizing the fooprint of the code, the
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. listed for IoT devices.
1.3. Document Audience 1.3. Document Audience
The recommendations of this document target IKEv2 implementers. In The recommendations of this document mostly target IKEv2 implementers
other words, the recommendations should not be considered for IKEv2 as implementations needs to meet both high security expectations as
configuration, as a preference for some algorithms. [PAUL: I don't well as high interoperability between various vendors and with
understand this. Clearly MTI are good default choices?] different updates. Interoperability requires a smooth move to more
secure cipher suites. This may differ from a user point of view that
may deploy and configure IKEv2 with only the safest cipher suites.
On the other hand, comments and recommendations are also expected to
be useful for such users.
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. recommendations of this document must not be considered for IKEv1.
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
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
We define some additional terms here: We define some additional terms here:
SHOULD+ This term means the same as SHOULD. However, it is likely SHOULD+ This term means the same as SHOULD. However, it is likely
that an algorithm marked as SHOULD+ will be promoted at some that an algorithm marked as SHOULD+ will be promoted at
future time to be a MUST. some future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, an algorithm SHOULD- This term means the same as SHOULD. However, an algorithm
marked as SHOULD- may be deprecated to a MAY in a future marked as SHOULD- may be deprecated to a MAY in a future
version of this document. version of this document.
MUST- This term means the same as MUST. However, we expect at MUST- This term means the same as MUST. However, we expect at
some point that this algorithm will no longer be a MUST in a some point that this algorithm will no longer be a MUST in
future document. Although its status will be determined at a future document. Although its status will be determined
a later time, it is reasonable to expect that if a future at a later time, it is reasonable to expect that if a
revision of a document alters the status of a MUST- future revision of a document alters the status of a MUST-
algorithm, it will remain at least a SHOULD or a SHOULD-. algorithm, it will remain at least a SHOULD or a SHOULD-.
IoT stands for Internet of Things. IoT stands for Internet of Things.
Table 1
3. Algorithm Selection 3. Algorithm Selection
3.1. Type 1 - IKEv2 Encryption Algorithm Transforms 3.1. Type 1 - IKEv2 Encryption 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 in the ENCR payload. References to the specifications and used in the Encrypted Payload. References to the specifications
defining these algorithms and the ones in the following subsections defining these algorithms and the ones in the following subsections
are in the IANA registry [IKEV2-IANA]. Some of these algorithms are are in the IANA registry [IKEV2-IANA]. Some of these algorithms are
Authenticated Encryption with Associated Data (AEAD - [RFC5282]). Authenticated Encryption with Associated Data (AEAD - [RFC5282]).
Algorithms that are not AEAD MUST be used in conjunction with an Algorithms that are not AEAD MUST be used in conjunction with an
integrity algorithms in Section 3.3. integrity algorithms in Section 3.3.
+-----------------------------+----------+-------+----------+ +-----------------------------+----------+-------+----------+
| Name | Status | AEAD? | Comment | | Name | Status | AEAD? | Comment |
+-----------------------------+----------+-------+----------+ +-----------------------------+----------+-------+----------+
| ENCR_AES_CBC | MUST- | No | [1] | | ENCR_AES_CBC | MUST- | No | [1] |
skipping to change at page 5, line 42 skipping to change at page 5, line 46
| AES-GCM with a 16 octet ICV | SHOULD | Yes | [1] | | AES-GCM with a 16 octet ICV | SHOULD | Yes | [1] |
| ENCR_AES_CCM_8 | SHOULD | Yes | [1][IoT] | | ENCR_AES_CCM_8 | SHOULD | Yes | [1][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 keys. 256-bit keys are at [1] - This requirement level is for 128-bit keys. 256-bit keys are at
MAY. 192-bit keys can safely be ignored. [IoT] - This requirement is MAY. 192-bit keys can safely be ignored. [IoT] - This requirement is
for interoperability with IoT. for interoperability with IoT.
Table 2
ENCR_AES_CBC is raised from SHOULD+ in RFC4307. It is the only ENCR_AES_CBC is raised from SHOULD+ in RFC4307. It is the only
shared mandatory-to-implement algorithm with RFC4307 and as a result shared mandatory-to-implement algorithm with RFC4307 and as a result
is necessary for interoperability with IKEv2 implementation is necessary for interoperability with IKEv2 implementation
compatible with RFC4307. 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 and others as an
alternative to AES and AES-GCM. It is also being standarized for alternative to AES and AES-GCM. It is also being standarized for
IPsec for the same reasons. At the time of writing, there were not IPsec for the same reasons. At the time of writing, there were not
enough IKEv2 implementations of ENCR_CHACHA20_POLY1305 to be able to enough IKEv2 implementations of ENCR_CHACHA20_POLY1305 to be able to
skipping to change at page 7, line 16 skipping to change at page 7, line 18
| 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- | [1] | | PRF_HMAC_SHA1 | MUST- | [1] |
| PRF_AES128_CBC | SHOULD | [IoT] | | PRF_AES128_CBC | SHOULD | [IoT] |
+-------------------+---------+---------+ +-------------------+---------+---------+
[IoT] - This requirement is for interoperability with IoT [IoT] - This requirement is for interoperability with IoT
Table 3
PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2 based PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2 based
authentication was mentioned. PRF_HMAC_SHA2_256 MUST be implemented authentication was mentioned. PRF_HMAC_SHA2_256 MUST be implemented
in order to replace SHA1 and PRF_HMAC_SHA1. in order to replace SHA1 and PRF_HMAC_SHA1.
PRF_HMAC_SHA2_512 SHOULD be implemented as as a future replacement of PRF_HMAC_SHA2_512 SHOULD be implemented as as a future replacement of
SHA2_256 or when stronger security is required. PRF_HMAC_SHA2_512 is SHA2_256 or when stronger security is required. PRF_HMAC_SHA2_512 is
preferred over PRF_HMAC_SHA2_384, as the overhead of preferred over PRF_HMAC_SHA2_384, as the overhead of
PRF_HMAC_SHA2_512 is negligible. PRF_HMAC_SHA2_512 is negligible.
PRF_HMAC_SHA1_96 has been downgraded from MUST in RFC4307. There is PRF_HMAC_SHA1_96 has been downgraded from MUST in RFC4307. There is
skipping to change at page 8, line 7 skipping to change at page 8, line 16
| Name | Status | Comment | | Name | Status | Comment |
+------------------------+--------+---------+ +------------------------+--------+---------+
| AUTH_HMAC_SHA2_256_128 | MUST | | | AUTH_HMAC_SHA2_256_128 | MUST | |
| AUTH_HMAC_SHA2_512_256 | SHOULD | | | AUTH_HMAC_SHA2_512_256 | SHOULD | |
| AUTH_HMAC_SHA1_96 | SHOULD | | | AUTH_HMAC_SHA1_96 | SHOULD | |
| AUTH_AES_XCBC_96 | SHOULD | [IoT] | | AUTH_AES_XCBC_96 | SHOULD | [IoT] |
+------------------------+--------+---------+ +------------------------+--------+---------+
[IoT] - This requirement is for interoperability with IoT [IoT] - This requirement is for interoperability with IoT
Table 4
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
authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST be authentication was 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 as a future AUTH_HMAC_SHA2_512_256 SHOULD be implemented as as a future
replacement of AUTH_HMAC_SHA2_256_128 or when stronger security is replacement of AUTH_HMAC_SHA2_256_128 or when stronger security is
required. This value has been preferred to AUTH_HMAC_SHA2_384, as required. This value has been preferred to AUTH_HMAC_SHA2_384, as
the overhead of AUTH_HMAC_SHA2_512 is negligible. the overhead of AUTH_HMAC_SHA2_512 is negligible.
AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307. There is AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307. There is
skipping to change at page 8, line 34 skipping to change at page 9, line 5
it has not been widely adopted, it has been downgraded from SHOULD in it has not been widely adopted, it has been downgraded from SHOULD in
RFC4307 to MAY. RFC4307 to MAY.
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. They Elliptic Curve groups (ECC) that are defined for use in IKEv2. They
are defined in both the [IKEv2] base document and in extensions are defined in both the [IKEv2] base document and in extensions
documents. They are identified by group number. documents. They are identified by group number.
+--------+--------------------------+------------+ +--------+----------------------------------------------+-----------+
| 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 |
| 2 | 1024-bit MODP Group | SHOULD NOT | | | | NOT |
| 1 | 768-bit MODP Group | MUST NOT | | 2 | 1024-bit MODP Group | SHOULD |
| TBD | Curve25519 | MAY | | | | NOT |
+--------+--------------------------+------------+ | 1 | 768-bit MODP Group | MUST NOT |
| 22 | 1024-bit MODP Group with 160-bit Prime Order | MUST NOT |
Table 5 | | Subgroup | |
| 23 | 1024-bit MODP Group with 224-bit Prime Order | MUST NOT |
| | Subgroup | |
| 24 | 1024-bit MODP Group with 256-bit Prime Order | MUST NOT |
| | 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. Group 19 or 256-bit random ECP group was not specified in RFC4307.
Group 19 is widely implemented and considered secure Group 19 is widely implemented and considered secure
Group 5 or 1536-bit MODP Group is downgrade from MUST- to SHOULD NOT. Group 5 or 1536-bit MODP Group is downgrade from MUST- to SHOULD NOT.
It was specified earlier, but now considered to be vulnerable to be It was specified earlier, but now considered to be vulnerable to be
broken within the next few years by a nation state level attack, so broken within the next few years by a nation state level attack, so
its security margin is considered too narrow. its security margin is considered too narrow.
Group 2 or 1024-bit MODP Group is downgrade from MUST- to SHOULD NOT. Group 2 or 1024-bit MODP Group is downgrade from MUST- to SHOULD NOT.
It was specified earlier, but now it is known to be weak against It was specified earlier, but now it is known to be weak against
sufficiently funded attackers using commercially available mass- sufficiently funded attackers using commercially available mass-
computing resources, so its security margin is considered too narrow. computing resources, so its security margin is considered too narrow.
It is expected in the near future to be downgraded to MUST NOT. It is expected in the near future to be downgraded to MUST NOT.
skipping to change at page 9, line 25 skipping to change at page 10, line 5
Group 1 or 768-bit MODP Group can be broken within hours using cheap Group 1 or 768-bit MODP Group can be broken within hours using cheap
of-the-shelves hardware. It provides no security whatsoever. of-the-shelves hardware. It provides no security whatsoever.
Curve25519 has been designed with performance and security in mind Curve25519 has been designed with performance and security in mind
and have been recommended by CFRG. At the time of writing, the IKEv2 and have been recommended by CFRG. At the time of writing, the IKEv2
specification is still at the draft status. This document specifies specification is still at the draft status. This document specifies
it as to encourage its implementation and deployment. If it gets it as to encourage its implementation and deployment. If it gets
widely implemented then it most likely will be upgraded to SHOULD or widely implemented then it most likely will be upgraded to SHOULD or
even MUST in the future. even MUST in the future.
Group 22-24 or 1024-bit MODP Group with 160-bit and 2048-bit MODP
Group with 224-256-bit Prime Order Subgroup are exposed to
synchronization or transcription attacks.
4. IKEv2 Authentication 4. IKEv2 Authentication
IKEv2 authentication may involve a signatures verification. IKEv2 authentication may involve a signatures verification.
Signatures may be used to validate a certificate or to check the Signatures may be used to validate a certificate or to check the
signature of the AUTH value. Cryptographic recommendations regarding signature of the AUTH value. Cryptographic recommendations regarding
certificate validation are out of scope of this document as what certificate validation are out of scope of this document as what
mandatory implementations are provided by the PKIX WG. This document mandatory implementations are provided by the PKIX WG. This document
is mostly concerned on signature verification and generation for the is mostly concerned on signature verification and generation for the
authentication. authentication.
4.1. IKEv2 Authentication Method 4.1. IKEv2 Authentication Method
+----------+-----------------------+----------+---------------------+ +--------+-------------------------+--------+-----------------------+
| Number | Description | Status | Comment | | Number | Description | Status | Comment |
+----------+-----------------------+----------+---------------------+ +--------+-------------------------+--------+-----------------------+
| 1 | RSA Digital Signature | MUST | With keys length | | 1 | RSA Digital Signature | MUST | With keys length 2048 |
| | | | 2048 | | 1 | RSA Digital Signature | SHOULD | With keys length |
| 1 | RSA Digital Signature | SHOULD | With keys length | | | | | 3072/4096 |
| | | | 3072/4096 | | 1 | RSA Digital Signature | MUST | With keys length |
| 1 | RSA Digital Signature | MUST NOT | With keys length | | | | NOT | lower than 2048 |
| | | | lower than 2048 | | 3 | DSS Digital Signature | MAY | |
| 3 | DSS Digital Signature | MAY | | | 9 | ECDSA with SHA-256 on | SHOULD | |
| 9 | ECDSA with SHA-256 on | SHOULD | | | | the P-256 curve | | |
| | the P-256 curve | | | | 10 | ECDSA with SHA-384 on | SHOULD | |
| 10 | ECDSA with SHA-384 on | SHOULD | | | | the P-384 curve | | |
| | the P-384 curve | | | | 11 | ECDSA with SHA-512 on | SHOULD | |
| 11 | ECDSA with SHA-512 on | SHOULD | | | | the P-521 curve | | |
| | the P-521 curve | | | | 14 | Digital Signature | SHOULD | |
| 14 | Digital Signature | SHOULD | | +--------+-------------------------+--------+-----------------------+
+----------+-----------------------+----------+---------------------+
Table 6
RSA Digital Signature is mostly kept for interoperability. It is RSA Digital Signature is mostly kept for interoperability. It is
expected to be downgraded in the future as signatures are based on expected to be downgraded in the future as signatures are based on
RSASSA-PKCS1-v1.5, not any more recommemded. Instead, more robust RSASSA-PKCS1-v1.5, not any more recommemded. Instead, more robust
use of RSA is expected to be performed via the Digital Signature use of RSA is expected to be performed via the Digital Signature
method. method.
ECDSA family are also expected to be downgraded as it does not ECDSA family are also expected to be downgraded as it does not
provide hash function agility. Instead ECDSA is expected to be provide hash function agility. Instead ECDSA is expected to be
performed using the generic Digital Signature method. performed using the generic Digital Signature method.
skipping to change at page 10, line 31 skipping to change at page 11, line 13
downgraded to MUST NOT in the future. downgraded to MUST NOT in the future.
Digital Signature is expected to be promoted as it provides hash Digital Signature is expected to be promoted as it provides hash
function, signature format and algorithm agility. function, signature format and algorithm agility.
[MGLT: Do we have any recommendation for the authentication based on [MGLT: Do we have any recommendation for the authentication based on
PSK?] PSK?]
4.2. Digital Signature Recommendation 4.2. Digital Signature Recommendation
Recommended methods: RSA (MUST), ECDSA (SHOULD), Ed25519 (MAY), Here are the recommendations for the authentication methods.
Ed25519ph(MAY), Ed448(MAY), Ed448ph(MAY)?
+--------+-------------+----------+---------------------------------+
| Number | Description | Status | Comment |
+--------+-------------+----------+---------------------------------+
| OID | RSA | MUST | With keys length 2048 |
| OID | RSA | SHOULD | With keys length 3072/4096 |
| OID | RSA | MUST NOT | With keys length lower than |
| | | | 2048 |
| OID | ECDSA | SHOULD | |
+--------+-------------+----------+---------------------------------+
Here are the recommendations when a hash function is involved in a Here are the recommendations when a hash function is involved in a
signature. signature.
+--------+----------------------+----------+---------+ +--------+-------------+--------+---------+
| Number | Description | Status | Comment | | Number | Description | Status | Comment |
+--------+----------------------+----------+---------+ +--------+-------------+--------+---------+
| 1 | SHA1 | MUST | | | 1 | SHA1 | MUST | |
| 2 | SHA2-256 | MUST | | | 2 | SHA2-256 | MUST | |
| 3 | SHA2-384 | MAY | | | 3 | SHA2-384 | MAY | |
| 4 | SHA2-512 | SHOULD | | | 4 | SHA2-512 | SHOULD | |
| | Other hash functions | MUST NOT | | +--------+-------------+--------+---------+
+--------+----------------------+----------+---------+
Table 7
With the use of Digital Signature, RSASSA-PKCS1-v1.5 MAY be With the use of Digital Signature, RSASSA-PKCS1-v1.5 MAY be
implemented, and RSASSA-PSS MUST be implemented. implemented, and RSASSA-PSS MUST be implemented.
RSA keys MUST be greater or equal than 20148 bits.
5. Security Considerations 5. 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.
The Diffie-Hellman Groups parameter is the most important one to The Diffie-Hellman Groups parameter is the most important one to
skipping to change at page 11, line 44 skipping to change at page 12, line 28
6. IANA Considerations 6. IANA Considerations
This document makes no requests of IANA. This document makes no requests of IANA.
7. Acknowledgements 7. Acknowledgements
The first version of this document was RFC 4307 by Jeffrey I. The first version of this document was RFC 4307 by Jeffrey I.
Schiller of the Massachusetts Institute of Technology (MIT). Much of Schiller of the Massachusetts Institute of Technology (MIT). Much of
the original text has been copied verbatim. the original text has been copied verbatim.
We would like to thanks Paul Hoffman, Yaron Sheffer and Tommy Pauly We would like to thanks Paul Hoffman, Yaron Sheffer John Mattsson and
for their valuable feed backs. Tommy Pauly for their valuable feed backs.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)", RFC (GCM) in IPsec Encapsulating Security Payload (ESP)",
4106, DOI 10.17487/RFC4106, June 2005, RFC 4106, DOI 10.17487/RFC4106, June 2005,
<http://www.rfc-editor.org/info/rfc4106>. <http://www.rfc-editor.org/info/rfc4106>.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307, DOI Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
10.17487/RFC4307, December 2005, DOI 10.17487/RFC4307, December 2005,
<http://www.rfc-editor.org/info/rfc4307>. <http://www.rfc-editor.org/info/rfc4307>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>. 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282, DOI Exchange version 2 (IKEv2) Protocol", RFC 5282,
10.17487/RFC5282, August 2008, DOI 10.17487/RFC5282, August 2008,
<http://www.rfc-editor.org/info/rfc5282>. <http://www.rfc-editor.org/info/rfc5282>.
8.2. Informative References 8.2. Informative References
[IKEV2-IANA] [IKEV2-IANA]
, "Internet Key Exchange Version 2 (IKEv2) Parameters", , "Internet Key Exchange Version 2 (IKEv2) Parameters",
<http://www.iana.org/assignments/ikev2-parameters>. <http://www.iana.org/assignments/ikev2-parameters>.
Authors' Addresses Authors' Addresses
Yoav Nir Yoav Nir
Check Point Software Technologies Ltd. Check Point Software Technologies Ltd.
5 Hasolelim st. 5 Hasolelim st.
Tel Aviv 6789735 Tel Aviv 6789735
Israel Israel
 End of changes. 30 change blocks. 
89 lines changed or deleted 100 lines changed or added

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