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/ |