ECMQV_ECQV Cipher Suites for Transport Layer Security (TLS)
draft-campagna-tls-ecmqv-ecqv-00

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 March 28, 2010.

Copyright Notice

Copyright (c) 2009 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 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document specifies a set of cipher suites for the Transport Layer Security (TLS) protocol that use Elliptic Curve Qu-Vanstone (ECQV) certificates to authenticate an Elliptic Curve Menezes-Qu-Vanstone (ECMQV) exchange. These cipher suites provide forward secrecy.

Table of Contents

1.  Introduction
2.  Notation
3.  ECMQV_ECQV Key Exchange Algorithm
    3.1.  ECMQV_ECQV Handshake Protocol Overview
    3.2.  Server Authentication
    3.3.  Client Authentication
4.  Data Structures and Computations
    4.1.  Server Certificate
    4.2.  Server Key Exchange
    4.3.  Certificate Request
    4.4.  Client Certificate
    4.5.  Client Key Exchange
5.  ECMQV_ECQV-Based Cipher Suites
    5.1.  ECMQV_ECQV Cipher Suites Using the SHA-1 Hash Function
    5.2.  ECMQV_ECQV Cipher Suites Using the SHA2 Hash Function Family
    5.3.  ECMQV_ECQV Cipher Suites Using AES-MMO Hash Functions
6.  ECMQV_ECQV-Based Cipher Suites With NULL Encryption
    6.1.  ECMQV_ECQV Cipher Suite Using the SHA-1 Hash Function with NULL Encryption
    6.2.  ECMQV_ECQV Cipher Suites Using the SHA2 Hash Function Family with NULL Encryption
    6.3.  ECMQV_ECQV Cipher Suites Using AES-MMO Hash Functions with NULL Encryption
7.  Security Considerations
8.  IANA Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  Acknowledgements
§  Authors' Addresses

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] (Standards for Efficient Cryptography Group, “Elliptic Curve Qu-Vanstone Implicit Certificate Scheme (ECQV), v0.91,” November 2008.). 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.

[RFC4492] (Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS),” May 2006.) 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.

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 Standards Organization, “ZigBee Smart Energy Profile Specification, revision 15,” December 2008.). 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 to support ECMQV_ECQV, applicable to TLS version 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.), TLS version 1.1 [RFC4346] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1,” April 2006.), and TLS version 1.2 [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.). In particular, it defines:

• the use of the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement scheme with long-term and ephemeral keys to establish the TLS premaster secret, and
• the use of Elliptic Curve Qu-Vanstone (ECQV) implicit certificates for authentication of TLS peers.

The remainder of this document is organized as follows. Section 3 (ECMQV_ECQV Key Exchange Algorithm) provides an overview of ECMQV_ECQV-based key exchange algorithms for TLS. Section 4 (Data Structures and Computations) describes the data structures and actions required to implement the new authenticated key agreement scheme. Section 5 (ECMQV_ECQV-Based Cipher Suites) defines new ECMQV_ECQV-based cipher suites and identifies a small subset of these as recommended for all implementations of this specification. Section 7 (Security Considerations) discusses security considerations. Section 8 (IANA Considerations) describes IANA considerations for the name spaces created by this document.

Implementation of this document requires familiarity with the following technologies and standards: elliptic curve cryptography [SEC1] (Standards for Efficient Cryptography Group, “Elliptic Curve Cryptography,” September 2000.) (additional information available in [HMV04] (Hankerson, D., Menezes, A., and S. Vanstone, “Guide to Elliptic Curve Cryptography,” 2004.), [IEEE1363] (Institute of Electrical and Electronics Engineers, “Standard Specifications for Public Key Cryptography,” 2000.)); ECMQV [SEC1] (Standards for Efficient Cryptography Group, “Elliptic Curve Cryptography,” September 2000.), Section 6.2 (additional information available in [LMQSV98] (Law, L., Menezes, A., Qu, M., Solinas, J., and S. Vanstone, “An Efficient Protocol for Authenticated Key Agreement,” August 1998.)); ECQV [SEC4] (Standards for Efficient Cryptography Group, “Elliptic Curve Qu-Vanstone Implicit Certificate Scheme (ECQV), v0.91,” November 2008.); the use of elliptic curve cryptography in TLS [RFC4492] (Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS),” May 2006.); and the relevant version of TLS [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.), [RFC4346] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1,” April 2006.), [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.).

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  ECMQV_ECQV Key Exchange Algorithm

This document describes a new ECC-based key exchange algorithm for TLS. It uses ECMQV to compute a TLS premaster secret. The derivation of the TLS 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.

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 (Client Certificate)) 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] (Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS),” May 2006.), which makes use of TLS extensions [RFC4366] (Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, “Transport Layer Security (TLS) Extensions,” April 2006.). 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).

4.  Data Structures and Computations

This section specifies the data structures and computations used by ECMQV key mechanisms specified in Section 5 (ECMQV_ECQV-Based Cipher Suites). The presentation language used here is the same as that used in TLS [RFC4346] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1,” April 2006.). 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] (Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS),” May 2006.).

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] (Standards for Efficient Cryptography Group, “Elliptic Curve Qu-Vanstone Implicit Certificate Scheme (ECQV), v0.91,” November 2008.).

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 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] (Standards for Efficient Cryptography Group, “Elliptic Curve Qu-Vanstone Implicit Certificate Scheme (ECQV), v0.91,” November 2008.) section 2.3, under the curve specified in the Server Key Exchange message defined in Section 4.2 (Server Key Exchange). (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] (Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS),” May 2006.), 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] (Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS),” May 2006.), 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:

    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] (Standards for Efficient Cryptography Group, “Elliptic Curve Cryptography,” September 2000.), 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] (Standards for Efficient Cryptography Group, “Elliptic Curve Cryptography,” September 2000.), Section 6.2.1, and MUST validate the ephemeral public keys in accordance with [SEC1] (Standards for Efficient Cryptography Group, “Elliptic Curve Cryptography,” September 2000.), 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] (Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS),” May 2006.), 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 TLS CertificateRequest message is extended as follows.

    enum {
        ecqv_ecmqv (xx),
    } ClientCertificateType;

ecqv_ecmqv: Indicates that the server would like to use the corresponding client authentication method specified in Section 4.4 (Client Certificate).

The TLS 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] (ZigBee Standards Organization, “ZigBee Specification, revision 17,” October 2007.), Section B.6; see also [MOV96] (Menezes, A., van Oorschot, P., and S. Vanstone, “Handbook of Applied Cryptography,” 1996.), 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] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.). The following rules augment the existing rules in [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.):

• 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.

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 (Server Certificate).

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 TLS server validates the information in the ECQVCert, and extracts the client's public key using the operations specified in [SEC4] (Standards for Efficient Cryptography Group, “Elliptic Curve Qu-Vanstone Implicit Certificate Scheme (ECQV), v0.91,” November 2008.) section 2.3, under the curve specified in the Server Key Exchange message defined in Section 4.2 (Server Key Exchange).

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 TLS ClientKeyExchange message mimics [RFC4492] (Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS),” May 2006.) 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.

    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] (Standards for Efficient Cryptography Group, “Elliptic Curve Cryptography,” September 2000.), 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] (Standards for Efficient Cryptography Group, “Elliptic Curve Cryptography,” September 2000.), 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] (Standards for Efficient Cryptography Group, “Elliptic Curve Qu-Vanstone Implicit Certificate Scheme (ECQV), v0.91,” November 2008.), Section 2.5, and then perform the ECMQV computation as described in [SEC1] (Standards for Efficient Cryptography Group, “Elliptic Curve Cryptography,” September 2000.), Section 6.2. Let premaster secret be the octet string produced by this computation.

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 (ECMQV_ECQV Cipher Suites Using the SHA-1 Hash Function) above, except for the hash and PRF algorithms, which are as follows.

For TLS_ECMQV_ECQV_WITH_AES_128_CBC_SHA256:

• The MAC is HMAC [RFC2104] (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” February 1997.) with SHA-256 as the hash function.
• 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] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) with SHA-256 as the hash function.

For TLS_ECMQV_ECQV_WITH_AES_256_CBC_SHA384:

• The MAC is HMAC [RFC2104] (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” February 1997.) with SHA-384 as the hash function.
• 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] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) 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};
    CipherSuite TLS_ECMQV_ECQV_WITH_AES_128_CCM_AES_256_MMO = {0xXX,0xXX};

The AES-MMO hash functions are specified in [ZigBee] (ZigBee Standards Organization, “ZigBee Specification, revision 17,” October 2007.), 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] (ZigBee Standards Organization, “ZigBee Smart Energy Profile Specification, revision 15,” December 2008.).

• The MAC is HMAC [RFC2104] (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” February 1997.) with AES-128-MMO or AES-256-MMO, respectively, as the hash function.
• 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] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) with AES-128-MMO or AES-256-MMO, respectively, as the hash function.

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 (ECMQV_ECQV Cipher Suites Using the SHA-1 Hash Function), 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 (ECMQV_ECQV Cipher Suites Using the SHA2 Hash Function Family), 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 (ECMQV_ECQV Cipher Suites Using AES-MMO Hash Functions), 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};

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] (Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS),” May 2006.), 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] (Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS),” May 2006.) 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] (Standards for Efficient Cryptography Group, “Elliptic Curve Cryptography,” September 2000.)) 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] (Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS),” May 2006.), 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] (Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS),” May 2006.) 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-, 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] (Standards for Efficient Cryptography Group, “Elliptic Curve Cryptography,” September 2000.).

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] (National Institute of Standards and Technology, “Recommendation for Key Management - Part 1: General (Revised),” March 2007.); the discussion in [RFC3766] (Orman, H. and P. Hoffman, “Determining Strengths For Public Keys Used For Exchanging Symmetric Keys,” April 2004.) 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] (Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS),” May 2006.). 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.

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] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.).

    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] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.).

    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] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.).

    ecqv (xx)

This document defines the following new hash algorithms, whose values are to be assigned from the TLS HashAlgorithm registry defined in [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.).

    aes_128_mmo (xx),
    aes_256_mmo (xx)

This document creates no new registries.

9.  References

9.1. Normative References

9.2. Informative References

Appendix A.  Acknowledgements

Authors' Addresses