draft-ietf-msec-mikey-ecc-00.txt | draft-ietf-msec-mikey-ecc-01.txt | |||
---|---|---|---|---|

MSEC Working Group A. Milne | ||||

Internet Draft M. Blaser | ||||

Expires December 2005 D. Brown | ||||

Certicom | ||||

Network Working Group A. Milne | ||||

Internet-Draft | ||||

Intended status: Standards Track M. Blaser | ||||

Expires: April 23, 2007 D. Brown | ||||

E. Chin | ||||

Certicom Corp. | ||||

L. Dondeti | L. Dondeti | |||

Qualcomm | QUALCOMM, Inc. | |||

ECC Algorithms For MIKEY | October 20, 2006 | |||

<draft-ietf-msec-mikey-ecc-00.txt> | ||||

ECC Algorithms for MIKEY | ||||

draft-ietf-msec-mikey-ecc-01 | ||||

Status of this Memo | Status of this Memo | |||

By submitting this Internet-Draft, each author represents that any | ||||

applicable patent or other IPR claims of which he or she is aware | ||||

have been or will be disclosed, and any of which he or she becomes | ||||

aware will be disclosed, in accordance with Section 6 of BCP 79. | ||||

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

other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||

Drafts. | Drafts. | |||

Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||

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/1id-abstracts.html | 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. | |||

IPR Statement | This Internet-Draft will expire on April 23, 2007. | |||

By submitting this Internet-Draft, each author represents | ||||

that any applicable patent or other IPR claims of which he | ||||

or she is aware have been or will be disclosed, and any of | ||||

which he or she becomes aware will be disclosed, in | ||||

accordance with Section 6 of BCP 79. | ||||

The IETF takes no position regarding the validity or scope of any | ||||

Intellectual Property Rights or other rights that might be claimed to | ||||

pertain to the implementation or use of the technology described in | ||||

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

made any independent effort to identify any such rights. Information | ||||

on the procedures with respect to rights in RFC documents can be | ||||

found in BCP 78 and BCP 79. | ||||

Copies of IPR disclosures made to the IETF Secretariat and any | Copyright Notice | |||

assurances of licenses to be made available, or the result of an | ||||

attempt made to obtain a general license or permission for the use of | ||||

such proprietary rights by implementers or users of this | ||||

specification can be obtained from the IETF on-line IPR repository at | ||||

http://www.ietf.org/ipr. | ||||

The IETF invites any interested party to bring to its attention any | Copyright (C) The Internet Society (2006). | |||

copyrights, patents or patent applications, or other proprietary | ||||

rights that may cover technology that may be required to implement | ||||

this standard. Please address the information to the IETF at | ||||

ietf-ipr@ietf.org. | ||||

Abstract | Abstract | |||

This document proposes extensions to the authentication, | This document proposes extensions to the authentication, encryption | |||

encryption and digital signature methods described for use in | and digital signature methods described for use in MIKEY, employing | |||

MIKEY, employing elliptic-curve cryptography (ECC). These | elliptic-curve cryptography (ECC). These extensions are defined to | |||

extensions are defined to align MIKEY with other ECC | align MIKEY with other ECC implementations and standards. | |||

implementations and standards. | ||||

It should be noted that this document is not self-contained; it | It should be noted that this document is not self-contained; it uses | |||

uses the notations and definitions of [MIKEY]. | the notations and definitions of [RFC3830]. | |||

Comments | Table of Contents | |||

Comments on this draft should be addressed to | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||

msec@securemulticast.org. | 2. MIKEY-DHSIGN with ECDSA . . . . . . . . . . . . . . . . . . . 5 | |||

3. MIKEY-DHSIGN with ECDH . . . . . . . . . . . . . . . . . . . . 6 | ||||

4. MIKEY-ECIES . . . . . . . . . . . . . . . . . . . . . . . . . 8 | ||||

5. MIKEY-ECMQV . . . . . . . . . . . . . . . . . . . . . . . . . 10 | ||||

6. Additional Payload Encoding . . . . . . . . . . . . . . . . . 11 | ||||

6.1. ECC Point payload (ECCPT) . . . . . . . . . . . . . . . . 11 | ||||

7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | ||||

8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | ||||

9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | ||||

9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 | ||||

9.2. Informative References . . . . . . . . . . . . . . . . . . 14 | ||||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 | ||||

Intellectual Property and Copyright Statements . . . . . . . . . . 18 | ||||

1. Introduction | 1. Introduction | |||

This document describes additional algorithms for use in MIKEY. | This document describes additional algorithms for use in MIKEY. The | |||

The document assumes that the reader is familiar with the MIKEY | document assumes that the reader is familiar with the MIKEY protocol. | |||

protocol. | ||||

RFC 3830 [MIKEY] defines three methods of key exchange during | The MIKEY protocol [RFC3830] defines three methods for transporting | |||

establishment of a TGK. The pre-shared key (MIKEY-PSA) and public | or establishing keys: with the use of a pre-shared key, public-key | |||

key (MIKEY-RSA) methods are mandatory, while support for | encryption (MIKEY-RSA), and Diffie-Hellman (DH) key exchange (MIKEY- | |||

Diffie-Hellman (MIKEY-DHSIGN) is optional. Elliptic curve | DHSIGN). This document extends MIKEY-DHSIGN to use ECDSA as the | |||

Diffie-Hellman (ECDH) can be used in the MIKEY Diffie-Hellman | signature algorithm and further extends MIKEY-DHSIGN to use Elliptic | |||

method; we specify this mode in this document. In addition, | Curve Diffie-Hellman (ECDH) groups. In addition, this document | |||

the elliptic curve protocols MCMQV and ECIES can be | introduces two new methods based on the elliptic curve algorithms | |||

used in MIKEY in exchanges similar to those of MIKEY-RSA; we | ECIES and ECMQV in exchanges similar to those of MIKEY-RSA, and name | |||

specify these modes, and name them MIKEY-ECIES and | these methods MIKEY-ECIES and MIKEY-ECMQV respectively. | |||

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

from [HOF] and [LEN], gives approximate comparable key sizes for | from [HOF] and [LEN], gives approximate comparable key sizes for | |||

symmetric systems, ECC systems, and DH/DSA/RSA systems. The estimates | symmetric systems, ECC systems, and DH/DSA/RSA systems. The | |||

are based on the running times of the best algorithms known today. | estimates are based on the running times of the best algorithms known | |||

today. | ||||

Symmetric | ECC | DH/DSA/RSA | Symmetric | ECC2N | ECP | DH/DSA/RSA | |||

80 | 163 | 1024 | 80 | 163 | 192 | 1024 | |||

128 | 283 | 3072 | 128 | 283 | 256 | 3072 | |||

192 | 409 | 7680 | 192 | 409 | 384 | 7680 | |||

256 | 571 | 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 ECC or 7680-bit DH/DSA/RSA. Of course | prudent to use either 409-bit ECC2N, 384-bit ECP, or 7680-bit DH/DSA/ | |||

it is possible to use shorter asymmetric keys, but it should be | RSA. With smaller key sizes the symmetric keys would be | |||

recognized in this case that the security of the system is likely | underprotected. | |||

dependent on the strength of the public-key algorithm and claims | ||||

such as "this system is highly secure because it uses 192-bit | ||||

encryption" are misleading. | ||||

Section 2 below describes the use of elliptic curve methods for | ||||

public-key authentication and encryption. Section 3 describes | ||||

the use of ECIES (The Elliptic Curve Integrated Encryption | ||||

Scheme). Section 4 describes methods for Elliptic Curve Diffie- | ||||

Hellman, including fifteen ECDH groups. Section 5 describes the | ||||

MIKEY-MQV method. Section 6 includes modifications to specific | ||||

sections of [MIKEY]. | ||||

2. Use of EC methods with public-key encryption (MIKEY-RSA) | ||||

MIKEY-RSA specifies the use of RSA PKCS#1, v1.5 as mandatory and RSA | ||||

PSS as recommended. This section describes how ECDSA signatures may | ||||

be used for certificate signature and signature operations, enabling | ||||

use of smaller signatures and certificates. This section also | ||||

describes the ECIES encryption/decryption scheme, for use with | ||||

elliptic curve key pairs. | ||||

2.1 ECDSA signature | ||||

Section 6.5 of [MIKEY] describes the signature payload for the PK | Section 2 describes the extension of MIKEY-DHSIGN to use the ECDSA | |||

and DH exchange messages. The ECDSA signature algorithm can be | signature algorithm. Section 3 describes the extension of MIKEY- | |||

applied to allow shorter and more-efficient signatures. | DHSIGN to use ECDH groups. Section 4 describes the MIKEY-ECIES | |||

method. Section 5 describes the MIKEY-ECMQV method. Section 6 | ||||

describes additional payloads required to support these new methods. | ||||

ECDSA signatures are detailed in ANSI X9.62 [X9.62]. Curve selection | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||

and other parameters will be defined by, and dependent on the | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||

certificate used. | document are to be interpreted as described in [RFC2119]. | |||

RFC3279 describes algorithms and identifiers for Internet X.509 | 2. MIKEY-DHSIGN with ECDSA | |||

certificates and CRLs. It includes ECC algorithms and identifiers. | ||||

3. MIKEY-ECIES | MIKEY-DHSIGN is described in Section 3.3 of [RFC3830]. The | |||

Initiator's message includes SIGNi, a signature covering the | ||||

Initiator's message. As well, the Responder's message includes | ||||

SIGNr, a signature covering the Responder's message. According to | ||||

Section 4.2.6 of [RFC3830], the signature algorithm applied is | ||||

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

PSS. Instead of these signature algorithms, ECDSA can be used to | ||||

allow shorter and more efficient signatures. | ||||

MIKEY's public-key encryption method (MIKEY-RSA) uses public key | ECDSA signatures are detailed in [ANSI-X9.62]. Curve selection and | |||

methods securely to transmit keying material between communicating | other parameters will be defined by, and dependent on the certificate | |||

parties having previously acquired one another's public keys. The | used. When generating signatures, the hash function that MUST be | |||

Elliptic Curve Integrated Encryption Scheme (ECIES) specifies how | used is SHA-1. | |||

two communicating parties having previously acquired one another's | ||||

public keys--assuming these are EC public keys--may use these keys | ||||

to transmit encrypted and authenticated messages. This section | ||||

therefore proposes how ECIES may be used in MIKEY. We call this | ||||

scheme MIKEY-ECIES. | ||||

We propose that ECIES be used as follows: | The signature payload (SIGN) specified in Section 6.5 of [RFC3830] | |||

can be used without modification. An additional S type for ECDSA is | ||||

defined as follows: | ||||

1. The ephemeral public key transmitted by the initiator, | S type | Value | Comments | |||

is transmitted in an ECCPT payload (see section 5.1) | ------------------------------------- | |||

preceding the KEMAC payload. | ECDSA | 2 | ECDSA signature [ANSI_X9.62] | |||

2. The ciphertext and message digest required under ECIES | ||||

are transmitted in the KEMAC payload, as in other forms | ||||

of the MIKEY protocol. | ||||

3. The encryption key and HMAC key in use in the KEMAC are those | ||||

extracted from the shared key derived using ECIES. | ||||

4. The PKE payload is not used. | ||||

Note that this differs from the 'envelope key' method used in the | [RFC3279] describes algorithms and identifiers for Internet X.509 | |||

MIKEY-RSA form of the protocol. ECIES, however, uses a symmetric | certificates and CRLs. It includes ECC algorithms and identifiers. | |||

encapsulation algorithm, so encrypting an envelope key (to be | ||||

used with another symmetric method to decrypt the actual payload) | ||||

would be redundant. | ||||

Note also that the derived ECIES key can be used as an input for the | To use the ECDSA signature algorithm with Elliptic Curve Diffie- | |||

key generation algorithm described in section 4.1.4 of RFC 3830, in | Hellman, this extension to MIKEY-DHSIGN may be combined with the | |||

identical fashion as is the envelope key used in the MIKEY-RSA | extension described in Section 3. | |||

method. | ||||

A MIKEY-ECIES exchange | 3. MIKEY-DHSIGN with ECDH | |||

---------------------- | ||||

Initiator Responder | 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 | |||

support for OAKLEY 1 and OAKLEY 2 is OPTIONAL. Instead of these | ||||

Diffie-Hellman (DH) groups, elliptic curve Diffie-Hellman (ECDH) | ||||

groups can significantly improve performance and security. | ||||

I_MESSAGE = | The ECDH groups to be used by MIKEY are the groups recommended by | |||

HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, | NIST in FIPS 186-2 [FIPS-186-2]. Detailed descriptions of the ECDH | |||

ECCPT, KEMAC, [CHASH], SIGNi ---> | 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 | ||||

prime or over GF[P] with P prime. Eleven of the groups proposed here | ||||

have been assigned identifiers by IANA [IANA] and the remaining five | ||||

might later be assigned identifiers by IANA. The group with IANA | ||||

number 6 is described in [ANSI-X9.62] and [SEC2], with object | ||||

identifier sect163r1, but it is not one of the fifteen curves that | ||||

NIST recommends [FIPS-186-2]. The remaining NIST recommended groups | ||||

are suggested and anticipated to be assigned IANA numbers as | ||||

specified in Table 2. | ||||

R_MESSAGE = | id Group Type Group Description NIST Name SEC 2 OID | |||

-- ---------- ----------------- --------- --------- | ||||

[<---] HDR, T, [IDr], V | 22 2 ECP ECPRGF192Random P-192 secp192r1 | |||

Note also that the derived key generated may also be cached for the | 23 3 EC2N EC2NGF163Random B-163 sect163r2 | |||

lifetime of a CSB, at the direction of the Initiator, and used as a | 7 3 EC2N EC2NGF163Koblitz K-163 sect163k1 | |||

preshared key, as described for the envelope key in RFC 3830, section | 6 3 EC2N EC2NGF163Random2 none sect163r1 | |||

3.2. | ||||

ECIES options | 24 2 ECP ECPRGF224Random P-224 secp224r1 | |||

------------- | 25 3 EC2N EC2NGF233Random B-233 sect233r1 | |||

26 3 EC2N EC2NGF233Koblitz K-233 sect233k1 | ||||

IEEE 1363A describes a number of options for ECIES. We recommend that | 19 2 ECP ECPRGF256Random P-256 secp256r1 | |||

in MIKEY-ECIES, the following options be understood as given: | 8 3 EC2N EC2NGF283Random B-283 sect283r1 | |||

9 3 EC2N EC2NGF283Koblitz K-283 sect283k1 | ||||

-- the KDF in use for the generation of the ephemeral key pairs | 20 2 ECP ECPRGF384Random P-384 secp384r1 | |||

shall be ECSVDP-DHC, without compatibility for the | 10 3 EC2N EC2NGF409Random B-409 sect409r1 | |||

corresponding -DH primitive | 11 3 EC2N EC2NGF409Koblitz K-409 sect409k1 | |||

-- DHAES mode shall not be used. | 21 2 ECP ECPRGF521Random P-521 secp521r1 | |||

12 3 EC2N EC2NGF571Random B-571 sect571r1 | ||||

13 3 EC2N EC2NGF571Koblitz K-571 sect571k1 | ||||

4. Use of EC methods with Diffie-Hellman key exchange (MIKEY-DHSIGN) | Table 2: Recommended Groups and Names | |||

The MIKEY-DHSIGN key exchange method is described in Section 3.3 of | The ECDH groups in Table 2 are arranged into 5 classes, corresponding | |||

[MIKEY]. Section 4.2.7 of [MIKEY] specifies the use of OAKLEY group | to approximately equivalent security strengths. To encourage | |||

5 as mandatory and groups 1 and 2 as optional. However, | interoperability, implementations that support one of these classes, | |||

implementations have shown that users of elliptic curve groups can | SHOULD support the one group in that class that is defined over a | |||

significantly improve performance and security by using groups other | prime field (which will be one of P-192, P-224, P-256, P-384, or | |||

than the Oakley Groups 1, 2, or 5. | P-521). Implementations SHOULD support one of P-256 or P-384. | |||

Implementations MAY support any set of groups. | ||||

The DH data payload specified in Section 6.4 of [MIKEY] can be used | The DH data payload (DH) specified in Section 6.4 of [RFC3830] can be | |||

without modification. The data in the KEMAC payload when using | used without modification. Additional DH-Group identifiers are | |||

these groups is the octet string representation specified in ANSI | required as follows: | |||

X9.62 [X9.62], ANSI X9.63 [X9.63], FIPS 186-2 [FIPS 186-2], and | ||||

IEEE P1363 of the point on the curve chosen by taking the randomly | ||||

chosen secret Ka and computing Ka*P, where * is the repetition of the | ||||

group addition and double operations. | ||||

An updated DH-Group table (as shown in Section 6.4 of [MIKEY]) will | DH-Group | Value | |||

be specified upon assignment of IANA numbers for the groups described | --------------------------------------|------- | |||

in section 8. See also the section "IANA considerations" in this | ECPRGF192Random / P-192 / secp192r1 | 3 | |||

document. | EC2NGF163Random / B-163 / sect163r2 | 4 | |||

EC2NGF163Koblitz / K-163 / sect163k1 | 5 | ||||

EC2NGF163Random2 / none / sect163r1 | 6 | ||||

| | ||||

ECPRGF224Random / P-224 / secp224r1 | 7 | ||||

EC2NGF233Random / B-233 / sect233r1 | 8 | ||||

EC2NGF233Koblitz / K-233 / sect233k1 | 9 | ||||

| | ||||

ECPRGF256Random / P-256 / secp256r1 | 10 | ||||

EC2NGF283Random / B-283 / sect283r1 | 11 | ||||

EC2NGF283Koblitz / K-283 / sect283k1 | 12 | ||||

| | ||||

ECPRGF384Random / P-384 / secp384r1 | 13 | ||||

EC2NGF409Random / B-409 / sect409r1 | 14 | ||||

EC2NGF409Koblitz / K-409 / sect409k1 | 15 | ||||

| | ||||

ECPRGF521Random / P-521 / secp521r1 | 16 | ||||

EC2NGF571Random / B-571 / sect571r1 | 17 | ||||

EC2NGF571Koblitz / K-571 / sect571k1 | 18 | ||||

5. Using ECMQV in MIKEY (MIKEY-MQV) | When using the ECDH groups, the DH-value in the DH data payload (DH) | |||

is the octet string representation specified in ANSI X9.62 | ||||

[ANSI-X9.62] and [SEC1]. | ||||

MQV is a protocol primitive equivalent to simultaneous Diffie-Hellman | To use ECDH and ECDSA signature algorithm, this extension to MIKEY- | |||

key exchange and digital signature authentication, achievable in a | DHSIGN may be combined with the extension described in Section 2. | |||

single transmission. The S_i and S_r values function as implicit | ||||

signatures proving possession of the private key corresponding to the | ||||

communicating party's known public key. | ||||

ECMQV (Elliptic Curve Menezes-Qu-Vanstone) is a three-pass or 1-pass | 4. MIKEY-ECIES | |||

protocol that has been standardized in ANSI X9.63. Both modes of | ||||

ECMQV provide mutual authentication between the communicating parties | ||||

and key establishment for the secure transport of data; the 1-pass | ||||

version is thus particularly attractive for MIKEY, as an alternative | ||||

method of establishing a secure channel for the transport of the TGK. | ||||

In this draft, we propose a fourth mode in MIKEY, called MIKEY-MQV, | ||||

in which ECMQV is used in this fashion. | ||||

A MIKEY-MQV exchange proceeds in similar fashion to the MIKEY-RSA | The Elliptic Curve Integrated Encryption Scheme (ECIES) is a public- | |||

exchange; the PKE is absent, and an ECCPT payload (see section 5.1) | key encryption scheme based on ECC. Section 3.2 of [RFC3830] already | |||

MUST precede the KEMAC payload in the intiator's first message: | specifies a public-key encryption method (MIKEY-RSA). Here we | |||

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 ---> | ECCPT, KEMAC, [CHASH], SIGNi ---> | |||

... the responder's acknowledgement, as in MIKEY-RSA, is optional, | ||||

and the initiator indicates whether a response is required. If | ||||

present, the acknowledgement is of the form: | ||||

R_MESSAGE = | R_MESSAGE = | |||

[<---] HDR, T, [IDr], V | [<---] HDR, T, [IDr], V | |||

The ECCPT payload carries Q_(e,I) as per the nomenclature of ANSI | As with the MIKEY-RSA case, the main objective of the Initiator's | |||

X9.63 -- the ephemeral public key contributed by the initiator. | message is to transport one or more TGKs and a set of security | |||

parameters to the Responder in a secure manner. | ||||

The encr_key and auth_key used in forming the KEMAC are the | ||||

encryption and authentication keys extracted from the derived key | ||||

arrived at via MQV. | ||||

1-pass ECMQV algorithm steps | ||||

---------------------------- | ||||

1-pass ECMQV is described in detail in ANSI X9.63-2001; for a | ||||

detailed specification for implementation purposes, see that | ||||

document. The following discussion is provided here for information | ||||

purposes only, to clarify the mechanism, and to ease mapping it to | ||||

the protocol components in this draft proposal. | ||||

Note that 1-pass MQV differs from 3-pass MQV in that only three | ||||

key pairs are used as inputs: the initiator's public, private key | ||||

pair, the respondent's public, private key pair, and the ephemeral | ||||

public, private key pair contributed by the initiator. The | ||||

respondent's public, private key pair is used twice--effectively | ||||

replacing the ephemeral key pair contributed by the respondent in | ||||

the 3-pass method. | ||||

Initiator transformation | ||||

------------------------ | ||||

1. Initiator selects an ephemeral private key k_A from the | With MIKEY-RSA, the TGKs are encrypted with an "envelope key". | |||

set {1..n-1}, where n is the order of the base point P | However, ECIES uses a symmetric encapsulation algorithm, so | |||

for the curve in use. Initiator computes the corresponding | encrypting an envelope key (to be used with another symmetric method | |||

ephemeral public key R_A = (k_A)P, and sends R_A to the | to decrypt the actual payload) would be redundant. As a result, the | |||

respondent. The ephemeral public key R_A derived is the | PKE payload is not used. | |||

value Q_(e,I) in the protocol described above. The | ||||

selection of k_A and the generation of R_A from it are | ||||

covered in detail in X9.63-2001 section 5.2.1--Key Pair | ||||

Generation Primitive. | ||||

2. Initiator calculates the shared secret value z as follows | ||||

(see X9.63-2001 section 5.5)-- | ||||

2a. Initiator uses their own private and public key, | ||||

and the ephemeral private and public key they | ||||

generated in step 1 as inputs (d_1, Q_1) and | ||||

(d_2, Q_2) respectively. | ||||

2b. Initiator uses the respondent's public key for | ||||

the values Q_3 and Q_4. | ||||

2c. Using the associate value function avf (see | ||||

X9.63-2001 section 5.6.1), and the values d_1, | ||||

d_2 and Q_2 as above (their own private key, and | ||||

the ephemeral key pair private and public values), | ||||

the Initiator calculates the implicit signature | ||||

S_i = d_2 + (avf(Q_2) x d_1) mod n. | ||||

2d. Using the associate value function avf, the | ||||

signature just calculated, the system cofactor h, | ||||

and the respondent's public key, the Initiator | ||||

finds the EC point | ||||

P = h x S_i x (Q_4 + (avf(Q_4) x Q_3)). | ||||

2e. Initiator verifies that P != 0. | ||||

2f. Initiator sets z = x_P, where x_P is the | ||||

x-coordinate of P. | ||||

3. Initiator converts z to bit string Z, using the convention | ||||

specified in X9.63-2001 section 4.3.3. | ||||

4. Initiator uses the key derivation function described in | ||||

X9.63-2001 section 5.6.3 with the hash function given in | ||||

table MQV_PARAMS to derive the keying data; the length of | ||||

the key to be generated is also given in MQV_PARAMS. | ||||

Respondent transformation | The ECCPT contains the elliptic curve point that represents the | |||

------------------------- | ephemeral public key required for ECIES. | |||

The respondent transformation is parallel to the initiator | As in MIKEY-RSA, the KEMAC contains a set of encrypted sub-payloads | |||

transformation, except that the respondent does not generate an | and a MAC: | |||

ephemeral key pair, and the inputs d_1, Q_1, d_2, Q_2, Q_3 and Q_4 | ||||

come from different sources. Again, see X9.63-2001 section 5.5 for | ||||

a detailed description appropriate for implementation purposes. | ||||

1. Respondent verifies that Q_(e, U) is a valid key for the | KEMAC = E(encr_key, IDi || {TGK}) || MAC | |||

domain parameters (see X9.63-2001 section 5.2.2). | ||||

2. Respondent calculates the shared secret value z as follows | ||||

(see X9.63-2001 section 5.5)-- | ||||

2a. Respondent uses their own private and public key in | ||||

step 1 as inputs for both (d_1, Q_1) and (d_2, Q_2). | ||||

2b. Respondent uses the initiator's public key for the | ||||

value Q_3, and the initiator's ephemeral public key | ||||

for the value Q_4. | ||||

2c. Using the associate value function avf (see X9.63-2001 | ||||

section 5.6.1), and the values d_1, d_2 and Q_2 as | ||||

above (their own private key is both d_1 and d_2, | ||||

while Q_2 is their public key), the Respondent | ||||

calculates the implicit signature | ||||

S_r = d_2 + (avf(Q_2) x d_1) mod n. | ||||

2d. Using the associate value function avf, the signature | ||||

just calculated, the system cofactor h, the respondent's | ||||

public key, and the respondent's ephemeral public key, | ||||

the Respondent finds the EC point | ||||

P = h x S_r x (Q_4 + (avf(Q_4) x Q_3)). | ||||

2e. Respondent verifies that P != 0. | ||||

2f. Respondent sets z = x_P, where x_P is the x-coordinate | ||||

of P. | ||||

3. Respondent converts z to bit string Z, using the convention | ||||

specified in X9.63-2001 section 4.3.3. | ||||

4. Respondent uses the key derivation function described in | ||||

X9.63-2001 section 5.6.3 with the hash function given in table | ||||

MQV_PARAMS to derive the keying data; the length of the key to | ||||

be generated is also given in MQV_PARAMS. | ||||

6. Additional MIKEY payloads | 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. | ||||

6.1 ECCPT payload format | Both SIGNi and SIGNr will use ECDSA as a signature algorithm, as | |||

described in Section 2. | ||||

The ECCPT payload provides for the transport of an EC point in the | As in MIKEY-RSA, it is possible to cache the ECIES-derived key, so | |||

MIKEY-MQV and in the MIKEY-RSA exchange when ECIES is in use. It is | that it can be used as a pre-shared key. | |||

of the form: | ||||

1 2 3 | ECIES is described in detail in [SEC1]. For ECIES, the key | |||

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

! Next payload ! Point length ! Pt data ... ! | 160. The 'standard' elliptic curve Diffie-Hellman primitive MUST be | |||

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | used (as opposed to 'cofactor'). The symmetric encryption scheme | |||

~ Point data ~ | that MUST be used depends on the key size, as follows: | |||

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||

Point length is the length of the point data in *bits*. | ECC2N | ECP | Symmetric Cipher To Use | |||

163 | 192 | 3DES-CBC | ||||

283 | 256 | AES-128-CBC | ||||

409 | 384 | AES-256-CBC | ||||

571 | 521 | AES-256-CBC | ||||

The point_data field is padded to end on a 32-bit boundary, and is | Table 3: Symmetric cipher to use with ECIES | |||

encoded as per ANSI X9.63-2001 4.3.6. Uncompressed format MUST be | ||||

supported. Hybrid and compressed formats MAY be supported. | ||||

7. Multicast applications of MQV and ECIES | 5. MIKEY-ECMQV | |||

Both MQV and ECDSA/ECIES may be used in multicast environments to | ECMQV (Elliptic Curve Menezes-Qu-Vanstone) is a 3-pass or 1-pass | |||

establish a group TEK, in the same fashion as MIKEY-RSA. | protocol that has been standardized in ANSI X9.63 [ANSI-X9.63]. Both | |||

modes of ECMQV provide mutual authentication between the | ||||

communicating parties and key establishment for the secure transport | ||||

of data. Here we describe the new MIKEY-ECMQV method based on the | ||||

1-pass protocol. | ||||

8. Recommended and optional domain parameter sets | Initiator Responder | |||

8.1 Available domain parameter sets | I_MESSAGE = | |||

HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, | ||||

ECCPT, KEMAC, [CHASH], SIGNi ---> | ||||

Elliptic curve domain parameter sets available for use in this | R_MESSAGE = | |||

protocol for all methods employing EC primitives--and given here-- | [<---] HDR, T, [IDr], V | |||

are the fifteen groups that NIST recommends in FIPS 186-2 | ||||

[FIPS-186-2]. Detailed descriptions of the ECC groups recommended | ||||

here for MIKEY are not given in this document but can be found | ||||

elsewhere: All fifteen groups are detailed in each of FIPS 186-2 | ||||

[FIPS-186-2] and SEC 2 [SEC-2]. The elliptic curve domain parameters | ||||

are uniquely identified in this document using the ASN.1 object | ||||

identifiers provided in ANSI X9.63 [X9.63], which are also given in | ||||

SEC2 [SEC-2]. | ||||

The fifteen groups proposed in this document use elliptic curves over | The ECCPT contains the elliptic curve point that represents the | |||

GF[2^N] with N prime or over GF[P] with P prime. Six of the groups | ephemeral public key contributed by the Initiator. | |||

proposed here have been assigned identifiers by IANA [IANA] and the | ||||

remaining nine curves recommended by NIST might later be assigned | ||||

identifiers by IANA. See also the 'IANA considerations' section. | ||||

IANA Group Descriptions X9.63 (and SEC 2) OID | As in MIKEY-RSA, the KEMAC contains a set of encrypted sub-payloads | |||

---- ----------------------------- --------------------- | and a MAC: | |||

NA ECPRGF192Random group P-192 secp192r1 | KEMAC = E(encr_key, IDi || {TGK}) || MAC | |||

NA EC2NGF163Random group B-163 sect163r2 | ||||

7 EC2NGF163Koblitz group K-163 sect163k1 | ||||

NA ECPRGF224Random group P-224 secp224r1 | The encr_key and auth_key are derived from the ECMQV-derived key by | |||

NA EC2NGF233Random group B-233 sect233r1 | using the algorithm described in Section 4.1.4 of [RFC3830], in | |||

NA EC2NGF233Koblitz group K-233 sect233k1 | identical fashion as the envelope key used in the MIKEY-RSA. | |||

NA ECPRGF256Random group P-256 secp256r1 | 1-pass ECMQV is described in detail in ANSI X9.63 [ANSI-X9.63]. | |||

8 EC2NGF283Random group B-283 sect283r1 | ||||

9 EC2NGF283Koblitz group K-283 sect283k1 | ||||

NA ECPRGF384Random group P-384 secp384r1 | 6. Additional Payload Encoding | |||

10 EC2NGF409Random group B-409 sect409r1 | ||||

11 EC2NGF409Koblitz group K-409 sect409k1 | ||||

NA ECPRGF521Random group P-521 secp521r1 | 6.1. ECC Point payload (ECCPT) | |||

12 EC2NGF571Random group B-571 sect571r1 | ||||

13 EC2NGF571Koblitz group K-571 sect571k1 | ||||

Three curves are defined at each strength - two curves chosen | The ECCPT payload carries a point on the elliptic curve used in | |||

verifiably at random (as defined in ANSI [X9.62]), one over a | MIKEY-ECIES and MIKEY-ECMQV. The payload identifier is 22. | |||

binary field and another over a prime field, and a Koblitz curve | ||||

over a binary field that, which enables especially efficient | ||||

implementations due to the special structure of the curve [Kob, NSA]. | ||||

Note that the large number of proposed curves is for two reasons: | 1 2 3 | |||

Flexibility in implementation in using groups over prime fields | 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 | |||

(GF[p]) or binary fields (GF[2^N]), which have different | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||

characteristics; and to provide higher security strength capabilities | ! Next payload ! Point length ! Pt data ... ~ | |||

for military-grade or future uses. In ECDH, The 163-bit and 192-bit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||

curves provide equivalent security strength to Oakley group 2; all | ~ Point data ~ | |||

other proposed curves offer significantly higher security strength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||

equivalents than the three Diffie-Hellman groups included in [MIKEY]. | ||||

8.1 Recommended domain parameter sets | * Next payload (8 bits): identifies the payload that is added after | |||

this payload. See Section 6.1 for values. | ||||

It is RECOMMENDED that, for minimum interoperability, all | * Point length (16 bits): length of the Point data field (in *bits*). | |||

implementations except those in highly constrained environments | ||||

support use of the P-256 curve. | ||||

It is RECOMMENDED that implementations in constrained environments | * Point data (variable length): point data, padded to end on a 32-bit | |||

support the K163 curve. | 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. | ||||

9. 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 RFC 3830 apply here | of the security considerations contained within [RFC3830] apply here | |||

as well. | as well. Some of the methods proposed in this document offer higher | |||

cryptographic strength than those proposed in [RFC3830]. In | ||||

Some of the methods proposed in this document offer higher | particular, there are elliptic curves corresponding to each of the | |||

cryptographic strength than those proposed in RFC 3830. In | symmetric key sizes 80 bits, 128 bits, 192 bits, and 256 bits. This | |||

particular, there are elliptic curves corresponding to each of | allows the MIKEY key exchange to offer security comparable with | |||

the symmetric key sizes 80 bits, 128 bits, 192 bits, and 256 bits. | higher-strength AES algorithms and SHA implementations. The methods | |||

This allows the MIKEY key exchange to offer security comparable | proposed in this document are among those standardized by NIST in | |||

with higher-strength AES algorithms and SHA implementations. | 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]. | ||||

The methods proposed in this document are among those standardized | ||||

by NIST in FIPS 186-2 [DSS], by the SECG in SEC2 [SEC2], and by ANSI | ||||

in ANSI X9.62 [X9.62] and X9.63 [X9.63]. | ||||

Proper validation of elliptic curve public keys can help prevent the | ||||

attacks described in [BMM]. | ||||

10. IANA Considerations | ||||

This specification requires additional parameter sets be defined for | ||||

use in MIKEY when elliptic curve cryptographic methods are used. | ||||

These are listed in section 8.1. | ||||

It is requested that these be added to the namespace for the | 8. IANA Considerations | |||

DH-Group field in table 6.4 of RFC 3830, which that document requests | ||||

shall be managed by the IANA. | ||||

12. References | This document adds entries to existing MIKEY namespaces in Section 2 | |||

(S types in signature payloads), Section 3 (DH Group identifier in DH | ||||

payloads), and Section 6.1 (ECCPT payload identifier). | ||||

[IANA] Internet Assigned Numbers Authority. Attribute Assigned | 9. References | |||

Numbers. | ||||

(http://www.isi.edu/in-notes/iana/assignments/ipsec-registry) | ||||

[IEEE 1363A-2004] Institute of Electrical and Electronics Engineers, | 9.1. Normative References | |||

IEEE P1363a, Draft Standard Specifications for Public Key | ||||

Cryptography - Amendment 1: Additional Techniques. | ||||

[KOB] N. Koblitz, CM curves with good cryptographic properties. | [ANSI-X9.62] | |||

Proceedings of Crypto '91. Pages 279-287. Springer-Verlag, 1992. | American National Standards Institute, "ANSI X9.62: Public | |||

Key Cryptography For The Financial Services Industry: The | ||||

Elliptic Curve Digital Signature Algorithm (ECDSA)", 2005. | ||||

[FIPS-186-2] U.S. Department of Commerce/National Institute of | [ANSI-X9.63] | |||

Standards and Technology. Digital Signature Standard (DSS), FIPS | American National Standards Institute, "ANSI X9.63: Public | |||

PUB 186-2, January 2000. | Key Cryptography For The Financial Services Industry: Key | |||

(http://csrc.nist.gov/fips/fips186-2.pdf) | Agreement and Key Transport using Elliptic Curve | |||

Cryptography", 2001. | ||||

[HOF] P. Hoffman and H. Orman, Determining strengths for public keys | [FIPS-186-2] | |||

used for exchanging symmetric keys, Internet-draft. August 2000. | National Institute of Standards and Technology, "FIPS | |||

186-2 Digital Signature Standard", 2000. | ||||

[LEN] A. Lenstra and E. Verhuel, Selecting cryptographic key sizes. | [IANA] Internet Assigned Numbers Authority, "Attribute Assigned | |||

Available at: www.cryptosavvy.com. | Numbers.", <http://www.isi.edu/in-notes/iana/assignments/ | |||

ipsec-registry>. | ||||

[MIKEY] [RFC-3830] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, | [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and | |||

K. Norrman, MIKEY: Multimedia Internet KEYing, RFC 3830, August | Identifiers for the Internet X.509 Public Key | |||

2004. | Infrastructure Certificate and Certificate Revocation List | |||

(CRL) Profile", RFC 3279, April 2002. | ||||

[NSA] J. Solinas, An improved algorithm for arithmetic on a family | [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. | |||

of elliptic curves, Proceedings of Crypto '97, Pages 357-371, | Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, | |||

Springer-Verlag, 1997. | August 2004. | |||

[RFC-3278] S. Blake-Wilson, D. Brown and P. Lambert, The Use of | [SEC1] Standards for Efficient Crytopgraphy Group, "Elliptic | |||

Elliptic Curve Cryptography (ECC) Algorithms in the Cryptographic | Curve Cryptography", September 2000. | |||

Message Syntax (CMS), RFC 3279, April 2002. | ||||

[RFC-3279] W. Polk, R. Housley, and L. Bassham, Algorithms and | [SEC2] Standards for Efficient Crytopgraphy Group, "Recommended | |||

Identifiers for the Internet X.509 Public Key Infrastructure | Elliptic Curve Domain Parameters", September 2000. | |||

Certificate and Certificate Revocation List (CRL) Profile, RFC | ||||

3279, April 2002. | ||||

[SEC2] Standards for Efficient Cryptography Group. SEC 2 - | 9.2. Informative References | |||

Recommended Elliptic Curve Domain Parameters. Working Draft | ||||

Ver. 1.0., 2000. (http://www.secg.org) | ||||

[X9.62] American National Standards Institute, ANSI X9.62-1998: | [HOF] Hoffman, P. and H. Orman, "Determining strengths for | |||

Public Key Cryptography for the Financial Services Industry: The | public keys used for exchanging symmetric keys", | |||

Elliptic Curve Digital Signature Algorithm. January 1999. | August 2000. | |||

[X9.63] American National Standards Institute. ANSI X9.63-2001, | [LEN] Lenstra, A. and E. Verhuel, "Selecting cryptographic key | |||

Public Key Cryptography for the Financial Services Industry: Key | sizes", <http://www.cryptosavvy.com>. | |||

Agreement and Key Transport using Elliptic Curve Cryptography. | ||||

November 2001. | ||||

[HANKERSON] Hankerson, Darrel et al. "Guide to Elliptic Curve | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||

Cryptography". Springer-Verlag, 2004. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||

Authors' Addresses | Authors' Addresses | |||

Andrew Milne | Andrew Milne | |||

Certicom Corp. | ||||

amilne@certicom.com | ||||

Mitch Blaser | Mitch Blaser | |||

Certicom Corp. | Certicom Corp. | |||

mblaser@certicom.com | 5520 Explorer Drive | |||

Mississauga, Ontario L4W 5L1 | ||||

CANADA | ||||

Phone: +1-905-507-4220 | ||||

Fax: +1-905-507-4230 | ||||

Email: mblaser@certicom.com | ||||

URI: http://www.certicom.com | ||||

Daniel R. L. Brown | Daniel R. L. Brown | |||

Certicom Corp. | Certicom Corp. | |||

dbrown@certicom.com | 5520 Explorer Drive | |||

Mississauga, Ontario L4W 5L1 | ||||

CANADA | ||||

Phone: +1-905-507-4220 | ||||

Fax: +1-905-507-4230 | ||||

Email: dbrown@certicom.com | ||||

URI: http://www.certicom.com | ||||

Eugene Chin | ||||

Certicom Corp. | ||||

5520 Explorer Drive | ||||

Mississauga, Ontario L4W 5L1 | ||||

CANADA | ||||

Phone: +1-905-507-4220 | ||||

Fax: +1-905-507-4230 | ||||

Email: mblaser@certicom.com | ||||

URI: http://www.certicom.com | ||||

Lakshminath Dondeti | Lakshminath Dondeti | |||

Qualcomm, Inc. | QUALCOMM, Inc. | |||

ldondeti@qualcomm.com | 5775 Morehouse Drive | |||

San Diego, CA | ||||

USA | ||||

Expiry reminder | Phone: +1-858-845-1267 | |||

Email: ldondeti@qualcomm.com | ||||

This draft expires December 1, 2005. | Full Copyright Statement | |||

Copyright (C) The Internet Society (2005). This document is subject | Copyright (C) The Internet Society (2006). | |||

to the rights, licenses and restrictions contained in BCP 78, and | ||||

except as set forth therein, the authors retain all their rights. | This document is subject to the rights, licenses and restrictions | |||

contained in BCP 78, and except as set forth therein, the authors | ||||

retain all their rights. | ||||

This document and the information contained herein are provided on an | 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 AND THE INTERNET | |||

ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |||

INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |||

INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | 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 | ||||

The IETF takes no position regarding the validity or scope of any | ||||

Intellectual Property Rights or other rights that might be claimed to | ||||

pertain to the implementation or use of the technology described in | ||||

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

made any independent effort to identify any such rights. Information | ||||

on the procedures with respect to rights in RFC documents can be | ||||

found in BCP 78 and BCP 79. | ||||

Copies of IPR disclosures made to the IETF Secretariat and any | ||||

assurances of licenses to be made available, or the result of an | ||||

attempt made to obtain a general license or permission for the use of | ||||

such proprietary rights by implementers or users of this | ||||

specification can be obtained from the IETF on-line IPR repository at | ||||

http://www.ietf.org/ipr. | ||||

The IETF invites any interested party to bring to its attention any | ||||

copyrights, patents or patent applications, or other proprietary | ||||

rights that may cover technology that may be required to implement | ||||

this standard. Please address the information to the IETF at | ||||

ietf-ipr@ietf.org. | ||||

Acknowledgment | ||||

Funding for the RFC Editor function is provided by the IETF | ||||

Administrative Support Activity (IASA). | ||||

End of changes. 100 change blocks. | ||||

438 lines changed or deleted | | 336 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/ |