~~MSEC~~NetworkWorking Group A. Milne~~Internet Draft~~Internet-Draft Intended status: Standards TrackM. Blaser~~Expires December 2005~~Expires: April 23, 2007D. BrownE. ChinCerticomCorp.L. Dondeti~~Qualcomm~~QUALCOMM, Inc. October 20, 2006ECC Algorithms~~For~~forMIKEY~~<draft-ietf-msec-mikey-ecc-00.txt>~~draft-ietf-msec-mikey-ecc-01Status of this MemoBy 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/1id-abstracts.html~~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.~~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~~This Internet-Draftwill~~be disclosed, in accordance with Section 6 of BCP 79.~~expire on April 23, 2007. Copyright Notice Copyright (C)The~~IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain~~Internet Society (2006). Abstract This document proposes extensionsto the~~implementation or use of the technology~~authentication, encryption and digital signature methodsdescribedfor usein~~this document or the extent~~MIKEY, employing elliptic-curve cryptography (ECC). These extensions are definedto~~which any license under such rights might or might not~~align MIKEY with other ECC implementations and standards. It shouldbe~~available; nor does it represent~~notedthatthis document is not self-contained;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~~usesthe~~IETF Secretariat~~notationsand~~any assurances~~definitionsof~~licenses to be made available, or the result~~[RFC3830]. Tableof~~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. 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~~Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. MIKEY-DHSIGNwith~~other~~ECDSA . . . . . . . . . . . . . . . . . . . 5 3. MIKEY-DHSIGN with ECDH . . . . . . . . . . . . . . . . . . . . 6 4. MIKEY-ECIES . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. MIKEY-ECMQV . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Additional Payload Encoding . . . . . . . . . . . . . . . . . 11 6.1.ECC~~implementations and standards. It should be noted that this document is not self-contained; it uses the notations~~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 Propertyand~~definitions of [MIKEY]. Comments Comments on this draft should be addressed to msec@securemulticast.org.~~Copyright Statements . . . . . . . . . . 181. 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]~~The MIKEY protocol [RFC3830]defines three methods~~of key exchange during establishment~~for transporting or establishing keys: with the useof a~~TGK. The~~pre-shared~~key (MIKEY-PSA)~~key, public-key encryption (MIKEY-RSA),and~~public key (MIKEY-RSA) methods are mandatory, while support for~~Diffie-Hellman~~(MIKEY-DHSIGN) is optional.~~(DH) key exchange (MIKEY- DHSIGN). This document extends MIKEY-DHSIGN to use ECDSA as the signature algorithm and further extends MIKEY-DHSIGN to useElliptic~~curve~~CurveDiffie-Hellman (ECDH)~~can be used in the MIKEY Diffie-Hellman method; we specify this mode in this document.~~groups.In addition,this document introduces two new methods based onthe elliptic curve~~protocols MCMQV and~~algorithmsECIES~~can be used in MIKEY~~and ECMQVin exchanges similar to those of~~MIKEY-RSA; we specify these modes,~~MIKEY-RSA,and name~~them~~these methodsMIKEY-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 |~~ECC~~ECC2N | ECP| DH/DSA/RSA 80 | 163 |192 |1024 128 | 283 |~~3072~~256 | 3072192 | 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~~ECC~~ECC2N, 384-bit ECP,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~~DH/DSA/ RSA. With smaller key sizesthe~~public-key algorithm and claims such as "this system is highly secure because it uses 192-bit encryption" are misleading.~~symmetric keys would be underprotected.Section 2~~below~~describes the~~use~~extensionof~~elliptic curve methods for public-key authentication and encryption.~~MIKEY-DHSIGN to use the ECDSA signature algorithm.Section 3 describes the~~use~~extensionof~~ECIES (The Elliptic Curve Integrated Encryption Scheme).~~MIKEY- DHSIGN to use ECDH groups.Section 4 describes~~methods for Elliptic Curve Diffie- Hellman, including fifteen ECDH groups.~~the MIKEY-ECIES method.Section 5 describes the~~MIKEY-MQV~~MIKEY-ECMQVmethod. Section 6~~includes modifications~~describes additional payloads requiredto~~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~~support these new methods. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",and~~RSA PSS~~"OPTIONAL" in this document are to be interpretedas~~recommended. This section describes how~~described in [RFC2119]. 2. MIKEY-DHSIGN withECDSA~~signatures may be used for certificate signature and signature operations, enabling use~~MIKEY-DHSIGN is described in Section 3.3of~~smaller signatures and certificates. This section also describes~~[RFC3830]. The Initiator's message includes SIGNi, a signature coveringthe~~ECIES encryption/decryption scheme, for use with elliptic curve key pairs. 2.1 ECDSA~~Initiator's message. As well, the Responder's message includes SIGNr, asignaturecovering the Responder's message. According toSection~~6.5~~4.2.6of~~[MIKEY] describes~~[RFC3830],the signature~~payload for~~algorithm applied is defined by, and dependent onthe~~PK~~certificate used. It is MANDATORY to support RSA PKCS#1, v1.5,and~~DH exchange messages. The ECDSA~~it is RECOMMENDED to support RSA PSS. Instead of thesesignature~~algorithm~~algorithms, ECDSAcan be~~applied~~usedto allow shorter and~~more-efficient~~more efficientsignatures. ECDSA signatures are detailed in~~ANSI X9.62 [X9.62].~~[ANSI-X9.62].Curve selection and other parameters will be defined by, and dependent on the certificate used.~~RFC3279~~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.~~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~~To use the ECDSA signature algorithm withElliptic 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~~Diffie- Hellman, this extensionto~~transmit encrypted and authenticated messages. This section therefore proposes how ECIES~~MIKEY-DHSIGNmay 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~~combined withthe~~initiator,~~extension described in Section 3. 3. MIKEY-DHSIGN with ECDH MIKEY-DHSIGNis~~transmitted~~describedin~~an ECCPT payload (see section 5.1) preceding~~Section 3.3 of [RFC3830]. According to Section 4.2.7 of [RFC3830],the~~KEMAC payload. 2. The ciphertext~~support for OAKLEY 5 is MANDATORYand~~message digest required under ECIES~~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 MIKEYare~~transmitted in~~the~~KEMAC payload, as~~groups recommended by NISTin~~other forms~~FIPS 186-2 [FIPS-186-2]. Detailed descriptionsof the~~MIKEY protocol. 3. The encryption key and HMAC key~~ECDH groups can be foundineach of FIPS 186-2 [FIPS-186-2] and SEC 2 [SEC2]. The ECDH groupsuse~~in~~elliptic curves over GF[2^N] with N prime or over GF[P] with P prime. Eleven ofthe~~KEMAC are those extracted from~~groups proposed here have been assigned identifiers by IANA [IANA] andthe~~shared key derived using ECIES. 4.~~remaining five might later be assigned identifiers by IANA.The~~PKE payload~~group with IANA number 6is~~not used. Note that this differs from the 'envelope key' method used~~describedin~~the MIKEY-RSA form of the protocol. ECIES, however, uses a symmetric encapsulation algorithm, so encrypting an envelope key (to be used~~[ANSI-X9.62] and [SEC2],with~~another symmetric method to decrypt~~object identifier sect163r1, but it is not one ofthe~~actual payload) would be redundant. Note also~~fifteen curvesthat~~the derived ECIES key can~~NIST recommends [FIPS-186-2]. The remaining NIST recommended groups are suggested and anticipated tobe~~used as an input for the key generation algorithm described in section 4.1.4 of RFC 3830, in identical fashion~~assigned IANA numbersas~~is the envelope key used~~specifiedin~~the MIKEY-RSA method. A MIKEY-ECIES exchange ---------------------- Initiator Responder~~Table 2. id Group Type Group Description NIST Name SEC 2 OID -- ---------- -------------------------- ---------~~I_MESSAGE = HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, ECCPT, KEMAC, [CHASH], SIGNi ---> R_MESSAGE = [<---] HDR, T, [IDr], V Note also~~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 to approximately equivalent security strengths. To encourage interoperability, implementationsthat~~the derived key generated may also be cached for the lifetime of a CSB, at the direction~~support oneofthese classes, SHOULD supportthe~~Initiator, and used as a preshared key, as described for the envelope key~~one groupin~~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~~class that is defined over a prime field (which willbe~~understood as given: -- the KDF~~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) specifiedin~~use for the generation~~Section 6.4of~~the ephemeral key pairs shall~~[RFC3830] canbe~~ECSVDP-DHC,~~usedwithout~~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~~modification. Additional DH-Group identifiers are requiredas~~optional. However, implementations have shown that users of elliptic curve groups can significantly improve performance and security by~~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 Whenusing~~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~~ECDH groups, the DH-valuein the~~KEMAC~~DH datapayload~~when using these groups~~(DH)is the octet string representation specified in ANSI X9.62~~[X9.62], ANSI X9.63 [X9.63], FIPS 186-2 [FIPS 186-2],~~[ANSI-X9.62]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~~[SEC1]. To use ECDHand~~double operations. An updated DH-Group table (as shown in Section 6.4 of [MIKEY]) will~~ECDSA signature algorithm, this extension to MIKEY- DHSIGN maybe~~specified upon assignment of IANA numbers for~~combined withthe~~groups~~extensiondescribed in~~section 8. See also the section "IANA considerations" in this document. 5. Using ECMQV in MIKEY (MIKEY-MQV) MQV~~Section 2. 4. MIKEY-ECIES The Elliptic Curve Integrated Encryption Scheme (ECIES)is a~~protocol primitive equivalent to simultaneous Diffie-Hellman~~public-key~~exchange and digital signature authentication, achievable in~~encryption scheme based on ECC. Section 3.2 of [RFC3830] already specifiesa~~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. 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~~public-key encryptionmethod~~of establishing a secure channel for the transport of the TGK. In this draft,~~(MIKEY-RSA). Herewe~~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~~describethe~~intiator's first message:~~new MIKEY-ECIES method.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], VAs 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~~payload carries Q_(e,I) as per~~containsthe~~nomenclature of ANSI X9.63 --~~elliptic curve point that representsthe ephemeral public key~~contributed by~~required for ECIES. As in MIKEY-RSA,the~~initiator.~~KEMAC contains a set of encrypted sub-payloads and a MAC: KEMAC = E(encr_key, IDi || {TGK}) || MACThe encr_key and auth_key~~used in forming the KEMAC~~are~~the encryption and authentication keys extracted~~derivedfrom the~~derived~~ECIES-derivedkey~~arrived at via MQV. 1-pass ECMQV~~by using thealgorithm~~steps ---------------------------- 1-pass ECMQV is~~described in~~detail~~Section 4.1.4 of [RFC3830],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~~identical fashion asthe~~protocol components in this draft proposal. 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~~envelopekey~~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,~~MIKEY-RSA. Both SIGNiand~~sends R_A to the respondent. The ephemeral public key R_A derived is the value Q_(e,I) in the protocol~~SIGNr will use ECDSA as a signature algorithm, asdescribed~~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.~~Section2.~~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~~Asin~~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~~MIKEY-RSA, it is possible to cachethe~~respondent's public~~ECIES-derivedkey,~~the Initiator finds the EC point P = h x S_i x (Q_4 + (avf(Q_4) x Q_3)). 2e. Initiator verifies~~sothat~~P != 0. 2f. Initiator sets z = x_P, where x_P~~it can be used as a pre-shared key. ECIESis~~the x-coordinate of P. 3. Initiator converts z to bit string Z, using the convention specified~~describedin~~X9.63-2001 section 4.3.3. 4. Initiator uses~~detail in [SEC1]. For ECIES,the key derivation functionthat MUST be used is ANSI-X9.63-KDF asdescribed 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~~[SEC1]. As well,the~~key to~~MAC scheme that MUSTbe~~generated~~usedis~~also given in MQV_PARAMS. Respondent transformation -------------------------~~HMAC-SHA-1- 160.The~~respondent transformation is parallel~~'standard' elliptic curve Diffie-Hellman primitive MUST be used (as opposedto~~the initiator transformation, except~~'cofactor'). The symmetric encryption schemethatMUST be used depends onthe~~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~~size,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~~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 cipherto~~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~~usewith~~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. 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~~ECIES5. MIKEY-ECMQV ECMQV (Elliptic Curve Menezes-Qu-Vanstone)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~~3-pass or 1-passprotocol~~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~~has been standardizedin 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~~[ANSI-X9.63]. Both modesofECMQV provide mutual authentication betweenthe~~groups proposed here have been assigned identifiers by IANA [IANA]~~communicating partiesandkey establishment forthe~~remaining nine curves recommended by NIST might later be assigned identifiers by IANA. See also~~secure transport of data. Here we describethe~~'IANA considerations' section. 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~~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. Asin~~ANSI [X9.62]), one over~~MIKEY-RSA, the KEMAC containsa~~binary field~~set of encrypted sub-payloadsand~~another over~~a~~prime field,~~MAC: KEMAC = E(encr_key, IDi || {TGK}) || MAC The encr_keyand~~a Koblitz curve over a binary field that, which enables especially efficient implementations due to~~auth_key are derived fromthe~~special structure~~ECMQV-derived key by using the algorithm described in Section 4.1.4of[RFC3830], in identical fashion asthe~~curve [Kob, NSA]. Note that~~envelope key used inthe~~large number of proposed curves~~MIKEY-RSA. 1-pass ECMQVis~~for two reasons: Flexibility~~describedin~~implementation~~detailin~~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,~~ANSI X9.63 [ANSI-X9.63]. 6. Additional Payload Encoding 6.1. ECC Point payload (ECCPT)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~~ECCPT payload carries a point onthe~~three Diffie-Hellman groups included~~elliptic curve usedin~~[MIKEY]. 8.1 Recommended domain parameter sets It~~MIKEY-ECIES and MIKEY-ECMQV. The payload identifieris~~RECOMMENDED that,~~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.1for~~minimum interoperability, all implementations except those in highly constrained environments support use~~values. * Point length (16 bits): lengthof the~~P-256 curve. It is RECOMMENDED that implementations~~Point data field (in *bits*). * Point data (variable length): point data, padded to end on a 32-bit boundary, encodedin~~constrained environments support the K163 curve. 9.~~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. 7.Security Considerations Since this document proposes new methods for use within MIKEY, many of the security considerations contained within~~RFC 3830~~[RFC3830]apply here as well. Some of the methods proposed in this document offer higher cryptographic strength than those proposed in~~RFC 3830.~~[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~~[DSS],~~[FIPS-186-2],by the SECG in SEC2 [SEC2], and by ANSI in ANSI X9.62~~[X9.62]~~[ANSI-X9.62]and X9.63~~[X9.63]. Proper validation of elliptic curve public keys can help prevent the attacks described in [BMM]. 10.~~[ANSI-X9.63]. 8.IANA Considerations This~~specification requires additional parameter sets be defined for use in~~document adds entries to existingMIKEY~~when elliptic curve cryptographic methods are used. These are listed~~namespacesin~~section 8.1. It is requested that these be added to the namespace for the DH-Group field~~Section 2 (S typesin~~table 6.4 of RFC 3830, which that document requests shall be managed by the IANA. 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~~signature payloads), Section 3 (DH Group identifier in DH payloads),and~~Electronics Engineers, IEEE P1363a, Draft Standard Specifications for~~Section 6.1 (ECCPT payload identifier). 9. References 9.1. Normative References [ANSI-X9.62] American National Standards Institute, "ANSI X9.62: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.~~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]~~U.S. Department of Commerce/National~~NationalInstitute of Standards and~~Technology.~~Technology, "FIPS 186-2Digital 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~~Standard",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~~[IANA]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.~~Assigned Numbers Authority, "Attribute Assigned Numbers.", <http://www.isi.edu/in-notes/iana/assignments/ ipsec-registry>. [RFC3279] Bassham, L.,Polk,W., andR. Housley,~~and L. Bassham, Algorithms~~"Algorithmsand Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)~~Profile,~~Profile",RFC 3279, April 2002.~~[SEC2]~~[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [SEC1]Standards for Efficient~~Cryptography Group. SEC 2 - Recommended Elliptic~~Crytopgraphy Group, "EllipticCurve~~Domain Parameters. Working Draft Ver. 1.0.,~~Cryptography", September2000.~~(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. [X9.63] American National Standards Institute. ANSI X9.63-2001, Public Key Cryptography~~[SEC2] Standardsfor~~the Financial Services Industry: Key Agreement and Key Transport using~~Efficient Crytopgraphy Group, "RecommendedElliptic Curve~~Cryptography. November 2001. [HANKERSON] Hankerson, Darrel et al. "Guide~~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", <http://www.cryptosavvy.com>. [RFC2119] Bradner, S., "Key words for use in RFCsto~~Elliptic Curve Cryptography". Springer-Verlag, 2004.~~Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.Authors' Addresses Andrew Milne~~Certicom Corp. amilne@certicom.com~~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.comURI: http://www.certicom.comDaniel 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.comURI: 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.comLakshminath Dondeti~~Qualcomm,~~QUALCOMM,Inc.5775 Morehouse Drive San Diego, CA USA Phone: +1-858-845-1267 Email:ldondeti@qualcomm.com~~Expiry reminder This draft expires December 1, 2005.~~Full Copyright StatementCopyright (C) The Internet Society~~(2005).~~(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).