draft-ietf-ipsecme-rfc4307bis

<?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-02" 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>
      <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>
      <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. 
      As a result, 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>          


    </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="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 
          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> 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_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>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>SHOULD</c>
        </texttable>
        <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_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>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>SHOULD</c>
        </texttable>
        <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="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>
        <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> 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>

    <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>
      <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;
      &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>