draft-ietf-msec-mikey-ecc-00.txt   draft-ietf-msec-mikey-ecc-01.txt 
MSEC Working Group A. Milne
Internet Draft M. Blaser
Expires December 2005 D. Brown
Certicom
Network Working Group A. Milne
Internet-Draft
Intended status: Standards Track M. Blaser
Expires: April 23, 2007 D. Brown
E. Chin
Certicom Corp.
L. Dondeti L. Dondeti
Qualcomm QUALCOMM, Inc.
ECC Algorithms For MIKEY October 20, 2006
<draft-ietf-msec-mikey-ecc-00.txt>
ECC Algorithms for MIKEY
draft-ietf-msec-mikey-ecc-01
Status of this Memo 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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at 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 The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
IPR Statement This Internet-Draft will expire on April 23, 2007.
By submitting this Internet-Draft, each author represents
that any applicable patent or other IPR claims of which he
or she is aware have been or will be disclosed, and any of
which he or she becomes aware will be disclosed, in
accordance with Section 6 of BCP 79.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copyright Notice
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 Copyright (C) The Internet Society (2006).
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 Abstract
This document proposes extensions to the authentication, This document proposes extensions to the authentication, encryption
encryption and digital signature methods described for use in and digital signature methods described for use in MIKEY, employing
MIKEY, employing elliptic-curve cryptography (ECC). These elliptic-curve cryptography (ECC). These extensions are defined to
extensions are defined to align MIKEY with other ECC align MIKEY with other ECC implementations and standards.
implementations and standards.
It should be noted that this document is not self-contained; it It should be noted that this document is not self-contained; it uses
uses the notations and definitions of [MIKEY]. the notations and definitions of [RFC3830].
Comments Table of Contents
Comments on this draft should be addressed to 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
msec@securemulticast.org. 2. MIKEY-DHSIGN with ECDSA . . . . . . . . . . . . . . . . . . . 5
3. MIKEY-DHSIGN with ECDH . . . . . . . . . . . . . . . . . . . . 6
4. MIKEY-ECIES . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. MIKEY-ECMQV . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Additional Payload Encoding . . . . . . . . . . . . . . . . . 11
6.1. ECC Point payload (ECCPT) . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
This document describes additional algorithms for use in MIKEY. This document describes additional algorithms for use in MIKEY. The
The document assumes that the reader is familiar with the MIKEY document assumes that the reader is familiar with the MIKEY protocol.
protocol.
RFC 3830 [MIKEY] defines three methods of key exchange during The MIKEY protocol [RFC3830] defines three methods for transporting
establishment of a TGK. The pre-shared key (MIKEY-PSA) and public or establishing keys: with the use of a pre-shared key, public-key
key (MIKEY-RSA) methods are mandatory, while support for encryption (MIKEY-RSA), and Diffie-Hellman (DH) key exchange (MIKEY-
Diffie-Hellman (MIKEY-DHSIGN) is optional. Elliptic curve DHSIGN). This document extends MIKEY-DHSIGN to use ECDSA as the
Diffie-Hellman (ECDH) can be used in the MIKEY Diffie-Hellman signature algorithm and further extends MIKEY-DHSIGN to use Elliptic
method; we specify this mode in this document. In addition, Curve Diffie-Hellman (ECDH) groups. In addition, this document
the elliptic curve protocols MCMQV and ECIES can be introduces two new methods based on the elliptic curve algorithms
used in MIKEY in exchanges similar to those of MIKEY-RSA; we ECIES and ECMQV in exchanges similar to those of MIKEY-RSA, and name
specify these modes, and name them MIKEY-ECIES and these methods MIKEY-ECIES and MIKEY-ECMQV respectively.
MIKEY-ECMQV respectively.
Implementations have shown that elliptic curve algorithms can Implementations have shown that elliptic curve algorithms can
significantly improve performance and security-per-bit over other significantly improve performance and security-per-bit over other
recommended algorithms. The purpose of this document is to expand recommended algorithms. The purpose of this document is to expand
the options available to implementers of MIKEY to take advantage of the options available to implementers of MIKEY to take advantage of
these benefits. these benefits.
In addition, elliptic curve algorithms are capable of providing In addition, elliptic curve algorithms are capable of providing
security consistent with AES keys of 128, 192, and 256 bits without security consistent with AES keys of 128, 192, and 256 bits without
extensive growth in asymmetric key sizes. The following table, taken extensive growth in asymmetric key sizes. The following table, taken
from [HOF] and [LEN], gives approximate comparable key sizes for from [HOF] and [LEN], gives approximate comparable key sizes for
symmetric systems, ECC systems, and DH/DSA/RSA systems. The estimates symmetric systems, ECC systems, and DH/DSA/RSA systems. The
are based on the running times of the best algorithms known today. estimates are based on the running times of the best algorithms known
today.
Symmetric | ECC | DH/DSA/RSA Symmetric | ECC2N | ECP | DH/DSA/RSA
80 | 163 | 1024 80 | 163 | 192 | 1024
128 | 283 | 3072 128 | 283 | 256 | 3072
192 | 409 | 7680 192 | 409 | 384 | 7680
256 | 571 | 15360 256 | 571 | 521 | 15360
Table 1: Comparable key sizes Table 1: Comparable key sizes
Thus, for example, when securing a 192-bit symmetric key, it is Thus, for example, when securing a 192-bit symmetric key, it is
prudent to use either 409-bit ECC or 7680-bit DH/DSA/RSA. Of course prudent to use either 409-bit ECC2N, 384-bit ECP, or 7680-bit DH/DSA/
it is possible to use shorter asymmetric keys, but it should be RSA. With smaller key sizes the symmetric keys would be
recognized in this case that the security of the system is likely underprotected.
dependent on the strength of the public-key algorithm and claims
such as "this system is highly secure because it uses 192-bit
encryption" are misleading.
Section 2 below describes the use of elliptic curve methods for
public-key authentication and encryption. Section 3 describes
the use of ECIES (The Elliptic Curve Integrated Encryption
Scheme). Section 4 describes methods for Elliptic Curve Diffie-
Hellman, including fifteen ECDH groups. Section 5 describes the
MIKEY-MQV method. Section 6 includes modifications to specific
sections of [MIKEY].
2. Use of EC methods with public-key encryption (MIKEY-RSA)
MIKEY-RSA specifies the use of RSA PKCS#1, v1.5 as mandatory and RSA
PSS as recommended. This section describes how ECDSA signatures may
be used for certificate signature and signature operations, enabling
use of smaller signatures and certificates. This section also
describes the ECIES encryption/decryption scheme, for use with
elliptic curve key pairs.
2.1 ECDSA signature
Section 6.5 of [MIKEY] describes the signature payload for the PK Section 2 describes the extension of MIKEY-DHSIGN to use the ECDSA
and DH exchange messages. The ECDSA signature algorithm can be signature algorithm. Section 3 describes the extension of MIKEY-
applied to allow shorter and more-efficient signatures. DHSIGN to use ECDH groups. Section 4 describes the MIKEY-ECIES
method. Section 5 describes the MIKEY-ECMQV method. Section 6
describes additional payloads required to support these new methods.
ECDSA signatures are detailed in ANSI X9.62 [X9.62]. Curve selection The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
and other parameters will be defined by, and dependent on the "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
certificate used. document are to be interpreted as described in [RFC2119].
RFC3279 describes algorithms and identifiers for Internet X.509 2. MIKEY-DHSIGN with ECDSA
certificates and CRLs. It includes ECC algorithms and identifiers.
3. MIKEY-ECIES MIKEY-DHSIGN is described in Section 3.3 of [RFC3830]. The
Initiator's message includes SIGNi, a signature covering the
Initiator's message. As well, the Responder's message includes
SIGNr, a signature covering the Responder's message. According to
Section 4.2.6 of [RFC3830], the signature algorithm applied is
defined by, and dependent on the certificate used. It is MANDATORY
to support RSA PKCS#1, v1.5, and it is RECOMMENDED to support RSA
PSS. Instead of these signature algorithms, ECDSA can be used to
allow shorter and more efficient signatures.
MIKEY's public-key encryption method (MIKEY-RSA) uses public key ECDSA signatures are detailed in [ANSI-X9.62]. Curve selection and
methods securely to transmit keying material between communicating other parameters will be defined by, and dependent on the certificate
parties having previously acquired one another's public keys. The used. When generating signatures, the hash function that MUST be
Elliptic Curve Integrated Encryption Scheme (ECIES) specifies how used is SHA-1.
two communicating parties having previously acquired one another's
public keys--assuming these are EC public keys--may use these keys
to transmit encrypted and authenticated messages. This section
therefore proposes how ECIES may be used in MIKEY. We call this
scheme MIKEY-ECIES.
We propose that ECIES be used as follows: 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, S type | Value | Comments
is transmitted in an ECCPT payload (see section 5.1) -------------------------------------
preceding the KEMAC payload. ECDSA | 2 | ECDSA signature [ANSI_X9.62]
2. The ciphertext and message digest required under ECIES
are transmitted in the KEMAC payload, as in other forms
of the MIKEY protocol.
3. The encryption key and HMAC key in use in the KEMAC are those
extracted from the shared key derived using ECIES.
4. The PKE payload is not used.
Note that this differs from the 'envelope key' method used in the [RFC3279] describes algorithms and identifiers for Internet X.509
MIKEY-RSA form of the protocol. ECIES, however, uses a symmetric certificates and CRLs. It includes ECC algorithms and identifiers.
encapsulation algorithm, so encrypting an envelope key (to be
used with another symmetric method to decrypt the actual payload)
would be redundant.
Note also that the derived ECIES key can be used as an input for the To use the ECDSA signature algorithm with Elliptic Curve Diffie-
key generation algorithm described in section 4.1.4 of RFC 3830, in Hellman, this extension to MIKEY-DHSIGN may be combined with the
identical fashion as is the envelope key used in the MIKEY-RSA extension described in Section 3.
method.
A MIKEY-ECIES exchange 3. MIKEY-DHSIGN with ECDH
----------------------
Initiator Responder MIKEY-DHSIGN is described in Section 3.3 of [RFC3830]. According to
--------- --------- Section 4.2.7 of [RFC3830], the support for OAKLEY 5 is MANDATORY and
support for OAKLEY 1 and OAKLEY 2 is OPTIONAL. Instead of these
Diffie-Hellman (DH) groups, elliptic curve Diffie-Hellman (ECDH)
groups can significantly improve performance and security.
I_MESSAGE = The ECDH groups to be used by MIKEY are the groups recommended by
HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, NIST in FIPS 186-2 [FIPS-186-2]. Detailed descriptions of the ECDH
ECCPT, KEMAC, [CHASH], SIGNi ---> groups can be found in each of FIPS 186-2 [FIPS-186-2] and SEC 2
[SEC2]. The ECDH groups use elliptic curves over GF[2^N] with N
prime or over GF[P] with P prime. Eleven of the groups proposed here
have been assigned identifiers by IANA [IANA] and the remaining five
might later be assigned identifiers by IANA. The group with IANA
number 6 is described in [ANSI-X9.62] and [SEC2], with object
identifier sect163r1, but it is not one of the fifteen curves that
NIST recommends [FIPS-186-2]. The remaining NIST recommended groups
are suggested and anticipated to be assigned IANA numbers as
specified in Table 2.
R_MESSAGE = id Group Type Group Description NIST Name SEC 2 OID
-- ---------- ----------------- --------- ---------
[<---] HDR, T, [IDr], V 22 2 ECP ECPRGF192Random P-192 secp192r1
Note also that the derived key generated may also be cached for the 23 3 EC2N EC2NGF163Random B-163 sect163r2
lifetime of a CSB, at the direction of the Initiator, and used as a 7 3 EC2N EC2NGF163Koblitz K-163 sect163k1
preshared key, as described for the envelope key in RFC 3830, section 6 3 EC2N EC2NGF163Random2 none sect163r1
3.2.
ECIES options 24 2 ECP ECPRGF224Random P-224 secp224r1
------------- 25 3 EC2N EC2NGF233Random B-233 sect233r1
26 3 EC2N EC2NGF233Koblitz K-233 sect233k1
IEEE 1363A describes a number of options for ECIES. We recommend that 19 2 ECP ECPRGF256Random P-256 secp256r1
in MIKEY-ECIES, the following options be understood as given: 8 3 EC2N EC2NGF283Random B-283 sect283r1
9 3 EC2N EC2NGF283Koblitz K-283 sect283k1
-- the KDF in use for the generation of the ephemeral key pairs 20 2 ECP ECPRGF384Random P-384 secp384r1
shall be ECSVDP-DHC, without compatibility for the 10 3 EC2N EC2NGF409Random B-409 sect409r1
corresponding -DH primitive 11 3 EC2N EC2NGF409Koblitz K-409 sect409k1
-- DHAES mode shall not be used. 21 2 ECP ECPRGF521Random P-521 secp521r1
12 3 EC2N EC2NGF571Random B-571 sect571r1
13 3 EC2N EC2NGF571Koblitz K-571 sect571k1
4. Use of EC methods with Diffie-Hellman key exchange (MIKEY-DHSIGN) Table 2: Recommended Groups and Names
The MIKEY-DHSIGN key exchange method is described in Section 3.3 of The ECDH groups in Table 2 are arranged into 5 classes, corresponding
[MIKEY]. Section 4.2.7 of [MIKEY] specifies the use of OAKLEY group to approximately equivalent security strengths. To encourage
5 as mandatory and groups 1 and 2 as optional. However, interoperability, implementations that support one of these classes,
implementations have shown that users of elliptic curve groups can SHOULD support the one group in that class that is defined over a
significantly improve performance and security by using groups other prime field (which will be one of P-192, P-224, P-256, P-384, or
than the Oakley Groups 1, 2, or 5. P-521). Implementations SHOULD support one of P-256 or P-384.
Implementations MAY support any set of groups.
The DH data payload specified in Section 6.4 of [MIKEY] can be used The DH data payload (DH) specified in Section 6.4 of [RFC3830] can be
without modification. The data in the KEMAC payload when using used without modification. Additional DH-Group identifiers are
these groups is the octet string representation specified in ANSI required as follows:
X9.62 [X9.62], ANSI X9.63 [X9.63], FIPS 186-2 [FIPS 186-2], and
IEEE P1363 of the point on the curve chosen by taking the randomly
chosen secret Ka and computing Ka*P, where * is the repetition of the
group addition and double operations.
An updated DH-Group table (as shown in Section 6.4 of [MIKEY]) will DH-Group | Value
be specified upon assignment of IANA numbers for the groups described --------------------------------------|-------
in section 8. See also the section "IANA considerations" in this ECPRGF192Random / P-192 / secp192r1 | 3
document. 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
5. Using ECMQV in MIKEY (MIKEY-MQV) When using the ECDH groups, the DH-value in the DH data payload (DH)
is the octet string representation specified in ANSI X9.62
[ANSI-X9.62] and [SEC1].
MQV is a protocol primitive equivalent to simultaneous Diffie-Hellman To use ECDH and ECDSA signature algorithm, this extension to MIKEY-
key exchange and digital signature authentication, achievable in a DHSIGN may be combined with the extension described in Section 2.
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 4. MIKEY-ECIES
protocol that has been standardized in ANSI X9.63. Both modes of
ECMQV provide mutual authentication between the communicating parties
and key establishment for the secure transport of data; the 1-pass
version is thus particularly attractive for MIKEY, as an alternative
method of establishing a secure channel for the transport of the TGK.
In this draft, we propose a fourth mode in MIKEY, called MIKEY-MQV,
in which ECMQV is used in this fashion.
A MIKEY-MQV exchange proceeds in similar fashion to the MIKEY-RSA The Elliptic Curve Integrated Encryption Scheme (ECIES) is a public-
exchange; the PKE is absent, and an ECCPT payload (see section 5.1) key encryption scheme based on ECC. Section 3.2 of [RFC3830] already
MUST precede the KEMAC payload in the intiator's first message: specifies a public-key encryption method (MIKEY-RSA). Here we
describe the new MIKEY-ECIES method.
Initiator Responder Initiator Responder
--------- ---------
I_MESSAGE = I_MESSAGE =
HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, HDR, T, RAND, [IDi|CERTi], [IDr], {SP},
ECCPT, KEMAC, [CHASH], SIGNi ---> 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 = R_MESSAGE =
[<---] HDR, T, [IDr], V [<---] HDR, T, [IDr], V
The ECCPT payload carries Q_(e,I) as per the nomenclature of ANSI As with the MIKEY-RSA case, the main objective of the Initiator's
X9.63 -- the ephemeral public key contributed by the initiator. message is to transport one or more TGKs and a set of security
parameters to the Responder in a secure manner.
The encr_key and auth_key used in forming the KEMAC are the
encryption and authentication keys extracted from the derived key
arrived at via MQV.
1-pass ECMQV algorithm steps
----------------------------
1-pass ECMQV is described in detail in ANSI X9.63-2001; for a
detailed specification for implementation purposes, see that
document. The following discussion is provided here for information
purposes only, to clarify the mechanism, and to ease mapping it to
the protocol components in this draft proposal.
Note that 1-pass MQV differs from 3-pass MQV in that only three
key pairs are used as inputs: the initiator's public, private key
pair, the respondent's public, private key pair, and the ephemeral
public, private key pair contributed by the initiator. The
respondent's public, private key pair is used twice--effectively
replacing the ephemeral key pair contributed by the respondent in
the 3-pass method.
Initiator transformation
------------------------
1. Initiator selects an ephemeral private key k_A from the With MIKEY-RSA, the TGKs are encrypted with an "envelope key".
set {1..n-1}, where n is the order of the base point P However, ECIES uses a symmetric encapsulation algorithm, so
for the curve in use. Initiator computes the corresponding encrypting an envelope key (to be used with another symmetric method
ephemeral public key R_A = (k_A)P, and sends R_A to the to decrypt the actual payload) would be redundant. As a result, the
respondent. The ephemeral public key R_A derived is the PKE payload is not used.
value Q_(e,I) in the protocol described above. The
selection of k_A and the generation of R_A from it are
covered in detail in X9.63-2001 section 5.2.1--Key Pair
Generation Primitive.
2. Initiator calculates the shared secret value z as follows
(see X9.63-2001 section 5.5)--
2a. Initiator uses their own private and public key,
and the ephemeral private and public key they
generated in step 1 as inputs (d_1, Q_1) and
(d_2, Q_2) respectively.
2b. Initiator uses the respondent's public key for
the values Q_3 and Q_4.
2c. Using the associate value function avf (see
X9.63-2001 section 5.6.1), and the values d_1,
d_2 and Q_2 as above (their own private key, and
the ephemeral key pair private and public values),
the Initiator calculates the implicit signature
S_i = d_2 + (avf(Q_2) x d_1) mod n.
2d. Using the associate value function avf, the
signature just calculated, the system cofactor h,
and the respondent's public key, the Initiator
finds the EC point
P = h x S_i x (Q_4 + (avf(Q_4) x Q_3)).
2e. Initiator verifies that P != 0.
2f. Initiator sets z = x_P, where x_P is the
x-coordinate of P.
3. Initiator converts z to bit string Z, using the convention
specified in X9.63-2001 section 4.3.3.
4. Initiator uses the key derivation function described in
X9.63-2001 section 5.6.3 with the hash function given in
table MQV_PARAMS to derive the keying data; the length of
the key to be generated is also given in MQV_PARAMS.
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 As in MIKEY-RSA, the KEMAC contains a set of encrypted sub-payloads
transformation, except that the respondent does not generate an and a MAC:
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 KEMAC = E(encr_key, IDi || {TGK}) || MAC
domain parameters (see X9.63-2001 section 5.2.2).
2. Respondent calculates the shared secret value z as follows
(see X9.63-2001 section 5.5)--
2a. Respondent uses their own private and public key in
step 1 as inputs for both (d_1, Q_1) and (d_2, Q_2).
2b. Respondent uses the initiator's public key for the
value Q_3, and the initiator's ephemeral public key
for the value Q_4.
2c. Using the associate value function avf (see X9.63-2001
section 5.6.1), and the values d_1, d_2 and Q_2 as
above (their own private key is both d_1 and d_2,
while Q_2 is their public key), the Respondent
calculates the implicit signature
S_r = d_2 + (avf(Q_2) x d_1) mod n.
2d. Using the associate value function avf, the signature
just calculated, the system cofactor h, the respondent's
public key, and the respondent's ephemeral public key,
the Respondent finds the EC point
P = h x S_r x (Q_4 + (avf(Q_4) x Q_3)).
2e. Respondent verifies that P != 0.
2f. Respondent sets z = x_P, where x_P is the x-coordinate
of P.
3. Respondent converts z to bit string Z, using the convention
specified in X9.63-2001 section 4.3.3.
4. Respondent uses the key derivation function described in
X9.63-2001 section 5.6.3 with the hash function given in table
MQV_PARAMS to derive the keying data; the length of the key to
be generated is also given in MQV_PARAMS.
6. Additional MIKEY payloads The encr_key and auth_key are derived from the ECIES-derived key by
using the algorithm described in Section 4.1.4 of [RFC3830], in
identical fashion as the envelope key used in the MIKEY-RSA.
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 As in MIKEY-RSA, it is possible to cache the ECIES-derived key, so
MIKEY-MQV and in the MIKEY-RSA exchange when ECIES is in use. It is that it can be used as a pre-shared key.
of the form:
1 2 3 ECIES is described in detail in [SEC1]. For ECIES, the key
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 derivation function that MUST be used is ANSI-X9.63-KDF as described
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ in [SEC1]. As well, the MAC scheme that MUST be used is HMAC-SHA-1-
! Next payload ! Point length ! Pt data ... ! 160. The 'standard' elliptic curve Diffie-Hellman primitive MUST be
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ used (as opposed to 'cofactor'). The symmetric encryption scheme
~ Point data ~ 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 | 3DES-CBC
283 | 256 | AES-128-CBC
409 | 384 | AES-256-CBC
571 | 521 | AES-256-CBC
The point_data field is padded to end on a 32-bit boundary, and is Table 3: Symmetric cipher to use with ECIES
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 5. MIKEY-ECMQV
Both MQV and ECDSA/ECIES may be used in multicast environments to ECMQV (Elliptic Curve Menezes-Qu-Vanstone) is a 3-pass or 1-pass
establish a group TEK, in the same fashion as MIKEY-RSA. protocol that has been standardized in ANSI X9.63 [ANSI-X9.63]. Both
modes of ECMQV provide mutual authentication between the
communicating parties and key establishment for the secure transport
of data. Here we describe the new MIKEY-ECMQV method based on the
1-pass protocol.
8. Recommended and optional domain parameter sets Initiator Responder
8.1 Available domain parameter sets I_MESSAGE =
HDR, T, RAND, [IDi|CERTi], [IDr], {SP},
ECCPT, KEMAC, [CHASH], SIGNi --->
Elliptic curve domain parameter sets available for use in this R_MESSAGE =
protocol for all methods employing EC primitives--and given here-- [<---] HDR, T, [IDr], V
are the fifteen groups that NIST recommends in FIPS 186-2
[FIPS-186-2]. Detailed descriptions of the ECC groups recommended
here for MIKEY are not given in this document but can be found
elsewhere: All fifteen groups are detailed in each of FIPS 186-2
[FIPS-186-2] and SEC 2 [SEC-2]. The elliptic curve domain parameters
are uniquely identified in this document using the ASN.1 object
identifiers provided in ANSI X9.63 [X9.63], which are also given in
SEC2 [SEC-2].
The fifteen groups proposed in this document use elliptic curves over The ECCPT contains the elliptic curve point that represents the
GF[2^N] with N prime or over GF[P] with P prime. Six of the groups ephemeral public key contributed by the Initiator.
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.
IANA Group Descriptions X9.63 (and SEC 2) OID As in MIKEY-RSA, the KEMAC contains a set of encrypted sub-payloads
---- ----------------------------- --------------------- and a MAC:
NA ECPRGF192Random group P-192 secp192r1 KEMAC = E(encr_key, IDi || {TGK}) || MAC
NA EC2NGF163Random group B-163 sect163r2
7 EC2NGF163Koblitz group K-163 sect163k1
NA ECPRGF224Random group P-224 secp224r1 The encr_key and auth_key are derived from the ECMQV-derived key by
NA EC2NGF233Random group B-233 sect233r1 using the algorithm described in Section 4.1.4 of [RFC3830], in
NA EC2NGF233Koblitz group K-233 sect233k1 identical fashion as the envelope key used in the MIKEY-RSA.
NA ECPRGF256Random group P-256 secp256r1 1-pass ECMQV is described in detail in ANSI X9.63 [ANSI-X9.63].
8 EC2NGF283Random group B-283 sect283r1
9 EC2NGF283Koblitz group K-283 sect283k1
NA ECPRGF384Random group P-384 secp384r1 6. Additional Payload Encoding
10 EC2NGF409Random group B-409 sect409r1
11 EC2NGF409Koblitz group K-409 sect409k1
NA ECPRGF521Random group P-521 secp521r1 6.1. ECC Point payload (ECCPT)
12 EC2NGF571Random group B-571 sect571r1
13 EC2NGF571Koblitz group K-571 sect571k1
Three curves are defined at each strength - two curves chosen The ECCPT payload carries a point on the elliptic curve used in
verifiably at random (as defined in ANSI [X9.62]), one over a MIKEY-ECIES and MIKEY-ECMQV. The payload identifier is 22.
binary field and another over a prime field, and a Koblitz curve
over a binary field that, which enables especially efficient
implementations due to the special structure of the curve [Kob, NSA].
Note that the large number of proposed curves is for two reasons: 1 2 3
Flexibility in implementation in using groups over prime fields 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
(GF[p]) or binary fields (GF[2^N]), which have different +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
characteristics; and to provide higher security strength capabilities ! Next payload ! Point length ! Pt data ... ~
for military-grade or future uses. In ECDH, The 163-bit and 192-bit +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
curves provide equivalent security strength to Oakley group 2; all ~ Point data ~
other proposed curves offer significantly higher security strength +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
equivalents than the three Diffie-Hellman groups included in [MIKEY].
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 * Point length (16 bits): length of the Point data field (in *bits*).
implementations except those in highly constrained environments
support use of the P-256 curve.
It is RECOMMENDED that implementations in constrained environments * Point data (variable length): point data, padded to end on a 32-bit
support the K163 curve. boundary, encoded in octet string representation specified in
ANSI X9.62 [ANSI-X9.62] and [SEC1]. Uncompressed format MUST be
supported. Hybrid and compressed formats MAY be supported.
9. Security Considerations 7. Security Considerations
Since this document proposes new methods for use within MIKEY, many Since this document proposes new methods for use within MIKEY, many
of the security considerations contained within RFC 3830 apply here of the security considerations contained within [RFC3830] apply here
as well. as well. Some of the methods proposed in this document offer higher
cryptographic strength than those proposed in [RFC3830]. In
Some of the methods proposed in this document offer higher particular, there are elliptic curves corresponding to each of the
cryptographic strength than those proposed in RFC 3830. In symmetric key sizes 80 bits, 128 bits, 192 bits, and 256 bits. This
particular, there are elliptic curves corresponding to each of allows the MIKEY key exchange to offer security comparable with
the symmetric key sizes 80 bits, 128 bits, 192 bits, and 256 bits. higher-strength AES algorithms and SHA implementations. The methods
This allows the MIKEY key exchange to offer security comparable proposed in this document are among those standardized by NIST in
with higher-strength AES algorithms and SHA implementations. FIPS 186-2 [FIPS-186-2], by the SECG in SEC2 [SEC2], and by ANSI in
ANSI X9.62 [ANSI-X9.62] and X9.63 [ANSI-X9.63].
The methods proposed in this document are among those standardized
by NIST in FIPS 186-2 [DSS], by the SECG in SEC2 [SEC2], and by ANSI
in ANSI X9.62 [X9.62] and X9.63 [X9.63].
Proper validation of elliptic curve public keys can help prevent the
attacks described in [BMM].
10. IANA Considerations
This specification requires additional parameter sets be defined for
use in MIKEY when elliptic curve cryptographic methods are used.
These are listed in section 8.1.
It is requested that these be added to the namespace for the 8. IANA Considerations
DH-Group field in table 6.4 of RFC 3830, which that document requests
shall be managed by the IANA.
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 9. References
Numbers.
(http://www.isi.edu/in-notes/iana/assignments/ipsec-registry)
[IEEE 1363A-2004] Institute of Electrical and Electronics Engineers, 9.1. Normative References
IEEE P1363a, Draft Standard Specifications for Public Key
Cryptography - Amendment 1: Additional Techniques.
[KOB] N. Koblitz, CM curves with good cryptographic properties. [ANSI-X9.62]
Proceedings of Crypto '91. Pages 279-287. Springer-Verlag, 1992. American National Standards Institute, "ANSI X9.62: Public
Key Cryptography For The Financial Services Industry: The
Elliptic Curve Digital Signature Algorithm (ECDSA)", 2005.
[FIPS-186-2] U.S. Department of Commerce/National Institute of [ANSI-X9.63]
Standards and Technology. Digital Signature Standard (DSS), FIPS American National Standards Institute, "ANSI X9.63: Public
PUB 186-2, January 2000. Key Cryptography For The Financial Services Industry: Key
(http://csrc.nist.gov/fips/fips186-2.pdf) Agreement and Key Transport using Elliptic Curve
Cryptography", 2001.
[HOF] P. Hoffman and H. Orman, Determining strengths for public keys [FIPS-186-2]
used for exchanging symmetric keys, Internet-draft. August 2000. National Institute of Standards and Technology, "FIPS
186-2 Digital Signature Standard", 2000.
[LEN] A. Lenstra and E. Verhuel, Selecting cryptographic key sizes. [IANA] Internet Assigned Numbers Authority, "Attribute Assigned
Available at: www.cryptosavvy.com. Numbers.", <http://www.isi.edu/in-notes/iana/assignments/
ipsec-registry>.
[MIKEY] [RFC-3830] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
K. Norrman, MIKEY: Multimedia Internet KEYing, RFC 3830, August Identifiers for the Internet X.509 Public Key
2004. Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, April 2002.
[NSA] J. Solinas, An improved algorithm for arithmetic on a family [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
of elliptic curves, Proceedings of Crypto '97, Pages 357-371, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
Springer-Verlag, 1997. August 2004.
[RFC-3278] S. Blake-Wilson, D. Brown and P. Lambert, The Use of [SEC1] Standards for Efficient Crytopgraphy Group, "Elliptic
Elliptic Curve Cryptography (ECC) Algorithms in the Cryptographic Curve Cryptography", September 2000.
Message Syntax (CMS), RFC 3279, April 2002.
[RFC-3279] W. Polk, R. Housley, and L. Bassham, Algorithms and [SEC2] Standards for Efficient Crytopgraphy Group, "Recommended
Identifiers for the Internet X.509 Public Key Infrastructure Elliptic Curve Domain Parameters", September 2000.
Certificate and Certificate Revocation List (CRL) Profile, RFC
3279, April 2002.
[SEC2] Standards for Efficient Cryptography Group. SEC 2 - 9.2. Informative References
Recommended Elliptic Curve Domain Parameters. Working Draft
Ver. 1.0., 2000. (http://www.secg.org)
[X9.62] American National Standards Institute, ANSI X9.62-1998: [HOF] Hoffman, P. and H. Orman, "Determining strengths for
Public Key Cryptography for the Financial Services Industry: The public keys used for exchanging symmetric keys",
Elliptic Curve Digital Signature Algorithm. January 1999. August 2000.
[X9.63] American National Standards Institute. ANSI X9.63-2001, [LEN] Lenstra, A. and E. Verhuel, "Selecting cryptographic key
Public Key Cryptography for the Financial Services Industry: Key sizes", <http://www.cryptosavvy.com>.
Agreement and Key Transport using Elliptic Curve Cryptography.
November 2001.
[HANKERSON] Hankerson, Darrel et al. "Guide to Elliptic Curve [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Cryptography". Springer-Verlag, 2004. Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses Authors' Addresses
Andrew Milne Andrew Milne
Certicom Corp.
amilne@certicom.com
Mitch Blaser Mitch Blaser
Certicom Corp. Certicom Corp.
mblaser@certicom.com 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 Daniel R. L. Brown
Certicom Corp. Certicom Corp.
dbrown@certicom.com 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 Lakshminath Dondeti
Qualcomm, Inc. QUALCOMM, Inc.
ldondeti@qualcomm.com 5775 Morehouse Drive
San Diego, CA
USA
Expiry reminder Phone: +1-858-845-1267
Email: ldondeti@qualcomm.com
This draft expires December 1, 2005. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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).
 End of changes. 100 change blocks. 
438 lines changed or deleted 336 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/