<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246.xml">
<!ENTITY rfc4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!--
<!ENTITY rfc4347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4347.xml">
-->
<!ENTITY rfc4309 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4309.xml">
<!ENTITY rfc4366 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4366.xml">
<!ENTITY rfc5288 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5288.xml">
<!ENTITY ietf-tls-rfc4346-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-rfc4346-bis.xml">
<!ENTITY ietf-tls-ctr SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-ctr.xml">
<!ENTITY rescorla-tls-suiteb SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rescorla-tls-suiteb.xml">
<!ENTITY I-D.draft-mcgrew-fundamental-ecc PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-mcgrew-fundamental-ecc-04.xml">
<!ENTITY I-D.draft-mcgrew-tls-aes-ccm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-mcgrew-tls-aes-ccm-03.xml">
<!--
<!ENTITY I-D.draft-ietf-tls-rfc4347-bis   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tls-rfc4347-bis-03.xml">
-->
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc5116 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5116.xml">
<!ENTITY rfc5430 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5430.xml">
<!ENTITY rfc4492 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4492.xml">
<!ENTITY rfc6090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6090.xml">
<!ENTITY rfc6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-mcgrew-tls-aes-ccm-ecc-03"
     ipr="trust200902">
  <front>
    <title abbrev="AES-CCM ECC TLS">AES-CCM ECC Cipher Suites for TLS</title>

    <author fullname="David McGrew" initials="D" surname="McGrew">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>13600 Dulles Technology Drive</street>

          <city>Herndon</city>

          <code>20171</code>

          <region>VA</region>

          <country>USA</country>
        </postal>

        <email>mcgrew@cisco.com</email>
      </address>
    </author>

    <author fullname="Daniel V. Bailey" initials="D" surname="Bailey">
      <organization>RSA/EMC</organization>

      <address>
        <postal>
          <street>174 Middlesex Tpke.</street>

          <city>Bedford</city>

          <code>01463</code>

          <region>MA</region>

          <country>USA</country>
        </postal>

        <email>dbailey@rsa.com</email>
      </address>
    </author>

    <author fullname="Matthew Campagna" initials="M." surname="Campagna">
      <organization>Certicom Corp.</organization>

      <address>
        <postal>
          <street>5520 Explorer Drive #400</street>

          <city>Mississauga</city>

          <region>Ontario</region>

          <code>L4W 5L1</code>

          <country>Canada</country>
        </postal>

        <email>mcampagna@certicom.com</email>
      </address>
    </author>

    <author fullname="Robert Dugal" initials="R." surname="Dugal">
      <organization>Certicom Corp.</organization>

      <address>
        <postal>
          <street>5520 Explorer Drive #400</street>

          <city>Mississauga</city>

          <region>Ontario</region>

          <code>L4W 5L1</code>

          <country>Canada</country>
        </postal>

        <email>rdugal@certicom.com</email>
      </address>
    </author>

    <date day="31" month="May" year="2012"/>

    <area>Security Area</area>

    <workgroup>TLS Working Group</workgroup>

    <abstract>
      <t>This memo describes the use of the Advanced Encryption Standard (AES)
      in the Counter and CBC-MAC Mode (CCM) of operation within Transport
      Layer Security (TLS) to provide confidentiality and data origin
      authentication. The AES-CCM algorithm is amenable to compact
      implementations, making it suitable for constrained environments. The
      ciphersuites defined in this document use Elliptic Curve Cryptography
      (ECC), and are advantageous in networks with limited bandwidth.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document describes the use of Advanced Encryption Standard (AES)
      <xref target="AES"/> in Counter with CBC-MAC Mode (CCM) <xref
      target="CCM"/> in several TLS ciphersuites. AES-CCM provides both
      authentication and confidentiality and uses as its only primitive the
      AES encrypt operation (the AES decrypt operation is not needed). This
      makes it amenable to compact implementations, which is advantageous in
      constrained environments. Of course, adoption outside of constrained
      environments is necessary to enable interoperability, such as that
      between web clients and embedded servers, or between embedded clients
      and web servers. The use of AES-CCM has been specified for IPsec ESP
      <xref target="RFC4309"/> and 802.15.4 wireless networks <xref
      target="IEEE802154"/>.</t>

      <t>Authenticated encryption, in addition to providing confidentiality
      for the plaintext that is encrypted, provides a way to check its
      integrity and authenticity. Authenticated Encryption with Associated
      Data, or AEAD <xref target="RFC5116"/>, adds the ability to check the
      integrity and authenticity of some associated data that is not
      encrypted. This note utilizes the AEAD facility within TLS 1.2 <xref
      target="RFC5246"/> and the AES-CCM-based AEAD algorithms defined in
      <xref target="RFC5116"/> and <xref target="I-D.mcgrew-tls-aes-ccm"/>
      <!-- <xref target="I-D.draft-mcgrew-tls-aes-ccm"/> -->. All of these
      algorithms use AES-CCM; some have shorter authentication tags, and are
      therefore more suitable for use across networks in which bandwidth is
      constrained and message sizes may be small.</t>

      <t>The ciphersuites defined in this document use Ephemeral Elliptic
      Curve Diffie-Hellman (ECDHE) as their key establishment mechanism; these
      ciphersuites can be used with DTLS <xref target="RFC6347"/>.</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 anchor="suites" title="ECC based AES-CCM Cipher Suites">
      <t>The ciphersuites defined in this document are based on the AES-CCM
      authenticated encryption with associated data (AEAD) algorithms
      AEAD_AES_128_CCM and AEAD_AES_256_CCM described in <xref
      target="RFC5116"/>. The following ciphersuites are defined:</t>

      <t><list style="hanging">
          <t>CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM =
          {TBD1,TBD1}<vspace/> CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CCM =
          {TBD2,TBD2}<vspace/> CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
          = {TBD3,TBD3}<vspace/> CipherSuite
          TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 = {TBD4,TBD4}<vspace/></t>
        </list></t>

      <t>These ciphersuites make use of the AEAD capability in TLS 1.2 <xref
      target="RFC5246"/>. Note that each of these AEAD algorithms uses
      AES-CCM. Ciphersuites ending with "8" use eight-octet authentication
      tags; the other ciphersuites have 16 octet authentication tags.</t>

      <t>The HMAC truncation option described in Section 3.5 of <xref
      target="RFC4366"/> (which negotiates the "truncated_hmac" TLS extension)
      does not have an effect on the cipher suites defined in this note,
      because they do not use HMAC to protect TLS records.</t>

      <t>The "nonce" input to the AEAD algorithm is as in <xref
      target="RFC5288"/>; for the convenience of the reader, we summarize the
      details in this note. The "nonce" SHALL be 12 bytes long and constructed
      as follows:</t>

      <figure>
        <artwork align="center"><![CDATA[
struct {
   case client:
      uint32 client_write_IV;  // low order 32-bits
   case server:
      uint32 server_write_IV;  // low order 32-bits
   uint64 seq_num;
} CCMNonce.]]></artwork>
      </figure>

      <t>In DTLS, the 64-bit seq_num field is the 16-bit DTLS epoch field
      concatenated with the 48-bit sequence_number field. The epoch and
      sequence_number appear in the DTLS record layer.</t>

      <t>This construction allows the internal counter to be 32-bits long,
      which is a convenient size for use with CCM.</t>

      <t>These ciphersuites make use of the default TLS 1.2 Pseudorandom
      Function (PRF), which uses HMAC with the SHA-256 hash function.</t>

      <t>The ECDHE_ECDSA key exchange is performed as defined in <xref
      target="RFC4492"/>, with the following additional stipulations:</t>

      <t><list style="symbols">
          <t>The curve secp256r1 MUST be supported, and the curves secp384r1
          and secp521r1 MAY be supported; these curves are equivalent to the
          NIST P-256, P-384, and P-521 curves. Note that all of these curves
          have cofactor equal to one, which simplifies their use.</t>

          <t>The server's certificate MUST contain an ECDSA-capable public
          key, it MUST be signed with ECDSA, and it MUST use SHA-256, SHA-384,
          or SHA-512. The Signature Algorithms extension (Section 7.4.1.4.1 of
          <xref target="RFC5246"/>) MUST be used to indicate support of those
          signature and hash algorithms. If a client certificate is used, the
          same conditions apply to it. The acceptable choices of hashes and
          curves that can be used with each ciphersuite are detailed in <xref
          target="reqts"/>.</t>

          <t>The uncompressed point format MUST be supported. Other point
          formats MAY be used.</t>

          <t>The client SHOULD offer the elliptic_curves extension and the
          server SHOULD expect to receive it.</t>

          <t>The client MAY offer the ec_point_formats extension, but the
          server need not expect to receive it.</t>

          <t><xref target="RFC6090"/> MAY be used as an implementation
          method.</t>
        </list></t>

      <t>Implementations of these ciphersuites will interoperate with <xref
      target="RFC4492"/>, but can be more compact than a full implementation
      of that RFC.</t>

      <section anchor="newaead" title="AEAD algorithms">
        <t>The following AEAD algorithms are used: </t>

        <t><list style="hanging">
            <t>AEAD_AES_128_CCM is used in the
            TLS_ECDHE_ECDSA_WITH_AES_128_CCM ciphersuite,</t>

            <t><vspace/> AEAD_AES_256_CCM is used in the
            TLS_ECDHE_ECDSA_WITH_AES_256_CCM ciphersuite,<vspace/></t>

            <t><vspace/> AEAD_AES_128_CCM_8 is used in the
            TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 ciphersuite, and<vspace/></t>

            <t><vspace/> AEAD_AES_256_CCM_8 is used in the
            TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 ciphersuite.<vspace/></t>
          </list><!-- <xref
	  target="draft-mcgrew-tls-aes-ccm"/> --></t>
      </section>

      <section anchor="reqts" title="Required algorithms for each CipherSuite">
        <t>The curves and hash algorithms that can be used with each
        ciphersuite are as follows. The ciphersuites
        TLS_ECDHE_ECDSA_WITH_AES_128_CCM and
        TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 MUST be used with one of the
        following combinations:</t>

        <t><list style="hanging">
            <t>secp256r1 and SHA-256, or</t>

            <t>secp384r1 and SHA-384, or</t>

            <t>secp521r1 and SHA-512.</t>
          </list></t>

        <t>The ciphersuites TLS_ECDHE_ECDSA_WITH_AES_256_CCM and
        TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 MUST be used with one of the
        following combinations:</t>

        <t><list style="hanging">
            <t>secp384r1 and SHA-384, or</t>

            <t>secp521r1 and SHA-512.</t>
          </list></t>

        <!--       
    <t>
    The curves and hash algorithms that can be used with each 
    ciphersuite are described in the following table.
    </t>

<texttable>
     <ttcol align="left"> CipherSuite </ttcol>
     <ttcol align="left"> Curve and Hash </ttcol>
     
     <c>
       	TLS_ECDHE_ECDSA_WITH_AES_128_CCM   
	TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 
     </c>

     <c>
       secp256r1, SHA-256
       </c>
     <c>
       </c>
     <c>
       secp384r1, SHA-384
       </c>
     <c>
       </c>
     <c>
       secp521r1, SHA-512
       </c>

     <c>
       	TLS_ECDHE_ECDSA_WITH_AES_256_CCM   
	TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 
     </c>

     <c>
        secp384r1, SHA-384
       </c>
     <c>
       </c>
     <c>
       secp521r1, SHA-512
       </c>

   </texttable>
-->
      </section>
    </section>

    <section title="TLS Versions">
      <t>These ciphersuites make use of the authenticated encryption with
      additional data defined in TLS 1.2 <xref target="RFC5288"/>. They MUST
      NOT be negotiated in older versions of TLS. Clients MUST NOT offer these
      cipher suites if they do not offer TLS 1.2 or later. Servers which
      select an earlier version of TLS MUST NOT select one of these cipher
      suites. Earlier versions do not have support for AEAD; for instance, the
      TLSCiphertext structure does not have the "aead" option in TLS 1.1.
      Because TLS has no way for the client to indicate that it supports TLS
      1.2 but not earlier, a non-compliant server might potentially negotiate
      TLS 1.1 or earlier and select one of the cipher suites in this document.
      Clients MUST check the TLS version and generate a fatal
      "illegal_parameter" alert if they detect an incorrect version.</t>
    </section>

    <section title="History">
      <t>The 03 version removed materials that are redundant with
      draft-mcgrew-tls-aes-ccm, and replaced them with references to that
      draft. That draft has been approved for RFC and will be a suitable
      stable normative reference.</t>

      <t>The 02 version removed the AEAD_AES_128_CCM_12 and
      AEAD_AES_256_CCM_12 AEAD algorithms, because they were not needed in any
      ciphersuites. The AES-256 ciphersuites were retained, however, to
      provide a secure cipher for use with the higher security curves
      secp384r1 and secp521r1.</t>

      <t>This section is to be removed by the RFC editor upon publication.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>IANA has assigned values for the Ciphersuites defined in <xref
      target="suites"/> and the AEAD algorithms defined in <xref
      target="newaead"/> of this note.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <section title="Perfect Forward Secrecy">
        <t>The perfect forward secrecy properties of ephemeral Diffie-Hellman
        ciphersuites are discussed in the security analysis of <xref
        target="RFC4346"/>. This analysis applies to the ECDHE
        ciphersuites.</t>
      </section>

      <section title="Counter Reuse">
        <t>AES-CCM security requires that the counter is never reused. The IV
        construction in <xref target="suites"/> is designed to prevent counter
        reuse.</t>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This draft borrows heavily from <xref target="RFC5288"/>. Thanks are
      due to Robert Cragie.</t>

      <t>This draft is motivated by the considerations raised in the Zigbee
      Smart Energy 2.0 working group.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &rfc6090;

      &rfc6347;

      &I-D.draft-mcgrew-tls-aes-ccm;

      &rfc4492;

      &rfc2119;

      <!--
			&rfc4347;
-->

      &rfc4366;

      &rfc5288;

      &rfc5116;

      &rfc5246;

      <reference anchor="CCM">
        <front>
          <title>Recommendation for Block Cipher Modes of Operation: The CCM
          Mode for Authentication and Confidentiality</title>

          <author>
            <organization>National Institute of Standards and
            Technology</organization>
          </author>

          <date month="May" year="2004"/>
        </front>

        <seriesInfo name="SP" value="800-38C"/>
      </reference>

      <reference anchor="AES">
        <front>
          <title>Specification for the Advanced Encryption Standard
          (AES)</title>

          <author>
            <organization>National Institute of Standards and
            Technology</organization>
          </author>

          <date month="November" year="2001"/>
        </front>

        <seriesInfo name="FIPS" value="197"/>
      </reference>
    </references>

    <references title="Informative References">
      &rfc4309;

      <reference anchor="IEEE802154">
        <front>
          <title>Wireless Personal Area Networks</title>

          <author>
            <organization>Institute of Electrical and Electronics
            Engineers</organization>
          </author>

          <date year="2006"/>
        </front>

        <seriesInfo name="IEEE Standard" value="802.15.4-2006"/>
      </reference>

      &rfc4346;
    </references>
  </back>
</rfc>
