MSEC
Network Working Group                                           A. Milne
Internet Draft
Internet-Draft
Intended status: Standards Track                               M. Blaser
Expires December 2005
Expires: April 23, 2007                                         D. Brown
                                                                 E. Chin
                                                          Certicom Corp.
                                                              L. Dondeti
                                                            Qualcomm
                                                          QUALCOMM, Inc.
                                                        October 20, 2006

                        ECC Algorithms For for MIKEY
                    <draft-ietf-msec-mikey-ecc-00.txt>
                      draft-ietf-msec-mikey-ecc-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/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-Draft will 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 extensions to the implementation or use of the technology authentication, encryption
   and digital signature methods described for use in
   this document or the extent MIKEY, employing
   elliptic-curve cryptography (ECC).  These extensions are defined to which any license under such rights
   might or might not
   align MIKEY with other ECC implementations and standards.

   It should be available; nor does it represent noted that this 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 uses
   the IETF Secretariat notations and any
   assurances definitions of licenses to be made available, or the result [RFC3830].

Table 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.

                               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-DHSIGN with 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 Property and definitions of [MIKEY].

                              Comments

   Comments on this draft should be addressed to
   msec@securemulticast.org. 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.

   RFC 3830 [MIKEY]

   The MIKEY protocol [RFC3830] defines three methods of key exchange during
   establishment for transporting
   or establishing keys: with the use of 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 use Elliptic curve
   Curve Diffie-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 on the elliptic curve protocols MCMQV and algorithms
   ECIES can be
   used in MIKEY and ECMQV in exchanges similar to those of MIKEY-RSA; we
   specify these modes, MIKEY-RSA, and name them
   these methods MIKEY-ECIES and MIKEY-ECMQV respectively.

   Implementations have shown that elliptic curve algorithms can
   significantly improve performance and security-per-bit over other
   recommended algorithms.  The purpose of this document is to expand
   the options available to implementers of MIKEY to take advantage of
   these benefits.

   In addition, elliptic curve algorithms are capable of providing
   security consistent with AES keys of 128, 192, and 256 bits without
   extensive growth in asymmetric key sizes.  The following table, taken
   from [HOF] and [LEN], gives approximate comparable key sizes for
   symmetric systems, ECC systems, and DH/DSA/RSA systems.  The
   estimates are based on the running times of the best algorithms known
   today.

                 Symmetric  |  ECC  ECC2N  |  ECP  |  DH/DSA/RSA
                     80     |   163   |  192  |     1024
                    128     |   283   |   3072  256  |     3072
                    192     |   409   |  384  |     7680
                    256     |   571   |  521  |    15360

                       Table 1: Comparable key sizes

   Thus, for example, when securing a 192-bit symmetric key, it is
   prudent to use either 409-bit 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 sizes the 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 extension of elliptic curve methods for
   public-key authentication and encryption. MIKEY-DHSIGN to use the ECDSA
   signature algorithm.  Section 3 describes the use extension of 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-ECMQV method.  Section 6 includes modifications
   describes additional payloads required 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 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 interpreted as recommended.  This section describes how described in [RFC2119].

2.  MIKEY-DHSIGN with ECDSA signatures may
   be used for certificate signature and signature operations, enabling
   use

   MIKEY-DHSIGN is described in Section 3.3 of smaller signatures and certificates.  This section also
   describes [RFC3830].  The
   Initiator's message includes SIGNi, a signature covering the 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, a signature covering the Responder's message.  According to
   Section 6.5 4.2.6 of [MIKEY] describes [RFC3830], the signature payload for algorithm applied is
   defined by, and dependent on the 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 these signature algorithm algorithms, ECDSA can be
   applied used to
   allow shorter and more-efficient more efficient signatures.

   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 with 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 Diffie-
   Hellman, this extension to transmit encrypted and authenticated messages. This section
   therefore proposes how ECIES MIKEY-DHSIGN 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 combined with the initiator,
   extension described in Section 3.

3.  MIKEY-DHSIGN with ECDH

   MIKEY-DHSIGN is transmitted described in 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 MANDATORY and 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 MIKEY are transmitted in the KEMAC payload, as groups recommended by
   NIST in other forms FIPS 186-2 [FIPS-186-2].  Detailed descriptions of the MIKEY protocol.
      3. The encryption key and HMAC key ECDH
   groups can be found in each of FIPS 186-2 [FIPS-186-2] and SEC 2
   [SEC2].  The ECDH groups use in elliptic curves over GF[2^N] with N
   prime or over GF[P] with P prime.  Eleven of the KEMAC are those
         extracted from groups proposed here
   have been assigned identifiers by IANA [IANA] and the shared key derived using ECIES.
      4. remaining five
   might later be assigned identifiers by IANA.  The PKE payload group with IANA
   number 6 is not used.

   Note that this differs from the 'envelope key' method used described in 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 of the actual payload)
   would be redundant.

   Note also fifteen curves that the derived ECIES key can
   NIST recommends [FIPS-186-2].  The remaining NIST recommended groups
   are suggested and anticipated to be used as an input for the
   key generation algorithm described in section 4.1.4 of RFC 3830, in
   identical fashion assigned IANA numbers as is the envelope key used
   specified in 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, implementations that the derived key generated may also be cached for the
   lifetime of a CSB, at the direction support one of these classes,
   SHOULD support the Initiator, and used as a
   preshared key, as described for the envelope key one group 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 class that is defined over a
   prime field (which will be 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) specified in use for the generation Section 6.4 of the ephemeral key pairs
           shall [RFC3830] can be ECSVDP-DHC,
   used 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 modification.  Additional DH-Group identifiers are
   required as 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

   When 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 ECDH groups, the DH-value in the KEMAC DH data payload 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 ECDH and double operations.

   An updated DH-Group table (as shown in Section 6.4 of [MIKEY]) will ECDSA signature algorithm, this extension to MIKEY-
   DHSIGN may be specified upon assignment of IANA numbers for combined with the groups extension described 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
   specifies 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.

   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 encryption method of establishing a secure channel for the transport of the TGK.
   In this draft, (MIKEY-RSA).  Here 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
   describe the 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], V

   As with the MIKEY-RSA case, the main objective of the Initiator's
   message is to transport one or more TGKs and a set of security
   parameters to the Responder in a secure manner.

   With MIKEY-RSA, the TGKs are encrypted with an "envelope key".
   However, ECIES uses a symmetric encapsulation algorithm, so
   encrypting an envelope key (to be used with another symmetric method
   to decrypt the actual payload) would be redundant.  As a result, the
   PKE payload is not used.

   The ECCPT payload carries Q_(e,I) as per contains the nomenclature of ANSI
   X9.63 -- elliptic curve point that represents the
   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}) || MAC

   The encr_key and auth_key used in forming the KEMAC are the
   encryption and authentication keys extracted derived from the derived ECIES-derived key
   arrived at via MQV.

   1-pass ECMQV by
   using the algorithm 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 as the 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 envelope 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, MIKEY-RSA.

   Both SIGNi and 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, as
   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. Section 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

   As 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 MIKEY-RSA, it is possible to cache the respondent's public ECIES-derived key, the Initiator
               finds the EC point
               P = h x S_i x (Q_4 + (avf(Q_4) x Q_3)).
           2e. Initiator verifies so
   that P != 0.
           2f. Initiator sets z = x_P, where x_P it can be used as a pre-shared key.

   ECIES is the
               x-coordinate of P.
      3. Initiator converts z to bit string Z, using the convention
         specified described in X9.63-2001 section 4.3.3.
      4. Initiator uses detail in [SEC1].  For ECIES, the key
   derivation function that MUST be used is ANSI-X9.63-KDF as 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 [SEC1].  As well, the key to MAC scheme that MUST be generated used is 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 opposed to the initiator
   transformation, except 'cofactor').  The symmetric encryption scheme
   that MUST be used depends on 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 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 cipher 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 use 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.

   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

5.  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-pass
   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 has been standardized 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 [ANSI-X9.63].  Both
   modes of ECMQV provide mutual authentication between the groups
   proposed here have been assigned identifiers by IANA [IANA]
   communicating parties and key establishment for the
   remaining nine curves recommended by NIST might later be assigned
   identifiers by IANA. See also secure transport
   of data.  Here we describe the '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.

   As in ANSI [X9.62]), one over MIKEY-RSA, the KEMAC contains a
   binary field set of encrypted sub-payloads
   and another over a prime field, MAC:

   KEMAC = E(encr_key, IDi || {TGK}) || MAC

   The encr_key and a Koblitz curve
   over a binary field that, which enables especially efficient
   implementations due to auth_key are derived from the special structure ECMQV-derived key by
   using the algorithm described in Section 4.1.4 of [RFC3830], in
   identical fashion as the curve [Kob, NSA].

   Note that envelope key used in the large number of proposed curves MIKEY-RSA.

   1-pass ECMQV is for two reasons:
   Flexibility described in implementation detail 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, 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 on the three Diffie-Hellman groups included elliptic curve used in [MIKEY].

   8.1 Recommended domain parameter sets

   It
   MIKEY-ECIES and MIKEY-ECMQV.  The payload identifier is 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.1 for minimum interoperability, all
   implementations except those in highly constrained environments
   support use values.

   * Point length (16 bits): length of 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, encoded in 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 existing MIKEY when elliptic curve cryptographic methods are used.
   These are listed namespaces in section 8.1.

   It is requested that these be added to the namespace for the
   DH-Group field Section 2
   (S types in 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
              National Institute of Standards and Technology. Technology, "FIPS
              186-2 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 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., and R. Housley, and L. Bassham, Algorithms "Algorithms and
              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, "Elliptic
              Curve Domain Parameters. Working Draft
     Ver. 1.0., Cryptography", September 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.

   [X9.63] American National Standards Institute. ANSI X9.63-2001,
     Public Key Cryptography

   [SEC2]     Standards for the Financial Services Industry: Key
     Agreement and Key Transport using Efficient Crytopgraphy Group, "Recommended
              Elliptic 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 RFCs to 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.com
   URI:   http://www.certicom.com

   Daniel R. L. Brown
   Certicom Corp.
   5520 Explorer Drive
   Mississauga, Ontario  L4W 5L1
   CANADA

   Phone: +1-905-507-4220
   Fax:   +1-905-507-4230
   Email: dbrown@certicom.com
   URI:   http://www.certicom.com

   Eugene Chin
   Certicom Corp.
   5520 Explorer Drive
   Mississauga, Ontario  L4W 5L1
   CANADA

   Phone: +1-905-507-4220
   Fax:   +1-905-507-4230
   Email: mblaser@certicom.com
   URI:   http://www.certicom.com
   Lakshminath 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 Statement

   Copyright (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).