<?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-rfc4347-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-rfc4347-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-ietf-tls-rfc4347-bis   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tls-rfc4347-bis-03.xml">
-->

<!ENTITY rfc4309 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4309.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 rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.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">


]>
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<rfc ipr="trust200902" category="std" docName="draft-mcgrew-tls-aes-ccm-ecc-02">
	<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 initials="M." surname="Campagna" fullname="Matthew 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 initials="R." surname="Dugal" fullname="Robert 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 month="October" year="2011"/>
		<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
		    intended for use 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"></xref> in Counter with CBC-MAC Mode
    (CCM) <xref target="CCM"></xref> 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.  The use of AES-CCM has been specified for 
    IPsec ESP <xref target="RFC4309"></xref> and 802.15.4 wireless
    networks <xref target="IEEE802154"></xref>.
</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"></xref> and the AES-CCM-based AEAD
  algorithms defined in <xref target="RFC5116"/>.  Additional AEAD
  algorithms are defined in this note; these use AES-CCM but
  have shorter authentication tags, and therefore are 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="I-D.ietf-tls-rfc4347-bis"></xref>.
</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"></xref></t>
</section>

</section>


<section title="ECC based AES-CCM Cipher Suites" anchor="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"></xref>.
    The following ciphersuites are defined:</t>
  <t><list style="hanging" >
      <t>
	CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM   = {TBD1,TBD1}<vspace></vspace>
	CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CCM   = {TBD2,TBD2}<vspace></vspace>
 	CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 = {TBD3,TBD3}<vspace></vspace>
	CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 = {TBD4,TBD4}<vspace></vspace>
      </t>
  </list>
  </t>
  <t>These ciphersuites make use of the AEAD capability in TLS
    1.2 <xref target="RFC5246"></xref>.  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">
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"></xref>, 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="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='symbols'> 
      <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='symbols'> 
      <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"></xref>.  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.  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 anchor="newaead" title="New AEAD algorithms">
	<t>
	  The following AEAD algorithms are defined:
	  <list style="hanging" >
	    <t>
	      AEAD_AES_128_CCM_8     = TBD9 <vspace></vspace>
	      AEAD_AES_256_CCM_8     = TBD10<vspace></vspace>
	<!--  AEAD_AES_128_CCM_12 =  TBD11 <vspace></vspace>
	      AEAD_AES_256_CCM_12 = TBD12 -->
	    </t>
	  </list>
	</t>
	
	  <section title="AES-128-CCM with an 8-octet ICV">
	    <t>
	      
   The AEAD_AES_128_CCM_8 authenticated encryption algorithm is
   identical to the AEAD_AES_128_CCM algorithm (see Section 5.3 of
   <xref target="RFC5116"/>), except that it uses eight octets for
   authentication, instead of the full sixteen octets used by
   AEAD_AES_128_CCM.  The AEAD_AES_128_CCM_8 ciphertext consists of
   the ciphertext output of the CCM encryption operation concatenated
   with the 8-octet authentication tag output of the CCM encryption
   operation.  Test cases are provided in [CCM].  The input and output
   lengths are as for AEAD_AES_128_CCM.  An AEAD_AES_128_CCM_8
   ciphertext is exactly 8 octets longer than its corresponding
   plaintext.

	  </t>
	    </section>

	  <section title="AES-256-CCM with an 8-octet ICV">
	    <t>
	      
   The AEAD_AES_256_CCM_8 authenticated encryption algorithm is
   identical to the AEAD_AES_256_CCM algorithm (see Section 5.4 of
   <xref target="RFC5116"/>), except that it uses eight octets for
   authentication, instead of the full sixteen octets used by
   AEAD_AES_256_CCM.  The AEAD_AES_256_CCM_8 ciphertext consists of
   the ciphertext output of the CCM encryption operation concatenated
   with the 8-octet authentication tag output of the CCM encryption
   operation.  Test cases are provided in [CCM].  The input and output
   lengths are as for AEAD_AES_128_CCM.  An AEAD_AES_128_CCM_8
   ciphertext is exactly 8 octets longer than its corresponding
   plaintext.

	  </t>
	    </section>

	</section>

<section title="History">
<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"></xref>.  
				  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"></xref> is
				designed to prevent counter
				reuse. </t>
			
			</section>
		</section>


		<section anchor="Acknowledgements" title="Acknowledgements">
			<t>This draft borrows heavily from <xref target="RFC5288"></xref>.
			</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;
			&I-D.draft-ietf-tls-rfc4347-bis;

			&rfc4492;
			&rfc4346;
			&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"></date>
					
				</front>
				<seriesInfo name="SP" value="800-38C"></seriesInfo>
			</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"></date>
				</front>
				<seriesInfo name="FIPS" value="197"></seriesInfo>
			</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"></date>
					</front>
					<seriesInfo name="IEEE Standard" value="802.15.4-2006"></seriesInfo>
				</reference>
		</references>
	</back>
</rfc>
