Network Working Group A. Milne
InternetDraft
Intended status: Standards Track M. Blaser
Expires: April 23, 2007 D. Brown
E. Chin
Certicom Corp.
L. Dondeti
QUALCOMM, Inc.
October 20, 2006
ECC Algorithms for MIKEY
draftietfmsecmikeyecc01
Status of this Memo
By submitting this InternetDraft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet
Drafts.
InternetDrafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use InternetDrafts as reference
material or to cite them other than as "work in progress."
The list of current InternetDrafts can be accessed at
http://www.ietf.org/ietf/1idabstracts.txt.
The list of InternetDraft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This InternetDraft will expire on April 23, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Milne, et al. Expires April 23, 2007 [Page 1]
InternetDraft ECC Algorithms for MIKEY October 2006
Abstract
This document proposes extensions to the authentication, encryption
and digital signature methods described for use in MIKEY, employing
ellipticcurve cryptography (ECC). These extensions are defined to
align MIKEY with other ECC implementations and standards.
It should be noted that this document is not selfcontained; it uses
the notations and definitions of [RFC3830].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. MIKEYDHSIGN with ECDSA . . . . . . . . . . . . . . . . . . . 5
3. MIKEYDHSIGN with ECDH . . . . . . . . . . . . . . . . . . . . 6
4. MIKEYECIES . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. MIKEYECMQV . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Additional Payload Encoding . . . . . . . . . . . . . . . . . 11
6.1. ECC Point payload (ECCPT) . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Milne, et al. Expires April 23, 2007 [Page 2]
InternetDraft ECC Algorithms for MIKEY October 2006
1. 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 preshared key, publickey
encryption (MIKEYRSA), and DiffieHellman (DH) key exchange (MIKEY
DHSIGN). This document extends MIKEYDHSIGN to use ECDSA as the
signature algorithm and further extends MIKEYDHSIGN to use Elliptic
Curve DiffieHellman (ECDH) groups. In addition, this document
introduces two new methods based on the elliptic curve algorithms
ECIES and ECMQV in exchanges similar to those of MIKEYRSA, and name
these methods MIKEYECIES and MIKEYECMQV respectively.
Implementations have shown that elliptic curve algorithms can
significantly improve performance and securityperbit over other
recommended algorithms. The purpose of this document is to expand
the options available to implementers of MIKEY to take advantage of
these benefits.
In addition, elliptic curve algorithms are capable of providing
security consistent with AES keys of 128, 192, and 256 bits without
extensive growth in asymmetric key sizes. The following table, taken
from [HOF] and [LEN], gives approximate comparable key sizes for
symmetric systems, ECC systems, and DH/DSA/RSA systems. The
estimates are based on the running times of the best algorithms known
today.
Symmetric  ECC2N  ECP  DH/DSA/RSA
80  163  192  1024
128  283  256  3072
192  409  384  7680
256  571  521  15360
Table 1: Comparable key sizes
Thus, for example, when securing a 192bit symmetric key, it is
prudent to use either 409bit ECC2N, 384bit ECP, or 7680bit DH/DSA/
RSA. With smaller key sizes the symmetric keys would be
underprotected.
Section 2 describes the extension of MIKEYDHSIGN to use the ECDSA
signature algorithm. Section 3 describes the extension of MIKEY
DHSIGN to use ECDH groups. Section 4 describes the MIKEYECIES
method. Section 5 describes the MIKEYECMQV method. Section 6
describes additional payloads required to support these new methods.
Milne, et al. Expires April 23, 2007 [Page 3]
InternetDraft ECC Algorithms for MIKEY October 2006
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Milne, et al. Expires April 23, 2007 [Page 4]
InternetDraft ECC Algorithms for MIKEY October 2006
2. MIKEYDHSIGN with ECDSA
MIKEYDHSIGN is described in Section 3.3 of [RFC3830]. The
Initiator's message includes SIGNi, a signature covering the
Initiator's message. As well, the Responder's message includes
SIGNr, a signature covering the Responder's message. According to
Section 4.2.6 of [RFC3830], the signature algorithm applied is
defined by, and dependent on the certificate used. It is MANDATORY
to support RSA PKCS#1, v1.5, and it is RECOMMENDED to support RSA
PSS. Instead of these signature algorithms, ECDSA can be used to
allow shorter and more efficient signatures.
ECDSA signatures are detailed in [ANSIX9.62]. Curve selection and
other parameters will be defined by, and dependent on the certificate
used. When generating signatures, the hash function that MUST be
used is SHA1.
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.
To use the ECDSA signature algorithm with Elliptic Curve Diffie
Hellman, this extension to MIKEYDHSIGN may be combined with the
extension described in Section 3.
Milne, et al. Expires April 23, 2007 [Page 5]
InternetDraft ECC Algorithms for MIKEY October 2006
3. MIKEYDHSIGN with ECDH
MIKEYDHSIGN is described in Section 3.3 of [RFC3830]. According to
Section 4.2.7 of [RFC3830], the support for OAKLEY 5 is MANDATORY and
support for OAKLEY 1 and OAKLEY 2 is OPTIONAL. Instead of these
DiffieHellman (DH) groups, elliptic curve DiffieHellman (ECDH)
groups can significantly improve performance and security.
The ECDH groups to be used by MIKEY are the groups recommended by
NIST in FIPS 1862 [FIPS1862]. Detailed descriptions of the ECDH
groups can be found in each of FIPS 1862 [FIPS1862] and SEC 2
[SEC2]. The ECDH groups use elliptic curves over GF[2^N] with N
prime or over GF[P] with P prime. Eleven of the groups proposed here
have been assigned identifiers by IANA [IANA] and the remaining five
might later be assigned identifiers by IANA. The group with IANA
number 6 is described in [ANSIX9.62] and [SEC2], with object
identifier sect163r1, but it is not one of the fifteen curves that
NIST recommends [FIPS1862]. The remaining NIST recommended groups
are suggested and anticipated to be assigned IANA numbers as
specified in Table 2.
id Group Type Group Description NIST Name SEC 2 OID
    
22 2 ECP ECPRGF192Random P192 secp192r1
23 3 EC2N EC2NGF163Random B163 sect163r2
7 3 EC2N EC2NGF163Koblitz K163 sect163k1
6 3 EC2N EC2NGF163Random2 none sect163r1
24 2 ECP ECPRGF224Random P224 secp224r1
25 3 EC2N EC2NGF233Random B233 sect233r1
26 3 EC2N EC2NGF233Koblitz K233 sect233k1
19 2 ECP ECPRGF256Random P256 secp256r1
8 3 EC2N EC2NGF283Random B283 sect283r1
9 3 EC2N EC2NGF283Koblitz K283 sect283k1
20 2 ECP ECPRGF384Random P384 secp384r1
10 3 EC2N EC2NGF409Random B409 sect409r1
11 3 EC2N EC2NGF409Koblitz K409 sect409k1
21 2 ECP ECPRGF521Random P521 secp521r1
12 3 EC2N EC2NGF571Random B571 sect571r1
13 3 EC2N EC2NGF571Koblitz K571 sect571k1
Table 2: Recommended Groups and Names
The ECDH groups in Table 2 are arranged into 5 classes, corresponding
Milne, et al. Expires April 23, 2007 [Page 6]
InternetDraft ECC Algorithms for MIKEY October 2006
to approximately equivalent security strengths. To encourage
interoperability, implementations that support one of these classes,
SHOULD support the one group in that class that is defined over a
prime field (which will be one of P192, P224, P256, P384, or
P521). Implementations SHOULD support one of P256 or P384.
Implementations MAY support any set of groups.
The DH data payload (DH) specified in Section 6.4 of [RFC3830] can be
used without modification. Additional DHGroup identifiers are
required as follows:
DHGroup  Value

ECPRGF192Random / P192 / secp192r1  3
EC2NGF163Random / B163 / sect163r2  4
EC2NGF163Koblitz / K163 / sect163k1  5
EC2NGF163Random2 / none / sect163r1  6

ECPRGF224Random / P224 / secp224r1  7
EC2NGF233Random / B233 / sect233r1  8
EC2NGF233Koblitz / K233 / sect233k1  9

ECPRGF256Random / P256 / secp256r1  10
EC2NGF283Random / B283 / sect283r1  11
EC2NGF283Koblitz / K283 / sect283k1  12

ECPRGF384Random / P384 / secp384r1  13
EC2NGF409Random / B409 / sect409r1  14
EC2NGF409Koblitz / K409 / sect409k1  15

ECPRGF521Random / P521 / secp521r1  16
EC2NGF571Random / B571 / sect571r1  17
EC2NGF571Koblitz / K571 / sect571k1  18
When using the ECDH groups, the DHvalue in the DH data payload (DH)
is the octet string representation specified in ANSI X9.62
[ANSIX9.62] and [SEC1].
To use ECDH and ECDSA signature algorithm, this extension to MIKEY
DHSIGN may be combined with the extension described in Section 2.
Milne, et al. Expires April 23, 2007 [Page 7]
InternetDraft ECC Algorithms for MIKEY October 2006
4. MIKEYECIES
The Elliptic Curve Integrated Encryption Scheme (ECIES) is a public
key encryption scheme based on ECC. Section 3.2 of [RFC3830] already
specifies a publickey encryption method (MIKEYRSA). Here we
describe the new MIKEYECIES method.
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDiCERTi], [IDr], {SP},
ECCPT, KEMAC, [CHASH], SIGNi >
R_MESSAGE =
[<] HDR, T, [IDr], V
As with the MIKEYRSA case, the main objective of the Initiator's
message is to transport one or more TGKs and a set of security
parameters to the Responder in a secure manner.
With MIKEYRSA, the TGKs are encrypted with an "envelope key".
However, ECIES uses a symmetric encapsulation algorithm, so
encrypting an envelope key (to be used with another symmetric method
to decrypt the actual payload) would be redundant. As a result, the
PKE payload is not used.
The ECCPT contains the elliptic curve point that represents the
ephemeral public key required for ECIES.
As in MIKEYRSA, the KEMAC contains a set of encrypted subpayloads
and a MAC:
KEMAC = E(encr_key, IDi  {TGK})  MAC
The encr_key and auth_key are derived from the ECIESderived key by
using the algorithm described in Section 4.1.4 of [RFC3830], in
identical fashion as the envelope key used in the MIKEYRSA.
Both SIGNi and SIGNr will use ECDSA as a signature algorithm, as
described in Section 2.
As in MIKEYRSA, it is possible to cache the ECIESderived key, so
that it can be used as a preshared key.
ECIES is described in detail in [SEC1]. For ECIES, the key
derivation function that MUST be used is ANSIX9.63KDF as described
in [SEC1]. As well, the MAC scheme that MUST be used is HMACSHA1
160. The 'standard' elliptic curve DiffieHellman primitive MUST be
Milne, et al. Expires April 23, 2007 [Page 8]
InternetDraft ECC Algorithms for MIKEY October 2006
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  3DESCBC
283  256  AES128CBC
409  384  AES256CBC
571  521  AES256CBC
Table 3: Symmetric cipher to use with ECIES
Milne, et al. Expires April 23, 2007 [Page 9]
InternetDraft ECC Algorithms for MIKEY October 2006
5. MIKEYECMQV
ECMQV (Elliptic Curve MenezesQuVanstone) is a 3pass or 1pass
protocol that has been standardized in ANSI X9.63 [ANSIX9.63]. Both
modes of ECMQV provide mutual authentication between the
communicating parties and key establishment for the secure transport
of data. Here we describe the new MIKEYECMQV method based on the
1pass protocol.
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDiCERTi], [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 MIKEYRSA, the KEMAC contains a set of encrypted subpayloads
and a MAC:
KEMAC = E(encr_key, IDi  {TGK})  MAC
The encr_key and auth_key are derived from the ECMQVderived key by
using the algorithm described in Section 4.1.4 of [RFC3830], in
identical fashion as the envelope key used in the MIKEYRSA.
1pass ECMQV is described in detail in ANSI X9.63 [ANSIX9.63].
Milne, et al. Expires April 23, 2007 [Page 10]
InternetDraft ECC Algorithms for MIKEY October 2006
6. Additional Payload Encoding
6.1. ECC Point payload (ECCPT)
The ECCPT payload carries a point on the elliptic curve used in
MIKEYECIES and MIKEYECMQV. The payload identifier is 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 values.
* Point length (16 bits): length of the Point data field (in *bits*).
* Point data (variable length): point data, padded to end on a 32bit
boundary, encoded in octet string representation specified in
ANSI X9.62 [ANSIX9.62] and [SEC1]. Uncompressed format MUST be
supported. Hybrid and compressed formats MAY be supported.
Milne, et al. Expires April 23, 2007 [Page 11]
InternetDraft ECC Algorithms for MIKEY October 2006
7. 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
higherstrength AES algorithms and SHA implementations. The methods
proposed in this document are among those standardized by NIST in
FIPS 1862 [FIPS1862], by the SECG in SEC2 [SEC2], and by ANSI in
ANSI X9.62 [ANSIX9.62] and X9.63 [ANSIX9.63].
Milne, et al. Expires April 23, 2007 [Page 12]
InternetDraft ECC Algorithms for MIKEY October 2006
8. IANA Considerations
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).
Milne, et al. Expires April 23, 2007 [Page 13]
InternetDraft ECC Algorithms for MIKEY October 2006
9. References
9.1. Normative References
[ANSIX9.62]
American National Standards Institute, "ANSI X9.62: Public
Key Cryptography For The Financial Services Industry: The
Elliptic Curve Digital Signature Algorithm (ECDSA)", 2005.
[ANSIX9.63]
American National Standards Institute, "ANSI X9.63: Public
Key Cryptography For The Financial Services Industry: Key
Agreement and Key Transport using Elliptic Curve
Cryptography", 2001.
[FIPS1862]
National Institute of Standards and Technology, "FIPS
1862 Digital Signature Standard", 2000.
[IANA] Internet Assigned Numbers Authority, "Attribute Assigned
Numbers.", .
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, April 2002.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[SEC1] Standards for Efficient Crytopgraphy Group, "Elliptic
Curve Cryptography", September 2000.
[SEC2] Standards for Efficient Crytopgraphy Group, "Recommended
Elliptic Curve 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", .
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Milne, et al. Expires April 23, 2007 [Page 14]
InternetDraft ECC Algorithms for MIKEY October 2006
Requirement Levels", BCP 14, RFC 2119, March 1997.
Milne, et al. Expires April 23, 2007 [Page 15]
InternetDraft ECC Algorithms for MIKEY October 2006
Authors' Addresses
Andrew Milne
Mitch Blaser
Certicom Corp.
5520 Explorer Drive
Mississauga, Ontario L4W 5L1
CANADA
Phone: +19055074220
Fax: +19055074230
Email: mblaser@certicom.com
URI: http://www.certicom.com
Daniel R. L. Brown
Certicom Corp.
5520 Explorer Drive
Mississauga, Ontario L4W 5L1
CANADA
Phone: +19055074220
Fax: +19055074230
Email: dbrown@certicom.com
URI: http://www.certicom.com
Eugene Chin
Certicom Corp.
5520 Explorer Drive
Mississauga, Ontario L4W 5L1
CANADA
Phone: +19055074220
Fax: +19055074230
Email: mblaser@certicom.com
URI: http://www.certicom.com
Milne, et al. Expires April 23, 2007 [Page 16]
InternetDraft ECC Algorithms for MIKEY October 2006
Lakshminath Dondeti
QUALCOMM, Inc.
5775 Morehouse Drive
San Diego, CA
USA
Phone: +18588451267
Email: ldondeti@qualcomm.com
Milne, et al. Expires April 23, 2007 [Page 17]
InternetDraft ECC Algorithms for MIKEY October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF online IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietfipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Milne, et al. Expires April 23, 2007 [Page 18]