One document matched: draft-ietf-ipsecme-rfc4307bis-15.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc4106 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4106.xml">
<!ENTITY rfc4307 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4307.xml">
<!ENTITY rfc6989 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6989.xml">
<!ENTITY rfc7296 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml">
<!ENTITY rfc7427 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7427.xml">
<!ENTITY rfc5282 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5282.xml">
<!ENTITY rfc7815 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7815.xml">
<!ENTITY rfc5529 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5529.xml">
]>
<?rfc toc="yes"?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<?rfc symrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc rfcedstyle="yes"?>
<rfc ipr="trust200902"
docName="draft-ietf-ipsecme-rfc4307bis-15"
obsoletes="4307"
updates="7296"
category="std">
<front>
<title abbrev="IKEv2 Cryptographic Algorithms">Algorithm Implementation Requirements and Usage Guidance for IKEv2</title>
<author initials="Y." surname="Nir" fullname="Yoav Nir">
<organization abbrev="Check Point">Check Point Software Technologies Ltd.</organization>
<address>
<postal>
<street>5 Hasolelim st.</street>
<city>Tel Aviv</city>
<code>6789735</code>
<country>Israel</country>
</postal>
<email>ynir.ietf@gmail.com</email>
</address>
</author>
<author initials='T.' surname='Kivinen' fullname='Tero Kivinen'>
<organization>INSIDE Secure</organization>
<address>
<postal>
<street>Eerikinkatu 28</street>
<code>FI-00180</code>
<city>HELSINKI</city>
<country>FI</country>
</postal>
<email>kivinen@iki.fi</email>
</address>
</author>
<author fullname="Paul Wouters" initials="P." surname="Wouters">
<organization>Red Hat</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>pwouters@redhat.com</email>
</address>
</author>
<author fullname="Daniel Migault" initials="D." surname="Migault">
<organization> Ericsson </organization>
<address>
<postal>
<street> 8400 boulevard Decarie </street>
<city> Montreal, QC </city>
<code> H4P 2N2 </code>
<country> Canada </country>
</postal>
<phone> +1 514-452-2160 </phone>
<email> daniel.migault@ericsson.com </email>
</address>
</author>
<date year="2016"/>
<area>Security</area>
<!-- <workgroup>IPSecME Working Group</workgroup> -->
<keyword>Internet-Draft</keyword>
<abstract>
<t> The IPsec series of protocols makes use of various
cryptographic algorithms in order to provide security services.
The Internet Key Exchange (IKE) protocol is used to negotiate
the IPsec Security Association (IPsec SA) parameters, such as
which algorithms should be used. To ensure interoperability
between different implementations, it is necessary to specify a
set of algorithm implementation requirements and usage guidance
to ensure that there is at least one algorithm that all
implementations support. This document updates RFC 7296 and obsoletes
RFC 4307 in defining the current algorithm implementation requirements and
usage guidance for IKEv2, and does minor cleaning up of
the IKEv2 IANA registry. This document does not update the algorithms
used for packet encryption using IPsec Encapsulated Security Payload
(ESP).</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t> The Internet Key Exchange (IKE) protocol <xref
target="RFC7296" /> is used to negotiate the parameters of the
IPsec SA, such as the encryption and authentication algorithms
and the keys for the protected communications between the two
endpoints. The IKE protocol itself is also protected by
cryptographic algorithms which are negotiated between the two
endpoints using IKE. Different implementations of IKE may
negotiate different algorithms based on their individual local
policy. To ensure interoperability, a set of
"mandatory-to-implement" IKE cryptographic algorithms is
defined.</t>
<t> 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. </t>
<section title="Updating Algorithm Implementation Requirements and Usage Guidance">
<t> The field of cryptography evolves continuously. New stronger
algorithms appear and existing algorithms are found to be less
secure then originally thought. Therefore, algorithm
implementation requirements and usage guidance need to be
updated from time to time to reflect the new reality. The
choices for algorithms must be conservative to minimize the risk
of algorithm compromise. Algorithms need to be suitable for a
wide variety of CPU architectures and device deployments ranging
from high end bulk encryption devices to small low-power IoT
devices.</t>
<t> The algorithm implementation requirements and usage guidance
may need to change over time to adapt to the changing world. For
this reason, the selection of mandatory-to-implement algorithms
was removed from the main IKEv2 specification and placed in a
separate document. </t>
</section>
<section title="Updating Algorithm Requirement Levels">
<t>The mandatory-to-implement algorithm of tomorrow should
already be available in most implementations of IKE by the time
it is made mandatory. This document attempts to identify and
introduce those algorithms for future mandatory-to-implement
status. There is no guarantee that the algorithms in use today
may become mandatory in the future. Published algorithms are
continuously subjected to cryptographic attack and may become
too weak or could become completely broken before this document
is updated.</t>
<t> This document only provides recommendations for the
mandatory-to-implement algorithms or algorithms too weak that
are recommended not to be implemented. As a result, any
algorithm listed at the IKEv2 IANA registry not mentioned in
this document MAY be implemented. For clarification and
consistency with <xref target="RFC4307"/> an algorithm will be
denoted here as MAY only when it has been downgraded.</t>
<t> Although this document updates the algorithms to keep the
IKEv2 communication secure over time, it also aims at providing
recommendations so that IKEv2 implementations remain
interoperable. IKEv2 interoperability is addressed by an
incremental introduction or deprecation of algorithms. In
addition, this document also considers the new use cases for
IKEv2 deployment, such as Internet of Things (IoT).</t>
<t> It is expected that deprecation of an algorithm is performed
gradually. This provides time for various implementations to
update their implemented algorithms while remaining
interoperable. Unless there are strong security reasons, an
algorithm is expected to be downgraded from MUST to MUST- or
SHOULD, instead of MUST NOT. Similarly, an algorithm that has
not been mentioned as mandatory-to-implement is expected to be
introduced with a SHOULD instead of a MUST.</t>
<t>The current trend toward Internet of Things and its adoption
of IKEv2 requires this specific use case to be taken into
account as well. IoT devices are resource constrained devices
and their choice of algorithms are motivated by minimizing the
footprint of the code, the computation effort and the size of
the messages to send. This document indicates "(IoT)" when a
specified algorithm is specifically listed for IoT devices.
Requirement levels that are marked as "IoT" apply to IoT devices
and to server-side implementations that might presumably need to
interoperate with them, including any general-purpose VPN
gateways.</t>
</section>
<section title="Document Audience">
<t>The recommendations of this document mostly target IKEv2
implementers as implementations need to meet both high security
expectations as well as high interoperability between various
vendors and with different versions. 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 suite.</t>
<t>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.</t>
<t> IKEv1 is out of scope of this document. IKEv1 is deprecated
and the recommendations of this document must not be considered
for IKEv1, as most IKEv1 implementations have been "frozen" and
will not be able to update the list of mandatory-to-implement
algorithms.</t>
</section>
</section>
<section anchor="mustshouldmay" title="Conventions Used in This Document">
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119"/>.</t>
<t> We define some additional terms here:</t>
<texttable anchor="tbl" style="none" suppress-title="true">
<ttcol align="left" width="12%"/>
<ttcol align="left" />
<c>SHOULD+</c><c>This term means the same as SHOULD. However,
it is likely that an algorithm marked as SHOULD+ will be
promoted at some future time to be a MUST.</c>
<c>SHOULD-</c><c>This term means the same as SHOULD. However,
an algorithm marked as SHOULD- may be deprecated to a MAY in a
future version of this document.</c>
<c>MUST-</c><c>This term means the same as MUST. However, we
expect at some point that this algorithm will no longer be a
MUST in a future document. Although its status will be
determined at a later time, it is reasonable to expect that if
a future revision of a document alters the status of a MUST-
algorithm, it will remain at least a SHOULD or a SHOULD-
level.</c>
<c>IoT</c><c>stands for Internet of Things.</c>
</texttable>
</section>
<section anchor="algs" title="Algorithm Selection">
<section anchor="algs_enc" title="Type 1 - IKEv2 Encryption Algorithm Transforms">
<t> The algorithms in the below table are negotiated in the SA
payload and used for the Encrypted Payload. References to the
specification defining these algorithms and the ones in the
following subsections are in the IANA registry <xref
target="IKEV2-IANA"/>. Some of these algorithms are
Authenticated Encryption with Associated Data (AEAD - <xref
target="RFC5282" />). Algorithms that are not AEAD MUST be
used in conjunction with an integrity algorithms in <xref
target="algs_integ"/>.</t>
<texttable anchor="tbl_enc" suppress-title="true">
<ttcol align="left">Name</ttcol>
<ttcol align="left">Status</ttcol>
<ttcol>AEAD?</ttcol>
<ttcol align="left">Comment</ttcol>
<c>ENCR_AES_CBC</c><c>MUST</c><c>No</c><c>(1)</c>
<c>ENCR_CHACHA20_POLY1305</c><c>SHOULD</c><c>Yes</c><c/>
<c>ENCR_AES_GCM_16</c><c>SHOULD</c><c>Yes</c><c>(1)</c>
<c>ENCR_AES_CCM_8</c><c>SHOULD</c><c>Yes</c><c>(IoT)</c>
<c>ENCR_3DES</c><c>MAY</c><c>No</c><c/>
<c>ENCR_DES</c><c>MUST NOT</c><c>No</c><c/>
<postamble>
(1) - This requirement level is for 128-bit and 256-bit keys.
192-bit keys remain at MAY level.
(IoT) - This requirement is for interoperability with IoT. Only
128-bit keys are at SHOULD level. 192-bit and 256-bit remain
at the MAY level.
</postamble>
</texttable>
<t> ENCR_AES_CBC is raised from SHOULD+ for 128-bit keys and
MAY for 256-bit keys in <xref
target="RFC4307"/> to MUST. 192-bit keys remain at the MAY level.
ENCR_AES_CBC is the only shared mandatory-to-implement algorithm with
RFC4307 and as a result it is necessary for interoperability with IKEv2
implementation compatible with RFC4307.</t>
<t> ENCR_CHACHA20_POLY1305 was not ready to be considered at
the time of 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 same reasons. At the time of writing, there were
not enough IKEv2 implementations supporting ENCR_CHACHA20_POLY1305
to be able to introduce it at the SHOULD+ level.</t>
<t> 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 defined for ESP in <xref
target="RFC4106"/> and later for IKEv2 in <xref
target="RFC5282"/>. The main motivation for adopting AES-GCM
for ESP is encryption performance and key longevity compared
to AES-CBC. This resulted in AES-GCM being widely implemented
for ESP. As the computation load of IKEv2 is relatively small
compared to ESP, many IKEv2 implementations have not
implemented AES-GCM. For this reason, AES-GCM is not promoted
to a greater status than SHOULD. The reason for promotion from
MAY to SHOULD is to promote the slightly more secure AEAD
method over the traditional encrypt+auth method. Its status is
expected to be raised once widely implemented. As the
advantage of the shorter (and weaker) ICVs is minimal, the 8
and 12 octet ICV's remain at the MAY level.</t>
<t> ENCR_AES_CCM_8 was not considered in RFC4307. This
document 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 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 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 level
is for 128-bit keys, 256-bit keys remains at MAY level.</t>
<t> ENCR_3DES has been downgraded from RFC4307 MUST- to SHOULD
NOT. All IKEv2 implementation already implement ENCR_AES_CBC,
so there is no need to keep support for the much slower
ENCR_3DES. In addition, ENCR_CHACHA20_POLY1305 provides a more
modern alternative to AES.</t>
<t> ENCR_DES can be brute-forced using of-the-shelves
hardware. It provides no meaningful security whatsoever and
therefor MUST NOT be implemented.</t>
</section>
<section anchor="algs_prf" title="Type 2 - IKEv2 Pseudo-random Function Transforms">
<t> Transform Type 2 algorithms are pseudo-random functions
used to generate pseudo-random values when needed.</t>
<texttable anchor="tbl_alg2" suppress-title="true">
<ttcol align="left">Name</ttcol>
<ttcol align="left">Status</ttcol>
<ttcol align="left">Comment</ttcol>
<c>PRF_HMAC_SHA2_256</c><c>MUST</c><c></c>
<c>PRF_HMAC_SHA2_512</c><c>SHOULD+</c><c></c>
<c>PRF_HMAC_SHA1</c><c>MUST-</c><c></c>
<c>PRF_AES128_XCBC</c><c>SHOULD</c><c>(IoT)</c>
<c>PRF_HMAC_MD5</c><c>MUST NOT</c><c></c>
<postamble>
(IoT) - This requirement is for interoperability with IoT
</postamble>
</texttable>
<t>As no SHA2 based transforms were referenced in RFC4307,
PRF_HMAC_SHA2_256 was not mentioned in RFC4307. PRF_HMAC_SHA2_256
MUST be implemented in order to replace SHA1 and PRF_HMAC_SHA1.</t>
<t> PRF_HMAC_SHA2_512 SHOULD be implemented as a future
replacement for PRF_HMAC_SHA2_256 or when stronger security is
required. PRF_HMAC_SHA2_512 is preferred over
PRF_HMAC_SHA2_384, as the additional overhead of
PRF_HMAC_SHA2_512 is negligible.</t>
<t> PRF_HMAC_SHA1 has been downgraded from MUST in RFC4307 to
MUST- as cryptographic attacks against SHA1 are increasing,
resulting in an industry-wide trend to deprecate its usage</t>
<t> PRF_AES128_XCBC is only recommended in the scope of IoT,
as Internet of Things deployments tend to prefer AES based
pseudo-random functions in order to avoid implementing SHA2.
For the non-IoT VPN deployment it has been downgraded from
SHOULD in RFC4307 to MAY as it has not seen wide adoption.</t>
<t>PRF_HMAC_MD5 has been downgraded from MAY in RFC4307 to
MUST NOT. Cryptographic attacks against MD5, such as
collision attacks mentioned in <xref target="TRANSCRIPTION"/>,
are resulting in an industry-wide trend to deprecate and
remove MD5 (and thus HMAC-MD5) from cryptographic libraries.</t>
</section>
<section anchor="algs_integ" title="Type 3 - IKEv2 Integrity Algorithm Transforms">
<t> The algorithms in the below table are negotiated in the SA
payload and used for the Encrypted Payload. References to the
specification defining these algorithms are in the IANA
registry. When an AEAD algorithm (see <xref
target="algs_enc"/>) is proposed, this algorithm transform
type is not in use.</t>
<texttable anchor="tbl_alg3" suppress-title="true">
<ttcol align="left">Name</ttcol>
<ttcol align="left">Status</ttcol>
<ttcol align="left">Comment</ttcol>
<c>AUTH_HMAC_SHA2_256_128</c><c>MUST</c><c></c>
<c>AUTH_HMAC_SHA2_512_256</c><c>SHOULD</c><c></c>
<c>AUTH_HMAC_SHA1_96</c><c>MUST-</c><c></c>
<c>AUTH_AES_XCBC_96</c><c>SHOULD</c><c>(IoT)</c>
<c>AUTH_HMAC_MD5_96</c><c>MUST NOT</c><c></c>
<c>AUTH_DES_MAC</c><c>MUST NOT</c><c></c>
<c>AUTH_KPDK_MD5</c><c>MUST NOT</c><c></c>
<postamble>
(IoT) - This requirement is for interoperability with IoT
</postamble>
</texttable>
<t> AUTH_HMAC_SHA2_256_128 was not mentioned in RFC4307, as no
SHA2 based transforms were mentioned. AUTH_HMAC_SHA2_256_128
MUST be implemented in order to replace AUTH_HMAC_SHA1_96.</t>
<t> AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future
replacement of AUTH_HMAC_SHA2_256_128 or when stronger
security is required. This value has been preferred over
AUTH_HMAC_SHA2_384, as the additional overhead of
AUTH_HMAC_SHA2_512 is negligible.</t>
<t> AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307
to MUST- as cryptographic attacks against SHA1 are increasing,
resulting in an industry-wide trend to deprecate its usage</t>
<t> AUTH_AES_XCBC_96 is only recommended in the scope of IoT, as
Internet of Things deployments tend to prefer AES based
pseudo-random functions in order to avoid implementing SHA2.
For the non-IoT VPN deployment, it has been downgraded from
SHOULD in RFC4307 to MAY as it has not been widely adopted.
</t>
<t> AUTH_DES_MAC, AUTH_HMAC_MD5_96, and AUTH_KPDK_MD5 were not
mentioned in RFC4307 so their default status ware MAY. They
have been downgraded to MUST NOT. There is an industry-wide
trend to deprecate DES and MD5. MD5 support is being removed
from cryptographic libraries in general because its non-HMAC
use is known to be subject to collision attacks, for example
as mentioned in <xref target="TRANSCRIPTION"/>.</t>
</section>
<section anchor="algs_dh" title="Type 4 - IKEv2 Diffie-Hellman Group Transforms">
<t> There are several Modular Exponential (MODP) groups and
several Elliptic Curve groups (ECC) that are defined for use
in IKEv2. These groups are defined in both the <xref target="RFC7296"/> base
document and in extensions documents and are identified by
group number. Note that it is critical to enforce a secure
Diffie-Hellman exchange as this 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), then the
attacker can compute the secret and the keys used and decrypt
the exchange and IPsec SA created inside the IKEv2 SA. Such an
attack can be performed off-line on a previously recorded
communication, years after the communication happened. This
differs from attacks that need to be executed during the
authentication which must be performed online and in near
real-time.</t>
<texttable anchor="tbl_dh" suppress-title="true">
<ttcol align="left">Number</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Status</ttcol>
<c>14</c><c>2048-bit MODP Group</c><c>MUST</c>
<c>19</c><c>256-bit random ECP group</c><c>SHOULD</c>
<c>5</c><c>1536-bit MODP Group</c><c>SHOULD NOT</c>
<c>2</c><c>1024-bit MODP Group</c><c>SHOULD NOT</c>
<c>1</c><c>768-bit MODP Group</c><c>MUST NOT</c>
<c>22</c><c>1024-bit MODP Group with 160-bit Prime Order Subgroup</c><c>MUST NOT</c>
<c>23</c><c>2048-bit MODP Group with 224-bit Prime Order Subgroup</c><c>SHOULD NOT</c>
<c>24</c><c>2048-bit MODP Group with 256-bit Prime Order Subgroup</c><c>SHOULD NOT</c>
</texttable>
<t> 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 implemented and considered secure.</t>
<t> Group 19 or 256-bit random ECP group was not specified in
RFC4307, as this group were not defined at that time. Group
19 is widely implemented and considered secure.</t>
<t> Group 5 or 1536-bit MODP Group has been downgraded from
MAY in RFC4307 to SHOULD NOT. It was specified earlier, but is
now considered to be vulnerable to be broken within the next
few years by a nation state level attack, so its security
margin is considered too narrow.</t>
<t> 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 funded attackers using commercially available
mass-computing resources, so its security margin is considered
too narrow. It is expected in the near future to be downgraded
to MUST NOT.</t>
<t> 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-shelves hardware. It provides no security
whatsoever.</t>
<t> Group 22, 23 and 24 are MODP Groups with Prime Order
Subgroups thater are not safe-primes. The seeds for these
groups have not been publicly released, resulting in reduced
trust in these groups. These 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 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 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. Since Group 23 and 24
have small subgroups, the checks specified in "Additional
Diffie-Hellman Test for the IKEv2" <xref target="RFC6989"/>
section 2.2 first bullet point MUST be done when these groups
are used.</t>
</section>
<section anchor="summ_chang" title="Summary of Changes from RFC 4307">
<t> The following table summarizes the changes from RFC 4307.</t>
<t> RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH AND REPLACE XXXX IN
THE TABLE BELOW WITH THE NUMBER OF THIS RFC</t>
<texttable anchor="tbl_summ" suppress-title="true">
<ttcol align="left">Algorithm</ttcol>
<ttcol align="center">RFC 4307</ttcol>
<ttcol align="center">RFC XXXX</ttcol>
<c>ENCR_3DES</c><c>MUST-</c><c>MAY</c>
<c>ENCR_NULL</c><c>MUST NOT[errata]</c><c>MUST NOT</c>
<c>ENCR_AES_CBC</c><c>SHOULD+</c><c>MUST</c>
<c>ENCR_AES_CTR</c><c>SHOULD</c><c>(*)</c>
<c>PRF_HMAC_MD5</c><c>MAY</c><c>MUST NOT</c>
<c>PRF_HMAC_SHA1</c><c>MUST</c><c>MUST-</c>
<c>PRF_AES128_XCBC</c><c>SHOULD+</c><c>SHOULD</c>
<c>AUTH_HMAC_MD5_96</c><c>MAY</c><c>MUST NOT</c>
<c>AUTH_HMAC_SHA1_96</c><c>MUST</c><c>MUST-</c>
<c>AUTH_AES_XCBC_96</c><c>SHOULD+</c><c>SHOULD</c>
<c>Group 2 (1024-bit)</c><c>MUST-</c><c>SHOULD NOT</c>
<c>Group 14 (2048-bit)</c><c>SHOULD+</c><c>MUST</c>
<postamble>(*) This algorithm is not mentioned in the above sections,
so it defaults to MAY.</postamble>
</texttable>
</section>
</section>
<section title="IKEv2 Authentication">
<t>IKEv2 authentication may involve a signatures verification.
Signatures may be used to validate a certificate or to check the
signature of the AUTH value. Cryptographic recommendations
regarding certificate validation are out of scope of this
document. What is mandatory to implement is provided by the PKIX
Community. This document is mostly concerned on signature
verification and generation for the authentication.</t>
<section anchor="auth" title="IKEv2 Authentication Method">
<texttable anchor="tbl_auth" suppress-title="true">
<ttcol align="left">Number</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Status</ttcol>
<c>1</c><c>RSA Digital Signature</c><c>MUST</c>
<c>2</c><c>Shared Key Message Integrity Code</c><c>MUST</c>
<c>3</c><c>DSS Digital Signature</c><c>SHOULD NOT</c>
<c>9</c><c>ECDSA with SHA-256 on the P-256 curve</c><c>SHOULD</c>
<c>10</c><c>ECDSA with SHA-384 on the P-384 curve</c><c>SHOULD</c>
<c>11</c><c>ECDSA with SHA-512 on the P-521 curve</c><c>SHOULD</c>
<c>14</c><c>Digital Signature</c><c>SHOULD</c>
</texttable>
<t> RSA Digital Signature is widely deployed and therefore
kept for 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 longer recommended. RSA
authentication, as well as other specific Authentication
Methods, are expected to be replaced with the generic Digital
Signature method of <xref target="RFC7427"/>. RSA Digital
Signature is not recommended for keys smaller then 2048, but
since these signatures only have value in real-time, and need
no future protection, smaller keys was kept at SHOULD NOT
instead of MUST NOT.</t>
<t>Shared Key Message Integrity Code is widely deployed and
mandatory to implement in the IKEv2 in the RFC7296.</t>
<t> ECDSA based Authentication Methods are also expected to be
downgraded as it does not provide hash function agility.
Instead, ECDSA (like RSA) is expected to be performed using
the generic Digital Signature method.</t>
<t> 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 NOT in the future.</t>
<t> Digital Signature <xref target="RFC7427"/> is expected to
be promoted as it provides hash function, signature format and
algorithm agility.</t>
<section anchor="auth_rsa" title="Recommendations for RSA key length">
<texttable anchor="tbl_auth_keysize" suppress-title="true">
<ttcol align="left">Description</ttcol>
<ttcol align="left">Status</ttcol>
<c>RSA with key length 2048</c><c>MUST</c>
<c>RSA with key length 3072 and 4096</c><c>SHOULD</c>
<c>RSA with key length between 2049 and 4095</c><c>MAY</c>
<c>RSA with key length smaller than 2048</c><c>SHOULD NOT</c>
</texttable>
<t>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.</t>
</section>
</section>
<section title="Digital Signature Recommendations">
<t>When Digital Signature authentication method is
implemented, then the following recommendations are applied
for hash functions:</t>
<texttable anchor="tbl_hash" suppress-title="true">
<ttcol align="left">Number</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Status</ttcol>
<ttcol align="left">Comment</ttcol>
<c>1</c><c>SHA1</c><c>MUST NOT</c><c></c>
<c>2</c><c>SHA2-256</c><c>MUST</c><c></c>
<c>3</c><c>SHA2-384</c><c>MAY</c><c></c>
<c>4</c><c>SHA2-512</c><c>SHOULD</c><c></c>
</texttable>
<t>When Digital Signature authentication method is used with
RSA signature algorithm, then RSASSA-PSS MUST be supported and
RSASSA-PKCS1-v1.5 MAY be supported.</t>
<t>The following table lists recommendations for
authentication methods in RFC7427 <xref target="RFC7427"/>
notation. These recommendations are applied only if Digital
Signature authentication method is implemented.</t>
<texttable anchor="tbl_auth_methods_apply" suppress-title="true">
<ttcol align="left">Description</ttcol>
<ttcol align="left">Status</ttcol>
<ttcol align="left">Comment</ttcol>
<c>RSASSA-PSS with SHA-256</c><c>MUST</c><c></c>
<c>ecdsa-with-sha256</c><c>SHOULD</c><c></c>
<c>sha1WithRSAEncryption</c><c>MUST NOT</c><c></c>
<c>dsa-with-sha1</c><c>MUST NOT</c><c></c>
<c>ecdsa-with-sha1</c><c>MUST NOT</c><c></c>
<c>RSASSA-PSS with Empty Parameters</c><c>MUST NOT</c><c>(*)</c>
<c>RSASSA-PSS with Default Parameters</c><c>MUST NOT</c><c>(*)</c>
<postamble>(*) Empty or Default parameters means it is using SHA1, which
is at level MUST NOT.</postamble>
</texttable>
</section>
</section>
<section title="Algorithms for Internet of Things">
<t>Some algorithms in this document are marked for use with the
Internet of Things (IoT). There are several reasons why IoT
devices prefer a different set of algorithms from regular IKEv2
clients. IoT devices are usually very constrained, meaning the
memory size and CPU power is so limited, that these clients only
have resources to implement and run one set of algorithms. For
example, instead of implementing AES and SHA, these devices
typically use AES_XCBC as integrity algorithm so SHA does not
need to be implemented.</t>
<t>For example, IEEE Std 802.15.4 <xref target="IEEE-802-15-4" />
devices have a mandatory to implement link level security using
AES-CCM with 128 bit keys. The IEEE Recommended Practice for
Transport of Key Management Protocol (KMP) Datagrams <xref
target="IEEE-802-15-9" /> already provide a way to use Minimal
IKEv2 <xref target="RFC7815" /> over 802.15.4 to provide link
keys for the 802.15.4 layer.</t>
<t>These devices might want to use AES-CCM as their IKEv2
algorithm, so they can reuse the hardware implementing it. They
cannot use the AES-CBC algorithm, as the hardware quite often do
not include support for AES decryption needed to support the CBC
mode. So despite the AES-CCM algorithm requiring AEAD <xref
target="RFC5282" /> support, the benefit of reusing the crypto
hardware makes AES-CCM the preferred algorithm.</t>
<t>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 they transmit has an energy consumption
cost associated with it and shortens their battery life.
Therefore, shorter packets are preferred. This is the reason for
recommending the 8 octet ICV over the 16 octet ICV.</t>
<t>Because different IoT devices will have different
constraints, this document cannot specify the one mandatory
profile for IoT. Instead, this document points out commonly used
algorithms with IoT devices.
</t>
</section>
<section anchor="security" title="Security Considerations">
<t> The security of cryptographic-based systems depends on both
the strength of the cryptographic algorithms chosen and the
strength of the keys used with those algorithms. The security
also depends on the engineering of the protocol used by the
system to ensure that there are no non-cryptographic ways to
bypass the security of the overall system.</t>
<t> The Diffie-Hellman Group parameter is the most important one
to choose conservatively. Any party capturing all IKE and ESP
traffic that (even years later) can break the selected DH group
in IKE, can gain access to the symmetric keys used to encrypt
all the ESP traffic. Therefore, these groups must be chosen very
conservatively. However, specifying an extremely large DH group
also puts a considerable load on the device, especially when
this is a large VPN gateway or an IoT constrained device.</t>
<t> This document concerns itself with the selection of
cryptographic algorithms for the use of IKEv2, specifically with
the selection of "mandatory-to-implement" algorithms. The
algorithms identified in this document as "MUST implement" or
"SHOULD implement" are not known to be broken at the current
time, and cryptographic research so far leads us to believe that
they will likely remain secure into the foreseeable future.
However, this isn't necessarily forever and it is expected that
new revisions of this document will be issued from time to time
to reflect the current best practice in this area.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document renames some of the names in the "Transform Type
1 - Encryption Algorithm Transform IDs" registry of the "Internet
Key Exchange Version 2 (IKEv2) Parameters". All the other names
have ENCR_ prefix except 3, and all other entries use names in
format of uppercase words separated with underscores except 6.
This document changes those names to match others.</t>
<t>This document requests IANA to rename following entries for the
AES-GCM cipher <xref target="RFC4106"/> and the Camellia cipher
<xref target="RFC5529"/>:</t>
<texttable anchor="iana_rename" suppress-title="true">
<ttcol align="left">Old name</ttcol>
<ttcol align="left">New name</ttcol>
<c>AES-GCM with a 8 octet ICV</c><c>ENCR_AES_GCM_8</c>
<c>AES-GCM with a 12 octet ICV</c><c>ENCR_AES_GCM_12</c>
<c>AES-GCM with a 16 octet ICV</c><c>ENCR_AES_GCM_16</c>
<c>ENCR_CAMELLIA_CCM with an 8-octet
ICV</c><c>ENCR_CAMELLIA_CCM_8</c>
<c>ENCR_CAMELLIA_CCM with a 12-octet
ICV</c><c>ENCR_CAMELLIA_CCM_12</c>
<c>ENCR_CAMELLIA_CCM with a 16-octet
ICV</c><c>ENCR_CAMELLIA_CCM_16</c>
</texttable>
<t>In addition to add this RFC as reference to both ESP
Reference and IKEv2 Reference columns for ENCR_AES_GCM entries,
keeping the current references there also, and also add this RFC
as reference to the ESP Reference column for ENCR_CAMELLIA_CCM
entries, keeping the current reference there also.</t>
<t>The final registry entries should be:</t>
<figure><artwork><![CDATA[
Number Name ESP Reference IKEv2 Reference
...
18 ENCR_AES_GCM_8 [RFC4106][RFCXXXX] [RFC5282][RFCXXXX]
19 ENCR_AES_GCM_12 [RFC4106][RFCXXXX] [RFC5282][RFCXXXX]
20 ENCR_AES_GCM_16 [RFC4106][RFCXXXX] [RFC5282][RFCXXXX]
...
25 ENCR_CAMELLIA_CCM_8 [RFC5529][RFCXXXX] -
26 ENCR_CAMELLIA_CCM_12 [RFC5529][RFCXXXX] -
27 ENCR_CAMELLIA_CCM_16 [RFC5529][RFCXXXX] -
]]></artwork></figure>
</section>
<section anchor="ack" title="Acknowledgements">
<t> The first version of this document was RFC 4307 by Jeffrey
I. Schiller of the Massachusetts Institute of Technology (MIT).
Much of the original text has been copied verbatim.</t>
<t> We would like to thank Paul Hoffman, Yaron Sheffer, John
Mattsson and Tommy Pauly for their valuable feedback.</t>
</section>
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References">
&rfc2119;
&rfc4106;
&rfc4307;
&rfc7296;
&rfc5282;
</references>
<references title="Informative References">
&rfc7427;
&rfc6989;
&rfc7815;
&rfc5529;
<reference anchor="IKEV2-IANA" target="http://www.iana.org/assignments/ikev2-parameters">
<front>
<title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>
<author initials="" surname="" fullname="">
<organization />
</author>
<date />
</front>
</reference>
<reference anchor="TRANSCRIPTION">
<front>
<title>Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH</title>
<author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhargavan">
<organization>INRIA</organization>
</author>
<author initials="G." surname="Leurent" fullname=" Gaetan Leurent">
<organization>INRIA</organization>
</author>
<date month="feb" year="2016" />
</front>
<seriesInfo name="NDSS" value="" />
</reference>
<reference anchor='IEEE-802-15-4'>
<front>
<title>IEEE Standard for Low-Rate Wireless Personal Area
Networks (WPANs)</title>
<author></author>
<date year='2015'/>
</front>
<seriesInfo name="IEEE" value="Standard 802.15.4" />
</reference>
<reference anchor='IEEE-802-15-9'>
<front>
<title>IEEE Recommended Practice for Transport of Key
Management Protocol (KMP) Datagrams</title>
<author></author>
<date year='2016'/>
</front>
<seriesInfo name="IEEE" value="Standard 802.15.9" />
</reference>
</references>
<!-- ====================================================================== -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:16:10 |