Personal Draft Internet Draft Q. Dang Document: draft-dang-nistkdf-00.txt T. Polk NIST Expires: April 19 2006 October 2005 Hash-Based Key Derivation draft-dang-nistkdf-00.txt 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Copyright Notice Copyright (C) The Internet Society (2005). This Internet-Draft will expire on April 19, 2006. Abstract Dang Expires April 2006 [Page 1] Hash-Based Key Derivation October 2005 This draft specifies a Key Derivation Function (KDF) used to derive secret symmetric keying material for participating parties from a secret value and application specific information. The KDF is based on concatenation and a secure hash function. The length in bits of secret keying material that can be generated by the KDF is limited to (2**32 - 1) times the length in bits of the output block of the hash function. The derived keying material is a concatenation of the outputs of the hashing operations. Inputs to the hash function are incremented counter values, one for each separate hashing operation; the secret value; an optional algorithm identifier; identifiers for the participating parties, and optional protocol specific information. Conventions used in this document The Key Word "Secret Value" and "Key Derivation" are defined as follows: Secret Value: A value known only by the two communicating parties that will be used as input to the key derivation function. This value may be established out-of-band, selected by one of the communicating parties, or by the two communicating parties. Key Derivation: The process by which keying material (e.g., one or more symmetric keys) is derived from a secret value and other non- secret information. 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 [KEYWORDS]. Table of Contents 1. Introduction...................................................3 2. Hash-Based Key Derivation Function (HKDF)......................3 2.1 HKDF Inputs and Fixed Values...............................4 2.2 HKDF Algorithm.............................................7 3. Supported Scenarios............................................8 3.1 Secret Values Established out of band......................8 3.2 Initiator Selected Secret Values...........................8 3.3 Key agreements.............................................9 4. Security Considerations.......................................11 5. Acknowledgments...............................................13 6. References....................................................13 6.1 Normative References......................................13 6.2 Informative References....................................13 7. Author's Addresses............................................14 Dang Expires April 2006 [Page 2] Hash-Based Key Derivation October 2005 8. IANA Considerations...........................................14 9. Disclaimer of Validity........................................14 10. Copyright Statement..........................................14 1. Introduction The security of a secret key shared between two participating parties may be reduced if the secret key is used for each and every secure channel or transaction. However, it is inconvenient and inefficient if communicating parties must maintain different secret values for each secure channel or transaction. Therefore, it is necessary to have an algorithm that can be used to derive distinct secret keying material for each and every secure channel or transaction from a single secret value shared between participating parties. This algorithm should be strong and standardized to overcome compatibility issues in communication protocols and their implementations. The hash-based key derivation function (HKDF) specified in this draft is used to derive secret keying material from a secret value. The output from the HKDF is only used for secret keying material, such as a symmetric key used for data encryption or message integrity, a secret initialization vector, etc. Non-secret keying material (such as a non-secret initialization vector) is not generated using the secret value. The algorithm is based on a secret value, a hash function (e.g., SHA- 256) [1], and concatenation. This document defines a general algorithm for hash-based key derivation in Section 2 that can be used with any secure hash function. This algorithm includes mandatory and optional steps, enabling the algorithm to support a broad range of protocols and applications. Section 3 describes four general scenarios to establish secret values that are used in the HKDF algorithm, and indicates when the optional steps are required. Section 4 presents security considerations with respect to the application of the HKDF. 2. Hash-Based Key Derivation Function (HKDF) The HKDF is constructed from a secure hash function H. HKDF accepts three mandatory inputs and two optional inputs, and uses one implementation dependent fixed value. The mandatory HKDF inputs are a secret value that is a bit string, contextual information, and the length of the desired key material. The optional HKDF inputs are an algorithm identifier and information shared between the participating parties. The implementation dependent fixed value describes the length of the output from the Dang Expires April 2006 [Page 3] Hash-Based Key Derivation October 2005 hash function H. The HKDF inputs and implementation-dependent fixed values are described in detail in Section 2.1. The HKDF algorithm returns either the desired key material, or an error. The complete HKDF algorithm is presented in Section 2.2. 2.1 HKDF Inputs and Fixed Values 2.1.1 Secret Value (SV) The secret value, SV, is a bit string known only to the participating parties. The secret value can be either a fixed or variable length bit string. To ensure that the secret value input by both parties is the same when the secret value is variable in length, it is preceded by a fixed length string that indicates the length (in bytes) of the secret value. Let SVData be a secret bit string that is generated from one of Supported Scenarios described in Section 3 of this document. When SVData is a fixed length bit string, SV has the form: SV = SVData When SVData is a variable length bit string, SV has the form: SV = SVLen || SVData, where SVData is a variable-length bit string of (eight-bit) bytes, while SVLen is a fixed length bit string that indicates the length (in bytes) of SVData. Protocols that reference this specification MUST specify the format of the secret value and the lengths of the fixed length quantities: a) Where SV is a fixed length string, the protocol MUST specify the length; and b) Where SV is a variable length string, the protocol MUST specify the size of SVLen. SV may be established through off-line or on-line processes, depending upon the scenario. See Section 3 for supported scenarios through which the SV can be established. The security strength of SV is determined by the method used to generate SV (see Section 4). 2.1.2 algorithmID The algorithmID is an optional input. If present, the algorithmID indicates how the derived keying material will be parsed and for which algorithm(s) the derived keying material will be used. For example, algorithmID might indicate that bits 1-80 are to be used as Dang Expires April 2006 [Page 4] Hash-Based Key Derivation October 2005 an 80-bit HMAC key, and that bits 81-208 are to be used as a 128-bit AES key. An algorithmID consists of two concatenated values: algorithmLen and algorithmOID. The algorithmLen is a fixed length bit string that indicates the length (in bytes) of algorithmOID. The algorithmOID is an ASCII string representing an ASN.1 object identifier. Protocols that reference this specification MUST specify whether algorithmID is omitted or included. If included, the protocol MUST specify the length of algorithmLen and the semantics of any recognized object identifiers. 2.1.3 contextID The contextID is a mandatory input. The contextID is a string formed by concatenating strings IDU and IDV; IDU and IDV identify the participating parties. Each of the bit strings IDU and IDV is an identifier (that is, a bit string that is associated with a person, device or organization). An identifier may be an identifying name or may be something more abstract (for example, an IP address and timestamp), depending on the application. IDU identifies the initiator of the session or transaction, and IDV identifies the responder, as specified by the protocol. There are two formats for the contextID: a fixed-length contextID format and a variable-length contextID format. The fixed-length contextID format is used where IDU and IDV are fixed-length bit strings, and contextID consists of IDU || IDV. The variable-length contextID format is used where IDU and IDV are variable-length bit strings. In this case, contextID has the form: IDlenU || IDU || IDlenV || IDV where IDU and IDV are variable-length strings (of eight-bit bytes) that serve as the identifiers of the participating parties, and IDLenU and IDlenV are fixed-length bit strings that indicate the lengths (in eight-bit bytes) of IDU and IDV, respectively. Party U shall be the initiator, and party V shall be the responder, as assigned by the protocol. Protocols that reference this specification MUST specify the following information: (a) Which party is defined as the initiator and which is the responder; Dang Expires April 2006 [Page 5] Hash-Based Key Derivation October 2005 (b) The contextID format (i.e., fixed length vs. variable length); (c) The source of the identifiers IDU and IDV (e.g., "use the dns name of the server as IDV"). The values for IDU and IDV should be as specific as feasible for their intended use, and each shall be represented in a protocol-specific format. (d) The lengths for the fixed-length quantities and the acceptable range of variable-length quantities. For the fixed-length contextID, the fixed-length quantities are IDU and IDV. For the variable-length contextID, the fixed-length quantities are IDlenU and IDlenV. (Note that the maximum length of IDU and IDV in the variable-length format must be consistent with the size of IDlenU and IDlenV. 2.1.4 keydatalen Keydatalen is a mandatory input. Keydatalen is an integer that indicates the length in bits of the secret keying material to be generated; keydatalen shall be less than or equal to hashlen x (2**32 - 1). 2.1.5 SharedInfo SharedInfo is an optional input. SharedInfo is a bit string that consists of the concatenation of a (protocol-specific) sequence of substrings of data shared by the parties generating the secret keying material. Where the substring has a fixed length, the substring is composed of just the substring data. Where a substring has variable length, the substring has the form Datalen || Data, where Data is a variable length string (of eight bit bytes), and Datalen is a fixed- length string that indicates the length (in bytes) of Data. Protocols may specify a SharedInfo field that contains fixed length substrings, variable length substrings, or a combination. For each substring of SharedInfo, a protocol using this key derivation function must specify which of these data representations is used. The protocol must also specify the lengths for all fixed-length quantities. SharedInfo ::= Substring-1 || Substring-2 ||... Substring-n n is a number of substrings in SharedInfo. Substring-i ::= FixedSubString / VariableSubString i is an integer between 1 and n. FixedSubstring ::= Fixed-length bit string VariableSubstring::= Datalen || Data Datalen ::= fixed-length string Data ::= variable length eight-bit byte string. Dang Expires April 2006 [Page 6] Hash-Based Key Derivation October 2005 2.1.6 Hash function H and hashlen In addition to the input values, the HKDF algorithm depends upon the base hash function and one related implementation-dependent fixed value. The base hash function, or H, is used to derive blocks of secret keying material. The implementation-dependent fixed value is hashlen. The hashlen is an integer value that indicates the length in bits of the output block of H. Protocols that reference this specification SHOULD support multiple hash functions and MAY support negotiation between the communicating parties for the selection of H. 2.2 HKDF Algorithm 1. reps = ceiling ( keydatalen / hashlen ) 2. If reps > (2**32 - 1), then ABORT: output "Invalid" and stop. 3. Initialize a 32-bit, big-endian bit string counter as 00000001 in hexadecimal. 4. For i = 1 to reps by 1, do the following: a. Compute Hash-i = H (counter || SV {|| algorithmID} || contextID {|| SharedInfo}). b. Increment counter (modulo 2**32), treating it as an unsigned 32-bit integer. 5. Let Hhash be set to Hash-reps if (keydatalen / hashlen) is an integer; otherwise, let Hhash be set to the (keydatalen mod hashlen) leftmost bits of Hash-reps. 6. Set DerivedKeyingMaterial = Hash-1 || Hash-2 || ... || Hash-(reps- 1)|| Hhash. Output: The bit string DerivedKeyingMaterial of length keydatalen bits (or "Invalid"). Any scheme attempting to call this key derivation function with keydatalen greater than or equal to hashlen * (2**32 - 1) shall output "Invalid" and stop without outputting DerivedKeyingMaterial. Dang Expires April 2006 [Page 7] Hash-Based Key Derivation October 2005 3. Supported Scenarios This section describes three general scenarios to generate secret values for the hash-based key derivation function (HKDF): (1) two parties have previously established a secret value using an out-of- band method; (2) the initiator selects a secret value and conveys it to a recipient using standard key transport mechanisms; and (3) two parties use one of key agreement protocols to establish a secret value. 3.1 Secret Values Established out of band In the first scenario, two parties establish a secret value through out-of-band channels. The secret value is used with the HKDF to establish session-specific or transaction-specific keying material in future communications. To ensure that distinct keying material is generated, a protocol supporting secret values established out of band MUST include SharedInfo substrings with transaction or application specific information unique to this execution of the protocol. For online protocols, the SharedInfo substrings SHOULD include information contributed by both the initiator and the recipient. 3.2 Initiator Selected Secret Values In the second scenario, one party (the initiator) wishes to establish a secure communication channel with a second party (the recipient). The recipient has a long term asymmetric key pair for use during key establishment, and the public key is known to the initiator. (Most commonly, the public key is distributed in an X.509 certificate.) The initiator generates a secret value and encrypts the secret value by using an asymmetric cryptographic technique (e.g., RSA) with the recipient's public key, and then sends the secret value to the other party. The recipient decrypts it to get the secret value; the secret value is used with the HKDF to generate session-specific or transaction-specific keying material. The initiator can authenticate the recipient's public key using the recipient's certificate. There is no authentication of the initiator in this case unless the initiator (a) signs the transmitted secret value using a long term asymmetric (digital signature) key pair, or (b) is a registered party to the recipient with an ID and associated password. The initiator can encrypt the ID and password by using the recipient's public key, and then sends the resulting ciphertext to the recipient. This is a common scenario in SSL or TLS sessions, with the initiator being a client and the recipient being a server. Protocols that support initiator-selected secret values SHOULD include SharedInfo substrings with transaction or application Dang Expires April 2006 [Page 8] Hash-Based Key Derivation October 2005 specific information. For online protocols, the SharedInfo substrings SHOULD include information contributed by the recipient. This prevents an initiator from predicting the output from the HKDF. The computation MAY include SharedInfo substrings contributed by the initiator. 3.3 Key agreements In the third scenario, two parties use asymmetric cryptography (e.g., Diffie-Hellman or Menezes-Qu-Vanstone) to establish a secret value using a key agreement scheme. The secret value is used with the HKDF to establish a session-specific or transaction-specific keying material. The secret value should be deleted immediately after computing the keying material. The parties may use previously registered long-term asymmetric keys (a.k.a. static keys), or generate a new ephemeral (temporary, one- time) key pair specifically for this iteration of the key agreement process. Where one or more static keys are employed, the HKDF supplements the secret value with application specific and/or session specific information to ensure that the keying material is distinct. 3.3.1 Static-Static Key Agreement When both participating parties have complementary static key pairs for key agreement, the secret value SV may be computed. For example, if both parties have Diffie-Hellman static key pairs with the same parameters, or elliptic curve key pairs over the same curve, the secret value SV may be generated using the appropriate key agreement algorithm. In general, the public keys associated with these static key pairs are conveyed in X.509 certificates. After SV is generated, it is then used to derive the keying material. Since both key pairs are static, this method will always produce the same SV for any pair of participants. Similarly, the contextID will be the same for these participants for any given protocol or application. To ensure that distinct keying material is derived, a protocol using static-static key agreement MUST include SharedInfo substrings that are unique to this session or execution of a protocol. The SharedInfo substrings MUST include information contributed by both the initiator and the recipient. 3.3.2 Static-Ephemeral Key Agreement Static-ephemeral key agreement may be performed when one participant (the recipient) has a static key pair, and the other party (the intiator) has the ability to generate ephemeral keys. The recipient's static public key is known to the initiator through an X.509 certificate or other secure mechanism. In this case, the Dang Expires April 2006 [Page 9] Hash-Based Key Derivation October 2005 initator generates a complementary ephemeral key pair (e.g., a temporary or one-time Diffie-Hellman key pair that is generated with the same parameters that were used to generate the recipient's static key pair) for this specific session or transaction. The initiator sends its ephemeral public key to the recipient. Each party uses its own key pair, the other party's public key and the appropriate key agreement algorithm to generate the secret value. The secret value is then used to derive the keying material. (The initiator should delete the ephemeral private key after generating the secret value.) This method is vulnerable to man-in-the-middle attacks if the initiator's ephemeral public key is not verified, because an attacker can impersonate the initiator in this key agreement protocol. Authentication of the ephemeral public key can be obtained if the initiator has a digital signature key pair with a corresponding public key certificate. In this case, the initiator signs its ephemeral public key using its digital signature private key, and then sends the ephemeral public key and the signature to the recipient, who can use the corresponding public key certificate to verify the signature and authenticate the initiator. The HKDF computation SHOULD include SharedInfo substrings with transaction or application-specific information. 3.3.3 Ephemeral-Ephemeral Key Agreement Ephemeral-ephemeral key agreement may be performed when neither participant has a long term key pair, but each participant has the ability to generate ephemeral key pairs. In this case, the participants agree on parameters (or curves), then each participant generates an ephemeral key pair using those parameters. Each participant signs the public key from its ephemeral key agreement key pair using its private digital signature key and sends the ephemeral public key and the signature to the other party. The receiver uses the sending party's corresponding public key to verify the signature. In general, the receiver will use the sender's public key certificate to authenticate the participant. Each party uses its own ephemeral key pair, the other party's ephemeral public key and the appropriate key agreement algorithm to compute the secret value. The ephemeral private keys should be erased after computation of the secret value. This option appears to be the most secure of the key agreement options because it results in a temporary, authenticated ephemeral key. Dang Expires April 2006 [Page 10] Hash-Based Key Derivation October 2005 For this scenario, the SharedInfo substrings are optional, since the participants generate a new secret value based on new ephemeral key pairs for each execution of the HKDF. Each participant contributes randomness through their key generation process. 3.3.4 Anonymous Key Agreement In this scenario, the ephemeral-ephemeral key agreement algorithm is used without authentication. That is, the participants agree on public (e.g., Diffie-Hellman) parameters and exchange ephemeral public keys but do not sign the messages. This protocol results in a secret value and derived keying material in the same way as ephemeral-ephemeral key agreement. This approach is vulnerable to man-in-the-middle attacks, in which the attacker conducts anonymous key agreement exchanges with both parties. The public key agreement parameters can be delivered physically or electronically. As above, the SharedInfo substrings are optional, since the participants generate a new secret value based on new ephemeral key pairs for each execution of the HKDF. 4. Security Considerations Special care should be taken to protect the secret value and to limit its exposure over time. When a secret value is no longer needed, it should be destroyed. If a session key generated from the HKDF is compromised, an attacker can decrypt all the messages exchanged in the session. However, this provides no information about the other session keys or the original secret value. [CSD1]Previous and subsequent session keys generated from the same secret value in different HKDF computations are still secure. This provides a much stronger security than using the same key in all sessions. This is one of the main purposes to use the HKDF algorithm as described above. If the original secret value is somehow compromised, then an attacker can derive all the session keying material and use it to access all messages in all communication sessions between the two parties that used that secret value. So, the original secret value must be strongly resistant to brute-force attacks and kept securely. The strength of a key derived using the HKDF is limited by the security strength of the hash function H, the strength of the secret value, and the length of the derived key itself. Dang Expires April 2006 [Page 11] Hash-Based Key Derivation October 2005 Assuming that the output of the HKDF cannot be differentiated from random data, the best attack against a derived key is a brute force attack. The work factor to perform such an attack is 2**n, where n is the length of the derived key. When used in HKDF, the work factor to attack a secure hash function is 2**h, where h is the length of the output. Calculating the security strength of the secret value is more complex. In this specification, secret values may be distributed out-of-band, obtained through key agreement, or user selecte[CSD2]d. Security Strengths of secret values depend on the mechanisms used to generate and distribute them, as well as their sizes. Where secret values are randomly chosen (for out-of-band distribution or during the user selection process), the security strengths of these secret values describe their resistance to brute-force attacks. If a strong random number generator is employed, the security strength depends [CSD3]only on the length s (in bits) of the secret value. In this case, the strength of the secret value is approximately 2**s. Where secret values are generated using key agreement schemes, the security strengths of the secret values depend on the key agreement algorithm used and the security strength of the asymmetric keys. For example, 1024 bit Diffie-Hellman has an approximate security strength of 80 bits. That is, a secret value derived using 1024 bit Diffie- Hellman is roughly equivalent to an 80 bit randomly generated secret value. Similarly, a secret value derived using 163 bit elliptic curve Diffie-Hellman is roughly equivalent to an 80 bit randomly generated secret value. For additional information regarding the strength of values obtained using key agreemnent schemes, see [4] and [6]. Where secret values are established out-of-band, the process used to distribute the secret values must prevent disclosure to other parties. Assuming that the secret values are established securely, the strength of the derived key material depends upon the security strength s of the secret value and the length m of a derived key. The security level achieved is 2**y where y is the smallest of the values m and s. In the "Initiator Selected Secret Values" scenario, the secret value is selected by one party and encrypted under an asymmetric key (e.g., the secret value is sent to the recipient using RSA transport). The security strength of the derived keying material is the minimum of the security strength of the asymmetric key pair, the strength of the secret value, and the length of a derived key. For example, 1024 bit RSA provides approximately 80 bits of security. The strength of a Dang Expires April 2006 [Page 12] Hash-Based Key Derivation October 2005 derived key is limited to 80 bits even if the secret value itself has a security strength greater than 80 bits. Therefore, all components MUST have a security strength equal to or greater than the target security strength for the keying material to be derived. See [5] for guidance on random number generation and [6] for information on the cryptographic strength of asymmetric cryptography. 5. Acknowledgments The protocol defined in this document is based largely on work by Elaine Barker, Don Johnson, and Miles Smid in [2]. This document also borrows some text from [3] by C. Michael Chernick, Charles Edington III, Mathew J. Fanto. John Kelsey, Morrie Dworkin, and Bill Burr provided invaluable advice and assistance. 6. References 6.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 6.2 Informative References 1 National Institute of Standards and Technology, "Secure Hash Standard (SHS)", Federal Information Processing Standards Publication 180-2, August 2002. 2 National Institute of Standards and Technology, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56, July, 2005. 3 National Institute of Standards and Technology, "Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementation", NIST Special Publication 800-52, June, 2005. 4 Orman H. and Hoffman P., "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", RFC 3766, April 2004. 5 National Institute of Standards and Technology, "Digital Signature Standard (DSS)", Federal Information Processing Standards Publication 186-2, October 2001. 6 National Institute of Standards and Technology, "Recommendation for Key Management", NIST Special Publication 800-57, August 2005. 7 National Institute of Standards and Technology, "Electronic Authentication Guideline", NIST Special Publication 800-63, June 2004. Dang Expires April 2006 [Page 13] Hash-Based Key Derivation October 2005 7. Author's Addresses Quynh Dang National Institute of Standards and Technology 100 Bureau Drive, Mail Stop 8930 Gaithersburg, MD 20899-8930 Email: quynh.dang@nist.gov Tim Polk National Institute of Standards and Technology 100 Bureau Drive, Mail Stop 8930 Gaithersburg, MD 20899-8930 Email: tim.polk@nist.gov 8. IANA Considerations None. 9. Disclaimer of Validity 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. 10. Copyright Statement Copyright (C) The Internet Society (2005). 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. Dang Expires April 2006 [Page 14] Hash-Based Key Derivation October 2005 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. This Internet-Draft will expire on April 19, 2006. Dang Expires - April 2006 [Page 15]