One document matched: draft-ietf-ipsecme-rfc4307bis-01.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 rfc7296 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml">
<!ENTITY rfc5282 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5282.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-01" category="std">
<front>
<title abbrev="IKEv2 Cryptographic Algorithms">Cryptographic Algorithms for Use in the Internet Key Exchange
Version 2 (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="2015"/>
<area>Security Area</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 protocol provides a mechanism to negotiate which algorithms should be used
in any given association. However, to ensure interoperability between disparate implementations, it is
necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm
that all implementations will have available. This document defines the current set of algorithms that are
mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be
promoted to mandatory at some future time.</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t> The Internet Key Exchange protocol <xref target="RFC7296" /> provides for the negotiation of cryptographic
algorithms between both endpoints of a cryptographic association. Different implementations of IPsec and IKE
may provide different algorithms. However, the IETF desires that all implementations should have some way to
interoperate. In particular, this requires that IKE define a set of mandatory-to-implement algorithms because
IKE itself uses such algorithms as part of its own negotiations. This requires that some set of algorithms be
specified as "mandatory-to-implement" for IKE.</t>
<t> The nature of cryptography is that new algorithms surface continuously and existing algorithms are
continuously attacked. An algorithm believed to be strong today may be demonstrated to be weak tomorrow.
Given this, the choice of mandatory-to-implement algorithm should be conservative so as to minimize the
likelihood of it being compromised quickly. Thought should also be given to performance considerations as
many uses of IPsec will be in environments where performance is a concern.</t>
<t> Finally, we need to recognize that the mandatory-to-implement algorithm(s) 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 this document. As the choice of algorithm changes, only this
document should need to be updated.</t>
<t> Ideally, the mandatory-to-implement algorithm of tomorrow should already be available in most implementations
of IPsec by the time it is made mandatory. To facilitate this, we will attempt to identify those algorithms
(that are known today) in this document. There is no guarantee that the algorithms we believe today may be
mandatory in the future will in fact become so. All algorithms known today are subject to cryptographic attack
and may be broken in the future.</t>
</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-.</c>
</texttable>
</section>
<section anchor="algs" title="Algorithm Selection">
<section anchor="algs_enc" title="IKEv2 Transform Type 1 Algorithms">
<t> The algorithms in the below table are negotiated in the SA payload and used in the ENCR payload.
References to the specifications 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 the 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]</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.</postamble>
</texttable>
<t> Explanation about AES-CBC is TBD.</t>
<t> Explanation about ChaCha20 is TBD.</t>
<t> Explanation about AES-GCM is TBD.</t>
<t> Explanation about AES-CCM is TBD.</t>
<t> Explanation about 3DES is TBD.</t>
<t> Explanation about DES is TBD.</t>
</section>
<section anchor="algs_integ" title="IKEv2 Transform Type 3 Algorithms">
<t> The algorithms in the below table are negotiated in the SA payload and used in the ENCR payload. References
to the specifications defining these algorithms are in the IANA registry. When an AEAD algorithm (see <xref
target="algs_enc"/>) is used, no algorithm from this table needs to be used.</t>
<texttable anchor="tbl_alg3" suppress-title="true">
<ttcol align="left">Name</ttcol>
<ttcol align="left">Status</ttcol>
<c>AUTH_HMAC_SHA2_256_128</c><c>MUST</c>
<c>AUTH_HMAC_SHA2_512_256</c><c>SHOULD+</c>
<c>AUTH_HMAC_SHA1_96</c><c>MUST-</c>
<c>AUTH_AES_XCBC_96</c><c>MAY</c>
</texttable>
<t> Explanation about SHA-256 is TBD.</t>
<t> Explanation about SHA-512 is TBD.</t>
<t> Explanation about SHA-1 is TBD.</t>
<t> Explanation about AES-XCBC is TBD.</t>
</section>
<section anchor="algs_prf" title="IKEv2 Transform Type 2 Algorithms">
<t> Transform Type 2 Algorithms are pseudo-random functions used to generate random values when needed.</t>
<texttable anchor="tbl_alg2" suppress-title="true">
<ttcol align="left">Name</ttcol>
<ttcol align="left">Status</ttcol>
<c>PRF_HMAC_SHA2_256</c><c>MUST</c>
<c>PRF_HMAC_SHA2_512</c><c>SHOULD+</c>
<c>PRF_HMAC_SHA1</c><c>MUST-</c>
<c>PRF_AES128_CBC</c><c>MAY</c>
</texttable>
<t> Explanation about SHA-256 is TBD.</t>
<t> Explanation about SHA-512 is TBD.</t>
<t> Explanation about SHA-1 is TBD.</t>
<t> Explanation about AES-XCBC is TBD.</t>
</section>
<section anchor="algs_dh" title="Diffie-Hellman Groups">
<t> There are several Modular Exponential (MODP) groups and several Elliptic Curve groups (ECC) that are
defined for use in IKEv2. They are defined in both the [IKEv2] base document and in extensions documents.
They are identified by group number.</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>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>
</texttable>
<t> Explanation about Group 14 is TBD.</t>
<t> Explanation about Group 19 is TBD.</t>
<t> Explanation about Group 2 is TBD.</t>
<t> Explanation about Group 1 is TBD.</t>
</section>
</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> 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. We would therefore expect that new revisions of this
document will be issued from time to time that 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>
</section>
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References">
&rfc2119;
&rfc7296;
&rfc5282;
</references>
<references title="Informative References">
<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>
</references>
<!-- ====================================================================== -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:15:00 |