Internet-Draft R. Dugal October 2006 B. Minard Expires: April 19, 2007 Certicom Corp. October 16, 2006 ECMQV Ciphersuites for TLS draft-dugal-tls-ecmqv-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 April 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the changes necessary to permit Transport Layer Security (TLS) to support the Elliptic Curve Menezes-Qu- Vanstone Key Agreement (ECMQV). Dugal & Minard Expires April 19, 2007 [Page 1] Internet-Draft ECMQV in TLS October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. ECMQV Key Exchange Algorithms . . . . . . . . . . . . . . . . 4 3. Client Authentication . . . . . . . . . . . . . . . . . . . . 6 4. Data Structures and Computations . . . . . . . . . . . . . . . 7 4.1. Server Certificate . . . . . . . . . . . . . . . . . . . . 7 4.2. Server Key Exchange . . . . . . . . . . . . . . . . . . . 7 4.3. Certificate Request . . . . . . . . . . . . . . . . . . . 8 4.4. Client Certificate . . . . . . . . . . . . . . . . . . . . 8 4.5. Client Key Exchange . . . . . . . . . . . . . . . . . . . 9 4.6. Certificate Verify . . . . . . . . . . . . . . . . . . . . 10 4.7. ECMQV, ECDSA, and RSA Computations . . . . . . . . . . . . 11 5. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Dugal & Minard Expires April 19, 2007 [Page 2] Internet-Draft ECMQV in TLS October 2006 1. Introduction This document describes the changes necessary to permit TLS to support the Elliptic Curve Menezes-Qu-Vanstone Key Agreement (ECMQV) with ECDSA- and RSA-signed certificates. These changes permit the use of Full MQV in TLS [2] and are applicable to TLS Version 1.0 [4] and TLS Version 1.1 [9]. The ECMQV key exchange algorithm is designed to provide a variety of security goals such as mutual implicit key authentication, known-key security, and forward secrecy [2] [13]. Each of these security goals is achieved through the use of Full MQV with mutually authenticated peers. The use of Full MQV with anonymous clients is also defined. Note: the addition of ECMQV to TLS was first proposed in ECC Cipher Suites for TLS (draft-ietf-tls-ecc-00.txt, March 13, 1998), a predecessor of [10]. This document provides an update to ECC Cipher Suites for TLS [10]. 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 RFC 2119 [3]. Dugal & Minard Expires April 19, 2007 [Page 3] Internet-Draft ECMQV in TLS October 2006 2. ECMQV Key Exchange Algorithms The ECMQV_ECDSA and ECMQV_RSA key exchange algorithms are added to TLS. These key exchange algorithms use fixed ECMQV-capable keys in certificates. Two ephemeral ECMQV public keys are also exchanged. The exchange of ephemeral public keys occurs in the ServerKeyExchange and ClientKeyExchange messages (see Section 4.2 and Section 4.5, respectively). In ECMQV_ECDSA, the server MUST have a certificate containing an ECMQV-capable key. Both the client and server MUST generate an ephemeral ECMQV key. The client MUST provide the server with either a certificate containing an ECMQV-capable key, a static ECMQV key, or a second ephemeral ECMQV key. If the client has a suitable certificate then it MUST send that certificate in the ClientCertificate message. This message has the same format and meaning as the message defined in [10]. The option to provide a static ECMQV key to the server allows for the possibility that the server has another means of validating the binding of that public key to the client. We differentiate between static and ephemeral keys: no binding exists between an ephemeral key and the peer generating it. In the absence of both a suitable certificate and a static key the client MUST send a second ephemeral key. The two ephemeral keys sent in this case MAY be the same key. An ECMQV-capable key is an ECC key whose use in ECMQV is permitted. All key-pairs MUST be generated using the same elliptic curve parameters and the client's certificate MUST be eligible for use with client authentication. Each certificate MUST be signed with ECDSA [1]. Note that there is no structural difference between ECDSA and ECMQV keys. A certificate issuer MAY use the X.509 v3 keyUsage and extendedKeyUsage extensions to restrict the use of an ECC public key to certain computations [6]. X509 certificates containing ECC public keys or signed using ECDSA MUST comply with [5] or another RFC that replaces or extends it. Clients SHOULD use the elliptic curve domain parameters recommended in ANSI X9.62 [1], FIPS 186-2 [12], and SEC 2 [14]. The ECMQV_RSA key exchange algorithm is the same as ECMQV_ECDSA, except that each certificate MUST be signed with RSA [8]. The ECMQV_RSA key exchange algorithm allows the certificate issuer to continue using existing RSA certificates for signing whereas the Dugal & Minard Expires April 19, 2007 [Page 4] Internet-Draft ECMQV in TLS October 2006 ECMQV_ECDSA key exchange algorithm requires the certificate issuer to adopt an ECC certificate. Regardless of the key exchange algorithm used, the server MUST adopt an ECC certificate. Client Server ------ ------ ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest*+ <-------- ServerHelloDone Certificate*+ ClientKeyExchange CertificateVerify*+ [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data * message is not sent under some conditions + message is not sent unless client authentication is desired Figure 1: Message flow in a full TLS handshake Figure 1 shows all of the messages in the TLS key establishment protocol. The addition of ECMQV has a direct impact on the ServerCertificate, ServerKeyExchange, CertificateRequest, ClientCertificate, ClientKeyExchange, and CertificateVerify messages. Each of these messages are discussed in Section 4. All other messages have the format and meaning defined in [10]. Dugal & Minard Expires April 19, 2007 [Page 5] Internet-Draft ECMQV in TLS October 2006 3. Client Authentication The ECDSA_mqv and RSA_mqv client authentication mechanisms are added to TLS. These authentication mechanisms permit the client's certified ECMQV public key to participate in the key exchange. If the server sends a CertificateRequest message containing the ECDSA_mqv authentication type, then the client SHOULD send the server both a certificate containing an ECMQV-capable public key and an ephemeral ECMQV public key. The client's certificate is signed with ECDSA and sent in the ClientCertificate message and the ephemeral ECMQV public key is provided in the ClientKeyExchange message (see Section 4.5). If the client does not have a certificate eligible for client authentication then the client MUST provide the server with either a static ECMQV key or a second ephemeral ECMQV key. The public half of this ECMQV key is sent to the server in the ClientKeyExchange message (see Section 4.5). A certificate is eligible for client authentication if the ECMQV public key contained in that certificate uses the same elliptic curve domain parameters as the server's public keys and if it respects the server's choice of point format. All ECMQV keys sent by the client MUST be generated using the same elliptic curve parameters used to generate the server's public keys. The RSA_mqv client authentication mechanism is the same as the ECDSA_mqv client authentication mechanism, except that the client's certificate is signed with RSA. Dugal & Minard Expires April 19, 2007 [Page 6] Internet-Draft ECMQV in TLS October 2006 4. Data Structures and Computations The TLS presentation language is used to specify new data structures required to support the ECMQV key exchange algorithm (see [9] and [4]). These specifications extend the TLS protocol specification and MUST be merged with those in TLS [4] and in any other specifications which extend TLS ([7], [9], and [10]). 4.1. Server Certificate The section updates Table 3, "Server certificate types" in [10], otherwise this message is exactly as defined in [10]. +--------------+----------------------------------------------------+ | Key Exchange | Server Certificate Type | | Algorithm | | +--------------+----------------------------------------------------+ | ECMQV_ECDSA | Certificate MUST contain an ECMQV-capable public | | | key. It MUST be signed with ECDSA. | | | | | ECMQV_RSA | Certificate MUST contain an ECMQV-capable public | | | key. It MUST be signed with RSA. | +--------------+----------------------------------------------------+ Table 1: Server certificate types 4.2. Server Key Exchange When this message is sent: This message is sent in the ECMQV_ECDSA and ECMQV_RSA key establishment methods. Meaning of this message: This message is used to convey the server's ephemeral ECMQV public key to the client. Structure of this message: The ServerKeyExchange message is extended as follows. enum { ec_menezes_qu_vanstone } KeyExchangeAlgorithm; Dugal & Minard Expires April 19, 2007 [Page 7] Internet-Draft ECMQV in TLS October 2006 struct { ECPoint ecmqv_ephemeral; } ServerECMQVPublic; struct { select (KeyExchangeAlgorithm) { case ec_menezes_qu_vanstone: ServerMQVPublic public; }; } ServerKeyExchange; ec_menezes_qu_vanstone: Indicates the ServerKeyExchange message contains an ECMQV public key. public: Specifies the ECMQV public key. Actions of the sender: The server generates an ephemeral ECMQV public key corresponding to the curve parameters of the server's ECMQV-capable public key sent in the Server Certificate message. This key is used in the Full MQV Scheme described in Section 6.10 of X9.63 [2]. It conveys this information to the client in the ServerKeyExchange message using the format defined above. Actions of the recipient: The client retrieves the server's ephemeral ECMQV public key from the ServerKeyExchange message. 4.3. Certificate Request The TLS CertificateRequest message is extended as follows. enum { ecdsa_mqv(??), rsa_mqv(??), (255) } ClientCertificateType; ecdsa_mqv and rsa_mqv indicate that the server would like to use the corresponding client authentication method (see Section 3). This message is otherwise exactly as defined in [10]. 4.4. Client Certificate The section updates Table 4, "Client certificate types" in [10], otherwise this message is exactly as defined in [10]. (The client Dugal & Minard Expires April 19, 2007 [Page 8] Internet-Draft ECMQV in TLS October 2006 certificate MUST respect the Supported Point Formats Extension whenever this extension is used by the server.) +-----------------+-------------------------------------------------+ | Client | Client Certificate Type | | Authentication | | | Method | | +-----------------+-------------------------------------------------+ | ECDSA_mqv | Certificate MUST contain an ECMQV-capable | | | public key. It MUST be signed with ECDSA. | | | | | RSA_mqv | Certificate MUST contain an ECMQV-capable | | | public key. It MUST be signed with RSA. | +-----------------+-------------------------------------------------+ Table 2: Client certificate types 4.5. Client Key Exchange When this message is sent: This message is sent in the ECMQV_ECDSA and ECMQV_RSA key establishment methods. Meaning of the message: This message is used to convey ephemeral data relating to the ECMQV key exchange belonging to the client. When the client does not have a suitable certificate or client authentication is not requested this message MUST contain a second ECMQV public key. Structure of this message: The TLS ClientKeyExchange message is extended as follows. Dugal & Minard Expires April 19, 2007 [Page 9] Internet-Draft ECMQV in TLS October 2006 enum { implicit, explicit } PublicValueEncoding; implicit If the client certificate already contains a suitable ECMQV key, then it does not need to be sent again. In this case, the ClientKeyExchange message will be sent, but this value will be empty. explicit An ECMQV public key needs to be sent. struct { select(PublicValueEncoding) { case implicit: struct {}; case explicit: ECPoint ecmqv; } ecmqv_public; ECPoint ecmqv_ephemeral; } ClientECMQVPublic; struct { select (KeyExchangeAlgorithm) { case ec_menezes_qu_vanstone: ClientECMQVPublic; } exchange_keys; } ClientKeyExchange; Actions of the sender: If the client has sent a certificate with an MQV key, ecmqv_ephemeral will contain the client's ephemeral public key for the MQV operation; otherwise ecmqv_ephemeral will contain an ephemeral public key that is used as the ephemeral public key for the MQV operation and ecmqv will contain a second ECMQV public key which takes the place of the certified key. Actions of the recipient: The server retrieves the client's ECMQV public keys from the ClientKeyExchange message and checks that it is on the same elliptic curve as the server's ECMQV key. 4.6. Certificate Verify The CertificateVerify message is never used. The client's ability to arrive at the same premaster secret as the server is sufficient to demonstrate its control over the private half of the certified ECMQV public key. Dugal & Minard Expires April 19, 2007 [Page 10] Internet-Draft ECMQV in TLS October 2006 4.7. ECMQV, ECDSA, and RSA Computations All ECMQV calculations (including the elliptic curve parameters, key generation, and the shared secret calculation) are performed according to the Full MQV Scheme described in Section 6.10 of X9.63 [2]. All ECDSA computations MUST be performed according to ANSI X9.62 [1] or its successors. Data to be signed or verified is hashed and the result run directly through the ECDSA algorithm with no additional hashing. The default hash function is SHA-1 [11] and sha_size Section 4.7) is 20. However, an alternative hash function, such as one of the new SHA hash functions specified in FIPS 180-2 [11], MAY be used instead if the certificate containing the EC public key explicitly requires use of another hash function. (The mechanism for specifying the required hash function has not been standardized but this provision anticipates such standardization and obviates the need to update this document in response. Future PKIX RFCs may choose, for example, to specify the hash function to be used with a public key in the parameters field of subjectPublicKeyInfo.) All RSA signatures MUST be verified according to [8], or its successors. Dugal & Minard Expires April 19, 2007 [Page 11] Internet-Draft ECMQV in TLS October 2006 5. Cipher Suites The following cipher suites are defined: +-------------------------------------------------------------------+ | CipherSuite TLS_ECMQV_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } | | | | CipherSuite TLS_ECMQV_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } | | | | CipherSuite TLS_ECMQV_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? | | } | | | | CipherSuite TLS_ECMQV_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } | | | | CipherSuite TLS_ECMQV_ECDSA_WITH_AES_128_CBC_SHA256 = { 0x00, | | 0x?? } | | | | CipherSuite TLS_ECMQV_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } | | | | CipherSuite TLS_ECMQV_ECDSA_WITH_AES_256_CBC_SHA384 = { 0x00, | | 0x?? } | | | | CipherSuite TLS_ECMQV_RSA_WITH_NULL_SHA = { 0x00, 0x?? } | | | | CipherSuite TLS_ECMQV_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } | | | | CipherSuite TLS_ECMQV_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } | | | | CipherSuite TLS_ECMQV_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } | | | | CipherSuite TLS_ECMQV_RSA_WITH_AES_128_CBC_SHA256 = { 0x00, 0x?? | | } | | | | CipherSuite TLS_ECMQV_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } | | | | CipherSuite TLS_ECMQV_RSA_WITH_AES_256_CBC_SHA384 = { 0x00, 0x?? | | } | +-------------------------------------------------------------------+ Table 3: TLS ECMQV cipher suites Server implementations SHOULD support all of the cipher suites defined here and client implementations should support at least one of the following cipher suites: TLS_ECMQV_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECMQV_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECMQV_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECMQV_RSA_WITH_3DES_EDE_CBC_SHA, Dugal & Minard Expires April 19, 2007 [Page 12] Internet-Draft ECMQV in TLS October 2006 TLS_ECMQV_RSA_WITH_AES_128_CBC_SHA, or TLS_ECMQV_RSA_WITH_AES_128_CBC_SHA256. Dugal & Minard Expires April 19, 2007 [Page 13] Internet-Draft ECMQV in TLS October 2006 6. Security Considerations This document is based on X9.62 [1], RFC 2246 [4], RFC 3268 [15], RFC 4346 [9], RFC 4492 [10], and IEEE 1363 [16]. The appropriate security considerations of those documents apply. Implementors SHOULD select security levels appropriate for their application. X9.62 [1] measures security level in bits. The approved security levels are: 80-, 112-, 128-, 192-, and 265-bits. The security level provided by ECDSA is dependent upon the security level of each cryptographic component used in an ECDSA operation. In general, the hash algorithm used for ECDSA signature generation SHOULD more or less match the symmetric key size shown in the following table (reproduced for convenience from [10]). +---------------+-------------+------------+ | Symmetric Key | ECDSA/ECMQV | DH/DSA/RSA | +---------------+-------------+------------+ | 80 | 163 | 1024 | | | | | | 112 | 233 | 2048 | | | | | | 128 | 283 | 3072 | | | | | | 192 | 409 | 7680 | | | | | | 256 | 571 | 15360 | +---------------+-------------+------------+ Table 4: Comparable Key Sizes Dugal & Minard Expires April 19, 2007 [Page 14] Internet-Draft ECMQV in TLS October 2006 7. IANA Considerations TBD. Dugal & Minard Expires April 19, 2007 [Page 15] Internet-Draft ECMQV in TLS October 2006 8. Acknowledgments Thanks to Dan Brown for reviewing this document. Dugal & Minard Expires April 19, 2007 [Page 16] Internet-Draft ECMQV in TLS October 2006 9. References 9.1. Normative References [1] American National Standards Institute, "ANSI X9.62: Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", 2005. [2] American National Standards Institute, "ANSI X9.63: Public Key Cryptography For The Financial Services Industry: Key Agreement and Key Transport using Elliptic Curve Cryptography", 2001. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [5] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002. [6] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [7] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [8] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005. [9] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [10] 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. [11] National Institute of Standards and Technology, "FIPS 180 Secure Hashing Algorithm", 2002. [12] National Institute of Standards and Technology, "FIPS 186-2 Digital Signature Standard", 2000. Dugal & Minard Expires April 19, 2007 [Page 17] Internet-Draft ECMQV in TLS October 2006 [13] Standards for Efficient Crytopgraphy Group, "Elliptic Curve Cryptography", September 2000. [14] Standards for Efficient Crytopgraphy Group, "Recommended Elliptic Curve Domain Parameters", September 2000. 9.2. Informative References [15] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [16] International Electrial and Electronic Engineers, "IEEE 1363: 2000 Standard Specifications for Public Key Cryptograph", 2000. Dugal & Minard Expires April 19, 2007 [Page 18] Internet-Draft ECMQV in TLS October 2006 Authors' Addresses Robert Dugal Certicom Corp. 5520 Explorer Drive Mississauga, Ontario L4W 5L1 CANADA Phone: +1-905-507-4220 Fax: +1-905-507-4230 Email: rdugal@certicom.com URI: http://www.certicom.com Brian Minard Certicom Corp. 5520 Explorer Drive Mississauga, Ontario L4W 5L1 CANADA Phone: +1-905-507-4220 Fax: +1-905-507-4230 Email: bminard@certicom.com URI: http://www.certicom.com Dugal & Minard Expires April 19, 2007 [Page 19] Internet-Draft ECMQV in TLS October 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Dugal & Minard Expires April 19, 2007 [Page 20]