Network Working Group M. Campagna Internet-Draft Certicom Corp. Intended status: Informational D. Stebila Expires: March 28, 2010 Queensland University of Technology September 24, 2009 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. Campagna & Stebila Expires March 28, 2010 [Page 1] Internet-Draft ECMQV_ECQV in TLS September 2009 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 March 28, 2010 [Page 2] Internet-Draft ECMQV_ECQV in TLS September 2009 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 March 28, 2010 [Page 3] Internet-Draft ECMQV_ECQV in TLS September 2009 +--------------------------------+----------------------------------+ | 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 to support ECMQV_ECQV, applicable to TLS version 1.0 [RFC2246], TLS version 1.1 [RFC4346], and TLS version 1.2 [RFC5246]. 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 TLS premaster secret, and o 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 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. Implementation of this document requires familiarity with the following technologies and standards: elliptic curve cryptography Campagna & Stebila Expires March 28, 2010 [Page 4] Internet-Draft ECMQV_ECQV in TLS September 2009 [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]. Campagna & Stebila Expires March 28, 2010 [Page 5] Internet-Draft ECMQV_ECQV in TLS September 2009 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 March 28, 2010 [Page 6] Internet-Draft ECMQV_ECQV in TLS September 2009 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. Figure 1 Campagna & Stebila Expires March 28, 2010 [Page 7] Internet-Draft ECMQV_ECQV in TLS September 2009 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 March 28, 2010 [Page 8] Internet-Draft ECMQV_ECQV in TLS September 2009 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 March 28, 2010 [Page 9] Internet-Draft ECMQV_ECQV in TLS September 2009 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 March 28, 2010 [Page 10] Internet-Draft ECMQV_ECQV in TLS September 2009 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 TLS CertificateRequest message is extended as follows. enum { ecqv_ecmqv (xx), Campagna & Stebila Expires March 28, 2010 [Page 11] Internet-Draft ECMQV_ECQV in TLS September 2009 } ClientCertificateType; ecqv_ecmqv: Indicates that the server would like to use the corresponding client authentication method specified in Section 4.4. 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], 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 March 28, 2010 [Page 12] Internet-Draft ECMQV_ECQV in TLS September 2009 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 TLS 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 March 28, 2010 [Page 13] Internet-Draft ECMQV_ECQV in TLS September 2009 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] 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 March 28, 2010 [Page 14] Internet-Draft ECMQV_ECQV in TLS September 2009 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 March 28, 2010 [Page 15] Internet-Draft ECMQV_ECQV in TLS September 2009 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 March 28, 2010 [Page 16] Internet-Draft ECMQV_ECQV in TLS September 2009 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 March 28, 2010 [Page 17] Internet-Draft ECMQV_ECQV in TLS September 2009 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 March 28, 2010 [Page 18] Internet-Draft ECMQV_ECQV in TLS September 2009 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 March 28, 2010 [Page 19] Internet-Draft ECMQV_ECQV in TLS September 2009 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 March 28, 2010 [Page 20] Internet-Draft ECMQV_ECQV in TLS September 2009 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 March 28, 2010 [Page 21] Internet-Draft ECMQV_ECQV in TLS September 2009 9. References 9.1. Normative References [FIPS-180-3] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-3, October 2008, . [FIPS-197] National Institute of Standards and Technology, "Advanced Encryption Standard", FIPS 197, November 2001, . [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. [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 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 Campagna & Stebila Expires March 28, 2010 [Page 22] Internet-Draft ECMQV_ECQV in TLS September 2009 (TLS) Protocol Version 1.2", RFC 5246, August 2008. [SEC1] Standards for Efficient Cryptography Group, "Elliptic Curve Cryptography", SEC 1, September 2000, . [SEC4] Standards for Efficient Cryptography Group, "Elliptic Curve Qu-Vanstone Implicit Certificate Scheme (ECQV), v0.91", SEC 4, November 2008, . [ZigBee] ZigBee Standards Organization, "ZigBee Specification, revision 17", October 2007, . 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, . [MOV96] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", 1996, . CRC Press, ISBN 0-8493-8523-7. Available online. [ZigBeeSE] ZigBee Standards Organization, "ZigBee Smart Energy Profile Specification, revision 15", December 2008, . Registration required. Campagna & Stebila Expires March 28, 2010 [Page 24] Internet-Draft ECMQV_ECQV in TLS September 2009 Appendix A. Acknowledgements Campagna & Stebila Expires March 28, 2010 [Page 25] Internet-Draft ECMQV_ECQV in TLS September 2009 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 March 28, 2010 [Page 26]