draft-ietf-msec-mikey-ecc-02.txt   draft-ietf-msec-mikey-ecc-03.txt 
Network Working Group A. Milne Network Working Group D. Brown
Internet-Draft Internet-Draft E. Chin
Intended status: Standards Track M. Blaser Intended status: Standards Track C. Tse
Expires: September 23, 2007 D. Brown Expires: December 13, 2007 Certicom Corp.
E. Chin June 11, 2007
Certicom Corp.
L. Dondeti
QUALCOMM, Inc.
March 22, 2007
ECC Algorithms for MIKEY ECC Algorithms for MIKEY
draft-ietf-msec-mikey-ecc-02 draft-ietf-msec-mikey-ecc-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. 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
skipping to change at page 1, line 39 skipping to change at page 1, line 35
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/ietf/1id-abstracts.txt. 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.
This Internet-Draft will expire on September 23, 2007. This Internet-Draft will expire on December 13, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document proposes extensions to the authentication, encryption This document proposes extensions to the authentication, encryption
and digital signature methods described for use in MIKEY, employing and digital signature methods described for use in MIKEY, employing
elliptic-curve cryptography (ECC). These extensions are defined to elliptic-curve cryptography (ECC). These extensions are defined to
skipping to change at page 2, line 21 skipping to change at page 2, line 21
It should be noted that this document is not self-contained; it uses It should be noted that this document is not self-contained; it uses
the notations and definitions of [RFC3830]. the notations and definitions of [RFC3830].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. MIKEY-DHSIGN with ECDSA or ECGDSA . . . . . . . . . . . . . . 5 2. MIKEY-DHSIGN with ECDSA or ECGDSA . . . . . . . . . . . . . . 5
3. MIKEY-DHSIGN with ECDH . . . . . . . . . . . . . . . . . . . . 6 3. MIKEY-DHSIGN with ECDH . . . . . . . . . . . . . . . . . . . . 6
4. MIKEY-ECIES . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. MIKEY-ECIES . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. MIKEY-ECMQV . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. MIKEY-ECMQV . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Additional Payload Encoding . . . . . . . . . . . . . . . . . 11 6. Additional Payload Encoding . . . . . . . . . . . . . . . . . 11
6.1. ECC Point payload (ECCPT) . . . . . . . . . . . . . . . . 11 6.1. ECC Point payload (ECCPT) . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
This document describes additional algorithms for use in MIKEY. The This document describes additional algorithms for use in MIKEY. The
document assumes that the reader is familiar with the MIKEY protocol. document assumes that the reader is familiar with the MIKEY protocol.
The MIKEY protocol [RFC3830] defines three methods for transporting The MIKEY protocol [RFC3830] defines three methods for transporting
or establishing keys: with the use of a pre-shared key, public-key or establishing keys: with the use of a pre-shared key, public-key
encryption (MIKEY-RSA), and Diffie-Hellman (DH) key exchange (MIKEY- encryption (MIKEY-RSA), and Diffie-Hellman (DH) key exchange (MIKEY-
DHSIGN). This document extends MIKEY-DHSIGN to use Elliptic Curve DHSIGN). This document extends MIKEY-DHSIGN to use Elliptic Curve
Digital Signature Algorithm (ECDSA) or Elliptic Curve German Digital Digital Signature Algorithm (ECDSA) or Elliptic Curve German Digital
Signature Algorithm (ECGDSA) as the signature algorithm and further Signature Algorithm (ECGDSA) as the signature algorithm and further
extends MIKEY-DHSIGN to use Elliptic Curve Diffie-Hellman (ECDH) extends MIKEY-DHSIGN to use Elliptic Curve Diffie-Hellman (ECDH)
groups. In addition, this document introduces two new methods based groups. In addition, this document introduces two new methods based
on the the Elliptic Curve Integrated Encryption Scheme (ECIES) and on the the Elliptic Curve Integrated Encryption Scheme (ECIES) and
Elliptic Curve Menezes-Qu-Vanstone (ECMQV) in exchanges similar to Elliptic Curve Menezes-Qu-Vanstone (ECMQV). The ECIES method (MIKEY-
those of MIKEY-RSA, and name these methods MIKEY-ECIES and MIKEY- ECIES) is similar to MIKEY-RSA method, and the ECMQV method (MIKEY-
ECMQV respectively. ECMQV) is similar to MIKEY-DHSIGN method.
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
skipping to change at page 5, line 34 skipping to change at page 5, line 34
163 | 192 | SHA-1 163 | 192 | SHA-1
233 | 224 | SHA-224 233 | 224 | SHA-224
283 | 256 | SHA-256 283 | 256 | SHA-256
409 | 384 | SHA-384 409 | 384 | SHA-384
571 | 521 | SHA-512 571 | 521 | SHA-512
Table 2: Hash to use with ECDSA and ECGDSA Table 2: Hash to use with ECDSA and ECGDSA
The signature payload (SIGN) specified in Section 6.5 of [RFC3830] The signature payload (SIGN) specified in Section 6.5 of [RFC3830]
can be used without modification. Two additional S types for ECDSA 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 S type | Value | Comments
------------------------------------- -------------------------------------
ECDSA | 2 | ECDSA signature [ANSI_X9.62] ECDSA | 2 | ECDSA signature [ANSI_X9.62]
ECGDSA | 3 | ECGDSA signature [ISO/IEC_15946-2] ECGDSA | 3 | ECGDSA signature [ISO/IEC_15946-2]
[RFC3279] describes algorithms and identifiers for Internet X.509 [RFC3279] describes algorithms and identifiers for Internet X.509
certificates and CRLs. It includes ECC algorithms and identifiers. certificates and CRLs. It includes ECC algorithms and identifiers.
To use the ECDSA or ECGDSA signature algorithm with Elliptic Curve To use the ECDSA or ECGDSA signature algorithm with Elliptic Curve
Diffie-Hellman, this extension to MIKEY-DHSIGN may be combined with Diffie-Hellman, this extension to MIKEY-DHSIGN may be combined with
the extension described in Section 3. the extension described in Section 3.
3. MIKEY-DHSIGN with ECDH 3. MIKEY-DHSIGN with ECDH
MIKEY-DHSIGN is described in Section 3.3 of [RFC3830]. According to 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 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
Diffie-Hellman (DH) groups, elliptic curve Diffie-Hellman (ECDH) Diffie-Hellman (DH) groups, elliptic curve Diffie-Hellman (ECDH)
groups may significantly improve performance and security. groups may significantly improve performance and security.
The ECDH groups to be used by MIKEY are the groups recommended by The ECDH groups to be used by MIKEY are the groups recommended by
NIST in FIPS 186-2 [FIPS-186-2]. Detailed descriptions of the ECDH NIST in FIPS 186-2 [FIPS-186-2]. Detailed descriptions of the ECDH
groups can be found in each of FIPS 186-2 [FIPS-186-2] and SEC 2 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 [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 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 have been assigned identifiers by IANA [IANA] and the remaining five
might later be assigned identifiers by IANA. The group with IANA might later be assigned identifiers by IANA. The group with IANA
skipping to change at page 8, line 16 skipping to change at page 8, line 16
The Elliptic Curve Integrated Encryption Scheme (ECIES) is a public- The Elliptic Curve Integrated Encryption Scheme (ECIES) is a public-
key encryption scheme based on ECC. Section 3.2 of [RFC3830] already key encryption scheme based on ECC. Section 3.2 of [RFC3830] already
specifies a public-key encryption method (MIKEY-RSA). Here we specifies a public-key encryption method (MIKEY-RSA). Here we
describe the new MIKEY-ECIES method. 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 ---> KEMAC, [CHASH], PKE, SIGNi --->
R_MESSAGE = R_MESSAGE =
[<---] HDR, T, [IDr], V [<---] HDR, T, [IDr], V
As with the MIKEY-RSA case, the main objective of the Initiator's 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 message is to transport one or more TGKs and a set of security
parameters to the Responder in a secure manner. parameters to the Responder in a secure manner. In general, the
MIKEY-ECIES and MIKEY-RSA methods are exactly the same, except that
With MIKEY-RSA, the TGKs are encrypted with an "envelope key". the supported signature algorithm and the public key encryption
However, ECIES uses a symmetric encapsulation algorithm, so algorithm are different.
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 MIKEY-RSA, the KEMAC contains a set of encrypted sub-payloads
and a MAC:
KEMAC = E(encr_key, IDi || {TGK}) || MAC
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.
Both SIGNi and SIGNr will use either ECDSA or ECGDSA as a signature
algorithm, as described in Section 2.
As in MIKEY-RSA, it is possible to cache the ECIES-derived key, so The signature algorithm applied is defined by, and dependent on the
that it can be used as a pre-shared key. 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.
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 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 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- 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 160. The 'standard' elliptic curve Diffie-Hellman primitive MUST be
used (as opposed to 'cofactor'). The symmetric encryption scheme used (as opposed to 'cofactor'). The symmetric encryption scheme
that MUST be used depends on the key size, as follows: that MUST be used depends on the key size, as follows:
ECC2N | ECP | Symmetric Cipher To Use ECC2N | ECP | Symmetric Cipher To Use
163 | 192 | 3DES-CBC 163 | 192 | 3DES-CBC
233 | 224 | AES-128-CBC 233 | 224 | AES-128-CBC
283 | 256 | AES-128-CBC 283 | 256 | AES-128-CBC
409 | 384 | AES-256-CBC 409 | 384 | AES-256-CBC
571 | 521 | AES-256-CBC 571 | 521 | AES-256-CBC
Table 4: Symmetric cipher to use with ECIES Table 4: Symmetric cipher to use with ECIES
5. MIKEY-ECMQV 5. MIKEY-ECMQV
ECMQV (Elliptic Curve Menezes-Qu-Vanstone) is a 3-pass or 1-pass ECMQV (Elliptic Curve Menezes-Qu-Vanstone) is defined in ANSI X9.63
protocol that has been standardized in ANSI X9.63 [ANSI-X9.63]. Both [ANSI-X9.63]. ECMQV provides mutual authentication between the
modes of ECMQV provide mutual authentication between the
communicating parties and key establishment for the secure transport communicating parties and key establishment for the secure transport
of data. Here we describe the new MIKEY-ECMQV method based on the of data. Here we describe the new MIKEY-ECMQV method based on the
1-pass protocol. 2-pass protocol.
Initiator Responder Initiator Responder
I_MESSAGE = I_MESSAGE =
HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, HDR, T, RAND, [IDi|CERTi], [IDr],
ECCPT, KEMAC, [CHASH], SIGNi ---> {SP}, ECCPTi, SIGNi --->
R_MESSAGE = R_MESSAGE =
[<---] HDR, T, [IDr], V [<---] HDR, T, [IDr|CERTr],
IDi, ECCPTr, ECCPTi, V
The ECCPT contains the elliptic curve point that represents the The MIKEY-ECMQV method is similar to the MIKEY-DHSIGN method, except
ephemeral public key contributed by the Initiator. 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.
As in MIKEY-RSA, the KEMAC contains a set of encrypted sub-payloads The MIKEY-ECMQV method create a variable-length shared secret. From
and a MAC: 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 ECMQV-derived key by The SIGNi is a signature covering the Initiator's message using the
using the algorithm described in Section 4.1.4 of [RFC3830], in Initiator's signature key from the Initiator's certificate. The
identical fashion as the envelope key used in the MIKEY-RSA. 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.
1-pass ECMQV is described in detail in ANSI X9.63 [ANSI-X9.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 MIKEY-PSA 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 [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].
6. Additional Payload Encoding 6. Additional Payload Encoding
6.1. ECC Point payload (ECCPT) 6.1. ECC Point payload (ECCPT)
The ECCPT payload carries a point on the elliptic curve used in The ECCPT payload carries a point on the elliptic curve used in
MIKEY-ECIES and MIKEY-ECMQV. The payload identifier is 22. MIKEY-ECMQV. The payload identifier is 22.
1 2 3 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 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 * 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 32-bit ECC curve | Value
boundary, encoded in octet string representation specified in ---------------------------------------------
ANSI X9.62 [ANSI-X9.62] and [SEC1]. Uncompressed format MUST be ECPRGF192Random / P-192 / secp192r1 | 0
EC2NGF163Random / B-163 / sect163r2 | 1
EC2NGF163Koblitz / K-163 / sect163k1 | 2
EC2NGF163Random2 / none / sect163r1 | 3
ECPRGF224Random / P-224 / secp224r1 | 4
EC2NGF233Random / B-233 / sect233r1 | 5
EC2NGF233Koblitz / K-233 / sect233k1 | 6
ECPRGF256Random / P-256 / secp256r1 | 7
EC2NGF283Random / B-283 / sect283r1 | 8
EC2NGF283Koblitz / K-283 / sect283k1 | 9
ECPRGF384Random / P-384 / secp384r1 | 10
EC2NGF409Random / B-409 / sect409r1 | 11
EC2NGF409Koblitz / K-409 / sect409k1 | 12
ECPRGF521Random / P-521 / secp521r1 | 13
EC2NGF571Random / B-571 / sect571r1 | 14
EC2NGF571Koblitz / K-571 / sect571k1 | 15
* ECC point (variable length): ECC point data, padded to end on a
32-bit 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. 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 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.
7. 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 [RFC3830] apply here of the security considerations contained within [RFC3830] apply here
as well. Some of the methods proposed in this document offer higher as well. Some of the methods proposed in this document offer higher
cryptographic strength than those proposed in [RFC3830]. In cryptographic strength than those proposed in [RFC3830]. In
particular, there are elliptic curves corresponding to each of the particular, there are elliptic curves corresponding to each of the
symmetric key sizes 80 bits, 128 bits, 192 bits, and 256 bits. This symmetric key sizes 80 bits, 128 bits, 192 bits, and 256 bits. This
allows the MIKEY key exchange to offer security comparable with allows the MIKEY key exchange to offer security comparable with
higher-strength AES algorithms and SHA implementations. The methods higher-strength AES algorithms and SHA implementations. The methods
proposed in this document are among those standardized by NIST in 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 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]. ANSI X9.62 [ANSI-X9.62] and X9.63 [ANSI-X9.63].
8. IANA Considerations 8. IANA Considerations
This document adds entries to existing MIKEY namespaces in Section 2 This document adds entries to existing MIKEY namespaces in Section 2
(S types in signature payloads), Section 3 (DH Group identifier in DH (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. References
9.1. Normative References 9.1. Normative References
[ANSI-X9.62] [ANSI-X9.62]
American National Standards Institute, "ANSI X9.62: Public American National Standards Institute, "ANSI X9.62: Public
Key Cryptography For The Financial Services Industry: The Key Cryptography For The Financial Services Industry: The
Elliptic Curve Digital Signature Algorithm (ECDSA)", 2005. Elliptic Curve Digital Signature Algorithm (ECDSA)", 2005.
skipping to change at page 14, line 44 skipping to change at page 15, line 44
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, April 2002. (CRL) Profile", RFC 3279, April 2002.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[SEC1] Standards for Efficient Crytopgraphy Group, "Elliptic [SEC1] Standards for Efficient Cryptography Group, "Elliptic
Curve Cryptography", September 2000. Curve Cryptography", September 2000.
[SEC2] Standards for Efficient Crytopgraphy Group, "Recommended [SEC2] Standards for Efficient Cryptography Group, "Recommended
Elliptic Curve Domain Parameters", September 2000. Elliptic Curve Domain Parameters", September 2000.
9.2. Informative References 9.2. Informative References
[HOF] Hoffman, P. and H. Orman, "Determining strengths for [HOF] Hoffman, P. and H. Orman, "Determining strengths for
public keys used for exchanging symmetric keys", public keys used for exchanging symmetric keys",
August 2000. August 2000.
[LEN] Lenstra, A. and E. Verhuel, "Selecting cryptographic key [LEN] Lenstra, A. and E. Verhuel, "Selecting cryptographic key
sizes", <http://www.cryptosavvy.com>. sizes", <http://www.cryptosavvy.com>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses Authors' Addresses
Andrew Milne Daniel R. L. Brown
Mitch Blaser
Certicom Corp. Certicom Corp.
5520 Explorer Drive 5520 Explorer Drive
Mississauga, Ontario L4W 5L1 Mississauga, Ontario L4W 5L1
CANADA CANADA
Phone: +1-905-507-4220 Phone: +1-905-507-4220
Fax: +1-905-507-4230 Fax: +1-905-507-4230
Email: mblaser@certicom.com Email: dbrown@certicom.com
URI: http://www.certicom.com URI: http://www.certicom.com
Daniel R. L. Brown Eugene Chin
Certicom Corp. Certicom Corp.
5520 Explorer Drive 5520 Explorer Drive
Mississauga, Ontario L4W 5L1 Mississauga, Ontario L4W 5L1
CANADA CANADA
Phone: +1-905-507-4220 Phone: +1-905-507-4220
Fax: +1-905-507-4230 Fax: +1-905-507-4230
Email: dbrown@certicom.com Email: echin@certicom.com
URI: http://www.certicom.com URI: http://www.certicom.com
Eugene Chin Chi Chiu Tse
Certicom Corp. Certicom Corp.
5520 Explorer Drive 5520 Explorer Drive
Mississauga, Ontario L4W 5L1 Mississauga, Ontario L4W 5L1
CANADA CANADA
Phone: +1-905-507-4220 Phone: +1-905-507-4220
Fax: +1-905-507-4230 Fax: +1-905-507-4230
Email: echin@certicom.com Email: ctse@certicom.com
URI: http://www.certicom.com URI: http://www.certicom.com
Lakshminath Dondeti
QUALCOMM, Inc.
5775 Morehouse Drive
San Diego, CA
USA
Phone: +1-858-845-1267
Email: ldondeti@qualcomm.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. 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
 End of changes. 38 change blocks. 
92 lines changed or deleted 152 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/