On Fri, 9 Oct 2015, Yoav Nir wrote:
On Sep 28, 2015, at 6:10 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
Sure. Someone volunteer to write up the short draft, and that author should put
Jeff Schiller at the top of the acknowledgements, and send it to the WG.
--Paul Hoffman
A new version of I-D, draft-nir-ipsecme-rfc4307bis-00.txt
has been successfully submitted by Yoav Nir and posted to the
IETF repository.
Oops. Guess our drafts crossed the beams. I had send one to Daniel
to look at. I've attached it in case some text is useful. It was
based more on the structure of RFC 7321.
I actually like how 7321 has the tables filled with links to the
actual RFC's. (which I had not done yet myself)
Some comments on your text:
I think AES_CBC should be MUST- as it is on the way out.
I have talked with one of the AES_GCM authors and got the advise to
only use the largest octet ICV's. Why are you promoting the 8 octet
version instead of the 16 octet version? I also think AES_GCM should
be a MUST, not a SHOULD. It is the preferred algorithm at this point.
I also think 3DES probably should be a SHOULD- because it is the only
other non-AES algorithm in widespread use. While we all want it to go
away, we should do so only after chacha20-poly1305 sees more adoption.
Why is sha2-512 not a SHOULD?
Can we add a recommendation to use integ == prf for non-AEAD algorithms?
Windows uses 8192 modp, which I think should be a SHOULD. I think we
should mention modp 1536 as SHOULD- or MAY.
Can we recommend that the initial exchanges and create child sa use
the same MODP group? and that we recommend PFS for create_child_sa.
Can we recommend that a default proposal set should have at least one
MUST algorithm for each type?
Can we recommend not to apply these recommendations for IKEv1 because
that will cause more interop problems (see my draft for text)
Paul
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml";>
<!ENTITY rfc2405 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2405.xml";>
<!ENTITY rfc2409 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2409.xml";>
<!ENTITY rfc3526 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3526.xml";>
<!ENTITY rfc4106 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4106.xml";>
<!ENTITY rfc4494 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4494.xml";>
<!ENTITY rfc4543 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4543.xml";>
<!ENTITY rfc4868 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4868.xml";>
<!ENTITY rfc5114 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5114.xml";>
<!ENTITY rfc5116 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5116.xml";>
<!ENTITY rfc5282 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5282.xml";>
<!ENTITY rfc5739 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5739.xml";>
<!ENTITY rfc5903 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5903.xml";>
<!ENTITY rfc5930 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5930.xml";>
<!ENTITY rfc7296 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml";>
<!ENTITY rfc7321 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7321.xml";>
<!ENTITY rfc7634 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7634.xml";>
]>
<rfc category="std" ipr="trust200902" docName="draft-ikev2-algorithm-update-00">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="ikev2 algo update">Cryptographic Algorithm Implementation Requirements and Usage Guidance for IKEv2</title>
<author initials='P.' surname="Wouters" fullname='Paul Wouters'>
<organization>Red Hat</organization>
<address>
<email>pwout...@redhat.com</email>
</address>
</author>
<author initials='D.' surname="Migault" fullname='Daniel Migault'>
<organization>Ericsson</organization>
<address>
<email>daniel.miga...@ericsson.com</email>
</address>
</author>
<date/>
<abstract>
<t>
This document updates the Cryptographic Algorithm Implementation
Requirements for the Internet Keying Exchange protocol version 2 (IKEv2).
It also adds usage guidance to help in the selection of these algorithms.
</t>
<t>
The IKEv2 protocol makes use of various cryptographic algorithms to
provide confidentiality and/or data origin authentication before
agreeing on keying material for use with IP Security (IPsec)
To ensure interoperability between disparate implementations,
the IKEv2 standard specifies a set of mandatory-to-
implement algorithms. This document specifies the current set of
mandatory-to-implement algorithms for IKEv2, specifies
algorithms that should be implemented because they may be promoted to
mandatory at some future time, and also recommends against the
implementation of some obsolete algorithms. Usage guidance is also
provided to help the user of IKEv2 best achieve their security
goals through appropriate choices of cryptographic algorithms.
</t>
<t>
While the recommendations for this document would equally apply to IKEv1
<xref target="RFC2409"/>, no suggestions are made to update IKEv1. Most
IKEv1 implementations at this time are frozen and vendors will not be able
to update the recommended algorithms in such implementations. Updating the
IKEv1 specification would therefor lead to increased interoperability issues.
IKEv1 deployments are encouraged to upgrade to IKEv2.
</t>
<t>
This document updates RFC 7296.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The Internet Key Exchange Protocol version 2 (IKEv2), specified in
<xref target="RFC7296"/>, provides a way for two parties to perform
an authenticated key exchange.
</t>
<t>
To ensure interoperability between disparate implementations, it is
necessary to specify a set of mandatory-to-implement algorithms.
This ensures that there is at least one algorithm that all
implementations will have in common. This document specifies the
current set of mandatory-to-implement algorithms for IKEv2,
specifies algorithms that should be implemented because they may be
promoted to mandatory at some future time, and also recommends
against the implementation of some obsolete algorithms. Usage
guidance is also provided to help the user of IKEv2 best achieve
their security goals through appropriate choices of mechanisms.
</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 IKEv2 will be in environments where
performance is a concern.
</t>
<t>
The IKEv2 mandatory-to-implement algorithm(s) may need to change
over time to adapt to new developments in cryptography. For this
reason, the specification of the mandatory-to-implement algorithms is
not included in the main IKE specifications, but is
instead placed in this document. Ideally, the mandatory-to-implement
algorithm of tomorrow should already be available in most
implementations of IKE by the time it is made mandatory. To
facilitate this, this document identifies such algorithms, as they
are known today. There is no guarantee that the algorithms that we
predict will be mandatory in the future will actually be so. All
algorithms known today are subject to cryptographic attack and may be
broken in the future.
</t>
<section 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>
</section>
</section>
<section title="Implementation Requirements">
<t>
This section specifies the cryptographic algorithms that MUST be
implemented, and provides guidance about ones that SHOULD or SHOULD
NOT be implemented.
</t>
<t>
In the following sections, all AES modes are for 128-bit AES. 192-bit
and 256-bit AES MAY be supported for those modes, but the requirements
here are for 128-bit AES.
</t>
<section title="IKE Combined Mode Algorithms">
<t>
IKE Combined mode algorithms provide both confidentiality and authentication
services; in cryptographic terms, these are authenticated encryption
algorithms <xref target="RFC5116"/>. Authenticated encryption transforms
are listed in the ESP encryption transforms IANA registry.
</t>
<t>
Where multiple octet sizes for ICV's are defined, only the largest ICV size
should be used.
</t>
<t>
<figure align="center">
<artwork align="left"><![CDATA[
Requirement Authenticated Encryption Algorithm
----------- ----------------------------------
MUST AES-GCM with a 16 octet ICV [RFC5282]
SHOULD+ CHACHA20_POLY1305 [RFC7634]
MAY AES-CCM with a 16 octet ICV [RFC5282]
]]></artwork>
</figure>
</t>
</section>
<section title="IKE Encryption Algorithms">
<t>
<figure align="center">
<artwork align="left"><![CDATA[
Requirement Encryption Algorithm
----------- ----------------------------------
SHOULD- 3DES_CBC [RFC7296]
SHOULD- AES_CBC [RFC7296]
SHOULD- CANELLIA_CBC [RFC7296]
MAY AES_CTR [RFC5930]
MUST NOT DES_CBC [RFC2405]
MUST NOT BLOWFISH [RFC7296]
]]></artwork>
</figure>
</t>
</section>
<section title="IKE Authentication Algorithms">
<t>
<figure align="center">
<artwork align="left"><![CDATA[
Requirement Authentication Algorithm
----------- ----------------------------------
MUST HMAC-SHA2_256_128 [RFC4868]
MUST- HMAC-MD5 [RFC7296]
MUST- HMAC-SHA1-96 [RFC7296]
SHOULD HMAC-SHA2_384_192 [RFC4868]
SHOULD HMAC-SHA2_512_256 [RFC4868]
MAY AES-CMAC-96 [RFC4494]
MAY AES_128_GMAC [RFC4543]
MAY AES_192_GMAC [RFC4543]
MAY AES_256_GMAC [RFC4543]
]]></artwork>
</figure>
</t>
</section>
<section title="IKE Diffie-Hellman Groups">
<t>
<figure align="center">
<artwork align="left"><![CDATA[
Requirement Group
----------- ----------------------------------
MUST 2048-bit MODP Group [RFC3526]
MUST 4096-bit MODP Group [RFC3526]
MUST 8192-bit MODP Group [RFC3526]
MUST? 256-bit random ECP group [RFC5903]
MUST? 384-bit random ECP group [RFC5903]
MUST? 521-bit random ECP group [RFC5903]
SHOULD 3072-bit MODP Group [RFC3526]
SHOULD 6144-bit MODP Group [RFC3526]
MAY 192-bit Random ECP Group [RFC5114]
MAY 224-bit Random ECP Group [RFC5114]
SHOULD- 1024-bit MODP Group [RFC7296]
SHOULD- 1536-bit MODP Group [RFC7296]
MUST NOT 768-bit MODP Group [RFC7296]
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Usage Guidance">
<t>
Since in IKEv2, an IPsec SA can be created using the Initial Exchanges or the CREATE_CHILD_SA
Exchange, it is recommended to use the same Diffie-Hellman Group for these Exchanges.
</t>
</section>
<section title="Rationale">
<t>
This section explains the principles behind the implementation
requirements described above.
</t>
<t>
The algorithms listed as "MAY implement" are not meant to be endorsed
over other non-standard alternatives. Algorithms listed as "SHOULD- implement"
are currently in wide use but are expected to become less favourable in the short
term. Algorithms listed as "SHOULD+" are expected to become a MUST in the short term.
</t>
<section title="Authenticated Encryption">
<t>
This document encourages the use of authenticated encryption
algorithms because they can provide significant efficiency and
throughput advantages, and the tight binding between authentication
and encryption can be a security advantage <xref target="RFC5116"/>.
</t>
<t>
AES-GCM <xref target="RFC4106"/> brings significant performance benefits
and has emerged as the preferred authenticated encryption method in IKE,
IPsec and other standards, and is therefor set as a MUST.
</t>
<t>
CHACHA20-POLY1305 <xref target="RFC7634"/> has emerged as strong, fast
and independant alternative to AES-GCM as is therefor introduced as SHOULD+
</t>
</section>
<section title="Encryption and Authentication Algorithms">
<t>
Algorithms that require a seperate encryption and authentication step are
generally less favourable than Authenticated Encryption. Use of these
seperated algorithms is expected to decline and new seperate encryption and
authentication algorithms are unlikely to be proposed.
</t>
<t>
While the HMAC versions of MD5 and SHA1 are still considered safe, these algorithms
are seeing an ever increasing reduction in strength due to new cryptanalyses research.
The use of MD5 and SHA1 is strongly discouraged at this point.
</t>
</section>
<section title="Groups">
<t>Something about this being a warzone with no clear winners yet?
</t>
</section>
</section>
<section title="Security Considerations">
</section>
<section title="Acknowledgments">
<t>
This document leverages most text <xref target="RFC7321"/> which was written by P Hoffman
and D. McGrew.
</t>
</section>
<section title="IANA Considerations">
<t>None
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&rfc2409;
&rfc4106;
&rfc3526;
&rfc4494;
&rfc4543;
&rfc4868;
&rfc5282;
&rfc5114;
&rfc5116;
&rfc5739;
&rfc5903;
&rfc5930;
&rfc7296;
&rfc7321;
&rfc7634;
</references>
<references title='Informative References'>
&rfc2405;
</references>
</back>
</rfc>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
