 1/draftietfmsecmikeyecc00.txt 20061023 01:12:30.000000000 +0200
+++ 2/draftietfmsecmikeyecc01.txt 20061023 01:12:30.000000000 +0200
@@ 1,591 +1,518 @@
MSEC Working Group A. Milne
Internet Draft M. Blaser
Expires December 2005 D. Brown
 Certicom
+Network Working Group A. Milne
+InternetDraft
+Intended status: Standards Track M. Blaser
+Expires: April 23, 2007 D. Brown
+ E. Chin
+ Certicom Corp.
L. Dondeti
 Qualcomm
 ECC Algorithms For MIKEY

+ QUALCOMM, Inc.
+ October 20, 2006
+
+ ECC Algorithms for MIKEY
+ draftietfmsecmikeyecc01
Status of this Memo
+ By submitting this InternetDraft, 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.
+
InternetDrafts 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.
InternetDrafts 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 InternetDrafts as reference
material or to cite them other than as "work in progress."
The list of current InternetDrafts can be accessed at
 http://www.ietf.org/1idabstracts.html
+ http://www.ietf.org/ietf/1idabstracts.txt.
The list of InternetDraft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
 IPR Statement

 By submitting this InternetDraft, 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.
+ This InternetDraft will expire on April 23, 2007.
 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 online IPR repository at
 http://www.ietf.org/ipr.
+Copyright Notice
 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
 ietfipr@ietf.org.
+ Copyright (C) The Internet Society (2006).
Abstract
 This document proposes extensions to the authentication,
 encryption and digital signature methods described for use in
 MIKEY, employing ellipticcurve cryptography (ECC). These
 extensions are defined to align MIKEY with other ECC
 implementations and standards.
+ This document proposes extensions to the authentication, encryption
+ and digital signature methods described for use in MIKEY, employing
+ ellipticcurve cryptography (ECC). These extensions are defined to
+ align MIKEY with other ECC implementations and standards.
 It should be noted that this document is not selfcontained; it
 uses the notations and definitions of [MIKEY].
+ It should be noted that this document is not selfcontained; it uses
+ the notations and definitions of [RFC3830].
 Comments
+Table of Contents
 Comments on this draft should be addressed to
 msec@securemulticast.org.
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. MIKEYDHSIGN with ECDSA . . . . . . . . . . . . . . . . . . . 5
+ 3. MIKEYDHSIGN with ECDH . . . . . . . . . . . . . . . . . . . . 6
+ 4. MIKEYECIES . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5. MIKEYECMQV . . . . . . . . . . . . . . . . . . . . . . . . . 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
1. Introduction
 This document describes additional algorithms for use in MIKEY.
 The document assumes that the reader is familiar with the MIKEY
 protocol.
+ 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 preshared key (MIKEYPSA) and public
 key (MIKEYRSA) methods are mandatory, while support for
 DiffieHellman (MIKEYDHSIGN) is optional. Elliptic curve
 DiffieHellman (ECDH) can be used in the MIKEY DiffieHellman
 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 MIKEYRSA; we
 specify these modes, and name them MIKEYECIES and
 MIKEYECMQV respectively.
+ The MIKEY protocol [RFC3830] defines three methods for transporting
+ or establishing keys: with the use of a preshared key, publickey
+ encryption (MIKEYRSA), and DiffieHellman (DH) key exchange (MIKEY
+ DHSIGN). This document extends MIKEYDHSIGN to use ECDSA as the
+ signature algorithm and further extends MIKEYDHSIGN to use Elliptic
+ Curve DiffieHellman (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 MIKEYRSA, and name
+ these methods MIKEYECIES and MIKEYECMQV respectively.
Implementations have shown that elliptic curve algorithms can
significantly improve performance and securityperbit 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 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
+ 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 192bit symmetric key, it is
 prudent to use either 409bit ECC or 7680bit 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 publickey algorithm and claims
 such as "this system is highly secure because it uses 192bit
 encryption" are misleading.

 Section 2 below describes the use of elliptic curve methods for
 publickey 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
 MIKEYMQV method. Section 6 includes modifications to specific
 sections of [MIKEY].

 2. Use of EC methods with publickey encryption (MIKEYRSA)

 MIKEYRSA 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
+ prudent to use either 409bit ECC2N, 384bit ECP, or 7680bit DH/DSA/
+ RSA. With smaller key sizes the symmetric keys would be
+ underprotected.
 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 moreefficient signatures.
+ Section 2 describes the extension of MIKEYDHSIGN to use the ECDSA
+ signature algorithm. Section 3 describes the extension of MIKEY
+ DHSIGN to use ECDH groups. Section 4 describes the MIKEYECIES
+ method. Section 5 describes the MIKEYECMQV method. Section 6
+ describes additional payloads required to support these new methods.
 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.
+ 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].
 RFC3279 describes algorithms and identifiers for Internet X.509
 certificates and CRLs. It includes ECC algorithms and identifiers.
+2. MIKEYDHSIGN with ECDSA
 3. MIKEYECIES
+ MIKEYDHSIGN 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.
 MIKEY's publickey encryption method (MIKEYRSA) 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 keysassuming these are EC public keysmay use these keys
 to transmit encrypted and authenticated messages. This section
 therefore proposes how ECIES may be used in MIKEY. We call this
 scheme MIKEYECIES.
+ ECDSA signatures are detailed in [ANSIX9.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 SHA1.
 We propose that ECIES be used as follows:
+ 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:
 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.
+ S type  Value  Comments
+ 
+ ECDSA  2  ECDSA signature [ANSI_X9.62]
 Note that this differs from the 'envelope key' method used in the
 MIKEYRSA 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.
+ [RFC3279] describes algorithms and identifiers for Internet X.509
+ certificates and CRLs. It includes ECC algorithms and identifiers.
 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 MIKEYRSA
 method.
+ To use the ECDSA signature algorithm with Elliptic Curve Diffie
+ Hellman, this extension to MIKEYDHSIGN may be combined with the
+ extension described in Section 3.
 A MIKEYECIES exchange
 
+3. MIKEYDHSIGN with ECDH
 Initiator Responder
  
+ MIKEYDHSIGN 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
+ DiffieHellman (DH) groups, elliptic curve DiffieHellman (ECDH)
+ groups can significantly improve performance and security.
 I_MESSAGE =
 HDR, T, RAND, [IDiCERTi], [IDr], {SP},
 ECCPT, KEMAC, [CHASH], SIGNi >
+ The ECDH groups to be used by MIKEY are the groups recommended by
+ NIST in FIPS 1862 [FIPS1862]. Detailed descriptions of the ECDH
+ groups can be found in each of FIPS 1862 [FIPS1862] 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 [ANSIX9.62] and [SEC2], with object
+ identifier sect163r1, but it is not one of the fifteen curves that
+ NIST recommends [FIPS1862]. The remaining NIST recommended groups
+ are suggested and anticipated to be assigned IANA numbers as
+ specified in Table 2.
 R_MESSAGE =
+ id Group Type Group Description NIST Name SEC 2 OID
+     
 [<] HDR, T, [IDr], V
 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.
+ 22 2 ECP ECPRGF192Random P192 secp192r1
+ 23 3 EC2N EC2NGF163Random B163 sect163r2
+ 7 3 EC2N EC2NGF163Koblitz K163 sect163k1
+ 6 3 EC2N EC2NGF163Random2 none sect163r1
 ECIES options
 
+ 24 2 ECP ECPRGF224Random P224 secp224r1
+ 25 3 EC2N EC2NGF233Random B233 sect233r1
+ 26 3 EC2N EC2NGF233Koblitz K233 sect233k1
 IEEE 1363A describes a number of options for ECIES. We recommend that
 in MIKEYECIES, the following options be understood as given:
+ 19 2 ECP ECPRGF256Random P256 secp256r1
+ 8 3 EC2N EC2NGF283Random B283 sect283r1
+ 9 3 EC2N EC2NGF283Koblitz K283 sect283k1
  the KDF in use for the generation of the ephemeral key pairs
 shall be ECSVDPDHC, without compatibility for the
 corresponding DH primitive
+ 20 2 ECP ECPRGF384Random P384 secp384r1
+ 10 3 EC2N EC2NGF409Random B409 sect409r1
+ 11 3 EC2N EC2NGF409Koblitz K409 sect409k1
  DHAES mode shall not be used.
+ 21 2 ECP ECPRGF521Random P521 secp521r1
+ 12 3 EC2N EC2NGF571Random B571 sect571r1
+ 13 3 EC2N EC2NGF571Koblitz K571 sect571k1
 4. Use of EC methods with DiffieHellman key exchange (MIKEYDHSIGN)
+ Table 2: Recommended Groups and Names
 The MIKEYDHSIGN 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 ECDH groups in Table 2 are arranged into 5 classes, corresponding
+ 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 P192, P224, P256, P384, or
+ P521). Implementations SHOULD support one of P256 or P384.
+ Implementations MAY support any set of groups.
 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 1862 [FIPS 1862], 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.
+ The DH data payload (DH) specified in Section 6.4 of [RFC3830] can be
+ used without modification. Additional DHGroup identifiers are
+ required as follows:
 An updated DHGroup 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.
+ DHGroup  Value
+ 
+ ECPRGF192Random / P192 / secp192r1  3
+ EC2NGF163Random / B163 / sect163r2  4
+ EC2NGF163Koblitz / K163 / sect163k1  5
+ EC2NGF163Random2 / none / sect163r1  6
+ 
+ ECPRGF224Random / P224 / secp224r1  7
+ EC2NGF233Random / B233 / sect233r1  8
+ EC2NGF233Koblitz / K233 / sect233k1  9
+ 
+ ECPRGF256Random / P256 / secp256r1  10
+ EC2NGF283Random / B283 / sect283r1  11
+ EC2NGF283Koblitz / K283 / sect283k1  12
+ 
+ ECPRGF384Random / P384 / secp384r1  13
+ EC2NGF409Random / B409 / sect409r1  14
+ EC2NGF409Koblitz / K409 / sect409k1  15
+ 
+ ECPRGF521Random / P521 / secp521r1  16
+ EC2NGF571Random / B571 / sect571r1  17
+ EC2NGF571Koblitz / K571 / sect571k1  18
 5. Using ECMQV in MIKEY (MIKEYMQV)
+ When using the ECDH groups, the DHvalue in the DH data payload (DH)
+ is the octet string representation specified in ANSI X9.62
+ [ANSIX9.62] and [SEC1].
 MQV is a protocol primitive equivalent to simultaneous DiffieHellman
 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.
+ To use ECDH and ECDSA signature algorithm, this extension to MIKEY
+ DHSIGN may be combined with the extension described in Section 2.
 ECMQV (Elliptic Curve MenezesQuVanstone) is a threepass or 1pass
 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 1pass
 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 MIKEYMQV,
 in which ECMQV is used in this fashion.
+4. MIKEYECIES
 A MIKEYMQV exchange proceeds in similar fashion to the MIKEYRSA
 exchange; the PKE is absent, and an ECCPT payload (see section 5.1)
 MUST precede the KEMAC payload in the intiator's first message:
+ The Elliptic Curve Integrated Encryption Scheme (ECIES) is a public
+ key encryption scheme based on ECC. Section 3.2 of [RFC3830] already
+ specifies a publickey encryption method (MIKEYRSA). Here we
+ describe the new MIKEYECIES method.
Initiator Responder
  
I_MESSAGE =
HDR, T, RAND, [IDiCERTi], [IDr], {SP},
ECCPT, KEMAC, [CHASH], SIGNi >
 ... the responder's acknowledgement, as in MIKEYRSA, 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.

 1pass ECMQV algorithm steps
 

 1pass ECMQV is described in detail in ANSI X9.632001; 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.

 Note that 1pass MQV differs from 3pass 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 twiceeffectively
 replacing the ephemeral key pair contributed by the respondent in
 the 3pass method.

 Initiator transformation
 
+ As with the MIKEYRSA 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.
 1. Initiator selects an ephemeral private key k_A from the
 set {1..n1}, 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.632001 section 5.2.1Key Pair
 Generation Primitive.
 2. Initiator calculates the shared secret value z as follows
 (see X9.632001 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.632001 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
 xcoordinate of P.
 3. Initiator converts z to bit string Z, using the convention
 specified in X9.632001 section 4.3.3.
 4. Initiator uses the key derivation function described in
 X9.632001 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.
+ With MIKEYRSA, 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.
 Respondent transformation
 
+ The ECCPT contains the elliptic curve point that represents the
+ ephemeral public key required for ECIES.
 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.632001 section 5.5 for
 a detailed description appropriate for implementation purposes.
+ As in MIKEYRSA, the KEMAC contains a set of encrypted subpayloads
+ and a MAC:
 1. Respondent verifies that Q_(e, U) is a valid key for the
 domain parameters (see X9.632001 section 5.2.2).
 2. Respondent calculates the shared secret value z as follows
 (see X9.632001 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.632001
 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 xcoordinate
 of P.
 3. Respondent converts z to bit string Z, using the convention
 specified in X9.632001 section 4.3.3.
 4. Respondent uses the key derivation function described in
 X9.632001 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.
+ KEMAC = E(encr_key, IDi  {TGK})  MAC
 6. Additional MIKEY payloads
+ The encr_key and auth_key are derived from the ECIESderived key by
+ using the algorithm described in Section 4.1.4 of [RFC3830], in
+ identical fashion as the envelope key used in the MIKEYRSA.
 6.1 ECCPT payload format
+ Both SIGNi and SIGNr will use ECDSA as a signature algorithm, as
+ described in Section 2.
 The ECCPT payload provides for the transport of an EC point in the
 MIKEYMQV and in the MIKEYRSA exchange when ECIES is in use. It is
 of the form:
+ As in MIKEYRSA, it is possible to cache the ECIESderived key, so
+ that it can be used as a preshared key.
 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 ~
 +++++++++++++++++++++++++++++++++
+ ECIES is described in detail in [SEC1]. For ECIES, the key
+ derivation function that MUST be used is ANSIX9.63KDF as described
+ in [SEC1]. As well, the MAC scheme that MUST be used is HMACSHA1
+ 160. The 'standard' elliptic curve DiffieHellman primitive MUST be
+ used (as opposed to 'cofactor'). The symmetric encryption scheme
+ that MUST be used depends on the key size, as follows:
 Point length is the length of the point data in *bits*.
+ ECC2N  ECP  Symmetric Cipher To Use
+ 163  192  3DESCBC
+ 283  256  AES128CBC
+ 409  384  AES256CBC
+ 571  521  AES256CBC
 The point_data field is padded to end on a 32bit boundary, and is
 encoded as per ANSI X9.632001 4.3.6. Uncompressed format MUST be
 supported. Hybrid and compressed formats MAY be supported.
+ Table 3: Symmetric cipher to use with ECIES
 7. Multicast applications of MQV and ECIES
+5. MIKEYECMQV
 Both MQV and ECDSA/ECIES may be used in multicast environments to
 establish a group TEK, in the same fashion as MIKEYRSA.
+ ECMQV (Elliptic Curve MenezesQuVanstone) is a 3pass or 1pass
+ protocol that has been standardized in ANSI X9.63 [ANSIX9.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 MIKEYECMQV method based on the
+ 1pass protocol.
 8. Recommended and optional domain parameter sets
+ Initiator Responder
 8.1 Available domain parameter sets
+ I_MESSAGE =
+ HDR, T, RAND, [IDiCERTi], [IDr], {SP},
+ ECCPT, KEMAC, [CHASH], SIGNi >
 Elliptic curve domain parameter sets available for use in this
 protocol for all methods employing EC primitivesand given here
 are the fifteen groups that NIST recommends in FIPS 1862
 [FIPS1862]. 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 1862
 [FIPS1862] and SEC 2 [SEC2]. 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 [SEC2].
+ R_MESSAGE =
+ [<] HDR, T, [IDr], V
 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.
+ The ECCPT contains the elliptic curve point that represents the
+ ephemeral public key contributed by the Initiator.
 IANA Group Descriptions X9.63 (and SEC 2) OID
   
+ As in MIKEYRSA, the KEMAC contains a set of encrypted subpayloads
+ and a MAC:
 NA ECPRGF192Random group P192 secp192r1
 NA EC2NGF163Random group B163 sect163r2
 7 EC2NGF163Koblitz group K163 sect163k1
+ KEMAC = E(encr_key, IDi  {TGK})  MAC
 NA ECPRGF224Random group P224 secp224r1
 NA EC2NGF233Random group B233 sect233r1
 NA EC2NGF233Koblitz group K233 sect233k1
+ The encr_key and auth_key are derived from the ECMQVderived key by
+ using the algorithm described in Section 4.1.4 of [RFC3830], in
+ identical fashion as the envelope key used in the MIKEYRSA.
 NA ECPRGF256Random group P256 secp256r1
 8 EC2NGF283Random group B283 sect283r1
 9 EC2NGF283Koblitz group K283 sect283k1
+ 1pass ECMQV is described in detail in ANSI X9.63 [ANSIX9.63].
 NA ECPRGF384Random group P384 secp384r1
 10 EC2NGF409Random group B409 sect409r1
 11 EC2NGF409Koblitz group K409 sect409k1
+6. Additional Payload Encoding
 NA ECPRGF521Random group P521 secp521r1
 12 EC2NGF571Random group B571 sect571r1
 13 EC2NGF571Koblitz group K571 sect571k1
+6.1. ECC Point payload (ECCPT)
 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].
+ The ECCPT payload carries a point on the elliptic curve used in
+ MIKEYECIES and MIKEYECMQV. The payload identifier is 22.
 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 militarygrade or future uses. In ECDH, The 163bit and 192bit
 curves provide equivalent security strength to Oakley group 2; all
 other proposed curves offer significantly higher security strength
 equivalents than the three DiffieHellman groups included in [MIKEY].
+ 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 ~
+ +++++++++++++++++++++++++++++++++
 8.1 Recommended domain parameter sets
+ * Next payload (8 bits): identifies the payload that is added after
+ this payload. See Section 6.1 for values.
 It is RECOMMENDED that, for minimum interoperability, all
 implementations except those in highly constrained environments
 support use of the P256 curve.
+ * Point length (16 bits): length of the Point data field (in *bits*).
 It is RECOMMENDED that implementations in constrained environments
 support the K163 curve.
+ * Point data (variable length): point data, padded to end on a 32bit
+ boundary, encoded in octet string representation specified in
+ ANSI X9.62 [ANSIX9.62] and [SEC1]. Uncompressed format MUST be
+ supported. Hybrid and compressed formats MAY be supported.
 9. Security Considerations
+7. 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 higherstrength AES algorithms and SHA implementations.

 The methods proposed in this document are among those standardized
 by NIST in FIPS 1862 [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.
+ 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
+ higherstrength AES algorithms and SHA implementations. The methods
+ proposed in this document are among those standardized by NIST in
+ FIPS 1862 [FIPS1862], by the SECG in SEC2 [SEC2], and by ANSI in
+ ANSI X9.62 [ANSIX9.62] and X9.63 [ANSIX9.63].
 It is requested that these be added to the namespace for the
 DHGroup field in table 6.4 of RFC 3830, which that document requests
 shall be managed by the IANA.
+8. IANA Considerations
 12. References
+ 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).
 [IANA] Internet Assigned Numbers Authority. Attribute Assigned
 Numbers.
 (http://www.isi.edu/innotes/iana/assignments/ipsecregistry)
+9. References
 [IEEE 1363A2004] Institute of Electrical and Electronics Engineers,
 IEEE P1363a, Draft Standard Specifications for Public Key
 Cryptography  Amendment 1: Additional Techniques.
+9.1. Normative References
 [KOB] N. Koblitz, CM curves with good cryptographic properties.
 Proceedings of Crypto '91. Pages 279287. SpringerVerlag, 1992.
+ [ANSIX9.62]
+ American National Standards Institute, "ANSI X9.62: Public
+ Key Cryptography For The Financial Services Industry: The
+ Elliptic Curve Digital Signature Algorithm (ECDSA)", 2005.
 [FIPS1862] U.S. Department of Commerce/National Institute of
 Standards and Technology. Digital Signature Standard (DSS), FIPS
 PUB 1862, January 2000.
 (http://csrc.nist.gov/fips/fips1862.pdf)
+ [ANSIX9.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.
 [HOF] P. Hoffman and H. Orman, Determining strengths for public keys
 used for exchanging symmetric keys, Internetdraft. August 2000.
+ [FIPS1862]
+ National Institute of Standards and Technology, "FIPS
+ 1862 Digital Signature Standard", 2000.
 [LEN] A. Lenstra and E. Verhuel, Selecting cryptographic key sizes.
 Available at: www.cryptosavvy.com.
+ [IANA] Internet Assigned Numbers Authority, "Attribute Assigned
+ Numbers.", .
 [MIKEY] [RFC3830] J. Arkko, E. Carrara, F. Lindholm, M. Naslund,
 K. Norrman, MIKEY: Multimedia Internet KEYing, RFC 3830, August
 2004.
+ [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.
 [NSA] J. Solinas, An improved algorithm for arithmetic on a family
 of elliptic curves, Proceedings of Crypto '97, Pages 357371,
 SpringerVerlag, 1997.
+ [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
+ Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
+ August 2004.
 [RFC3278] S. BlakeWilson, D. Brown and P. Lambert, The Use of
 Elliptic Curve Cryptography (ECC) Algorithms in the Cryptographic
 Message Syntax (CMS), RFC 3279, April 2002.
+ [SEC1] Standards for Efficient Crytopgraphy Group, "Elliptic
+ Curve Cryptography", September 2000.
 [RFC3279] 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 Crytopgraphy Group, "Recommended
+ Elliptic Curve Domain Parameters", September 2000.
 [SEC2] Standards for Efficient Cryptography Group. SEC 2 
 Recommended Elliptic Curve Domain Parameters. Working Draft
 Ver. 1.0., 2000. (http://www.secg.org)
+9.2. Informative References
 [X9.62] American National Standards Institute, ANSI X9.621998:
 Public Key Cryptography for the Financial Services Industry: The
 Elliptic Curve Digital Signature Algorithm. January 1999.
+ [HOF] Hoffman, P. and H. Orman, "Determining strengths for
+ public keys used for exchanging symmetric keys",
+ August 2000.
 [X9.63] American National Standards Institute. ANSI X9.632001,
 Public Key Cryptography for the Financial Services Industry: Key
 Agreement and Key Transport using Elliptic Curve Cryptography.
 November 2001.
+ [LEN] Lenstra, A. and E. Verhuel, "Selecting cryptographic key
+ sizes", .
 [HANKERSON] Hankerson, Darrel et al. "Guide to Elliptic Curve
 Cryptography". SpringerVerlag, 2004.
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Andrew Milne
 Certicom Corp.
 amilne@certicom.com
Mitch Blaser
Certicom Corp.
 mblaser@certicom.com
+ 5520 Explorer Drive
+ Mississauga, Ontario L4W 5L1
+ CANADA
+
+ Phone: +19055074220
+ Fax: +19055074230
+ Email: mblaser@certicom.com
+ URI: http://www.certicom.com
Daniel R. L. Brown
Certicom Corp.
 dbrown@certicom.com
+ 5520 Explorer Drive
+ Mississauga, Ontario L4W 5L1
+ CANADA
+ Phone: +19055074220
+ Fax: +19055074230
+ Email: dbrown@certicom.com
+ URI: http://www.certicom.com
+
+ Eugene Chin
+ Certicom Corp.
+ 5520 Explorer Drive
+ Mississauga, Ontario L4W 5L1
+ CANADA
+
+ Phone: +19055074220
+ Fax: +19055074230
+ Email: mblaser@certicom.com
+ URI: http://www.certicom.com
Lakshminath Dondeti
 Qualcomm, Inc.
 ldondeti@qualcomm.com
+ QUALCOMM, Inc.
+ 5775 Morehouse Drive
+ San Diego, CA
+ USA
 Expiry reminder
+ Phone: +18588451267
+ Email: ldondeti@qualcomm.com
 This draft expires December 1, 2005.
+Full Copyright Statement
 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.
+ 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 online 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
+ ietfipr@ietf.org.
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).