Internet DRAFT - draft-dugal-tls-ecmqv
draft-dugal-tls-ecmqv
Internet-Draft R. Dugal
October 2006 B. Minard
Expires: April 19, 2007 Certicom Corp.
October 16, 2006
ECMQV Ciphersuites for TLS
draft-dugal-tls-ecmqv-01
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
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 19, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes the changes necessary to permit Transport
Layer Security (TLS) to support the Elliptic Curve Menezes-Qu-
Vanstone Key Agreement (ECMQV).
Dugal & Minard Expires April 19, 2007 [Page 1]
Internet-Draft ECMQV in TLS October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. ECMQV Key Exchange Algorithms . . . . . . . . . . . . . . . . 4
3. Client Authentication . . . . . . . . . . . . . . . . . . . . 6
4. Data Structures and Computations . . . . . . . . . . . . . . . 7
4.1. Server Certificate . . . . . . . . . . . . . . . . . . . . 7
4.2. Server Key Exchange . . . . . . . . . . . . . . . . . . . 7
4.3. Certificate Request . . . . . . . . . . . . . . . . . . . 8
4.4. Client Certificate . . . . . . . . . . . . . . . . . . . . 8
4.5. Client Key Exchange . . . . . . . . . . . . . . . . . . . 9
4.6. Certificate Verify . . . . . . . . . . . . . . . . . . . . 10
4.7. ECMQV, ECDSA, and RSA Computations . . . . . . . . . . . . 11
5. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Dugal & Minard Expires April 19, 2007 [Page 2]
Internet-Draft ECMQV in TLS October 2006
1. Introduction
This document describes the changes necessary to permit TLS to
support the Elliptic Curve Menezes-Qu-Vanstone Key Agreement (ECMQV)
with ECDSA- and RSA-signed certificates. These changes permit the
use of Full MQV in TLS [2] and are applicable to TLS Version 1.0 [4]
and TLS Version 1.1 [9].
The ECMQV key exchange algorithm is designed to provide a variety of
security goals such as mutual implicit key authentication, known-key
security, and forward secrecy [2] [13]. Each of these security goals
is achieved through the use of Full MQV with mutually authenticated
peers. The use of Full MQV with anonymous clients is also defined.
Note: the addition of ECMQV to TLS was first proposed in ECC Cipher
Suites for TLS (draft-ietf-tls-ecc-00.txt, March 13, 1998), a
predecessor of [10]. This document provides an update to ECC Cipher
Suites for TLS [10].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
Dugal & Minard Expires April 19, 2007 [Page 3]
Internet-Draft ECMQV in TLS October 2006
2. ECMQV Key Exchange Algorithms
The ECMQV_ECDSA and ECMQV_RSA key exchange algorithms are added to
TLS. These key exchange algorithms use fixed ECMQV-capable keys in
certificates. Two ephemeral ECMQV public keys are also exchanged.
The exchange of ephemeral public keys occurs in the ServerKeyExchange
and ClientKeyExchange messages (see Section 4.2 and Section 4.5,
respectively).
In ECMQV_ECDSA, the server MUST have a certificate containing an
ECMQV-capable key. Both the client and server MUST generate an
ephemeral ECMQV key. The client MUST provide the server with either
a certificate containing an ECMQV-capable key, a static ECMQV key, or
a second ephemeral ECMQV key. If the client has a suitable
certificate then it MUST send that certificate in the
ClientCertificate message. This message has the same format and
meaning as the message defined in [10].
The option to provide a static ECMQV key to the server allows for the
possibility that the server has another means of validating the
binding of that public key to the client. We differentiate between
static and ephemeral keys: no binding exists between an ephemeral key
and the peer generating it.
In the absence of both a suitable certificate and a static key the
client MUST send a second ephemeral key. The two ephemeral keys sent
in this case MAY be the same key.
An ECMQV-capable key is an ECC key whose use in ECMQV is permitted.
All key-pairs MUST be generated using the same elliptic curve
parameters and the client's certificate MUST be eligible for use with
client authentication. Each certificate MUST be signed with ECDSA
[1].
Note that there is no structural difference between ECDSA and ECMQV
keys. A certificate issuer MAY use the X.509 v3 keyUsage and
extendedKeyUsage extensions to restrict the use of an ECC public key
to certain computations [6]. X509 certificates containing ECC public
keys or signed using ECDSA MUST comply with [5] or another RFC that
replaces or extends it. Clients SHOULD use the elliptic curve domain
parameters recommended in ANSI X9.62 [1], FIPS 186-2 [12], and SEC 2
[14].
The ECMQV_RSA key exchange algorithm is the same as ECMQV_ECDSA,
except that each certificate MUST be signed with RSA [8].
The ECMQV_RSA key exchange algorithm allows the certificate issuer to
continue using existing RSA certificates for signing whereas the
Dugal & Minard Expires April 19, 2007 [Page 4]
Internet-Draft ECMQV in TLS October 2006
ECMQV_ECDSA key exchange algorithm requires the certificate issuer to
adopt an ECC certificate. Regardless of the key exchange algorithm
used, the server MUST adopt an ECC certificate.
Client Server
------ ------
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*+
<-------- ServerHelloDone
Certificate*+
ClientKeyExchange
CertificateVerify*+
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
* message is not sent under some conditions
+ message is not sent unless client authentication is
desired
Figure 1: Message flow in a full TLS handshake
Figure 1 shows all of the messages in the TLS key establishment
protocol. The addition of ECMQV has a direct impact on the
ServerCertificate, ServerKeyExchange, CertificateRequest,
ClientCertificate, ClientKeyExchange, and CertificateVerify messages.
Each of these messages are discussed in Section 4.
All other messages have the format and meaning defined in [10].
Dugal & Minard Expires April 19, 2007 [Page 5]
Internet-Draft ECMQV in TLS October 2006
3. Client Authentication
The ECDSA_mqv and RSA_mqv client authentication mechanisms are added
to TLS. These authentication mechanisms permit the client's
certified ECMQV public key to participate in the key exchange.
If the server sends a CertificateRequest message containing the
ECDSA_mqv authentication type, then the client SHOULD send the server
both a certificate containing an ECMQV-capable public key and an
ephemeral ECMQV public key. The client's certificate is signed with
ECDSA and sent in the ClientCertificate message and the ephemeral
ECMQV public key is provided in the ClientKeyExchange message (see
Section 4.5).
If the client does not have a certificate eligible for client
authentication then the client MUST provide the server with either a
static ECMQV key or a second ephemeral ECMQV key. The public half of
this ECMQV key is sent to the server in the ClientKeyExchange message
(see Section 4.5).
A certificate is eligible for client authentication if the ECMQV
public key contained in that certificate uses the same elliptic curve
domain parameters as the server's public keys and if it respects the
server's choice of point format.
All ECMQV keys sent by the client MUST be generated using the same
elliptic curve parameters used to generate the server's public keys.
The RSA_mqv client authentication mechanism is the same as the
ECDSA_mqv client authentication mechanism, except that the client's
certificate is signed with RSA.
Dugal & Minard Expires April 19, 2007 [Page 6]
Internet-Draft ECMQV in TLS October 2006
4. Data Structures and Computations
The TLS presentation language is used to specify new data structures
required to support the ECMQV key exchange algorithm (see [9] and
[4]). These specifications extend the TLS protocol specification and
MUST be merged with those in TLS [4] and in any other specifications
which extend TLS ([7], [9], and [10]).
4.1. Server Certificate
The section updates Table 3, "Server certificate types" in [10],
otherwise this message is exactly as defined in [10].
+--------------+----------------------------------------------------+
| Key Exchange | Server Certificate Type |
| Algorithm | |
+--------------+----------------------------------------------------+
| ECMQV_ECDSA | Certificate MUST contain an ECMQV-capable public |
| | key. It MUST be signed with ECDSA. |
| | |
| ECMQV_RSA | Certificate MUST contain an ECMQV-capable public |
| | key. It MUST be signed with RSA. |
+--------------+----------------------------------------------------+
Table 1: Server certificate types
4.2. Server Key Exchange
When this message is sent:
This message is sent in the ECMQV_ECDSA and ECMQV_RSA key
establishment methods.
Meaning of this message:
This message is used to convey the server's ephemeral ECMQV public
key to the client.
Structure of this message:
The ServerKeyExchange message is extended as follows.
enum { ec_menezes_qu_vanstone } KeyExchangeAlgorithm;
Dugal & Minard Expires April 19, 2007 [Page 7]
Internet-Draft ECMQV in TLS October 2006
struct {
ECPoint ecmqv_ephemeral;
} ServerECMQVPublic;
struct {
select (KeyExchangeAlgorithm) {
case ec_menezes_qu_vanstone:
ServerMQVPublic public;
};
} ServerKeyExchange;
ec_menezes_qu_vanstone: Indicates the ServerKeyExchange message
contains an ECMQV public key.
public: Specifies the ECMQV public key.
Actions of the sender:
The server generates an ephemeral ECMQV public key corresponding to
the curve parameters of the server's ECMQV-capable public key sent in
the Server Certificate message. This key is used in the Full MQV
Scheme described in Section 6.10 of X9.63 [2].
It conveys this information to the client in the ServerKeyExchange
message using the format defined above.
Actions of the recipient:
The client retrieves the server's ephemeral ECMQV public key from the
ServerKeyExchange message.
4.3. Certificate Request
The TLS CertificateRequest message is extended as follows.
enum {
ecdsa_mqv(??), rsa_mqv(??), (255)
} ClientCertificateType;
ecdsa_mqv and rsa_mqv indicate that the server would like to use the
corresponding client authentication method (see Section 3).
This message is otherwise exactly as defined in [10].
4.4. Client Certificate
The section updates Table 4, "Client certificate types" in [10],
otherwise this message is exactly as defined in [10]. (The client
Dugal & Minard Expires April 19, 2007 [Page 8]
Internet-Draft ECMQV in TLS October 2006
certificate MUST respect the Supported Point Formats Extension
whenever this extension is used by the server.)
+-----------------+-------------------------------------------------+
| Client | Client Certificate Type |
| Authentication | |
| Method | |
+-----------------+-------------------------------------------------+
| ECDSA_mqv | Certificate MUST contain an ECMQV-capable |
| | public key. It MUST be signed with ECDSA. |
| | |
| RSA_mqv | Certificate MUST contain an ECMQV-capable |
| | public key. It MUST be signed with RSA. |
+-----------------+-------------------------------------------------+
Table 2: Client certificate types
4.5. Client Key Exchange
When this message is sent:
This message is sent in the ECMQV_ECDSA and ECMQV_RSA key
establishment methods.
Meaning of the message:
This message is used to convey ephemeral data relating to the ECMQV
key exchange belonging to the client. When the client does not have
a suitable certificate or client authentication is not requested this
message MUST contain a second ECMQV public key.
Structure of this message:
The TLS ClientKeyExchange message is extended as follows.
Dugal & Minard Expires April 19, 2007 [Page 9]
Internet-Draft ECMQV in TLS October 2006
enum { implicit, explicit } PublicValueEncoding;
implicit
If the client certificate already contains a suitable
ECMQV key, then it does not need to be sent again. In
this case, the ClientKeyExchange message will be sent,
but this value will be empty.
explicit
An ECMQV public key needs to be sent.
struct {
select(PublicValueEncoding) {
case implicit: struct {};
case explicit: ECPoint ecmqv;
} ecmqv_public;
ECPoint ecmqv_ephemeral;
} ClientECMQVPublic;
struct {
select (KeyExchangeAlgorithm) {
case ec_menezes_qu_vanstone: ClientECMQVPublic;
} exchange_keys;
} ClientKeyExchange;
Actions of the sender:
If the client has sent a certificate with an MQV key, ecmqv_ephemeral
will contain the client's ephemeral public key for the MQV operation;
otherwise ecmqv_ephemeral will contain an ephemeral public key that
is used as the ephemeral public key for the MQV operation and ecmqv
will contain a second ECMQV public key which takes the place of the
certified key.
Actions of the recipient:
The server retrieves the client's ECMQV public keys from the
ClientKeyExchange message and checks that it is on the same elliptic
curve as the server's ECMQV key.
4.6. Certificate Verify
The CertificateVerify message is never used. The client's ability to
arrive at the same premaster secret as the server is sufficient to
demonstrate its control over the private half of the certified ECMQV
public key.
Dugal & Minard Expires April 19, 2007 [Page 10]
Internet-Draft ECMQV in TLS October 2006
4.7. ECMQV, ECDSA, and RSA Computations
All ECMQV calculations (including the elliptic curve parameters, key
generation, and the shared secret calculation) are performed
according to the Full MQV Scheme described in Section 6.10 of X9.63
[2].
All ECDSA computations MUST be performed according to ANSI X9.62 [1]
or its successors. Data to be signed or verified is hashed and the
result run directly through the ECDSA algorithm with no additional
hashing. The default hash function is SHA-1 [11] and sha_size
Section 4.7) is 20. However, an alternative hash function, such as
one of the new SHA hash functions specified in FIPS 180-2 [11], MAY
be used instead if the certificate containing the EC public key
explicitly requires use of another hash function. (The mechanism for
specifying the required hash function has not been standardized but
this provision anticipates such standardization and obviates the need
to update this document in response. Future PKIX RFCs may choose,
for example, to specify the hash function to be used with a public
key in the parameters field of subjectPublicKeyInfo.)
All RSA signatures MUST be verified according to [8], or its
successors.
Dugal & Minard Expires April 19, 2007 [Page 11]
Internet-Draft ECMQV in TLS October 2006
5. Cipher Suites
The following cipher suites are defined:
+-------------------------------------------------------------------+
| CipherSuite TLS_ECMQV_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } |
| |
| CipherSuite TLS_ECMQV_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } |
| |
| CipherSuite TLS_ECMQV_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? |
| } |
| |
| CipherSuite TLS_ECMQV_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } |
| |
| CipherSuite TLS_ECMQV_ECDSA_WITH_AES_128_CBC_SHA256 = { 0x00, |
| 0x?? } |
| |
| CipherSuite TLS_ECMQV_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } |
| |
| CipherSuite TLS_ECMQV_ECDSA_WITH_AES_256_CBC_SHA384 = { 0x00, |
| 0x?? } |
| |
| CipherSuite TLS_ECMQV_RSA_WITH_NULL_SHA = { 0x00, 0x?? } |
| |
| CipherSuite TLS_ECMQV_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } |
| |
| CipherSuite TLS_ECMQV_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } |
| |
| CipherSuite TLS_ECMQV_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } |
| |
| CipherSuite TLS_ECMQV_RSA_WITH_AES_128_CBC_SHA256 = { 0x00, 0x?? |
| } |
| |
| CipherSuite TLS_ECMQV_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } |
| |
| CipherSuite TLS_ECMQV_RSA_WITH_AES_256_CBC_SHA384 = { 0x00, 0x?? |
| } |
+-------------------------------------------------------------------+
Table 3: TLS ECMQV cipher suites
Server implementations SHOULD support all of the cipher suites
defined here and client implementations should support at least one
of the following cipher suites:
TLS_ECMQV_ECDSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECMQV_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECMQV_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECMQV_RSA_WITH_3DES_EDE_CBC_SHA,
Dugal & Minard Expires April 19, 2007 [Page 12]
Internet-Draft ECMQV in TLS October 2006
TLS_ECMQV_RSA_WITH_AES_128_CBC_SHA, or
TLS_ECMQV_RSA_WITH_AES_128_CBC_SHA256.
Dugal & Minard Expires April 19, 2007 [Page 13]
Internet-Draft ECMQV in TLS October 2006
6. Security Considerations
This document is based on X9.62 [1], RFC 2246 [4], RFC 3268 [15], RFC
4346 [9], RFC 4492 [10], and IEEE 1363 [16]. The appropriate
security considerations of those documents apply.
Implementors SHOULD select security levels appropriate for their
application. X9.62 [1] measures security level in bits. The
approved security levels are: 80-, 112-, 128-, 192-, and 265-bits.
The security level provided by ECDSA is dependent upon the security
level of each cryptographic component used in an ECDSA operation. In
general, the hash algorithm used for ECDSA signature generation
SHOULD more or less match the symmetric key size shown in the
following table (reproduced for convenience from [10]).
+---------------+-------------+------------+
| Symmetric Key | ECDSA/ECMQV | DH/DSA/RSA |
+---------------+-------------+------------+
| 80 | 163 | 1024 |
| | | |
| 112 | 233 | 2048 |
| | | |
| 128 | 283 | 3072 |
| | | |
| 192 | 409 | 7680 |
| | | |
| 256 | 571 | 15360 |
+---------------+-------------+------------+
Table 4: Comparable Key Sizes
Dugal & Minard Expires April 19, 2007 [Page 14]
Internet-Draft ECMQV in TLS October 2006
7. IANA Considerations
TBD.
Dugal & Minard Expires April 19, 2007 [Page 15]
Internet-Draft ECMQV in TLS October 2006
8. Acknowledgments
Thanks to Dan Brown for reviewing this document.
Dugal & Minard Expires April 19, 2007 [Page 16]
Internet-Draft ECMQV in TLS October 2006
9. References
9.1. Normative References
[1] American National Standards Institute, "ANSI X9.62: Public Key
Cryptography For The Financial Services Industry: The Elliptic
Curve Digital Signature Algorithm (ECDSA)", 2005.
[2] American National Standards Institute, "ANSI X9.63: Public Key
Cryptography For The Financial Services Industry: Key Agreement
and Key Transport using Elliptic Curve Cryptography", 2001.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[5] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile",
RFC 3279, April 2002.
[6] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[7] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions",
RFC 3546, June 2003.
[8] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms
and Identifiers for RSA Cryptography for use in the Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 4055, June 2005.
[9] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[10] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for
Transport Layer Security (TLS)", RFC 4492, May 2006.
[11] National Institute of Standards and Technology, "FIPS 180
Secure Hashing Algorithm", 2002.
[12] National Institute of Standards and Technology, "FIPS 186-2
Digital Signature Standard", 2000.
Dugal & Minard Expires April 19, 2007 [Page 17]
Internet-Draft ECMQV in TLS October 2006
[13] Standards for Efficient Crytopgraphy Group, "Elliptic Curve
Cryptography", September 2000.
[14] Standards for Efficient Crytopgraphy Group, "Recommended
Elliptic Curve Domain Parameters", September 2000.
9.2. Informative References
[15] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002.
[16] International Electrial and Electronic Engineers, "IEEE 1363:
2000 Standard Specifications for Public Key Cryptograph", 2000.
Dugal & Minard Expires April 19, 2007 [Page 18]
Internet-Draft ECMQV in TLS October 2006
Authors' Addresses
Robert Dugal
Certicom Corp.
5520 Explorer Drive
Mississauga, Ontario L4W 5L1
CANADA
Phone: +1-905-507-4220
Fax: +1-905-507-4230
Email: rdugal@certicom.com
URI: http://www.certicom.com
Brian Minard
Certicom Corp.
5520 Explorer Drive
Mississauga, Ontario L4W 5L1
CANADA
Phone: +1-905-507-4220
Fax: +1-905-507-4230
Email: bminard@certicom.com
URI: http://www.certicom.com
Dugal & Minard Expires April 19, 2007 [Page 19]
Internet-Draft ECMQV in TLS October 2006
Intellectual Property Statement
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.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Dugal & Minard Expires April 19, 2007 [Page 20]
