[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01
Network Working Group M. Campagna
Internet-Draft Certicom Corp.
Intended status: Informational D. Stebila
Expires: July 20, 2010 Queensland University of
Technology
January 16, 2010
ECMQV_ECQV Cipher Suites for Transport Layer Security (TLS)
draft-campagna-tls-ecmqv-ecqv-01
Abstract
This document specifies a set of cipher suites for the Transport
Layer Security (TLS) and Datagram TLS (DTLS) protocols that use
Elliptic Curve Qu-Vanstone (ECQV) certificates to authenticate an
Elliptic Curve Menezes-Qu-Vanstone (ECMQV) exchange. These cipher
suites provide forward secrecy.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 20, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Campagna & Stebila Expires July 20, 2010 [Page 1]
Internet-Draft ECMQV_ECQV in TLS January 2010
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. ECMQV_ECQV Key Exchange Algorithm . . . . . . . . . . . . . . 7
3.1. ECMQV_ECQV Handshake Protocol Overview . . . . . . . . . . 7
3.2. Server Authentication . . . . . . . . . . . . . . . . . . 8
3.3. Client Authentication . . . . . . . . . . . . . . . . . . 8
4. Data Structures and Computations . . . . . . . . . . . . . . . 9
4.1. Server Certificate . . . . . . . . . . . . . . . . . . . . 9
4.2. Server Key Exchange . . . . . . . . . . . . . . . . . . . 10
4.3. Certificate Request . . . . . . . . . . . . . . . . . . . 11
4.4. Client Certificate . . . . . . . . . . . . . . . . . . . . 13
4.5. Client Key Exchange . . . . . . . . . . . . . . . . . . . 14
5. ECMQV_ECQV-Based Cipher Suites . . . . . . . . . . . . . . . . 16
5.1. ECMQV_ECQV Cipher Suites Using the SHA-1 Hash Function . . 16
5.2. ECMQV_ECQV Cipher Suites Using the SHA2 Hash Function
Family . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. ECMQV_ECQV Cipher Suites Using AES-MMO Hash Functions . . 16
6. ECMQV_ECQV-Based Cipher Suites With NULL Encryption . . . . . 18
6.1. ECMQV_ECQV Cipher Suite Using the SHA-1 Hash Function
with NULL Encryption . . . . . . . . . . . . . . . . . . . 18
6.2. ECMQV_ECQV Cipher Suites Using the SHA2 Hash Function
Family with NULL Encryption . . . . . . . . . . . . . . . 18
6.3. ECMQV_ECQV Cipher Suites Using AES-MMO Hash Functions
with NULL Encryption . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Campagna & Stebila Expires July 20, 2010 [Page 2]
Internet-Draft ECMQV_ECQV in TLS January 2010
1. Introduction
Elliptic curve implicit certificates, combined with the Elliptic
Curve Menezes-Qu-Vanstone (ECMQV) key agreement schemes, provide
significant computation and bandwidth savings over traditional
certificate schemes and the Diffie-Hellman key agreement schemes,
while still affording equivalent security properties.
Elliptic Curve Qu-Vanstone (ECQV) is an implicit certificate scheme
that removes the need for explicitly signing a public key and
associated data in the certificate. Details of the security
properties provided by ECQV can be found in [SEC4]. Compared to
currently prevalent certificate schemes, ECQV provides smaller
certificate sizes for equivalent security levels. This is
illustrated in the following table, which compares the minimial
number of bit required to convey the public key and, if required, the
explicit signature in the certificate, at various symmetric key
security levels. In the table columns with (p/2^m) shows sizes for
elliptic curve groups over prime fields of size p or 2^m,
respectively.
+-----------+--------------+---------------+------------+
| Symmetric | ECQV (p/2^m) | ECDSA (p/2^m) | DH/DSA/RSA |
+-----------+--------------+---------------+------------+
| 80 | 160/163 | 480/489 | 2064 |
| | | | |
| 112 | 224/233 | 672/699 | 4112 |
| | | | |
| 128 | 256/283 | 768/849 | 6160 |
| | | | |
| 192 | 384/409 | 1152/1227 | 15376 |
| | | | |
| 256 | 521/571 | 1563/1713 | 30736 |
+-----------+--------------+---------------+------------+
[RFC4492] defines a set of elliptic curve cryptography (ECC)-based
cipher suites for the Transport Layer Security (TLS) protocol and
describes the use of ECC certificates for client authentication. In
particular, it specifies the use of Elliptic Curve Diffie-Hellman
(ECDH) key agreement in a TLS handshake and the use of Elliptic Curve
Digital Signature Algorithm (ECDSA) for authentication.
ECMQV key agreement with ECQV implicit certifcates, denoted
ECMQV_ECQV, provides the same security properties as provided by
ephemeral ECDH (ECDHE) with ECDSA certificates, but requires less
computation. The following table compares the number of operations
required by each party in the two schemes.
Campagna & Stebila Expires July 20, 2010 [Page 3]
Internet-Draft ECMQV_ECQV in TLS January 2010
+--------------------------------+----------------------------------+
| ECMQV_ECQV with client | ECDHE_ECDSA with client |
| ECQV_ECMQV | ECDSA_sign |
+--------------------------------+----------------------------------+
| 1 hash operation | 3 hash operations |
| | |
| 1 key generation | 2 key generations |
| | |
| 2 point additions | 2 point additions |
| | |
| 2.5 point multiplications | 3 point multiplications |
+--------------------------------+----------------------------------+
The computational and bandwidth savings make ECMQV_ECQV particularly
attractive for bandwidth-constrained environments and devices with
constrained computational power.
ECMQV and ECQV are used in the Certificate Based Key Exchange (CBKE)
defined in the ZigBee Smart Energy Specification [ZigBeeSE]. ZigBee
is developing an Internet Protocol (IP) capability to support a
unified Smart Energy profile to run over HomePlug. This document is
meant to help support the general ZigBee and HomePlug efforts to use
IETF protocols and achieve application-layer security, bandwidth, and
computational goals.
This document describes additions to TLS and DTLS to support
ECMQV_ECQV, applicable to TLS version 1.0 [RFC2246], TLS version 1.1
[RFC4346], and TLS version 1.2 [RFC5246], as well as DTLS version 1.0
[RFC4347] and DTLS version 1.2 [I-D.ietf-tls-rfc4347-bis]. In
particular, it defines:
o the use of the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key
agreement scheme with long-term and ephemeral keys to establish
the premaster secret, and
o the use of Elliptic Curve Qu-Vanstone (ECQV) implicit certificates
for authentication of peers.
The remainder of this document is organized as follows. Section 3
provides an overview of ECMQV_ECQV-based key exchange algorithms for
TLS. Section 4 describes the data structures and actions required to
implement the new authenticated key agreement scheme. Section 5
defines new ECMQV_ECQV-based cipher suites and identifies a small
subset of these as recommended for all implementations of this
specification. Section 7 discusses security considerations.
Section 8 describes IANA considerations for the name spaces created
by this document.
Campagna & Stebila Expires July 20, 2010 [Page 4]
Internet-Draft ECMQV_ECQV in TLS January 2010
The cipher suites described in this are suitable for DTLS without any
additional changes beyond those required to implement DTLS.
Implementation of this document requires familiarity with the
following technologies and standards: elliptic curve cryptography
[SEC1] (additional information available in [HMV04], [IEEE1363]);
ECMQV [SEC1], Section 6.2 (additional information available in
[LMQSV98]); ECQV [SEC4]; the use of elliptic curve cryptography in
TLS [RFC4492]; and the relevant version of TLS [RFC2246], [RFC4346],
[RFC5246] or DTLS [RFC4347], [I-D.ietf-tls-rfc4347-bis].
Campagna & Stebila Expires July 20, 2010 [Page 5]
Internet-Draft ECMQV_ECQV in TLS January 2010
2. Notation
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 [RFC2119].
Campagna & Stebila Expires July 20, 2010 [Page 6]
Internet-Draft ECMQV_ECQV in TLS January 2010
3. ECMQV_ECQV Key Exchange Algorithm
This document describes a new ECC-based key exchange algorithm for
TLS and DTLS. It uses ECMQV to compute the premaster secret. The
derivation of the master secret from the premaster secret and the
subsequent generation of bulk encryption/MAC keys and initialization
vectors is independent of the key exchange algorithm and not impacted
by the techniques in this document.
ECMQV_ECQV key exchange provides forward secrecy and mutual
authentication. It provides a new server authentication mechanism
and a new client authentication mechanism, both using ECQV
certificates. This document treats the ECQV certificates as an
opaque data structure that is defined outside this specification; for
example, this structure could be an X.509 format.
3.1. ECMQV_ECQV Handshake Protocol Overview
The handshake defined for ECMQV_ECQV requires that a server has an
ECQV certificate. In the case that the client also has a certificate
no CertificateVerify message is required: proof of possession of the
private key is demonstrated by the verify_data in the Finished
method. This is a property afforded by ECMQV that also applies to
ECQV certificates and can reduce the bandwidth and computational
complexity of a mutually authenticated key establishment.
Client Server
ClientHello -------->
ServerHello
Certificate
ServerKeyExchange
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
* message is not sent in some conditions
Message flow for an ECMQV_ECQV handshake.
Figure 1
Campagna & Stebila Expires July 20, 2010 [Page 7]
Internet-Draft ECMQV_ECQV in TLS January 2010
3.2. Server Authentication
The ECMQV_ECQV scheme provides server authentication by the exchange
of an ECQV certificate issued by a certificate authority recognized
by the client.
3.3. Client Authentication
The ECMQV_ECQV scheme provides client authentication by the exchange
of an ECQV certificate issued by a certificate authority recognized
by the clientserver.
The server MUST request ECQV-based client authentication by including
this certificate type in its CertificateRequest message. The client
MUST check if it possesses a certificate appropriate for this method
suggested by the server and is willing to use it for authentication.
If these conditions are not met, the client SHOULD send a client
Certificate message containing no certificates. In this case, the
ClientKeyExchange message is as described in . If the server
requires client authentication, it MAY respond with a fatal handshake
failure alert.
If the client has an appropriate certificate and is willing to use it
for authentication, it MUST send that certificate in the client's
Certificate message (as per Section 4.4) and prove possession of the
private key corresponding to the certified key. The process of
proving possession is described below.
The cipher suites described in this document make use of the elliptic
curve parameter negotiation mechanism defined in [RFC4492], which
makes use of TLS extensions [RFC4366]. When the cipher suites
defined in this document are used, the 'ecmqv_ecqv' case inside the
ServerKeyExchange and ClientKeyExchange structure MUST be used (i.e.,
the ServerKeyExchange and ClientKeyExchange messages MUST include the
ECQV parameters).
Campagna & Stebila Expires July 20, 2010 [Page 8]
Internet-Draft ECMQV_ECQV in TLS January 2010
4. Data Structures and Computations
This section specifies the data structures and computations used by
ECMQV key mechanisms specified in Section 5. The presentation
language used here is the same as that used in TLS [RFC4346]. Since
this specification extends TLS, these descriptions should be merged
with those in the TLS specification and any others that extend TLS.
This means that enum types may not specify all possible values, and
structures with multiple formats chosen with a select() clause may
not indicate all possible cases.
The ClientHello message and the ServerHello messages are unchanged
and utilize those used in [RFC4492].
4.1. Server Certificate
When this message is sent:
This message is sent in all ECMQV_ECQV-based cipher suites.
Meaning of this message:
This message is used to authentically convey the server's static
public key to the client. ECC public keys MUST be encoded in a
Certificate message.
Structure of this message:
opaque ECQVCert<1..2^8-1>
struct {
ECQVCert certificate_list<0..2^16-1>
} Certificate;
The ECQVCert value is defined by the underlying application
specification. For general details on the necessary components see
SEC 4 [SEC4].
The server constructs an appropriate Certificate structure and
conveys it to the client in the Certificate message. If the client
has used a Supported Elliptic Curves Extension, the public key in the
server's certificate MUST respect the client's choice of elliptic
curves; in particular, the public key MUST employ a named curve (not
the same curve as an explicit curve) unless the client has indicated
support for explicit curves of the appropriate type. If the client
has used a Supported Point Formats Extension, both the server's
public key point and (in the case of an explicit curve) the curve's
base point MUST respect the client's choice of point formats. (A
Campagna & Stebila Expires July 20, 2010 [Page 9]
Internet-Draft ECMQV_ECQV in TLS January 2010
server that cannot satisfy these requirements MUST NOT choose an
ECMQV_ECQV cipher suite in its ServerHello message.)
Actions of the receiver:
The client validates the information in the ECQVCert and extracts the
server's public key using the operations specified in SEC 4 [SEC4]
section 2.3, under the curve specified in the Server Key Exchange
message defined in Section 4.2. (A possible reason for a fatal
handshake failure is that the client's capabilities for handling
elliptic curves and point formats are exceeded; cf. [RFC4492],
Section 5.1.)
4.2. Server Key Exchange
When this message is sent:
This message is sent in all ECMQV_ECQV-based cipher suites.
Meaning of this message:
This message is used to convey the server's ephemeral ECMQV public
key (and the corresponding elliptic curve domain parameters) to the
client.
Structure of this message:
struct {
ECParameters curve_params;
ECPoint public;
} ServerECMQVParams;
curve_params: Specifies the elliptic curve domain parameters
associated with the ECMQV public key and is as specified in
[RFC4492], Section 5.4.
public: The ephemeral ECMQV public key.
The ServerKeyExchange message is extended as follows.
enum {
ec_mqv (xx)
} KeyExchangeAlgorithm;
ec_mqv: Indicates the ServerKeyExchange message contains an ECMQV
public key.
The ServerKeyExchange structure is extended as follows:
Campagna & Stebila Expires July 20, 2010 [Page 10]
Internet-Draft ECMQV_ECQV in TLS January 2010
select (KeyExchangeAlgorithm) {
case ec_mqv:
ServerECMQVParams params;
} ServerKeyExchange;
params: Specifies the ECMQV public key and associated domain
parameters.
Actions of the sender:
The server selects elliptic curve domain parameters and an ephemeral
ECMQV public key corresponding to these parameters according to the
ECKAS-MQV scheme as specified in [SEC1], Section 6.2. It conveys
this information to the client in the ServerKeyExchange message using
the format defined above.
NOTE: curve_params MUST specify the same curve that is used by the
CA, and the curve on which the point in the Certificate from the
server's Certificate message lies.
Actions of the receiver:
The client retrieves the server's elliptic curve domain parameters
and ephemeral ECMQV public key from the ServerKeyExchange message and
MUST validate the parameters in accordance with [SEC1], Section
6.2.1, and MUST validate the ephemeral public keys in accordance with
[SEC1], Section 6.2.2. (A possible reason for a fatal handshake
failure is that the client's capabilities for handling elliptic
curves and point formats are exceeded; cf. [RFC4492], Section 5.1.)
4.3. Certificate Request
When this message is sent:
This message is sent by the server when requesting client
authentication.
Meaning of this message:
The server uses this message to suggest acceptable client
authentication methods.
Structure of this message:
The CertificateRequest message is extended as follows.
enum {
ecqv_ecmqv (xx),
Campagna & Stebila Expires July 20, 2010 [Page 11]
Internet-Draft ECMQV_ECQV in TLS January 2010
} ClientCertificateType;
ecqv_ecmqv: Indicates that the server would like to use the
corresponding client authentication method specified in Section 4.4.
The SignatureAndHashAlgorithms are extended by the addition of a
hashing algorithm which uses the Advanced Encryption Standard (AES)
functions AES-128 and AES-256 in Matyas-Meyer-Oseas (MMO) hash
function mode ([ZigBee], Section B.6; see also [MOV96], Section
9.4.1) and an implicit certificate type signature for ECQV.
enum {
aes_128_mmo (xx), aes_256_mmo (xx)
} HashAlgorithm;
enum {
ecqv (xx)
} SignatureAlgorithm;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm
supported_signature_algorithms<1..2^16-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
The benefit of ECQV certificate exchanges is the reduction in packet
sizes. It is expected that most of the parties communicating via
ECQV certificates belong to the same or a small list of acceptable
certificate authorities, and that these certificate authorities are
identified within the certificates. As such, it is expected that the
certificate_authorities list will often be empty.
The interaction of the certificate_types and
supported_signature_algorithms fields is further complicated when
using TLS version 1.2 [RFC5246]. The following rules augment the
existing rules in [RFC5246]:
o If the ecqv SignatureAlgorithm type is specified, it only applies
to the public key contained in the end-entity certificate. It
cannot be used to sign certificates.
Actions of the sender:
The server decides which client authentication methods it would like
to use, and conveys this information to the client using the format
defined above.
Campagna & Stebila Expires July 20, 2010 [Page 12]
Internet-Draft ECMQV_ECQV in TLS January 2010
Actions of the receiver:
The client determines whether it has a suitable certificate for use
with any of the requested methods and whether to proceed with client
authentication.
4.4. Client Certificate
When this message is sent:
This message is sent by the client in response to a
CertificateRequest when a client has a suitable certificate and has
decided to proceed with client authentication. (Note that if the
server has used a Supported Point Formats Extension, a certificate
can only be considered suitable for use with the ECQV_ECMQV
authentication methods if the public key point specified in it
respects the server's choice of point formats. If no Supported Point
Formats Extension has been used, a certificate can only be considered
suitable for use with these authentication methods if the point is
represented in uncompressed point format.)
Meaning of this message:
This message is used to authentically convey the client's static
public key to the server in an ECQV certificate.
Structure of this message:
Identical to the ECQV Certificate format specified in Server
Certificate Section 4.1.
Actions of the sender:
The client constructs an appropriate Certificate message.
NOTE: The ECQV certificate MUST be issued by a CA on the same curve
specified in the ECParameters sent in the Server Key Exchange
message. The point in the ECQV certificate MUST also be on the same
curve.
Actions of the receiver:
The server validates the information in the ECQVCert, and extracts
the client's public key using the operations specified in [SEC4]
section 2.3, under the curve specified in the Server Key Exchange
message defined in Section 4.2.
Campagna & Stebila Expires July 20, 2010 [Page 13]
Internet-Draft ECMQV_ECQV in TLS January 2010
4.5. Client Key Exchange
When this message is sent:
This message is sent in all ECMQV_ECQV-based cipher suites.
Meaning of the message:
This message is used to convey the client's ephemeral ECMQV public
key.
Structure of this message:
The ClientKeyExchange message mimics [RFC4492] as follows.
enum { implicit, explicit } PublicValueEncoding;
implicit, explicit: For ECMQV_ECQV cipher suites, this indicates
whether the client's has one ECMQV public key in the client's
certificate ("implicit") and is providing one ephemeral ECMQV public
key or if it is providing two ephemeral ECMQV public keys, in the
ClientKeyExchange message ("explicit").
struct {
select (PublicValueEncoding) {
case implicit:
ECPoint ecmqv_q2;
case explicit: struct {
ECPoint ecmqv_q1;
ECPoint ecmqv_q2;
};
} ecmqv_public;
} ClientECMQVPublic;
ecmqv_q1: Contains the client's ephemeral ECMQV public key as a byte
string ECPoint.point, which may represent an elliptic curve point in
uncompressed or compressed format. Here, the format MUST conform to
what the server has requested through a Supported Point Formats
Extension if this extension was used, and MUST be uncompressed if
this extension was not used.
ecmqv_q2: Is the same as above.
The ClientKeyExchange message is extended as follows.
Campagna & Stebila Expires July 20, 2010 [Page 14]
Internet-Draft ECMQV_ECQV in TLS January 2010
struct {
select (KeyExchangeAlgorithm) {
case ecmqv:
ClientECMQVPublic;
} exchange_keys;
} ClientKeyExchange;
Actions of the sender:
The client selects an ephemeral ECMQV public key corresponding to the
parameters it received from the server according to the ECKAS-MQV
scheme as specified in [SEC1], Section 6.2. It conveys this
information to the client in the ClientKeyExchange message using the
format defined above.
Actions of the receiver:
The server retrieves the client's ephemeral ECMQV public key(s) from
the ClientKeyExchange message, checks that the public key(s) is(are)
on the same elliptic curve as the server's ECMQV key, and validates
the ephemeral public keys in accordance with [SEC1], Section 6.2.2.
The premaster secret is formed as follows. First, recover the static
public key in the ECQV certificate as described in [SEC4], Section
2.5, and then perform the ECMQV computation as described in [SEC1],
Section 6.2. Let premaster secret be the octet string produced by
this computation.
Campagna & Stebila Expires July 20, 2010 [Page 15]
Internet-Draft ECMQV_ECQV in TLS January 2010
5. ECMQV_ECQV-Based Cipher Suites
5.1. ECMQV_ECQV Cipher Suites Using the SHA-1 Hash Function
The document specifies four cipher suites using ECMQV key exchange
and ECQV certificates with RC-4, Triple-DES (3DES), or Advanced
Encryption Standard (AES) encryption and the SHA-1 hash function:
CipherSuite TLS_ECMQV_ECQV_WITH_RC4_128_SHA = {0xXX,0xXX};
CipherSuite TLS_ECMQV_ECQV_WITH_3DES_EDE_CBC_SHA = {0xXX,0xXX};
CipherSuite TLS_ECMQV_ECQV_WITH_AES_128_CBC_SHA = {0xXX,0xXX};
CipherSuite TLS_ECMQV_ECQV_WITH_AES_256_CBC_SHA = {0xXX,0xXX};
5.2. ECMQV_ECQV Cipher Suites Using the SHA2 Hash Function Family
The document specifies two cipher suites using ECMQV key exchange and
ECQV certificates with AES encryption and the SHA2 hash function
family:
CipherSuite TLS_ECMQV_ECQV_WITH_AES_128_CBC_SHA256 = {0xXX,0xXX};
CipherSuite TLS_ECMQV_ECQV_WITH_AES_256_CBC_SHA384 = {0xXX,0xXX};
The above two cipher suites are the same as the corresponding AES
cipher suites in Section 5.1 above, except for the hash and PRF
algorithms, which are as follows.
For TLS_ECMQV_ECQV_WITH_AES_128_CBC_SHA256:
o The MAC is HMAC [RFC2104] with SHA-256 as the hash function.
o When negotiated in a version of TLS prior to 1.2, the PRF from
that version is used; otherwise the PRF is the TLS version 1.2 PRF
[RFC5246] with SHA-256 as the hash function.
For TLS_ECMQV_ECQV_WITH_AES_256_CBC_SHA384:
o The MAC is HMAC [RFC2104] with SHA-384 as the hash function.
o When negotiated in a version of TLS prior to 1.2, the PRF from
that version is used; otherwise the PRF is the TLS version 1.2 PRF
[RFC5246] with SHA-384 as the hash function.
5.3. ECMQV_ECQV Cipher Suites Using AES-MMO Hash Functions
The document specifies two cipher suites using ECMQV key exchange and
ECQV certificates with AES encryption and AES-MMO hash functions:
CipherSuite TLS_ECMQV_ECQV_WITH_AES_128_CCM_AES_128_MMO = {0xXX,0xXX};
Campagna & Stebila Expires July 20, 2010 [Page 16]
Internet-Draft ECMQV_ECQV in TLS January 2010
CipherSuite TLS_ECMQV_ECQV_WITH_AES_128_CCM_AES_256_MMO = {0xXX,0xXX};
The AES-MMO hash functions are specified in [ZigBee], Section B.6.
These two cipher suites are similar to the above and are included to
accommodate the Certificate-Based Key Establishment (CBKE) scheme in
[ZigBeeSE].
o The MAC is HMAC [RFC2104] with AES-128-MMO or AES-256-MMO,
respectively, as the hash function.
o When negotiated in a version of TLS prior to 1.2, the PRF from
that version is used; otherwise the PRF is the TLS version 1.2 PRF
[RFC5246] with AES-128-MMO or AES-256-MMO, respectively, as the
hash function.
Campagna & Stebila Expires July 20, 2010 [Page 17]
Internet-Draft ECMQV_ECQV in TLS January 2010
6. ECMQV_ECQV-Based Cipher Suites With NULL Encryption
This section specifies cipher suites using the NULL encryption
algorithm. As a result, these cipher suites provide only
authentication, not confidentiality.
6.1. ECMQV_ECQV Cipher Suite Using the SHA-1 Hash Function with NULL
Encryption
The following cipher suite matches the cipher suites defined in
Section 5.1, except that we define a suite with NULL encryption.
CipherSuite TLS_ECMQV_ECQV_WITH_NULL_SHA = {0xXX,0xXX};
6.2. ECMQV_ECQV Cipher Suites Using the SHA2 Hash Function Family with
NULL Encryption
The following two cipher suites are the same as the corresponding
cipher suites in Section 5.2, but with NULL encryption.
CipherSuite TLS_ECMQV_ECQV_WITH_NULL_SHA256 = {0xXX,0xXX};
CipherSuite TLS_ECMQV_ECQV_WITH_NULL_SHA384 = {0xXX,0xXX};
6.3. ECMQV_ECQV Cipher Suites Using AES-MMO Hash Functions with NULL
Encryption
The following two cipher suites are the same as the corresponding
cipher suites in Section 5.3, but with NULL encryption.
CipherSuite TLS_ECMQV_ECQV_WITH_NULL_AES_128_MMO = {0xXX,0xXX};
CipherSuite TLS_ECMQV_ECQV_WITH_NULL_AES_256_MMO = {0xXX,0xXX};
Campagna & Stebila Expires July 20, 2010 [Page 18]
Internet-Draft ECMQV_ECQV in TLS January 2010
7. Security Considerations
This document provides new cipher suites for the Transport Layer
Security protocol. For the most part, the security considerations
involved in using the Transport Layer Security protocol apply.
Additionally, implementers should be aware of security considerations
specific to elliptic curve cryptography.
For ECMQV authenticated key exchange, the current best known
technique for breaking the cryptosystems is by solving the elliptic
curve discrete logarithm problem (ECDLP).
The difficulty of breaking the ECDLP depends on the size and quality
of the elliptic curve parameters. Certain types of curves can be
more susceptible to known attacks than others. For example, curves
over finite fields GF(2^m), where m is composite, may be susceptible
to an attack based on the Weil descent. All of the named curves
specified in [RFC4492], Section 5.1.1, do not have this problem.
System administrators should be cautious when enabling named curves
other than the ones specified in [RFC4492] or in supporting explicit
curves, and should make a more detailed investigation into the
security of the curve in question.
It is believed (see for example Section B.2.1 of [SEC1]) that when
curve parameters are generated at random the curves will be resistant
to special attacks, and must rely on the most general attacks. The
named curves in [RFC4492], Section 5.1.1, were all generated
verifiably pseudorandomly. The runtime of general attacks depends on
the algorithm used. At present, the best known algorithm is the
Pollard-rho method. (Shor's algorithm for quantum computers can
solve the ECDLP in polynomial time, but at present large-scale
quantum computers have not been constructed and significant
experimental physics and engineering work needs to be done before
large-scale quantum computers can be constructed. There is no solid
estimate as to when this may occur, but it is widely believed to be
at least 20 years from the present.)
Based on projections of computation power, it is possible to estimate
the running time of the best known attacks based on the size of the
finite field. Table 1 in [RFC4492] gives an estimate of the
equivalence between elliptic curve field size and symmetric key size.
Roughly speaking, an N-bit elliptic curve offers the same security as
an N/2-bit symmetric cipher, so a 256-bit elliptic curve (such as the
secp256r1 curve) is suitable for use with 128-bit AES, for example.
Many estimates consider that 2^80-2^90 operations are beyond
feasible, so that would suggest using elliptic curves of at least
160-180 bits. The REQUIRED curves in this documents are 256-, 384-,
Campagna & Stebila Expires July 20, 2010 [Page 19]
Internet-Draft ECMQV_ECQV in TLS January 2010
and 521-bit curves; implementations SHOULD NOT use curves smaller
than 160 bits.
A detailed discussion on the security considerations of elliptic
curve domain parameters and the ECMQV algorithm can be found in
Appendix B of [SEC1].
Additionally, the cipher suites defined in this document rely on the
SHA-1 hash function, the SHA2 family of hash functions, and the AES-
MMO hash function, as well as the DES, Triple-DES, and AES block
ciphers. The appropriate security considerations of the documents
defining those functions apply. Although some weaknesses have been
discovered in SHA-1, it still provides a reasonable level of security
for lower security lebels. No weaknesses in the SHA2 family are
known at present. The SHA2 family consists of four variants -- SHA-
224, SHA-256, SHA-384, and SHA-521 -- named after their digest
lengths. In the absence of special purpose attacks exploiting the
specific structure of the hash function, the difficulty of finding
collisions, preimages, and second preimages for the hash function is
related to the digest length.
Since ECMQV allow for elliptic curves of arbitrary sizes and thus
arbitrary security strength, it is important that the size of
elliptic curve be chosen to match the security strength of other
elements of the cipher suite. In particular, key sizes, hashing
algorithms and bulk encryption algorithms must be chosen
appropriately. Information regarding estimated equivalence of key
sizes is available in [NIST-800-57]; the discussion in [RFC3766] is
also relevant.
System administrators and implementers should take careful
consideration of the security issues when enabling curves other than
the named curves defined in [RFC4492]. Not all elliptic curves are
secure, even if they are over a large field.
Implementers SHOULD ensure that any ephemeral private keys or random
values -- including the ephemeral private key values in ECMQV -- are
generated from a random number generator or a properly-seed
pseudorandom number generator, are protected from leakage, are not
reused outside of the context of the protocol in this document, and
are erased from memory when no longer needed. Additionally,
implementers SHOULD ensure that any public keys received are
validated as per the specification to avoid known attacks.
Campagna & Stebila Expires July 20, 2010 [Page 20]
Internet-Draft ECMQV_ECQV in TLS January 2010
8. IANA Considerations
This document defines the following new cipher suites, whose values
are to be assigned from the TLS Cipher Suite registry defined in
[RFC5246].
CipherSuite TLS_ECMQV_ECQV_WITH_RC4_128_SHA = {0xXX,0xXX};
CipherSuite TLS_ECMQV_ECQV_WITH_3DES_EDE_CBC_SHA = {0xXX,0xXX};
CipherSuite TLS_ECMQV_ECQV_WITH_AES_128_CBC_SHA = {0xXX,0xXX};
CipherSuite TLS_ECMQV_ECQV_WITH_AES_256_CBC_SHA = {0xXX,0xXX};
CipherSuite TLS_ECMQV_ECQV_WITH_AES_128_CBC_SHA256 = {0xXX,0xXX};
CipherSuite TLS_ECMQV_ECQV_WITH_AES_256_CBC_SHA384 = {0xXX,0xXX};
CipherSuite TLS_ECMQV_ECQV_WITH_NULL_SHA = {0xXX,0xXX};
CipherSuite TLS_ECMQV_ECQV_WITH_NULL_SHA256 = {0xXX,0xXX};
CipherSuite TLS_ECMQV_ECQV_WITH_NULL_SHA384 = {0xXX,0xXX};
This document defines the following new client certificate types,
whose values are to be assigned from the TLS ClientCertificateType
Identifiers registry defined in [RFC5246].
ecqv_ecmqv (xx)
This document defines the following new signature algorithms, whose
values are to be assigned from the TLS SignatureAlgorithm registry
defined in [RFC5246].
ecqv (xx)
This document defines the following new hash algorithms, whose values
are to be assigned from the TLS HashAlgorithm registry defined in
[RFC5246].
aes_128_mmo (xx),
aes_256_mmo (xx)
This document creates no new registries.
Campagna & Stebila Expires July 20, 2010 [Page 21]
Internet-Draft ECMQV_ECQV in TLS January 2010
9. References
9.1. Normative References
[FIPS-180-3]
National Institute of Standards and Technology, "Secure
Hash Standard", FIPS 180-3, October 2008, <http://
csrc.nist.gov/publications/fips/fips180-3/
fips180-3_final.pdf>.
[FIPS-197]
National Institute of Standards and Technology, "Advanced
Encryption Standard", FIPS 197, November 2001, <http://
csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.
[I-D.ietf-tls-rfc4347-bis]
Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security version 1.2", draft-ietf-tls-rfc4347-bis-03 (work
in progress), October 2009.
[NIST-800-57]
National Institute of Standards and Technology,
"Recommendation for Key Management - Part 1: General
(Revised)", NIST Special Publication 800-57, March 2007, <
http://csrc.nist.gov/publications/nistpubs/800-57/
sp800-57-Part1-revised2_Mar08-2007.pdf>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, April 2004.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
Campagna & Stebila Expires July 20, 2010 [Page 22]
Internet-Draft ECMQV_ECQV in TLS January 2010
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[SEC1] Standards for Efficient Cryptography Group, "Elliptic
Curve Cryptography", SEC 1, September 2000,
<http://www.secg.org/download/aid-780/sec1-v2.pdf>.
[SEC4] Standards for Efficient Cryptography Group, "Elliptic
Curve Qu-Vanstone Implicit Certificate Scheme (ECQV),
v0.91", SEC 4, November 2008,
<http://www.secg.org/download/aid-775/sec4-ECQV-v091.pdf>.
[ZigBee] ZigBee Standards Organization, "ZigBee Specification,
revision 17", October 2007, <http://www.zigbee.org/
ZigBeeSpecificationDownloadRequest/tabid/311/
Default.aspx>.
Registration required.
9.2. Informative References
[HMV04] Hankerson, D., Menezes, A., and S. Vanstone, "Guide to
Elliptic Curve Cryptography", 2004.
Springer, ISBN 038795273X.
[IEEE1363]
Institute of Electrical and Electronics Engineers,
"Standard Specifications for Public Key Cryptography",
IEEE 1363, 2000.
[LMQSV98] Law, L., Menezes, A., Qu, M., Solinas, J., and S.
Vanstone, "An Efficient Protocol for Authenticated Key
Agreement", University of Waterloo Technical Report
CORR 98-05, August 1998, <http://
www.cacr.math.uwaterloo.ca/techreports/1998/
corr98-05.pdf>.
[MOV96] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook
of Applied Cryptography", 1996,
<http://www.cacr.math.uwaterloo.ca/hac>.
Campagna & Stebila Expires July 20, 2010 [Page 23]
Internet-Draft ECMQV_ECQV in TLS January 2010
CRC Press, ISBN 0-8493-8523-7. Available online.
[ZigBeeSE]
ZigBee Standards Organization, "ZigBee Smart Energy
Profile Specification, revision 15", December 2008, <http:
//www.zigbee.org/
ZigBeeSmartEnergyPublicApplicationProfile/tabid/312/
Default.aspx>.
Registration required.
Campagna & Stebila Expires July 20, 2010 [Page 24]
Internet-Draft ECMQV_ECQV in TLS January 2010
The authors gratefully acknowledge helpful suggestions from Hamid
Mukhtar.
Campagna & Stebila Expires July 20, 2010 [Page 25]
Internet-Draft ECMQV_ECQV in TLS January 2010
Authors' Addresses
Matthew Campagna
Certicom Corp.
5520 Explorer Drive #400
Mississauga, Ontario L4W 5L1
Canada
Email: mcampagna@certicom.com
Douglas Stebila
Queensland University of Technology
Information Security Institute
Level 7, 126 Margaret St
Brisbane, Queensland 4000
Australia
Email: douglas@stebila.ca
Campagna & Stebila Expires July 20, 2010 [Page 26]
Html markup produced by rfcmarkup 1.115, available from
https://tools.ietf.org/tools/rfcmarkup/