Secure Shell Working Group D. Stebila Internet-Draft Sun Labs Expires: October 30, 2004 May 1, 2004 Elliptic-Curve Diffie-Hellman Key Exchange for the SSH Transport Level Protocol draft-stebila-secsh-ecdh-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 October 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Secure Shell (SSH) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement and ECDH with cofactor multiplication key agreement in the SSH Transport Layer protocol. 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 [1]. Stebila Expires October 30, 2004 [Page 1] Internet-Draft ECDH Key Exchange in SSH May 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. ECDH Parameter and Key Exchange . . . . . . . . . . . . . . 4 2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . 5 3. Key Exchange Messages . . . . . . . . . . . . . . . . . . . 7 3.1 SSH_MSG_KEX_ECDH_REQUEST . . . . . . . . . . . . . . . . . . 7 3.2 SSH_MSG_KEX_ECDH_CURVE_NAMED . . . . . . . . . . . . . . . . 7 3.3 SSH_MSG_KEX_ECDH_CURVE_GENERIC_GFP . . . . . . . . . . . . . 7 3.4 SSH_MSG_KEX_ECDH_CURVE_GENERIC_GF2M . . . . . . . . . . . . 8 3.5 SSH_MSG_KEX_ECDH_INIT . . . . . . . . . . . . . . . . . . . 8 3.6 SSH_MSG_KEX_ECDH_REPLY . . . . . . . . . . . . . . . . . . . 8 3.7 Named Elliptic Curve Domain Parameters . . . . . . . . . . . 9 3.7.1 Generic curve parameters . . . . . . . . . . . . . . . . . . 10 3.7.2 NIST-recommended curves . . . . . . . . . . . . . . . . . . 10 3.7.3 SEC-recommended curves . . . . . . . . . . . . . . . . . . . 10 3.7.4 ANSI-recommended curves . . . . . . . . . . . . . . . . . . 10 3.7.5 WTLS-recommended curves . . . . . . . . . . . . . . . . . . 10 3.8 Summary of Message Numbers . . . . . . . . . . . . . . . . . 11 4. ECDH Key Exchange Methods . . . . . . . . . . . . . . . . . 12 4.1 ecdh-exchange-sha1 . . . . . . . . . . . . . . . . . . . . . 12 4.2 ecdhc-exchange-sha1 . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . 13 6. Intellectual Property Rights . . . . . . . . . . . . . . . . 14 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . 17 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 Stebila Expires October 30, 2004 [Page 2] Internet-Draft ECDH Key Exchange in SSH May 2004 1. Introduction Elliptic Curve Cryptography (ECC) is emerging as an attractive public-key cryptosystem for mobile/wireless environments. Compared to currently prevalent cryptosystems such as RSA, DSA, and DH, ECC offers equivalent security with smaller key sizes. This is illustrated in the following table, based on [2], which gives approximate comparable key sizes for symmetric- and asymmetric-key cryptosystems based on the best known algorithms for attacking them. --------------------------------------------------------------------- Symmetric | ECC | DH/DSA/RSA -----------+-------+------------ 80 | 163 | 1024 128 | 283 | 3072 192 | 409 | 7680 256 | 571 | 15360 Figure 1: Comparable key sizes (in bits) --------------------------------------------------------------------- Smaller key sizes result in power, bandwidth, and computational savings that make ECC especially attractive for constrained environments. This document describes additions to SSH to support the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme to establish a shared key, either with or without cofactor multiplication. Implementation of this specification requires familiarity with both SSH [3][4] and ECC [5][6][7]. Stebila Expires October 30, 2004 [Page 3] Internet-Draft ECDH Key Exchange in SSH May 2004 2. ECDH Parameter and Key Exchange 2.1 Description The first stage of the key exchange mechanism is the exchange of elliptic curve domain parameters. These parameters define a finite field (either GF(p), a field of integers modulo a large prime p, or GF(2^m), the field of binary polynomials of degree m or less), an elliptic curve over that finite field, a point on that curve, and the order and cofactor of the subgroup generated by scalar-point multiplication by that point. Random elliptic curve domain parameters can be generated upon each request. However, this is costly and may result in the generation of parameters the security of which is untested. As a result, there are a number of so-called named elliptic curve domain parameters defined by various standards organizations [8][9][10][11]. In the following: C is the client, S is the server; curves is a list of supported named curves and generic identifiers; min is the minimal size in bits of acceptable generic elliptic curve domain parameters, or 0; pref is the preferred size in bits of acceptable generic elliptic curve domain parameters, or 0; max is the maximal size in bits of acceptable generic elliptic curve domain parameters, or 0; curve is a named curve or generic identifier; prime is a prime defining a prime field; irr is an irreducible polynomial defining a binary field; a is the curve parameter a; b is the curve parameter b; x is the x-coordinate of the generator; y is the y-coordinate of the generator; order is the order of the generator; cofactor is the cofactor of the generator; seed is the the binary string used as a seed for random generation of the elliptic curve domain parameters, or ""; c_x is the x-coordinate of the client's public key; c_y is the y-coordinate of the client's public key; s_x is the x-coordinate of the server's public key; s_y is the y-coordinate of the server's public key; and K is the shared secret. 1. C sends "curves", a list of preferred named elliptic curve domain parameters and, optionally, a range of bit sizes "min || pref || max" over which generic elliptic curve domain parameters are acceptable. 2. S selects the first curve in the list of preferred curves that it supports. If S selects a named curve, S returns the name as "curve". If S selects a set of generic elliptic curve domain parameters, then S creates or selects a set of elliptic curve domain parameters in the requested range, if S supports a curve in that range; S sends the elliptic curve domain parameters to C: either "prime || a || b || x || y || order || cofactor || seed" Stebila Expires October 30, 2004 [Page 4] Internet-Draft ECDH Key Exchange in SSH May 2004 for a prime curve or "irr || a || b || x || y || order || cofactor || seed" for a binary curve. 3. If S sends a set of generic elliptic curve domain parameters, then C MAY verify that the curve was generated at random, using for example the verification algorithms defined in section A.16.8 of [6]. If C decides to accept the parameters, then C generates an elliptic curve public-key / private-key pair using the selected elliptic curve domain parameters and sends the public- key value "c_x || c_y" to S. 4. S MAY validate C's public-key value using for example algorithm A.16.10 of [6]. S generates an elliptic curve public-key / private-key pair using the selected elliptic curve domain parameters; the public-key value is "s_x || s_y". S uses C's public-key value to compute the shared secret K using the key derivation function KDF. S computes the hash H of all values transmitted in the key exchange concatenated with K, and the signature s on H using its private host key. S sends "K_S || s_x || s_y || s", where K_S is S's public host key. 5. C MAY validate S's public-key value using for example algorithm A.16.10 of [6]. C verifies that K_S really is the host key for S (e.g., using certificates or a local database). C is also allowed to accept the key without verification; however, doing so will render the protocol insecure against active attacks (but may be desirable for practical reasons in the short term in many environments). C uses S's public-key value to compute the shared secret using the key derivation function KDF and verifies the signature s on H. When selecting a set of generic elliptic curve domain parameters, the server SHOULD choose the smallest domain parameters it knows that are not smaller than the size the client requested. If the server does not know any domain parameters that are not smaller than the client request, then it MUST return the largest domain parameters it knows. In all cases, the size of the returned domain parameters SHOULD be at least 112 bits, and preferably at least 160 bits. Note that size of domain parameters is measured as the size in bits of the order of the generator. 2.2 Implementation This key exchange algorithm is implemented with the following messages. The hash algorithm for computing the exchange hash is defined by the method name, and is called HASH. The key derivation function for computing the shared secret is defined by the method name, and is called KDF. The public key algorithm for signing is Stebila Expires October 30, 2004 [Page 5] Internet-Draft ECDH Key Exchange in SSH May 2004 negotiated with the KEXINIT messages. 1. The client sends the SSH_MSG_KEX_ECDH_REQUEST (Section 3.1) message. The value of curves is an ordered list of preferred elliptic curve domain parameters. In addition to the standardized named curves, there are two options for generic curves: generic-gfp and generic-gf2m. If curves contains either generic-gfp or generic-gf2m, the client MUST specify a range of acceptable curve sizes using the min, pref, and max values; otherwise, the values min, pref, and max MUST be 0. The following inequalities MUST be satisfied: min <= pref <= max. 2. The server responds with one of the following messages: * SSH_MSG_KEX_ECDH_CURVE_NAMED (Section 3.2) * SSH_MSG_KEX_ECDH_CURVE_GENERIC_GFP (Section 3.3) * SSH_MSG_KEX_ECDH_CURVE_GENERIC_GF2M (Section 3.4) 3. If the server responds with SSH_MSG_KEX_ECDH_CURVE_NAMED (Section 3.2), then the value of curve MUST be an element of the list curves, and MUST NOT be either generic-gfp or generic-gf2m. 4. If the server responds with either the SSH_MSG_KEX_ECDH_CURVE_GENERIC_GFP (Section 3.3) or SSH_MSG_KEX_ECDH_CURVE_GENERIC_GF2M (Section 3.4) message, then generic-gfp or generic-gf2m, respectively, MUST be in the list curves, and the size in bits of the order of the generator MUST be in the range min .. max inclusively, unless the server does not support any curves in that range, in which case the server MUST return the largest curve below that range that it supports. 5. The client sends the SSH_MSG_KEX_ECDH_INIT (Section 3.5) message. 6. The server responds with the SSH_MSG_KEX_ECDH_REPLY (Section 3.6) message. Stebila Expires October 30, 2004 [Page 6] Internet-Draft ECDH Key Exchange in SSH May 2004 3. Key Exchange Messages The following message formats are defined in this document. The messages are used as described in Section 2. 3.1 SSH_MSG_KEX_ECDH_REQUEST byte SSH_MSG_KEX_ECDH_REQUEST name-list curves, a list of supported named curves and generic identifiers uint32 min, minimal size in bits of acceptable generic elliptic curve domain parameters, or 0 uint32 pref, preferred size in bits of acceptable generic elliptic curve domain parameters, or 0 uint32 max, maximal size in bits of acceptable generic elliptic curve domain parameters, or 0 3.2 SSH_MSG_KEX_ECDH_CURVE_NAMED byte SSH_MSG_KEX_ECDH_CURVE_NAMED string curve, a named curve or generic identifier The value of curve MUST NOT be either generic-gfp or generic-gf2m. 3.3 SSH_MSG_KEX_ECDH_CURVE_GENERIC_GFP byte SSH_MSG_KEX_ECDH_CURVE_GENERIC_GFP mpint prime, the prime defining the field mpint a, the curve parameter a mpint b, the curve parameter b mpint x, the x-coordinate of the generator mpint y, the y-coordinate of the generator mpint order, the order of the generator uint32 cofactor, the cofactor of the generator string seed, the binary string used as a seed for random generation of the elliptic curve domain parameters Stebila Expires October 30, 2004 [Page 7] Internet-Draft ECDH Key Exchange in SSH May 2004 3.4 SSH_MSG_KEX_ECDH_CURVE_GENERIC_GF2M byte SSH_MSG_KEX_ECDH_CURVE_GENERIC_GF2M mpint irr, the irreducible polynomial defining the field mpint a, the curve parameter a mpint b, the curve parameter b mpint x, the x-coordinate of the generator mpint y, the y-coordinate of the generator mpint order, the order of the generator uint32 cofactor, the cofactor of the generator string seed, the binary string used as a seed for random generation of the elliptic curve domain parameters 3.5 SSH_MSG_KEX_ECDH_INIT byte SSH_MSG_KEX_ECDH_INIT mpint c_x, the x-coordinate of the client's public key mpint c_y, the y-coordinate of the client's public key 3.6 SSH_MSG_KEX_ECDH_REPLY byte SSH_MSG_KEX_ECDH_REPLY string K_S, server public host key and certificates mpint s_x, the x-coordinate of the server's public key mpint s_y, the y-coordinate of the server's public key string s, the signature of H The hash H is computed as the HASH hash of the concatenation of the following. Values marked with * are included in the concatenation only if the values are from messages that were actually transmitted. For example, if the message SSH_MSG_KEX_ECDH_CURVE_NAMED (Section 3.2) is sent, then the only value marked with a * that will be included in the concatenation below is the value curve. Stebila Expires October 30, 2004 [Page 8] Internet-Draft ECDH Key Exchange in SSH May 2004 string V_C, the client's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded) string I_C, the payload of the client's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT string K_S, the host key name-list curves, a list of supported named curves and generic identifiers uint32 min, minimal size in bits of acceptable generic elliptic curve domain parameters, or 0 uint32 pref, preferredsize in bits of acceptable generic elliptic curve domain parameters, or 0 uint32 max, maximal size in bits of acceptable generic elliptic curve domain parameters, or 0 string curve*, a named curve or generic identifier mpint prime*, the prime defining the field mpint irr*, the irreducible polynomial defining the field mpint a*, the curve parameter a mpint b*, the curve parameter b mpint x*, the x-coordinate of the generator mpint y*, the y-coordinate of the generator mpint order*, the order of the generator uint32 cofactor*, the cofactor of the generator string seed*, the binary string used as a seed for random generation of the elliptic curve domain parameters mpint c_x, the x-coordinate of the client's public key mpint c_y, the y-coordinate of the client's public key mpint s_x, the x-coordinate of the server's public key mpint s_y, the y-coordinate of the server's public key mpint K, the shared secret 3.7 Named Elliptic Curve Domain Parameters The naming scheme for named elliptic curve domain parameters follows the naming conventions defined in Section 5 of [3]. Names that do not contain an at-sign (@) are reserved to be defined by IETF consensus (RFCs). Valid names of this form are listed in the following sections. Anyone can define additional named elliptic curve domain parameters by using names in the format name@domainname, e.g. "our- curve@example.com". The format of the part preceding the at-sign is not specified. The part following the at-sign MUST be a valid fully qualified internet domain name controlled by the person or organization defining the curve name. It is up to each domain how it manages its local namespace. Stebila Expires October 30, 2004 [Page 9] Internet-Draft ECDH Key Exchange in SSH May 2004 3.7.1 Generic curve parameters The following identifiers are used to indicate the use of an arbitrary generic curve over either GF(p) or GF(2^m). generic-gfp generic-gf2m 3.7.2 NIST-recommended curves The following curves are defined in [8]. It is RECOMMENDED that an implementation support at least some of these curves. nistp192 nistp224 nistp256 nistp384 nistp521 nistk163 nistb163 nistk233 nistb233 nistk283 nistb283 nistk409 nistb409 nistk571 nistb571 3.7.3 SEC-recommended curves The following curves are defined in [9]. secp112r1 secp112r2 secp128r1 secp128r2 secp160k1 secp160r1 secp160r2 secp192k1 secp192r1 secp224k1 secp224r1 secp256k1 secp256r1 secp384r1 secp521r1 sect113r1 sect113r2 sect131r1 sect131r2 sect163k1 sect163r1 sect163r2 sect193r1 sect193r2 sect233k1 sect233r1 sect239k1 sect283k1 sect283r1 sect409k1 sect409r1 sect571k1 sect571r1 3.7.4 ANSI-recommended curves The following curves are defined in [10]. prime192v1 prime192v2 prime192v3 prime239v1 prime239v2 prime239v3 prime256v1 c2pnb163v1 c2pnb163v2 c2pnb163v3 c2pnb176v1 c2tnb191v1 c2tnb191v2 c2tnb191v3 c2pnb208w1 c2tnb239v1 c2tnb239v2 c2tnb239v3 c2pnb272w1 c2pnb304w1 c2tnb359v1 c2pnb368w1 c2tnb431r1 3.7.5 WTLS-recommended curves The following curves are defined in [11]. wtls1 wtls3 wtls4 wtls5 wtls6 wtls7 wtls8 wtls9 wtls10 wtls11 wtls12 Stebila Expires October 30, 2004 [Page 10] Internet-Draft ECDH Key Exchange in SSH May 2004 3.8 Summary of Message Numbers The following message numbers have been defined in this document: --------------------------------------------------------------------- #define SSH_MSG_KEX_ECDH_REQUEST 30 #define SSH_MSG_KEX_ECDH_CURVE_NAMED 31 #define SSH_MSG_KEX_ECDH_CURVE_GENERIC_GFP 32 #define SSH_MSG_KEX_ECDH_CURVE_GENERIC_GF2M 33 #define SSH_MSG_KEX_ECDH_INIT 34 #define SSH_MSG_KEX_ECDH_REPLY 35 Figure 14: Summary of Message Numbers --------------------------------------------------------------------- The numbers 30-49 are key exchange-specific and may be redefined by other key exchange methods. Stebila Expires October 30, 2004 [Page 11] Internet-Draft ECDH Key Exchange in SSH May 2004 4. ECDH Key Exchange Methods 4.1 ecdh-exchange-sha1 The "ecdh-exchange-sha1" method specifies Elliptic Curve Diffie- Hellman Parameter and Key Exchange with SHA-1 as HASH and ECDH without cofactor multiplication as KDF. The SHA-1 hash algorithm is defined in [12]. In ECDH without cofactor multiplication, the shared secret is generated as follows. Let k be the private key, and P be the generator. Then the shared secret K is the x-coordinate of the affine representation of the point Q = k * P. 4.2 ecdhc-exchange-sha1 The "ecdhc-exchange-sha1" method specifies Elliptic Curve Diffie- Hellman Parameter and Key Exchange with SHA-1 as HASH and ECDH with cofactor multiplication as KDF. The SHA-1 hash algorithm is defined in [12]. In ECDH with cofactor multiplication, the shared secret is generated as follows. Let k be the private key, P be the generator, and h be the cofactor. Then the shared secret K is the x-coordinate of the affine representation of the point Q = (k * h) * P. Stebila Expires October 30, 2004 [Page 12] Internet-Draft ECDH Key Exchange in SSH May 2004 5. Security Considerations The Elliptic Curve Diffie-Hellman key agreement algorithm is defined in [6] and [7]. The appropriate security considerations of those documents apply. The key exchange methods defined in Section 4 rely on the SHA-1 hash algorithm as defined in [12]. The appropriate security considerations of that document apply. Server implementations that generate random elliptic curve domain parameters SHOULD generate those parameters verifiably at random, using for example the algorithms defined in section A.16.7 of [6]. Client implementations SHOULD verify that generic parameters have been generated randomly, using for example the verification algorithms defined in section A.16.8 of [6]. Since ECDH allows for elliptic curves of arbitrary sizes and thus arbitrary security strength, it is important that the size of elliptic curve be chosen to match the security strength of other elements of the SSH handshake. In particular, host key sizes and bulk encryption algorithms must be chosen appropriately. Information regarding estimated equivalence of key sizes is available in [2]. For most applications, it should be sufficient to use an existing named curve as recommended in Section 3.7. Stebila Expires October 30, 2004 [Page 13] Internet-Draft ECDH Key Exchange in SSH May 2004 6. Intellectual Property Rights The IETF has been notified of intellectual property rights claimed in regard to the specification contained in this document. For more information, consult the online list of claimed rights (http:// www.ietf.org/ipr.html). The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in [13]. Copies of claims of rights made available for publication 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 Secretariat. Stebila Expires October 30, 2004 [Page 14] Internet-Draft ECDH Key Exchange in SSH May 2004 7. Acknowledgments The author wishes to thank Sheueling Chang and Vipul Gupta of Sun Microsystems. This work was largely performed during a student internship at Sun Microsystems Laboratories from the University of Waterloo. Stebila Expires October 30, 2004 [Page 15] Internet-Draft ECDH Key Exchange in SSH May 2004 References [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes", Journal of Cryptology 14 (2001) 255-293, . [3] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh- architecture-15.txt (work in progress), October 2003. [4] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Transport Layer Protocol", draft-ietf-secsh- transport-17.txt (work in progress), October 2003. [5] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, . [6] IEEE, "Standard Specifications for Public Key Cryptography", IEEE 1363, 2000. [7] ANSI, "Public Key Cryptography For The Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography", ANSI X9.63, January 1999. [8] NIST, "Recommended Elliptic Curves for Federal Government Use", July 1999, . [9] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, 2000, . [10] ANSI, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, 1998. [11] WAP, "Wireless Transport Layer Security", WAP 261-WTLS- 20010406-a, April 2001. [12] NIST, "Secure Hash Standard", FIPS 180-2, 2002. [13] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", RFC 2028, BCP 11, October 1996. Stebila Expires October 30, 2004 [Page 16] Internet-Draft ECDH Key Exchange in SSH May 2004 Author's Address Douglas Stebila Sun Microsystems Laboratories 2600 Casey Avenue MS UMTV29-112 Mountain View, CA 94043 USA EMail: douglas.stebila@sun.com Stebila Expires October 30, 2004 [Page 17] Internet-Draft ECDH Key Exchange in SSH May 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Stebila Expires October 30, 2004 [Page 18]