draft-ietf-msec-mikey-ecc-01.txt   draft-ietf-msec-mikey-ecc-02.txt 
Network Working Group A. Milne Network Working Group A. Milne
Internet-Draft Internet-Draft
Intended status: Standards Track M. Blaser Intended status: Standards Track M. Blaser
Expires: April 23, 2007 D. Brown Expires: September 23, 2007 D. Brown
E. Chin E. Chin
Certicom Corp. Certicom Corp.
L. Dondeti L. Dondeti
QUALCOMM, Inc. QUALCOMM, Inc.
October 20, 2006 March 22, 2007
ECC Algorithms for MIKEY ECC Algorithms for MIKEY
draft-ietf-msec-mikey-ecc-01 draft-ietf-msec-mikey-ecc-02
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 39
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 April 23, 2007. This Internet-Draft will expire on September 23, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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
align MIKEY with other ECC implementations and standards. align MIKEY with other ECC implementations and standards.
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 . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
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 ECDSA as the DHSIGN). This document extends MIKEY-DHSIGN to use Elliptic Curve
signature algorithm and further extends MIKEY-DHSIGN to use Elliptic Digital Signature Algorithm (ECDSA) or Elliptic Curve German Digital
Curve Diffie-Hellman (ECDH) groups. In addition, this document Signature Algorithm (ECGDSA) as the signature algorithm and further
introduces two new methods based on the elliptic curve algorithms extends MIKEY-DHSIGN to use Elliptic Curve Diffie-Hellman (ECDH)
ECIES and ECMQV in exchanges similar to those of MIKEY-RSA, and name groups. In addition, this document introduces two new methods based
these methods MIKEY-ECIES and MIKEY-ECMQV respectively. on the the Elliptic Curve Integrated Encryption Scheme (ECIES) and
Elliptic Curve Menezes-Qu-Vanstone (ECMQV) in exchanges similar to
those of MIKEY-RSA, and name these methods MIKEY-ECIES and 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
skipping to change at page 3, line 47 skipping to change at page 3, line 50
192 | 409 | 384 | 7680 192 | 409 | 384 | 7680
256 | 571 | 521 | 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 ECC2N, 384-bit ECP, or 7680-bit DH/DSA/ 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 RSA. With smaller key sizes the symmetric keys would be
underprotected. underprotected.
Section 2 describes the extension of MIKEY-DHSIGN to use the ECDSA Section 2 describes the extension of MIKEY-DHSIGN to use the ECDSA or
signature algorithm. Section 3 describes the extension of MIKEY- ECGDSA signature algorithm. Section 3 describes the extension of
DHSIGN to use ECDH groups. Section 4 describes the MIKEY-ECIES MIKEY-DHSIGN to use ECDH groups. Section 4 describes the MIKEY-ECIES
method. Section 5 describes the MIKEY-ECMQV method. Section 6 method. Section 5 describes the MIKEY-ECMQV method. Section 6
describes additional payloads required to support these new methods. describes additional payloads required to support these new methods.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. MIKEY-DHSIGN with ECDSA 2. MIKEY-DHSIGN with ECDSA or ECGDSA
MIKEY-DHSIGN is described in Section 3.3 of [RFC3830]. The MIKEY-DHSIGN is described in Section 3.3 of [RFC3830]. The
Initiator's message includes SIGNi, a signature covering the Initiator's message includes SIGNi, a signature covering the
Initiator's message. As well, the Responder's message includes Initiator's message. As well, the Responder's message includes
SIGNr, a signature covering the Responder's message. According to SIGNr, a signature covering the Responder's message. According to
Section 4.2.6 of [RFC3830], the signature algorithm applied is Section 4.2.6 of [RFC3830], the signature algorithm applied is
defined by, and dependent on the certificate used. It is MANDATORY 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 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 PSS. Instead of these signature algorithms, ECDSA or ECGDSA may be
allow shorter and more efficient signatures. used to allow shorter and more efficient signatures.
ECDSA signatures are detailed in [ANSI-X9.62]. Curve selection and ECDSA signatures are detailed in [ANSI-X9.62] and ECGDSA signatures
other parameters will be defined by, and dependent on the certificate are detailed in [ISO-IEC-15946-2]. Curve selection and other
used. When generating signatures, the hash function that MUST be parameters will be defined by, and dependent on the certificate used.
used is SHA-1. 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] The signature payload (SIGN) specified in Section 6.5 of [RFC3830]
can be used without modification. An additional S type for ECDSA is can be used without modification. Two additional S types for ECDSA
defined as follows: and ECGDSA is 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]
[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 signature algorithm with Elliptic Curve Diffie- To use the ECDSA or ECGDSA signature algorithm with Elliptic Curve
Hellman, this extension to MIKEY-DHSIGN may be combined with the Diffie-Hellman, this extension to MIKEY-DHSIGN may be combined with
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 is OPTIONAL. Instead of these
Diffie-Hellman (DH) groups, elliptic curve Diffie-Hellman (ECDH) Diffie-Hellman (DH) groups, elliptic curve Diffie-Hellman (ECDH)
groups can 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
number 6 is described in [ANSI-X9.62] and [SEC2], with object number 6 is described in [ANSI-X9.62] and [SEC2], with object
identifier sect163r1, but it is not one of the fifteen curves that identifier sect163r1, but it is not one of the fifteen curves that
NIST recommends [FIPS-186-2]. The remaining NIST recommended groups NIST recommends [FIPS-186-2]. The remaining NIST recommended groups
are suggested and anticipated to be assigned IANA numbers as are suggested and anticipated to be assigned IANA numbers as
specified in Table 2. specified in Table 3.
id Group Type Group Description NIST Name SEC 2 OID id Group Type Group Description NIST Name SEC 2 OID
-- ---------- ----------------- --------- --------- -- ---------- ----------------- --------- ---------
22 2 ECP ECPRGF192Random P-192 secp192r1 22 2 ECP ECPRGF192Random P-192 secp192r1
23 3 EC2N EC2NGF163Random B-163 sect163r2 23 3 EC2N EC2NGF163Random B-163 sect163r2
7 3 EC2N EC2NGF163Koblitz K-163 sect163k1 7 3 EC2N EC2NGF163Koblitz K-163 sect163k1
6 3 EC2N EC2NGF163Random2 none sect163r1 6 3 EC2N EC2NGF163Random2 none sect163r1
24 2 ECP ECPRGF224Random P-224 secp224r1 24 2 ECP ECPRGF224Random P-224 secp224r1
skipping to change at page 6, line 50 skipping to change at page 6, line 50
9 3 EC2N EC2NGF283Koblitz K-283 sect283k1 9 3 EC2N EC2NGF283Koblitz K-283 sect283k1
20 2 ECP ECPRGF384Random P-384 secp384r1 20 2 ECP ECPRGF384Random P-384 secp384r1
10 3 EC2N EC2NGF409Random B-409 sect409r1 10 3 EC2N EC2NGF409Random B-409 sect409r1
11 3 EC2N EC2NGF409Koblitz K-409 sect409k1 11 3 EC2N EC2NGF409Koblitz K-409 sect409k1
21 2 ECP ECPRGF521Random P-521 secp521r1 21 2 ECP ECPRGF521Random P-521 secp521r1
12 3 EC2N EC2NGF571Random B-571 sect571r1 12 3 EC2N EC2NGF571Random B-571 sect571r1
13 3 EC2N EC2NGF571Koblitz K-571 sect571k1 13 3 EC2N EC2NGF571Koblitz K-571 sect571k1
Table 2: Recommended Groups and Names Table 3: Recommended Groups and Names
The ECDH groups in Table 2 are arranged into 5 classes, corresponding The ECDH groups in Table 3 are arranged into 5 classes, corresponding
to approximately equivalent security strengths. To encourage to approximately equivalent security strengths. To encourage
interoperability, implementations that support one of these classes, interoperability, implementations that support one of these classes,
SHOULD support the one group in that class that is defined over a SHOULD support the one group in that class that is defined over a
prime field (which will be one of P-192, P-224, P-256, P-384, or prime field (which will be one of P-192, P-224, P-256, P-384, or
P-521). Implementations SHOULD support one of P-256 or P-384. P-521). Implementations SHOULD support one of P-256 or P-384.
Implementations MAY support any set of groups. Implementations MAY support any set of groups.
The DH data payload (DH) specified in Section 6.4 of [RFC3830] can be The DH data payload (DH) specified in Section 6.4 of [RFC3830] can be
used without modification. Additional DH-Group identifiers are used without modification. Additional DH-Group identifiers are
required as follows: required as follows:
skipping to change at page 7, line 42 skipping to change at page 7, line 42
EC2NGF409Koblitz / K-409 / sect409k1 | 15 EC2NGF409Koblitz / K-409 / sect409k1 | 15
| |
ECPRGF521Random / P-521 / secp521r1 | 16 ECPRGF521Random / P-521 / secp521r1 | 16
EC2NGF571Random / B-571 / sect571r1 | 17 EC2NGF571Random / B-571 / sect571r1 | 17
EC2NGF571Koblitz / K-571 / sect571k1 | 18 EC2NGF571Koblitz / K-571 / sect571k1 | 18
When using the ECDH groups, the DH-value in the DH data payload (DH) When using the ECDH groups, the DH-value in the DH data payload (DH)
is the octet string representation specified in ANSI X9.62 is the octet string representation specified in ANSI X9.62
[ANSI-X9.62] and [SEC1]. [ANSI-X9.62] and [SEC1].
To use ECDH and ECDSA signature algorithm, this extension to MIKEY- If the initiator chooses secret i and the responder chooses secret r,
DHSIGN may be combined with the extension described in Section 2. then the raw shared secret is the x-coordinate(only) of (ir)*G.
To use ECDH and ECDSA signature algorithm or to use ECDH and ECGDSA
signature algorithm, this extension to MIKEY-DHSIGN may be combined
with the extension described in Section 2.
4. MIKEY-ECIES 4. MIKEY-ECIES
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
skipping to change at page 8, line 43 skipping to change at page 8, line 43
As in MIKEY-RSA, the KEMAC contains a set of encrypted sub-payloads As in MIKEY-RSA, the KEMAC contains a set of encrypted sub-payloads
and a MAC: and a MAC:
KEMAC = E(encr_key, IDi || {TGK}) || MAC KEMAC = E(encr_key, IDi || {TGK}) || MAC
The encr_key and auth_key are derived from the ECIES-derived key by 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 using the algorithm described in Section 4.1.4 of [RFC3830], in
identical fashion as the envelope key used in the MIKEY-RSA. identical fashion as the envelope key used in the MIKEY-RSA.
Both SIGNi and SIGNr will use ECDSA as a signature algorithm, as Both SIGNi and SIGNr will use either ECDSA or ECGDSA as a signature
described in Section 2. algorithm, as described in Section 2.
As in MIKEY-RSA, it is possible to cache the ECIES-derived key, so As in MIKEY-RSA, it is possible to cache the ECIES-derived key, so
that it can be used as a pre-shared key. that it can be used as a pre-shared key.
ECIES is described in detail in [SEC1]. For ECIES, the key ECIES is 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
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 3: 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 a 3-pass or 1-pass
protocol that has been standardized in ANSI X9.63 [ANSI-X9.63]. Both protocol that has been standardized in ANSI X9.63 [ANSI-X9.63]. Both
modes of ECMQV provide 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. 1-pass protocol.
skipping to change at page 14, line 28 skipping to change at page 14, line 28
Cryptography", 2001. Cryptography", 2001.
[FIPS-186-2] [FIPS-186-2]
National Institute of Standards and Technology, "FIPS National Institute of Standards and Technology, "FIPS
186-2 Digital Signature Standard", 2000. 186-2 Digital Signature Standard", 2000.
[IANA] Internet Assigned Numbers Authority, "Attribute Assigned [IANA] Internet Assigned Numbers Authority, "Attribute Assigned
Numbers.", <http://www.isi.edu/in-notes/iana/assignments/ Numbers.", <http://www.isi.edu/in-notes/iana/assignments/
ipsec-registry>. ipsec-registry>.
[ISO-IEC-15946-2]
International Organization for Standardization and
International Electrotechnical Commission, "ISO/IEC
15946-2: Information technology -- Security techniques --
Cryptographic techniques based on elliptic curves -- Part
2: Digital signatures", 2002.
[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 Crytopgraphy Group, "Elliptic
skipping to change at page 16, line 39 skipping to change at page 16, line 39
URI: http://www.certicom.com URI: http://www.certicom.com
Eugene Chin 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: mblaser@certicom.com Email: echin@certicom.com
URI: http://www.certicom.com URI: http://www.certicom.com
Lakshminath Dondeti Lakshminath Dondeti
QUALCOMM, Inc. QUALCOMM, Inc.
5775 Morehouse Drive 5775 Morehouse Drive
San Diego, CA San Diego, CA
USA USA
Phone: +1-858-845-1267 Phone: +1-858-845-1267
Email: ldondeti@qualcomm.com Email: ldondeti@qualcomm.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). 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
"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, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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 Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 27 change blocks. 
43 lines changed or deleted 69 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/