One document matched: draft-mcgrew-tls-aes-ccm-ecc-03.xml
<?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>
| PAFTECH AB 2003-2026 | 2026-04-23 14:22:38 |