Network Working Group D. Brown
Internet-Draft E. Chin
Intended status: Standards Track C. Tse
Expires: December 13, 2007 Certicom Corp.
June 11, 2007
ECC Algorithms for MIKEYdraft-ietf-msec-mikey-ecc-03
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 13, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Brown, et al. Expires December 13, 2007 [Page 1]

Internet-Draft ECC Algorithms for MIKEY June 20071. Introduction
This document describes additional algorithms for use in MIKEY. The
document assumes that the reader is familiar with the MIKEY protocol.
The MIKEY protocol [RFC3830] defines three methods for transporting
or establishing keys: with the use of a pre-shared key, public-key
encryption (MIKEY-RSA), and Diffie-Hellman (DH) key exchange (MIKEY-
DHSIGN). This document extends MIKEY-DHSIGN to use Elliptic Curve
Digital Signature Algorithm (ECDSA) or Elliptic Curve German Digital
Signature Algorithm (ECGDSA) as the signature algorithm and further
extends MIKEY-DHSIGN to use Elliptic Curve Diffie-Hellman (ECDH)
groups. In addition, this document introduces two new methods based
on the the Elliptic Curve Integrated Encryption Scheme (ECIES) and
Elliptic Curve Menezes-Qu-Vanstone (ECMQV). The ECIES method (MIKEY-
ECIES) is similar to MIKEY-RSA method, and the ECMQV method (MIKEY-
ECMQV) is similar to MIKEY-DHSIGN method.
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 | 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 192-bit symmetric key, it is
prudent to use either 409-bit ECC2N, 384-bit ECP, or 7680-bit DH/DSA/
RSA. With smaller key sizes the symmetric keys would be
underprotected.
Section 2 describes the extension of MIKEY-DHSIGN to use the ECDSA or
ECGDSA signature algorithm. Section 3 describes the extension of
MIKEY-DHSIGN to use ECDH groups. Section 4 describes the MIKEY-ECIES
Brown, et al. Expires December 13, 2007 [Page 3]

Internet-Draft ECC Algorithms for MIKEY June 20072. MIKEY-DHSIGN with ECDSA or ECGDSA
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 or ECGDSA may be
used to allow shorter and more efficient signatures.
ECDSA signatures are detailed in [ANSI-X9.62] and ECGDSA signatures
are detailed in [ISO-IEC-15946-2]. 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
depends on the key size, as follows:
ECC2N | ECP | Hash To Use
163 | 192 | SHA-1
233 | 224 | SHA-224
283 | 256 | SHA-256
409 | 384 | SHA-384
571 | 521 | SHA-512
Table 2: Hash to use with ECDSA and ECGDSA
The signature payload (SIGN) specified in Section 6.5 of [RFC3830]
can be used without modification. Two additional S types for ECDSA
and ECGDSA are defined as follows:
S type | Value | Comments
-------------------------------------
ECDSA | 2 | ECDSA signature [ANSI_X9.62]
ECGDSA | 3 | ECGDSA signature [ISO/IEC_15946-2]
[RFC3279] describes algorithms and identifiers for Internet X.509
certificates and CRLs. It includes ECC algorithms and identifiers.
To use the ECDSA or ECGDSA signature algorithm with Elliptic Curve
Diffie-Hellman, this extension to MIKEY-DHSIGN may be combined with
the extension described in Section 3.
Brown, et al. Expires December 13, 2007 [Page 5]

Internet-Draft ECC Algorithms for MIKEY June 20074. MIKEY-ECIES
The Elliptic Curve Integrated Encryption Scheme (ECIES) is a public-
key encryption scheme based on ECC. Section 3.2 of [RFC3830] already
specifies a public-key encryption method (MIKEY-RSA). Here we
describe the new MIKEY-ECIES method.
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi], [IDr], {SP},
KEMAC, [CHASH], PKE, SIGNi --->
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. In general, the
MIKEY-ECIES and MIKEY-RSA methods are exactly the same, except that
the supported signature algorithm and the public key encryption
algorithm are different.
The signature algorithm applied is defined by, and dependent on the
certificate used. The MIKEY-ECIES method supports ECDSA as described
in [ANSI-X9.62] and ECGDSA as described in [ISO-IEC-15946-2]. The
SIGNi will use either ECDSA or ECGDSA as a signature algorithm, as
described in Section 2.
The public key encryption algorithm applied is defined by, and
dependent on the certificate used. The MIKEY-ECIES method supports
ECIES as described in detail in [SEC1]. For ECIES, the key
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-
160. The 'standard' elliptic curve Diffie-Hellman primitive MUST be
used (as opposed to 'cofactor'). The symmetric encryption scheme
that MUST be used depends on the key size, as follows:
ECC2N | ECP | Symmetric Cipher To Use
163 | 192 | 3DES-CBC
233 | 224 | AES-128-CBC
283 | 256 | AES-128-CBC
409 | 384 | AES-256-CBC
571 | 521 | AES-256-CBC
Table 4: Symmetric cipher to use with ECIES
Brown, et al. Expires December 13, 2007 [Page 8]

Internet-Draft ECC Algorithms for MIKEY June 20075. MIKEY-ECMQV
ECMQV (Elliptic Curve Menezes-Qu-Vanstone) is defined in ANSI X9.63
[ANSI-X9.63]. ECMQV provides 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
2-pass protocol.
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi], [IDr],
{SP}, ECCPTi, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr|CERTr],
IDi, ECCPTr, ECCPTi, V
The MIKEY-ECMQV method is similar to the MIKEY-DHSIGN method, except
that with MIKEY-ECMQV, a variable-length shared secret is created
using ECMQV instead of a fixed-length shared secret. Same as the
MIKEY-DHSIGN method, this method cannot be used to create group keys;
it can only be used to create single peer-to-peer keys.
The MIKEY-ECMQV method create a variable-length shared secret. From
this shared secret, the TGK and the auth_key for the Responder's
verification message are derived. The first portion of the shared
secret is the TGK, and the second portion of the shared secret is the
auth_key. The length of TGK is specified in ECCPT payload by the
Initiator. The length of auth_key is derived from the authentication
algorithm, which is also specified in ECCPT payload by the Initiator.
The main objective of the Initiator's message is to provide the
Responder with its ephemeral public key represented by the elliptic
curve point (ECCPTi), and a set of security protocol parameters.
These parameters include the authentication algorithm for the
Responder's verification message, the length of TGK, and the key
validity information.
The SIGNi is a signature covering the Initiator's message using the
Initiator's signature key from the Initiator's certificate. The
signature algorithm applied is defined by, and dependent on the
certificate used. The MIKEY-ECMQV method supports ECDSA as described
in [ANSI-X9.62] and ECGDSA as described in [ISO-IEC-15946-2]. The
SIGNi will use either ECDSA or ECGDSA as a signature algorithm, as
described in Section 2.
The main objective of the Responder's message is to provide the
Brown, et al. Expires December 13, 2007 [Page 9]

Internet-Draft ECC Algorithms for MIKEY June 2007
Initiator with its ephemeral public key represented by the elliptic
curve point (ECCPTr). The set of security protocol parameters are
the same as the one in the Initiator's message.
If the Initiator's message is authenticated and accepted by the
Responder, and the ECMQV shared secret is created successfully, then
the verification message (V) is created using the auth_key. V is
calculated in the same way as in the MIKEY-PSA method (see Section5.2 of [RFC3830]).
If the Responder does not support the set of parameters suggested by
the Initiator, the error message SHOULD include the supported
parameters (see Section 5.1.1 of [ANSI-X9.63]).
The error message is formed as:
HDR, T, {ERR}, {SP}, [SIGNr]
In case of error, the ECMQV shared secret should not be computed.
Without the shared secret, V cannot be generated. As a result, the
error message should include a SIGNr instead of V, in the cases when
the Responder is able to authenticate the Initiator's message.
The SIGNr is a signature covering the Responder's error message using
the Responder's signature key from the Responder's certificate. The
signature algorithm applied is defined by, and dependent on the
certificate used. The MIKEY-ECMQV method support ECDSA as described
in [ANSI-X9.62] and ECGDSA as described in [ISO-IEC-15946-2]. The
SIGNi will use either ECDSA or ECGDSA as a signature algorithm, as
described in Section 2.
2-pass ECMQV is described in detail in ANSI X9.63 [ANSI-X9.63].
Brown, et al. Expires December 13, 2007 [Page 10]

Internet-Draft ECC Algorithms for MIKEY June 2007
values.
* TGK len (16 bits): the length of the TGK (in bytes).
* KV (4 bits): indicates the type of key validity period specified.
This may be done by using an SPI (alternatively an MKI in SRTP) or
by providing an interval in which the key is valid (e.g., in the
latter case, for SRTP this will be the index range where the key
is valid). See Section 6.13 of [RFC3830] for pre-defined values.
* KV data (variable length): This includes either the SPI/MKI or an
interval (see Section 6.14 of [RFC3830]). If KV is NULL, this
field is not included.
Brown, et al. Expires December 13, 2007 [Page 12]

Internet-Draft ECC Algorithms for MIKEY June 20077. Security Considerations
Since this document proposes new methods for use within MIKEY, many
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
higher-strength AES algorithms and SHA implementations. The methods
proposed in this document are among those standardized by NIST in
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].
Brown, et al. Expires December 13, 2007 [Page 13]

Internet-Draft ECC Algorithms for MIKEY June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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).
Brown, et al. Expires December 13, 2007 [Page 18]