Skip to content

Update draft-ietf-ipsecme-rfc4307bis #8

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
Dec 31, 2015
Merged

Update draft-ietf-ipsecme-rfc4307bis #8

Changes from all commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
7a3a139
Update draft-ietf-ipsecme-rfc4307bis
mglt Nov 9, 2015
d2d31f6
addding comments from Yoav
mglt Nov 9, 2015
0b2696a
updating with Yaron feed backs
mglt Nov 16, 2015
b65c722
Update draft-ietf-ipsecme-rfc4307bis
mglt Nov 18, 2015
1854f98
update status for AUTH_AES_XCBC_96 to SHOULD
mglt Nov 20, 2015
8c125fa
considering IoT use case
mglt Nov 26, 2015
ef72ea4
adding subsection in the introduction
mglt Dec 2, 2015
9252c3d
nits correcting algorithm
mglt Dec 2, 2015
ffb6e9a
nits subsection comments from Yaron
mglt Dec 2, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
181 changes: 142 additions & 39 deletions draft-ietf-ipsecme-rfc4307bis
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,8 @@

<!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 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">
]>
Expand Down Expand Up @@ -87,12 +89,16 @@
<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>

<section title="Updating Mandatory to Implement Algorithms">
<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
Expand All @@ -102,11 +108,45 @@
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>
</section>

<section title="Updating Algorithm Requirement Levels">
<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>

<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 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 in order 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, so to provide sufficient
time for various implementations to simultaneously update their 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>If IKEv2 has been until now mostly used for VPNs, the current trend toward Internet of Things and its
adoption of IKEv2 brought us to consider this specific use case. IoT devices are resource
constrainted devices and their choice of algorithms are motivated by minimizing
the fooprint of the code, the computation or the size of the messages to send. This document indicates
IoT when the specified algorithm is especially targeted for IoT devices.</t>
</section>

<section title="Document Audience">
<t>The recommendations of this document target IKEv2 implementers. In other words, the recommendations
should not be considered for IKEv2 configuration, as a preference for some algorithms.</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.</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",
Expand All @@ -123,10 +163,12 @@
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>
<c>IoT</c><c>stands for Internet of Things.</c>
</texttable>
</section>
<section anchor="algs" title="Algorithm Selection">
<section anchor="algs_enc" title="IKEv2 Transform Type 1 Algorithms">

<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 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
Expand All @@ -140,52 +182,106 @@
<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_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.</postamble>
<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> 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>
<t> ENCR_AES_CBC is raised from SHOULD+ in RFC4307. It is the only shared mandatory-to-implement algorithm
with RFC4307 and as a result is necessary for interoperability with IKEv2 implementation compatible with
RFC4307.</t>
<t> ENCR_CHACHA20_POLY1305 was not considered as mandatory-to-implement in RFC4307. At the time RFC4307 was
written, ENCR_CHACHA20_POLY1305 was not defined in an IETF document. This document considers
it SHOULD be implemented as it is next to be implemented for IPsec as an alternative to AES. At the time
of writing this document, we are not aware of any IKEv2 implementing ENCR_CHACHA20_POLY1305 which refrains us
from setting its status to SHOULD+.</t>
<t> AES-GCM with a 16 octet ICV was not considered as mandatory-to-implement in RFC4307. At the time RFC4307
was written, AES-GCM was not defined in an IETF document. AES-GCM was defined for IPsec/ESP in
<xref target="RFC4106"/> and later for IKEv2 in <xref target="RFC5282"/>. The main motivation for adopting
AES-GCM for IPSec/ESP is encryption performance as well as key longevity - compared to AES-CBC for example.
This resulted in AES-GCM widely implemented for IPsec/ESP. As the load of IKEv2 is expected to remain
relatively small, many IKEv2 implementations do not include AES-GCM yet. In addition to its former MAY, this document
does not promote AES-GCM to a greater status than SHOULD so to preserve interoperability between IKEv2
implementations. This document considers AES-GCM as mandatory to implement in an effort to provide AEAD.
Its status is expected to be raised once widely deployed. </t>
<t> ENCR_AES_CCM_8 was not considered as mandatory-to-implement in RFC4307. This document considers it
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 VPNs, its status is expected to remain to SHOULD. The size of the ICV is
expected to be sufficient for most use cases of IKEv2, as far less packets are exchanged on the IKE_SA
compared to the IPsec SA. When implemented, ENCR_AES_CCM_8 MUST be implemented for both key length 128
and 256 bytes.</t>
<t> ENCR_3DES has been downgraded from RFC4307 MUST-. All IKEv2 implementation already implement
ENCR_AES_CBC, so there is no need to keep ENCR_3DES. In addition, ENCR_CHACHA20_POLY1305 provides a more
efficient alternative to AES.</t>
<t> ENCR_DES is known to be insecure and so MUST NOT be implemented.</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">


<section anchor="algs_prf" title="Type 2 - IKEv2 Pseudo-random Function Transforms">
<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>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>
<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_CBC</c><c>SHOULD</c><c>[IoT]</c>
<postamble>
[IoT] - This requirement is for interoperability with IoT
</postamble>
</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>
<t> PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2 based authentication was 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 as a future replacement of SHA2_256 or when stronger
security is required. This value has been preferred to PRF_HMAC_SHA2_384, as the overhead of
PRF_HMAC_SHA2_512 is negligible.</t>
<t> PRF_HMAC_SHA1_96 has been downgraded from MUST in RFC4307.
There is an industry-wide trend to deprecate its usage.</t>
<t> PRF_AES128_CBC has been downgraded from SHOULD in RFC4307 as it is not being deployed.
In order to provide compatibility between IKEv2 implementations, this document would not
envision to downgrade any further to a MAY for example. On the other hand, this document
considers new cases outside the VPN cases to keep it to a SHOULD status. This
document considers it SHOULD be implemented
in order to be able to interact with Internet of Things devices. Internet of Things might use
AES based pseudo-random function in order to avoid implementing SHA2, and use their implementation
of AES. As this case is not a general use case for VPNs, its status is expected to remain a SHOULD.</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">

<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 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>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>
<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>
<postamble>
[IoT] - This requirement is for interoperability with IoT
</postamble>
</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>
<t> AUTH_HMAC_SHA2_256_128 was not mentioned in RFC4307, as no SHA2 based authentication was mentioned.
AUTH_HMAC_SHA2_256_128 MUST be implemented in order to replace SHA1 and AUTH_HMAC_SHA1_96.</t>
<t> AUTH_HMAC_SHA2_512_256 SHOULD be implemented as as a future replacement of SHA2_128 or when stronger
security is required. This value has been preferred to AUTH_HMAC_SHA2_384, as the overhead of
AUTH_HMAC_SHA2_512 is negligible.</t>
<t> AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307.
There is an industry-wide trend to deprecate its usage.</t>
<t> AUTH_AES-XCBC has been kept as SHOULD in RFC4307. This document considers it SHOULD be implemented
in order to be able to interact with Internet of Things devices. Internet of Things might use
AES based pseudo-random function in order to avoid implementing SHA2, and use their implementation
of AES. As this case is not a general use case for VPNs, its status is expected to remain a SHOULD.</t>
</section>
<section anchor="algs_dh" title="Diffie-Hellman Groups">

<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. They are defined in both the [IKEv2] base document and in extensions documents.
They are identified by group number.</t>
Expand All @@ -198,10 +294,14 @@
<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>
<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.
Group 19 is widely implemented and considered secure</t>
<t> Group 2 or 1024-bit MODP Group is downgrade from MUST- to SHOULD NOT.
It was specified earlier, and now it is known to be weak against a nation state attack,
so its security margin is considered too narrow.</t>
<t> Group 1 or 768-bit MODP Group is known to be unsecured for several years.</t>
</section>
</section>

Expand All @@ -223,12 +323,15 @@
<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 thanks Paul Hoffman, Yaron Sheffer and Tommy Pauly for their valuable feed backs.</t>
</section>
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References">
&rfc2119;
&rfc4106;
&rfc4307;
&rfc7296;
&rfc5282;
</references>
Expand Down