 1/draftietfmsecmikeyecc02.txt 20070620 22:12:10.000000000 +0200
+++ 2/draftietfmsecmikeyecc03.txt 20070620 22:12:10.000000000 +0200
@@ 1,23 +1,19 @@
Network Working Group A. Milne
InternetDraft
Intended status: Standards Track M. Blaser
Expires: September 23, 2007 D. Brown
 E. Chin
 Certicom Corp.
 L. Dondeti
 QUALCOMM, Inc.
 March 22, 2007
+Network Working Group D. Brown
+InternetDraft E. Chin
+Intended status: Standards Track C. Tse
+Expires: December 13, 2007 Certicom Corp.
+ June 11, 2007
ECC Algorithms for MIKEY
 draftietfmsecmikeyecc02
+ draftietfmsecmikeyecc03
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
@@ 28,21 +24,21 @@
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 September 23, 2007.
+ This InternetDraft will expire on December 13, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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
@@ 50,48 +46,48 @@
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 or ECGDSA . . . . . . . . . . . . . . 5
3. MIKEYDHSIGN with ECDH . . . . . . . . . . . . . . . . . . . . 6
4. MIKEYECIES . . . . . . . . . . . . . . . . . . . . . . . . . 8
 5. MIKEYECMQV . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5. MIKEYECMQV . . . . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . 15
 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction
This document describes additional algorithms for use in MIKEY. The
document assumes that the reader is familiar with the MIKEY protocol.
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 Elliptic Curve
Digital Signature Algorithm (ECDSA) or Elliptic Curve German Digital
Signature Algorithm (ECGDSA) 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 the Elliptic Curve Integrated Encryption Scheme (ECIES) and
 Elliptic Curve MenezesQuVanstone (ECMQV) in exchanges similar to
 those of MIKEYRSA, and name these methods MIKEYECIES and MIKEY
 ECMQV respectively.
+ Elliptic Curve MenezesQuVanstone (ECMQV). The ECIES method (MIKEY
+ ECIES) is similar to MIKEYRSA method, and the ECMQV method (MIKEY
+ ECMQV) is similar to MIKEYDHSIGN method.
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
@@ 145,39 +141,39 @@
163  192  SHA1
233  224  SHA224
283  256  SHA256
409  384  SHA384
571  521  SHA512
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 is defined as follows:
+ and ECGDSA are defined as follows:
S type  Value  Comments

ECDSA  2  ECDSA signature [ANSI_X9.62]
ECGDSA  3  ECGDSA signature [ISO/IEC_159462]
[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
DiffieHellman, this extension to MIKEYDHSIGN may be combined with
the extension described in Section 3.
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
+ support for OAKLEY 1 and OAKLEY 2 are OPTIONAL. Instead of these
DiffieHellman (DH) groups, elliptic curve DiffieHellman (ECDH)
groups may 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
@@ 263,145 +259,219 @@
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 >
+ KEMAC, [CHASH], PKE, 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 either ECDSA or ECGDSA as a signature
 algorithm, as described in Section 2.
+ parameters to the Responder in a secure manner. In general, the
+ MIKEYECIES and MIKEYRSA methods are exactly the same, except that
+ the supported signature algorithm and the public key encryption
+ algorithm are different.
 As in MIKEYRSA, it is possible to cache the ECIESderived key, so
 that it can be used as a preshared key.
+ The signature algorithm applied is defined by, and dependent on the
+ certificate used. The MIKEYECIES method supports ECDSA as described
+ in [ANSIX9.62] and ECGDSA as described in [ISOIEC159462]. The
+ SIGNi will use either ECDSA or ECGDSA as a signature algorithm, as
+ described in Section 2.
 ECIES is described in detail in [SEC1]. For ECIES, the key
+ The public key encryption algorithm applied is defined by, and
+ dependent on the certificate used. The MIKEYECIES method supports
+ ECIES as described in detail in [SEC1]. For ECIES, the key
derivation function that MUST be used is ANSIX9.63KDF as described
in [SEC1]. As well, the MAC scheme that MUST be used is HMACSHA1
160. The 'standard' elliptic curve DiffieHellman primitive MUST be
used (as opposed to 'cofactor'). The symmetric encryption scheme
that MUST be used depends on the key size, as follows:
ECC2N  ECP  Symmetric Cipher To Use
163  192  3DESCBC
233  224  AES128CBC
283  256  AES128CBC
409  384  AES256CBC
571  521  AES256CBC
Table 4: Symmetric cipher to use with ECIES
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
+ ECMQV (Elliptic Curve MenezesQuVanstone) is defined in ANSI X9.63
+ [ANSIX9.63]. ECMQV provides 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.
+ 2pass protocol.
Initiator Responder
I_MESSAGE =
 HDR, T, RAND, [IDiCERTi], [IDr], {SP},
 ECCPT, KEMAC, [CHASH], SIGNi >
+ HDR, T, RAND, [IDiCERTi], [IDr],
+ {SP}, ECCPTi, SIGNi >
R_MESSAGE =
 [<] HDR, T, [IDr], V
+ [<] HDR, T, [IDrCERTr],
+ IDi, ECCPTr, ECCPTi, V
 The ECCPT contains the elliptic curve point that represents the
 ephemeral public key contributed by the Initiator.
+ The MIKEYECMQV method is similar to the MIKEYDHSIGN method, except
+ that with MIKEYECMQV, a variablelength shared secret is created
+ using ECMQV instead of a fixedlength shared secret. Same as the
+ MIKEYDHSIGN method, this method cannot be used to create group keys;
+ it can only be used to create single peertopeer keys.
 As in MIKEYRSA, the KEMAC contains a set of encrypted subpayloads
 and a MAC:
+ The MIKEYECMQV method create a variablelength 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.
 KEMAC = E(encr_key, IDi  {TGK})  MAC
+ 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 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.
+ 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 MIKEYECMQV method supports ECDSA as described
+ in [ANSIX9.62] and ECGDSA as described in [ISOIEC159462]. The
+ SIGNi will use either ECDSA or ECGDSA as a signature algorithm, as
+ described in Section 2.
 1pass ECMQV is described in detail in ANSI X9.63 [ANSIX9.63].
+ The main objective of the Responder's message is to provide the
+ 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 MIKEYPSA method (see Section
+ 5.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 [ANSIX9.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 MIKEYECMQV method support ECDSA as described
+ in [ANSIX9.62] and ECGDSA as described in [ISOIEC159462]. The
+ SIGNi will use either ECDSA or ECGDSA as a signature algorithm, as
+ described in Section 2.
+
+ 2pass ECMQV is described in detail in ANSI X9.63 [ANSIX9.63].
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.
+ 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 ... ~
+ ! Next payload ! ECC Curve ! ECC Point ~
+++++++++++++++++++++++++++++++++
 ~ Point data ~
+ ! Auth alg ! TGK len ! Reserv! KV !
+ +++++++++++++++++++++++++++++++++
+ ! KV data (optional) ~
+++++++++++++++++++++++++++++++++
* Next payload (8 bits): identifies the payload that is added after
 this payload. See Section 6.1 for values.
+ this payload. See Section 6.1 of [RFC3830] for values.
 * Point length (16 bits): length of the Point data field (in *bits*).
+ * ECC curve (8 bits): identifies the ECC curve used.
 * 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
+ ECC curve  Value
+ 
+ ECPRGF192Random / P192 / secp192r1  0
+ EC2NGF163Random / B163 / sect163r2  1
+ EC2NGF163Koblitz / K163 / sect163k1  2
+ EC2NGF163Random2 / none / sect163r1  3
+ ECPRGF224Random / P224 / secp224r1  4
+ EC2NGF233Random / B233 / sect233r1  5
+ EC2NGF233Koblitz / K233 / sect233k1  6
+ ECPRGF256Random / P256 / secp256r1  7
+ EC2NGF283Random / B283 / sect283r1  8
+ EC2NGF283Koblitz / K283 / sect283k1  9
+ ECPRGF384Random / P384 / secp384r1  10
+ EC2NGF409Random / B409 / sect409r1  11
+ EC2NGF409Koblitz / K409 / sect409k1  12
+ ECPRGF521Random / P521 / secp521r1  13
+ EC2NGF571Random / B571 / sect571r1  14
+ EC2NGF571Koblitz / K571 / sect571k1  15
+
+ * ECC point (variable length): ECC 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.
+ * Auth alg (8 bits): specifies the MAC algorithm used for the
+ verification message. See Section 6.2 of [RFC3830] for defined
+ 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 predefined 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.
+
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].
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).
+ payloads), Section 6.1 (ECCPT payload identifier), and Section 6.1
+ (ECC curve).
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.
@@ 428,82 +498,72 @@
[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
+ [SEC1] Standards for Efficient Cryptography Group, "Elliptic
Curve Cryptography", September 2000.
 [SEC2] Standards for Efficient Crytopgraphy Group, "Recommended
+ [SEC2] Standards for Efficient Cryptography 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
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
 Andrew Milne

 Mitch Blaser
+ Daniel R. L. Brown
Certicom Corp.
5520 Explorer Drive
Mississauga, Ontario L4W 5L1
CANADA
Phone: +19055074220
Fax: +19055074230
 Email: mblaser@certicom.com
+ Email: dbrown@certicom.com
URI: http://www.certicom.com
 Daniel R. L. Brown
+ Eugene Chin
Certicom Corp.
5520 Explorer Drive
Mississauga, Ontario L4W 5L1
CANADA
Phone: +19055074220
Fax: +19055074230
 Email: dbrown@certicom.com
+ Email: echin@certicom.com
URI: http://www.certicom.com
 Eugene Chin
+ Chi Chiu Tse
Certicom Corp.
5520 Explorer Drive
Mississauga, Ontario L4W 5L1
CANADA
Phone: +19055074220
Fax: +19055074230
 Email: echin@certicom.com
+ Email: ctse@certicom.com
URI: http://www.certicom.com
 Lakshminath Dondeti
 QUALCOMM, Inc.
 5775 Morehouse Drive
 San Diego, CA
 USA

 Phone: +18588451267
 Email: ldondeti@qualcomm.com
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