MSEC Working Group A. Milne Internet Draft M. Blaser Expires December 2005 D. Brown Certicom L. Dondeti Qualcomm June 2005 ECC Algorithms For MIKEY <draft-ietf-msec-mikey-ecc-00.txt> Status of this Memo 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. IPR Statement 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. 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. Milne et al [Page 1]

Internet Draft ECC Algorithms for MIKEY June 2005 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. Milne et al [Page 2]

Internet Draft ECC Algorithms for MIKEY June 2005 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 [MIKEY]. Comments Comments on this draft should be addressed to msec@securemulticast.org. 1. Introduction This document describes additional algorithms for use in MIKEY. The document assumes that the reader is familiar with the MIKEY protocol. RFC 3830 [MIKEY] defines three methods of key exchange during establishment of a TGK. The pre-shared key (MIKEY-PSA) and public key (MIKEY-RSA) methods are mandatory, while support for Diffie-Hellman (MIKEY-DHSIGN) is optional. Elliptic curve Diffie-Hellman (ECDH) can be used in the MIKEY Diffie-Hellman method; we specify this mode in this document. In addition, the elliptic curve protocols MCMQV and ECIES can be used in MIKEY in exchanges similar to those of MIKEY-RSA; we specify these modes, and name them 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 Milne et al [Page 3]

Internet Draft ECC Algorithms for MIKEY June 2005 symmetric systems, ECC systems, and DH/DSA/RSA systems. The estimates are based on the running times of the best algorithms known today. Symmetric | ECC | DH/DSA/RSA 80 | 163 | 1024 128 | 283 | 3072 192 | 409 | 7680 256 | 571 | 15360 Table 1: Comparable key sizes Thus, for example, when securing a 192-bit symmetric key, it is prudent to use either 409-bit ECC or 7680-bit DH/DSA/RSA. Of course it is possible to use shorter asymmetric keys, but it should be recognized in this case that the security of the system is likely dependent on the strength of the public-key algorithm and claims such as "this system is highly secure because it uses 192-bit encryption" are misleading. Section 2 below describes the use of elliptic curve methods for public-key authentication and encryption. Section 3 describes the use of ECIES (The Elliptic Curve Integrated Encryption Scheme). Section 4 describes methods for Elliptic Curve Diffie- Hellman, including fifteen ECDH groups. Section 5 describes the MIKEY-MQV method. Section 6 includes modifications to specific sections of [MIKEY]. 2. Use of EC methods with public-key encryption (MIKEY-RSA) MIKEY-RSA specifies the use of RSA PKCS#1, v1.5 as mandatory and RSA PSS as recommended. This section describes how ECDSA signatures may be used for certificate signature and signature operations, enabling use of smaller signatures and certificates. This section also describes the ECIES encryption/decryption scheme, for use with elliptic curve key pairs. 2.1 ECDSA signature Section 6.5 of [MIKEY] describes the signature payload for the PK and DH exchange messages. The ECDSA signature algorithm can be applied to allow shorter and more-efficient signatures. ECDSA signatures are detailed in ANSI X9.62 [X9.62]. Curve selection and other parameters will be defined by, and dependent on the certificate used. RFC3279 describes algorithms and identifiers for Internet X.509 certificates and CRLs. It includes ECC algorithms and identifiers. Milne et al [Page 4]

Internet Draft ECC Algorithms for MIKEY June 2005 3. MIKEY-ECIES MIKEY's public-key encryption method (MIKEY-RSA) uses public key methods securely to transmit keying material between communicating parties having previously acquired one another's public keys. The Elliptic Curve Integrated Encryption Scheme (ECIES) specifies how two communicating parties having previously acquired one another's public keys--assuming these are EC public keys--may use these keys to transmit encrypted and authenticated messages. This section therefore proposes how ECIES may be used in MIKEY. We call this scheme MIKEY-ECIES. We propose that ECIES be used as follows: 1. The ephemeral public key transmitted by the initiator, is transmitted in an ECCPT payload (see section 5.1) preceding the KEMAC payload. 2. The ciphertext and message digest required under ECIES are transmitted in the KEMAC payload, as in other forms of the MIKEY protocol. 3. The encryption key and HMAC key in use in the KEMAC are those extracted from the shared key derived using ECIES. 4. The PKE payload is not used. Note that this differs from the 'envelope key' method used in the MIKEY-RSA form of the protocol. ECIES, however, 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. Note also that the derived ECIES key can be used as an input for the key generation algorithm described in section 4.1.4 of RFC 3830, in identical fashion as is the envelope key used in the MIKEY-RSA method. A MIKEY-ECIES exchange ---------------------- Initiator Responder --------- --------- I_MESSAGE = HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, ECCPT, KEMAC, [CHASH], SIGNi ---> R_MESSAGE = [<---] HDR, T, [IDr], V Milne et al [Page 5]

Internet Draft ECC Algorithms for MIKEY June 2005 Note also that the derived key generated may also be cached for the lifetime of a CSB, at the direction of the Initiator, and used as a preshared key, as described for the envelope key in RFC 3830, section 3.2. ECIES options ------------- IEEE 1363A describes a number of options for ECIES. We recommend that in MIKEY-ECIES, the following options be understood as given: -- the KDF in use for the generation of the ephemeral key pairs shall be ECSVDP-DHC, without compatibility for the corresponding -DH primitive -- DHAES mode shall not be used. 4. Use of EC methods with Diffie-Hellman key exchange (MIKEY-DHSIGN) The MIKEY-DHSIGN key exchange method is described in Section 3.3 of [MIKEY]. Section 4.2.7 of [MIKEY] specifies the use of OAKLEY group 5 as mandatory and groups 1 and 2 as optional. However, implementations have shown that users of elliptic curve groups can significantly improve performance and security by using groups other than the Oakley Groups 1, 2, or 5. The DH data payload specified in Section 6.4 of [MIKEY] can be used without modification. The data in the KEMAC payload when using these groups is the octet string representation specified in ANSI X9.62 [X9.62], ANSI X9.63 [X9.63], FIPS 186-2 [FIPS 186-2], and IEEE P1363 of the point on the curve chosen by taking the randomly chosen secret Ka and computing Ka*P, where * is the repetition of the group addition and double operations. An updated DH-Group table (as shown in Section 6.4 of [MIKEY]) will be specified upon assignment of IANA numbers for the groups described in section 8. See also the section "IANA considerations" in this document. 5. Using ECMQV in MIKEY (MIKEY-MQV) MQV is a protocol primitive equivalent to simultaneous Diffie-Hellman key exchange and digital signature authentication, achievable in a single transmission. The S_i and S_r values function as implicit signatures proving possession of the private key corresponding to the communicating party's known public key. Milne et al [Page 6]

Internet Draft ECC Algorithms for MIKEY June 2005 ECMQV (Elliptic Curve Menezes-Qu-Vanstone) is a three-pass or 1-pass protocol that has been standardized in ANSI X9.63. Both modes of ECMQV provide mutual authentication between the communicating parties and key establishment for the secure transport of data; the 1-pass version is thus particularly attractive for MIKEY, as an alternative method of establishing a secure channel for the transport of the TGK. In this draft, we propose a fourth mode in MIKEY, called MIKEY-MQV, in which ECMQV is used in this fashion. A MIKEY-MQV exchange proceeds in similar fashion to the MIKEY-RSA exchange; the PKE is absent, and an ECCPT payload (see section 5.1) MUST precede the KEMAC payload in the intiator's first message: Initiator Responder --------- --------- I_MESSAGE = HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, ECCPT, KEMAC, [CHASH], SIGNi ---> ... the responder's acknowledgement, as in MIKEY-RSA, is optional, and the initiator indicates whether a response is required. If present, the acknowledgement is of the form: R_MESSAGE = [<---] HDR, T, [IDr], V The ECCPT payload carries Q_(e,I) as per the nomenclature of ANSI X9.63 -- the ephemeral public key contributed by the initiator. The encr_key and auth_key used in forming the KEMAC are the encryption and authentication keys extracted from the derived key arrived at via MQV. 1-pass ECMQV algorithm steps ---------------------------- 1-pass ECMQV is described in detail in ANSI X9.63-2001; for a detailed specification for implementation purposes, see that document. The following discussion is provided here for information purposes only, to clarify the mechanism, and to ease mapping it to the protocol components in this draft proposal. Milne et al [Page 7]

Internet Draft ECC Algorithms for MIKEY June 2005 Note that 1-pass MQV differs from 3-pass MQV in that only three key pairs are used as inputs: the initiator's public, private key pair, the respondent's public, private key pair, and the ephemeral public, private key pair contributed by the initiator. The respondent's public, private key pair is used twice--effectively replacing the ephemeral key pair contributed by the respondent in the 3-pass method. Initiator transformation ------------------------ 1. Initiator selects an ephemeral private key k_A from the set {1..n-1}, where n is the order of the base point P for the curve in use. Initiator computes the corresponding ephemeral public key R_A = (k_A)P, and sends R_A to the respondent. The ephemeral public key R_A derived is the value Q_(e,I) in the protocol described above. The selection of k_A and the generation of R_A from it are covered in detail in X9.63-2001 section 5.2.1--Key Pair Generation Primitive. 2. Initiator calculates the shared secret value z as follows (see X9.63-2001 section 5.5)-- 2a. Initiator uses their own private and public key, and the ephemeral private and public key they generated in step 1 as inputs (d_1, Q_1) and (d_2, Q_2) respectively. 2b. Initiator uses the respondent's public key for the values Q_3 and Q_4. 2c. Using the associate value function avf (see X9.63-2001 section 5.6.1), and the values d_1, d_2 and Q_2 as above (their own private key, and the ephemeral key pair private and public values), the Initiator calculates the implicit signature S_i = d_2 + (avf(Q_2) x d_1) mod n. 2d. Using the associate value function avf, the signature just calculated, the system cofactor h, and the respondent's public key, the Initiator finds the EC point P = h x S_i x (Q_4 + (avf(Q_4) x Q_3)). 2e. Initiator verifies that P != 0. 2f. Initiator sets z = x_P, where x_P is the x-coordinate of P. 3. Initiator converts z to bit string Z, using the convention specified in X9.63-2001 section 4.3.3. 4. Initiator uses the key derivation function described in X9.63-2001 section 5.6.3 with the hash function given in table MQV_PARAMS to derive the keying data; the length of the key to be generated is also given in MQV_PARAMS. Milne et al [Page 8]

Internet Draft ECC Algorithms for MIKEY June 2005 Respondent transformation ------------------------- The respondent transformation is parallel to the initiator transformation, except that the respondent does not generate an ephemeral key pair, and the inputs d_1, Q_1, d_2, Q_2, Q_3 and Q_4 come from different sources. Again, see X9.63-2001 section 5.5 for a detailed description appropriate for implementation purposes. 1. Respondent verifies that Q_(e, U) is a valid key for the domain parameters (see X9.63-2001 section 5.2.2). 2. Respondent calculates the shared secret value z as follows (see X9.63-2001 section 5.5)-- 2a. Respondent uses their own private and public key in step 1 as inputs for both (d_1, Q_1) and (d_2, Q_2). 2b. Respondent uses the initiator's public key for the value Q_3, and the initiator's ephemeral public key for the value Q_4. 2c. Using the associate value function avf (see X9.63-2001 section 5.6.1), and the values d_1, d_2 and Q_2 as above (their own private key is both d_1 and d_2, while Q_2 is their public key), the Respondent calculates the implicit signature S_r = d_2 + (avf(Q_2) x d_1) mod n. 2d. Using the associate value function avf, the signature just calculated, the system cofactor h, the respondent's public key, and the respondent's ephemeral public key, the Respondent finds the EC point P = h x S_r x (Q_4 + (avf(Q_4) x Q_3)). 2e. Respondent verifies that P != 0. 2f. Respondent sets z = x_P, where x_P is the x-coordinate of P. 3. Respondent converts z to bit string Z, using the convention specified in X9.63-2001 section 4.3.3. 4. Respondent uses the key derivation function described in X9.63-2001 section 5.6.3 with the hash function given in table MQV_PARAMS to derive the keying data; the length of the key to be generated is also given in MQV_PARAMS. Milne et al [Page 9]

Internet Draft ECC Algorithms for MIKEY June 2005 6. Additional MIKEY payloads 6.1 ECCPT payload format The ECCPT payload provides for the transport of an EC point in the MIKEY-MQV and in the MIKEY-RSA exchange when ECIES is in use. It is of the form: 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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Point length is the length of the point data in *bits*. The point_data field is padded to end on a 32-bit boundary, and is encoded as per ANSI X9.63-2001 4.3.6. Uncompressed format MUST be supported. Hybrid and compressed formats MAY be supported. 7. Multicast applications of MQV and ECIES Both MQV and ECDSA/ECIES may be used in multicast environments to establish a group TEK, in the same fashion as MIKEY-RSA. 8. Recommended and optional domain parameter sets 8.1 Available domain parameter sets Elliptic curve domain parameter sets available for use in this protocol for all methods employing EC primitives--and given here-- are the fifteen groups that NIST recommends in FIPS 186-2 [FIPS-186-2]. Detailed descriptions of the ECC groups recommended here for MIKEY are not given in this document but can be found elsewhere: All fifteen groups are detailed in each of FIPS 186-2 [FIPS-186-2] and SEC 2 [SEC-2]. The elliptic curve domain parameters are uniquely identified in this document using the ASN.1 object identifiers provided in ANSI X9.63 [X9.63], which are also given in SEC2 [SEC-2]. The fifteen groups proposed in this document use elliptic curves over GF[2^N] with N prime or over GF[P] with P prime. Six of the groups proposed here have been assigned identifiers by IANA [IANA] and the remaining nine curves recommended by NIST might later be assigned identifiers by IANA. See also the 'IANA considerations' section. Milne et al [Page 10]

Internet Draft ECC Algorithms for MIKEY June 2005 IANA Group Descriptions X9.63 (and SEC 2) OID ---- ----------------------------- --------------------- NA ECPRGF192Random group P-192 secp192r1 NA EC2NGF163Random group B-163 sect163r2 7 EC2NGF163Koblitz group K-163 sect163k1 NA ECPRGF224Random group P-224 secp224r1 NA EC2NGF233Random group B-233 sect233r1 NA EC2NGF233Koblitz group K-233 sect233k1 NA ECPRGF256Random group P-256 secp256r1 8 EC2NGF283Random group B-283 sect283r1 9 EC2NGF283Koblitz group K-283 sect283k1 NA ECPRGF384Random group P-384 secp384r1 10 EC2NGF409Random group B-409 sect409r1 11 EC2NGF409Koblitz group K-409 sect409k1 NA ECPRGF521Random group P-521 secp521r1 12 EC2NGF571Random group B-571 sect571r1 13 EC2NGF571Koblitz group K-571 sect571k1 Three curves are defined at each strength - two curves chosen verifiably at random (as defined in ANSI [X9.62]), one over a binary field and another over a prime field, and a Koblitz curve over a binary field that, which enables especially efficient implementations due to the special structure of the curve [Kob, NSA]. Note that the large number of proposed curves is for two reasons: Flexibility in implementation in using groups over prime fields (GF[p]) or binary fields (GF[2^N]), which have different characteristics; and to provide higher security strength capabilities for military-grade or future uses. In ECDH, The 163-bit and 192-bit curves provide equivalent security strength to Oakley group 2; all other proposed curves offer significantly higher security strength equivalents than the three Diffie-Hellman groups included in [MIKEY]. 8.1 Recommended domain parameter sets It is RECOMMENDED that, for minimum interoperability, all implementations except those in highly constrained environments support use of the P-256 curve. It is RECOMMENDED that implementations in constrained environments support the K163 curve. Milne et al [Page 11]

Internet Draft ECC Algorithms for MIKEY June 2005 9. Security Considerations Since this document proposes new methods for use within MIKEY, many of the security considerations contained within RFC 3830 apply here as well. Some of the methods proposed in this document offer higher cryptographic strength than those proposed in RFC 3830. 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 [DSS], by the SECG in SEC2 [SEC2], and by ANSI in ANSI X9.62 [X9.62] and X9.63 [X9.63]. Proper validation of elliptic curve public keys can help prevent the attacks described in [BMM]. 10. IANA Considerations This specification requires additional parameter sets be defined for use in MIKEY when elliptic curve cryptographic methods are used. These are listed in section 8.1. It is requested that these be added to the namespace for the DH-Group field in table 6.4 of RFC 3830, which that document requests shall be managed by the IANA. Milne et al [Page 12]

Internet Draft ECC Algorithms for MIKEY June 2005 12. References [IANA] Internet Assigned Numbers Authority. Attribute Assigned Numbers. (http://www.isi.edu/in-notes/iana/assignments/ipsec-registry) [IEEE 1363A-2004] Institute of Electrical and Electronics Engineers, IEEE P1363a, Draft Standard Specifications for Public Key Cryptography - Amendment 1: Additional Techniques. [KOB] N. Koblitz, CM curves with good cryptographic properties. Proceedings of Crypto '91. Pages 279-287. Springer-Verlag, 1992. [FIPS-186-2] U.S. Department of Commerce/National Institute of Standards and Technology. Digital Signature Standard (DSS), FIPS PUB 186-2, January 2000. (http://csrc.nist.gov/fips/fips186-2.pdf) [HOF] P. Hoffman and H. Orman, Determining strengths for public keys used for exchanging symmetric keys, Internet-draft. August 2000. [LEN] A. Lenstra and E. Verhuel, Selecting cryptographic key sizes. Available at: www.cryptosavvy.com. [MIKEY] [RFC-3830] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, MIKEY: Multimedia Internet KEYing, RFC 3830, August 2004. [NSA] J. Solinas, An improved algorithm for arithmetic on a family of elliptic curves, Proceedings of Crypto '97, Pages 357-371, Springer-Verlag, 1997. [RFC-3278] S. Blake-Wilson, D. Brown and P. Lambert, The Use of Elliptic Curve Cryptography (ECC) Algorithms in the Cryptographic Message Syntax (CMS), RFC 3279, April 2002. [RFC-3279] W. Polk, R. Housley, and L. Bassham, Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 3279, April 2002. [SEC2] Standards for Efficient Cryptography Group. SEC 2 - Recommended Elliptic Curve Domain Parameters. Working Draft Ver. 1.0., 2000. (http://www.secg.org) [X9.62] American National Standards Institute, ANSI X9.62-1998: Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm. January 1999. Milne et al [Page 13]

Internet Draft ECC Algorithms for MIKEY June 2005 [X9.63] American National Standards Institute. ANSI X9.63-2001, Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport using Elliptic Curve Cryptography. November 2001. [HANKERSON] Hankerson, Darrel et al. "Guide to Elliptic Curve Cryptography". Springer-Verlag, 2004. Authors' Addresses Andrew Milne Certicom Corp. amilne@certicom.com Mitch Blaser Certicom Corp. mblaser@certicom.com Daniel R. L. Brown Certicom Corp. dbrown@certicom.com Lakshminath Dondeti Qualcomm, Inc. ldondeti@qualcomm.com Expiry reminder This draft expires December 1, 2005. Copyright (C) The Internet Society (2005). 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. Milne et al [Page 14]