One document matched: draft-mcgrew-tls-aes-ccm-ecc-01.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-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">
]>
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="no"?>
<rfc ipr="trust200902" category="std" docName="draft-mcgrew-tls-aes-ccm-ecc-01">
<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, Inc.</organization>
<address><postal>
<street>170 W Tasman Drive</street>
<city>San Jose </city>
<code>95134</code>
<region>CA</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="January" 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 defined as in <xref target="RFC5288"/>. 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:
<list>
<t>
The curves secp256r1 and secp384r1 MUST be supported, and the
curve 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 MUST offer the elliptic_curves extension and the server
MUST 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="I-D.mcgrew-fundamental-ecc"/> MAY be used as an implementation method.
</t>
</list>
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 described in the following table.
</t>
<texttable>
<ttcol align="left"> CipherSuite </ttcol>
<ttcol align="left"> Algorithms </ttcol>
<c>
TLS_ECDHE_ECDSA_WITH_AES_128_CCM
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
</c>
<c>
MUST support secp256r1, SHA-256
</c>
<c>
</c>
<c>
MAY support secp384r1, SHA-384
</c>
<c>
</c>
<c>
MAY support secp521r1, SHA-512
</c>
<c>
TLS_ECDHE_ECDSA_WITH_AES_256_CCM
TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8
</c>
<c>
MUST support secp384r1, SHA-384
</c>
<c>
</c>
<c>
MAY support secp521r1, SHA-512
</c>
</texttable>
</section>
<!--
<section title="Data Structures and Encoding">
<t>
The key exchange method uses the data structures and encodings defined
in this section; these are a subset of <xref target="RFC4492"/>.
Unused enumerated values and branches of "select" operations are not shown.
</t>
<t>
<figure>
<artwork><![CDATA[
enum {
secp256r1 (23), secp384r1 (24), secp521r1 (25),
(0xFFFF)
} NamedCurve;
struct {
ECCurveType curve_type = named_curve;
NamedCurve namedcurve;
} ECParameters;
struct {
opaque point <1..2^8-1>;
} ECPoint;
struct {
ECParameters curve_params;
ECPoint public;
} ServerECDHParams;
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
{
ServerECDHParams params;
Signature signed_params;
} ServerKeyExchange;
enum { ecdsa } SignatureAlgorithm;
{
digitally-signed struct {
opaque sha_hash[sha_size];
};
} Signature;
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
enum {
ecdsa_sign(64), (255)
} ClientCertificateType;
]]></artwork>
</figure>
</t>
<t>
The TLS CertificateRequest message is extended as follows.
Because only ephemeral Diffie-Hellman is used, the PublicValueEncoding
is always "explicit".
<figure>
<artwork><![CDATA[
struct {
ECPoint ecdh_Yc;
} ecdh_public;
} ClientECDiffieHellmanPublic;
struct {
{
ClientECDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
]]></artwork>
</figure>
</t>
</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 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">
&I-D.draft-mcgrew-fundamental-ecc;
&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>
| PAFTECH AB 2003-2026 | 2026-04-23 10:03:50 |