Network Working Group A. Milne Internet-Draft Intended status: Standards Track M. Blaser Expires: April 23, 2007 D. Brown E. Chin Certicom Corp. L. Dondeti QUALCOMM, Inc. October 20, 2006 ECC Algorithms for MIKEY draft-ietf-msec-mikey-ecc-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 23, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Milne, et al. Expires April 23, 2007 [Page 1] Internet-Draft ECC Algorithms for MIKEY October 2006 Abstract This document proposes extensions to the authentication, encryption and digital signature methods described for use in MIKEY, employing elliptic-curve cryptography (ECC). These extensions are defined to align MIKEY with other ECC implementations and standards. It should be noted that this document is not self-contained; it uses the notations and definitions of [RFC3830]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. MIKEY-DHSIGN with ECDSA . . . . . . . . . . . . . . . . . . . 5 3. MIKEY-DHSIGN with ECDH . . . . . . . . . . . . . . . . . . . . 6 4. MIKEY-ECIES . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. MIKEY-ECMQV . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Additional Payload Encoding . . . . . . . . . . . . . . . . . 11 6.1. ECC Point payload (ECCPT) . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Milne, et al. Expires April 23, 2007 [Page 2] Internet-Draft ECC Algorithms for MIKEY October 2006 1. Introduction This document describes additional algorithms for use in MIKEY. The document assumes that the reader is familiar with the MIKEY protocol. The MIKEY protocol [RFC3830] defines three methods for transporting or establishing keys: with the use of a pre-shared key, public-key encryption (MIKEY-RSA), and Diffie-Hellman (DH) key exchange (MIKEY- DHSIGN). This document extends MIKEY-DHSIGN to use ECDSA as the signature algorithm and further extends MIKEY-DHSIGN to use Elliptic Curve Diffie-Hellman (ECDH) groups. In addition, this document introduces two new methods based on the elliptic curve algorithms ECIES and ECMQV in exchanges similar to those of MIKEY-RSA, and name these methods MIKEY-ECIES and MIKEY-ECMQV respectively. Implementations have shown that elliptic curve algorithms can significantly improve performance and security-per-bit over other recommended algorithms. The purpose of this document is to expand the options available to implementers of MIKEY to take advantage of these benefits. In addition, elliptic curve algorithms are capable of providing security consistent with AES keys of 128, 192, and 256 bits without extensive growth in asymmetric key sizes. The following table, taken from [HOF] and [LEN], gives approximate comparable key sizes for symmetric systems, ECC systems, and DH/DSA/RSA systems. The estimates are based on the running times of the best algorithms known today. Symmetric | ECC2N | ECP | DH/DSA/RSA 80 | 163 | 192 | 1024 128 | 283 | 256 | 3072 192 | 409 | 384 | 7680 256 | 571 | 521 | 15360 Table 1: Comparable key sizes Thus, for example, when securing a 192-bit symmetric key, it is prudent to use either 409-bit ECC2N, 384-bit ECP, or 7680-bit DH/DSA/ RSA. With smaller key sizes the symmetric keys would be underprotected. Section 2 describes the extension of MIKEY-DHSIGN to use the ECDSA signature algorithm. Section 3 describes the extension of MIKEY- DHSIGN to use ECDH groups. Section 4 describes the MIKEY-ECIES method. Section 5 describes the MIKEY-ECMQV method. Section 6 describes additional payloads required to support these new methods. Milne, et al. Expires April 23, 2007 [Page 3] Internet-Draft ECC Algorithms for MIKEY October 2006 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]. Milne, et al. Expires April 23, 2007 [Page 4] Internet-Draft ECC Algorithms for MIKEY October 2006 2. MIKEY-DHSIGN with ECDSA MIKEY-DHSIGN is described in Section 3.3 of [RFC3830]. The Initiator's message includes SIGNi, a signature covering the Initiator's message. As well, the Responder's message includes SIGNr, a signature covering the Responder's message. According to Section 4.2.6 of [RFC3830], the signature algorithm applied is defined by, and dependent on the certificate used. It is MANDATORY to support RSA PKCS#1, v1.5, and it is RECOMMENDED to support RSA PSS. Instead of these signature algorithms, ECDSA can be used to allow shorter and more efficient signatures. ECDSA signatures are detailed in [ANSI-X9.62]. Curve selection and other parameters will be defined by, and dependent on the certificate used. When generating signatures, the hash function that MUST be used is SHA-1. The signature payload (SIGN) specified in Section 6.5 of [RFC3830] can be used without modification. An additional S type for ECDSA is defined as follows: S type | Value | Comments ------------------------------------- ECDSA | 2 | ECDSA signature [ANSI_X9.62] [RFC3279] describes algorithms and identifiers for Internet X.509 certificates and CRLs. It includes ECC algorithms and identifiers. To use the ECDSA signature algorithm with Elliptic Curve Diffie- Hellman, this extension to MIKEY-DHSIGN may be combined with the extension described in Section 3. Milne, et al. Expires April 23, 2007 [Page 5] Internet-Draft ECC Algorithms for MIKEY October 2006 3. MIKEY-DHSIGN with ECDH MIKEY-DHSIGN is described in Section 3.3 of [RFC3830]. According to Section 4.2.7 of [RFC3830], the support for OAKLEY 5 is MANDATORY and support for OAKLEY 1 and OAKLEY 2 is OPTIONAL. Instead of these Diffie-Hellman (DH) groups, elliptic curve Diffie-Hellman (ECDH) groups can significantly improve performance and security. The ECDH groups to be used by MIKEY are the groups recommended by NIST in FIPS 186-2 [FIPS-186-2]. Detailed descriptions of the ECDH groups can be found in each of FIPS 186-2 [FIPS-186-2] and SEC 2 [SEC2]. The ECDH groups use elliptic curves over GF[2^N] with N prime or over GF[P] with P prime. Eleven of the groups proposed here have been assigned identifiers by IANA [IANA] and the remaining five might later be assigned identifiers by IANA. The group with IANA number 6 is described in [ANSI-X9.62] and [SEC2], with object identifier sect163r1, but it is not one of the fifteen curves that NIST recommends [FIPS-186-2]. The remaining NIST recommended groups are suggested and anticipated to be assigned IANA numbers as specified in Table 2. id Group Type Group Description NIST Name SEC 2 OID -- ---------- ----------------- --------- --------- 22 2 ECP ECPRGF192Random P-192 secp192r1 23 3 EC2N EC2NGF163Random B-163 sect163r2 7 3 EC2N EC2NGF163Koblitz K-163 sect163k1 6 3 EC2N EC2NGF163Random2 none sect163r1 24 2 ECP ECPRGF224Random P-224 secp224r1 25 3 EC2N EC2NGF233Random B-233 sect233r1 26 3 EC2N EC2NGF233Koblitz K-233 sect233k1 19 2 ECP ECPRGF256Random P-256 secp256r1 8 3 EC2N EC2NGF283Random B-283 sect283r1 9 3 EC2N EC2NGF283Koblitz K-283 sect283k1 20 2 ECP ECPRGF384Random P-384 secp384r1 10 3 EC2N EC2NGF409Random B-409 sect409r1 11 3 EC2N EC2NGF409Koblitz K-409 sect409k1 21 2 ECP ECPRGF521Random P-521 secp521r1 12 3 EC2N EC2NGF571Random B-571 sect571r1 13 3 EC2N EC2NGF571Koblitz K-571 sect571k1 Table 2: Recommended Groups and Names The ECDH groups in Table 2 are arranged into 5 classes, corresponding Milne, et al. Expires April 23, 2007 [Page 6] Internet-Draft ECC Algorithms for MIKEY October 2006 to approximately equivalent security strengths. To encourage interoperability, implementations that support one of these classes, SHOULD support the one group in that class that is defined over a prime field (which will be one of P-192, P-224, P-256, P-384, or P-521). Implementations SHOULD support one of P-256 or P-384. Implementations MAY support any set of groups. The DH data payload (DH) specified in Section 6.4 of [RFC3830] can be used without modification. Additional DH-Group identifiers are required as follows: DH-Group | Value --------------------------------------|------- ECPRGF192Random / P-192 / secp192r1 | 3 EC2NGF163Random / B-163 / sect163r2 | 4 EC2NGF163Koblitz / K-163 / sect163k1 | 5 EC2NGF163Random2 / none / sect163r1 | 6 | ECPRGF224Random / P-224 / secp224r1 | 7 EC2NGF233Random / B-233 / sect233r1 | 8 EC2NGF233Koblitz / K-233 / sect233k1 | 9 | ECPRGF256Random / P-256 / secp256r1 | 10 EC2NGF283Random / B-283 / sect283r1 | 11 EC2NGF283Koblitz / K-283 / sect283k1 | 12 | ECPRGF384Random / P-384 / secp384r1 | 13 EC2NGF409Random / B-409 / sect409r1 | 14 EC2NGF409Koblitz / K-409 / sect409k1 | 15 | ECPRGF521Random / P-521 / secp521r1 | 16 EC2NGF571Random / B-571 / sect571r1 | 17 EC2NGF571Koblitz / K-571 / sect571k1 | 18 When using the ECDH groups, the DH-value in the DH data payload (DH) is the octet string representation specified in ANSI X9.62 [ANSI-X9.62] and [SEC1]. To use ECDH and ECDSA signature algorithm, this extension to MIKEY- DHSIGN may be combined with the extension described in Section 2. Milne, et al. Expires April 23, 2007 [Page 7] Internet-Draft ECC Algorithms for MIKEY October 2006 4. MIKEY-ECIES The Elliptic Curve Integrated Encryption Scheme (ECIES) is a public- key encryption scheme based on ECC. Section 3.2 of [RFC3830] already specifies a public-key encryption method (MIKEY-RSA). Here we describe the new MIKEY-ECIES method. Initiator Responder I_MESSAGE = HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, ECCPT, KEMAC, [CHASH], SIGNi ---> R_MESSAGE = [<---] HDR, T, [IDr], V As with the MIKEY-RSA case, the main objective of the Initiator's message is to transport one or more TGKs and a set of security parameters to the Responder in a secure manner. With MIKEY-RSA, the TGKs are encrypted with an "envelope key". However, ECIES uses a symmetric encapsulation algorithm, so encrypting an envelope key (to be used with another symmetric method to decrypt the actual payload) would be redundant. As a result, the PKE payload is not used. The ECCPT contains the elliptic curve point that represents the ephemeral public key required for ECIES. As in MIKEY-RSA, the KEMAC contains a set of encrypted sub-payloads and a MAC: KEMAC = E(encr_key, IDi || {TGK}) || MAC The encr_key and auth_key are derived from the ECIES-derived key by using the algorithm described in Section 4.1.4 of [RFC3830], in identical fashion as the envelope key used in the MIKEY-RSA. Both SIGNi and SIGNr will use ECDSA as a signature algorithm, as described in Section 2. As in MIKEY-RSA, it is possible to cache the ECIES-derived key, so that it can be used as a pre-shared key. ECIES is described in detail in [SEC1]. For ECIES, the key derivation function that MUST be used is ANSI-X9.63-KDF as described in [SEC1]. As well, the MAC scheme that MUST be used is HMAC-SHA-1- 160. The 'standard' elliptic curve Diffie-Hellman primitive MUST be Milne, et al. Expires April 23, 2007 [Page 8] Internet-Draft ECC Algorithms for MIKEY October 2006 used (as opposed to 'cofactor'). The symmetric encryption scheme that MUST be used depends on the key size, as follows: ECC2N | ECP | Symmetric Cipher To Use 163 | 192 | 3DES-CBC 283 | 256 | AES-128-CBC 409 | 384 | AES-256-CBC 571 | 521 | AES-256-CBC Table 3: Symmetric cipher to use with ECIES Milne, et al. Expires April 23, 2007 [Page 9] Internet-Draft ECC Algorithms for MIKEY October 2006 5. MIKEY-ECMQV ECMQV (Elliptic Curve Menezes-Qu-Vanstone) is a 3-pass or 1-pass protocol that has been standardized in ANSI X9.63 [ANSI-X9.63]. Both modes of ECMQV provide mutual authentication between the communicating parties and key establishment for the secure transport of data. Here we describe the new MIKEY-ECMQV method based on the 1-pass protocol. Initiator Responder I_MESSAGE = HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, ECCPT, KEMAC, [CHASH], SIGNi ---> R_MESSAGE = [<---] HDR, T, [IDr], V The ECCPT contains the elliptic curve point that represents the ephemeral public key contributed by the Initiator. As in MIKEY-RSA, the KEMAC contains a set of encrypted sub-payloads and a MAC: KEMAC = E(encr_key, IDi || {TGK}) || MAC The encr_key and auth_key are derived from the ECMQV-derived key by using the algorithm described in Section 4.1.4 of [RFC3830], in identical fashion as the envelope key used in the MIKEY-RSA. 1-pass ECMQV is described in detail in ANSI X9.63 [ANSI-X9.63]. Milne, et al. Expires April 23, 2007 [Page 10] Internet-Draft ECC Algorithms for MIKEY October 2006 6. Additional Payload Encoding 6.1. ECC Point payload (ECCPT) The ECCPT payload carries a point on the elliptic curve used in MIKEY-ECIES and MIKEY-ECMQV. The payload identifier is 22. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next payload ! Point length ! Pt data ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Point data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values. * Point length (16 bits): length of the Point data field (in *bits*). * Point data (variable length): point data, padded to end on a 32-bit boundary, encoded in octet string representation specified in ANSI X9.62 [ANSI-X9.62] and [SEC1]. Uncompressed format MUST be supported. Hybrid and compressed formats MAY be supported. Milne, et al. Expires April 23, 2007 [Page 11] Internet-Draft ECC Algorithms for MIKEY October 2006 7. Security Considerations Since this document proposes new methods for use within MIKEY, many of the security considerations contained within [RFC3830] apply here as well. Some of the methods proposed in this document offer higher cryptographic strength than those proposed in [RFC3830]. In particular, there are elliptic curves corresponding to each of the symmetric key sizes 80 bits, 128 bits, 192 bits, and 256 bits. This allows the MIKEY key exchange to offer security comparable with higher-strength AES algorithms and SHA implementations. The methods proposed in this document are among those standardized by NIST in FIPS 186-2 [FIPS-186-2], by the SECG in SEC2 [SEC2], and by ANSI in ANSI X9.62 [ANSI-X9.62] and X9.63 [ANSI-X9.63]. Milne, et al. Expires April 23, 2007 [Page 12] Internet-Draft ECC Algorithms for MIKEY October 2006 8. IANA Considerations This document adds entries to existing MIKEY namespaces in Section 2 (S types in signature payloads), Section 3 (DH Group identifier in DH payloads), and Section 6.1 (ECCPT payload identifier). Milne, et al. Expires April 23, 2007 [Page 13] Internet-Draft ECC Algorithms for MIKEY October 2006 9. References 9.1. Normative References [ANSI-X9.62] American National Standards Institute, "ANSI X9.62: Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", 2005. [ANSI-X9.63] 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. [FIPS-186-2] National Institute of Standards and Technology, "FIPS 186-2 Digital Signature Standard", 2000. [IANA] Internet Assigned Numbers Authority, "Attribute Assigned Numbers.", . [RFC3279] 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. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [SEC1] Standards for Efficient Crytopgraphy Group, "Elliptic Curve Cryptography", September 2000. [SEC2] Standards for Efficient Crytopgraphy Group, "Recommended Elliptic Curve Domain Parameters", September 2000. 9.2. Informative References [HOF] Hoffman, P. and H. Orman, "Determining strengths for public keys used for exchanging symmetric keys", August 2000. [LEN] Lenstra, A. and E. Verhuel, "Selecting cryptographic key sizes", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Milne, et al. Expires April 23, 2007 [Page 14] Internet-Draft ECC Algorithms for MIKEY October 2006 Requirement Levels", BCP 14, RFC 2119, March 1997. Milne, et al. Expires April 23, 2007 [Page 15] Internet-Draft ECC Algorithms for MIKEY October 2006 Authors' Addresses Andrew Milne Mitch Blaser Certicom Corp. 5520 Explorer Drive Mississauga, Ontario L4W 5L1 CANADA Phone: +1-905-507-4220 Fax: +1-905-507-4230 Email: mblaser@certicom.com URI: http://www.certicom.com Daniel R. L. Brown Certicom Corp. 5520 Explorer Drive Mississauga, Ontario L4W 5L1 CANADA Phone: +1-905-507-4220 Fax: +1-905-507-4230 Email: dbrown@certicom.com URI: http://www.certicom.com Eugene Chin Certicom Corp. 5520 Explorer Drive Mississauga, Ontario L4W 5L1 CANADA Phone: +1-905-507-4220 Fax: +1-905-507-4230 Email: mblaser@certicom.com URI: http://www.certicom.com Milne, et al. Expires April 23, 2007 [Page 16] Internet-Draft ECC Algorithms for MIKEY October 2006 Lakshminath Dondeti QUALCOMM, Inc. 5775 Morehouse Drive San Diego, CA USA Phone: +1-858-845-1267 Email: ldondeti@qualcomm.com Milne, et al. Expires April 23, 2007 [Page 17] Internet-Draft ECC Algorithms for MIKEY October 2006 Full 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Milne, et al. Expires April 23, 2007 [Page 18]