One document matched: draft-ietf-ipsecme-rfc4307bis-05.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">
]>
<?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-05" 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 defines the current
algorithm implementation requirements and usage guidance for
IKEv2. 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 cryptograhic algorithms is
defined.</t>
<t> This document describes the parameters of the IKE protocol.
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
set to 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.</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. On the other hand, comments and
recommendations from this document are also expected to be
useful for such users.</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>AES-GCM with a 16 octet ICV</c><c>SHOULD</c><c>Yes</c><c>[1]</c>
<c>ENCR_AES_CCM_8</c><c>SHOULD</c><c>Yes</c><c>[1][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 keys. 256-bit
keys are at MAY. 192-bit keys can safely be ignored.
[IoT] - This requirement is for interoperability with IoT.
</postamble>
</texttable>
<t> ENCR_AES_CBC is raised from SHOULD+ in <xref
target="RFC4307"/> to MUST. It 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 and
others 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> AES-GCM with a 16 octet ICV 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. When implemented,
ENCR_AES_CCM_8 MUST be implemented for key length 128 and MAY
be implemented for key length 256.</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 pseudorandom values when needed.</t>
<t> 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 needs to be made. The table below lists the
recommended algorithms.</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> PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2
based transforms were mentioned. 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 their is 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. There is an industry-wide trend to deprecate its
usage as 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_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 there is an industry-wide trend to deprecate its
usage.</t>
<t> AUTH_AES-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 been widely adopted.
</t>
<t> AUTH_HMAC_MD5_96, AUTH_DES_MAC and AUTH_KPDK_MD5 were not
mentioned in RFC4307 so its default status was MAY. It has
been downgraded to MUST NOT. There is an industry-wide trend
to deprecate its usage. 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 [IKEv2] 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>SHOULD 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 specified 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 or 1024-bit MODP Group with 160-bit,
and 2048-bit MODP Group with 224-bit and 256-bit Prime Order
Subgroup have small subgroups, which means that checks
specified in the "Additional Diffie-Hellman Test for the
IKEv2" <xref target="RFC6989"/> section 2.2 first bullet point
MUST be done when these groups are used. These groups are also
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 is expected in the near
future to be further downgraded to MUST NOT.</t>
</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>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> 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 smaler than 2048</c><c>SHOULD NOT</c>
</texttable>
</section>
</section>
<section title="Digital Signature Recommendations">
<t>Recommendations for when a hash function is involved in a
signature:</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>SHOULD 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>With the use of Digital Signature, RSASSA-PKCS1-v1.5 MAY be
implemented. RSASSA-PSS MUST be implemented.</t>
<t>Recommendation of Authentication Method described in <xref
target="RFC7427"/> notation:</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>SHOULD</c><c></c>
<c>ecdsa-with-sha256</c><c>SHOULD</c><c></c>
<c>sha1WithRSAEncryption</c><c>SHOULD NOT</c><c></c>
<c>dsa-with-sha1</c><c>SHOULD NOT</c><c></c>
<c>ecdsa-with-sha1</c><c>SHOULD NOT</c><c></c>
<c>RSASSA-PSS with Empty Parameters</c><c>SHOULD NOT</c><c></c>
<c>RSASSA-PSS with Default Parameters</c><c>SHOULD NOT</c><c></c>
<c>sha256WithRSAEncryption</c><c>MAY</c><c></c>
<c>sha384WithRSAEncryption</c><c>MAY</c><c></c>
<c>sha512WithRSAEncryption</c><c>MAY</c><c></c>
<c>sha512WithRSAEncryption</c><c>MAY</c><c></c>
<c>dsa-with-sha256</c><c>MAY</c><c></c>
<c>ecdsa-with-sha384</c><c>MAY</c><c></c>
<c>ecdsa-with-sha512</c><c>MAY</c><c>?SHOULD</c>
</texttable>
</section>
</section>
<section title="Algorithms for Internet of Things">
<t>Some algorithms in this document are marked for the Internet
of Things (IoT). There are several reasons why the IoT devices
want have different set of algorithms than other users of IKEv2.
Those devices are usually very constrained, meaning the memory
size and cpu power is so limited, that they want to implement
just minimal set of algorithms. This means they quite often only
implement one algorithm and pick it so that the same algorithm
is already implemented in software or hardware for other
users.</t>
<t>For example IEEE Std 802.15.4 <xref target="IEEE-802-15-4" />
devices has 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 provides a way to use Minimal
IKEv2 <xref target="RFC7815" /> over 802.15.4 to provide link
keys for the 802.15.4.</t>
<t>Those 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, as the hardware quite often do not
include support for AES decryption needed for it. So even when
AES-CCM algorithm support requires support for the AEAD <xref
target="RFC5282" /> support for IKEv2, the benefit of reusing
crypto hardware makes it worthwhile.</t>
<t>Other important aspects of the IoT devices, that their
transfer rates are usually quite low (in order of tens of
kbits/s), and each bit they transmit costs a lot in energy
consumption (shortening the battery life). Because of this they
usually want to use options which support shorter packets. I.e.,
using 8 octet ICV instead of 16.</t>
<t>Also as each of those IoT devices have different constraints,
we cannot specify one exact profile for them. This document
points out some algorithms commonly used in the IoT devices, but
there might be devices using different set of algorithms,
because of requirements for the environment.</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 makes no requests of IANA.</t>
</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;
<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:15:34 |