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