Network Working Group J. Linn Internet-Draft RSA Laboratories Expires: December 7, 2006 M. Nystroem RSA Security June 5, 2006 OTP Methods for TLS draft-linn-otp-tls-00 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 December 7, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes means for applying One-Time Password (OTP) methods to authenticate Transport Layer Security sessions, operating in conjunction with Pre-Shared Key (PSK) ciphersuites defined for use with TLS. Linn & Nystroem Expires December 7, 2006 [Page 1] Internet-Draft OTP Methods for TLS June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Document organization . . . . . . . . . . . . . . . . . . 3 2. Acronyms and notation . . . . . . . . . . . . . . . . . . . . 4 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. OTP TLS elements and protocol . . . . . . . . . . . . . . . . 5 3.1. PSK establishment . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. Direct use with entropy-enhancing PSK ciphersuites . . 6 3.1.3. Deriving a PSK through OTP hardening . . . . . . . . . 6 3.2. Structure of the PSK_Identity element . . . . . . . . . . 6 3.3. TLS extension definitions . . . . . . . . . . . . . . . . 7 3.3.1. Extension types . . . . . . . . . . . . . . . . . . . 8 3.3.2. OTP challenge data . . . . . . . . . . . . . . . . . . 8 3.3.3. OTP hardening extension . . . . . . . . . . . . . . . 9 3.4. Error alerts . . . . . . . . . . . . . . . . . . . . . . . 11 4. Security considerations . . . . . . . . . . . . . . . . . . . 13 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Intellectual property considerations . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. Normative References . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Example messages . . . . . . . . . . . . . . . . . . 17 A.1. Example syntax . . . . . . . . . . . . . . . . . . . . . . 17 A.2. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 17 A.3. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. About OTPS . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Linn & Nystroem Expires December 7, 2006 [Page 2] Internet-Draft OTP Methods for TLS June 2006 1. Introduction 1.1. Scope This document describes means for applying One-Time Password (OTP) methods to authenticate Transport Layer Security (TLS) [1] sessions, operating in conjunction with Pre-Shared Key (PSK) [2] ciphersuites defined for use with TLS. 1.2. Background The TLS protocol is widely deployed and used to provide secure sessions, not only for web browsing but also for many other purposes. It supports a broad range of cryptographic methods, through definition and use of different ciphersuites. Today, the majority of TLS deployments authenticate servers using certificate-based public- key techniques. While certificate-based authentication of clients is also supported within the protocol, most deployments authenticate clients by passing other data (e.g., passwords) to servers across the protected channel that TLS establishes. A recent specification [2] defines new ciphersuites, where clients and servers are authenticated to each other based on common possession of a shared secret. The current document leverages these ciphersuites by using shared secrets that are based on OTPs. As such, the OTP becomes the basis for authentication of a TLS session. 1.3. Document organization The organization of this document is as follows: o Section 1 is an introduction. o Section 2 defines acronyms and notation used in this document. o Section 3 defines methods for use of OTPs within TLS. o Section 4 discusses security considerations. o Section 5 discusses IANA considerations. o Section 6 discusses intellectual property considerations. o Appendix A provides example messages. o Appendix B provides general information about the One-Time Password Specifications document series, where the initial drafts of this document were produced. Linn & Nystroem Expires December 7, 2006 [Page 3] Internet-Draft OTP Methods for TLS June 2006 2. Acronyms and notation 2.1. Acronyms PSK Pre-Shared Key TLS Transport Layer Security 2.2. Notation TLS extension definitions are expressed in the TLS presentation language syntax. Linn & Nystroem Expires December 7, 2006 [Page 4] Internet-Draft OTP Methods for TLS June 2006 3. OTP TLS elements and protocol 3.1. PSK establishment 3.1.1. Introduction We define two classes of approaches for establishing a PSK based on an OTP value: o The first choice applies the OTP directly as the PSK. Given that the entropy of the value space produced by many OTP methods is insufficient to preclude exhaustive search by an attacker, this class is recommended only for use with PSK ciphersuites that incorporate additional random elements in PSK construction; currently-defined ciphersuites with this characteristic employ public-key methods. o The second choice applies "hardening" techniques (i.e. techniques that do not make it computationally impossible, but economically unattractive for an attacker to search for a given key) to the OTP in order to derive a resulting PSK that is more resistant to search by an attacker. A PSK of this form is suitable for use with arbitrary PSK ciphersuites, even those based purely on symmetric-key operations. When the OTP method requires a server-issued challenge, we rely on the TLS extension feature of [3] to request and provide such challenges. We also rely on the TLS extension feature of [3] to negotiate OTP hardening parameters. It is important to recognize that some underlying OTP methods employ and transfer user-entered PINs in conjunction with OTP values. For purposes of this discussion, we are concerned with PINs that users provide for distributed processing purposes, not those consumed locally to unlock a token device. Two basic alternatives exist: o Apply a function to combine the PIN with the OTP value, and use the result as input to PSK derivation. With this approach, successful establishment of a TLS-PSK session implies that both peers have been independently able to provide matching OTP and PIN values. As such, it offers two-factor mutual authentication. This approach increases the input entropy to PSK derivation, but may be inconsistent with operational models where users' PINs are maintained independently from secrets associated with their token devices. o Omit the PIN from PSK derivation, instead retaining it to be separately transferred for validation in a subsequent step outside Linn & Nystroem Expires December 7, 2006 [Page 5] Internet-Draft OTP Methods for TLS June 2006 the scope of TLS, though the newly-established TLS channel may be used as a means to transfer it securely. This approach decouples the PIN from TLS processing, which may be appropriate for environments where PINs and token device secrets are managed separately (e.g., if PINs are to be accepted and processed by applications above the TLS layer). This specification allows either alternative to be supported, but leaves the decision as a matter to be profiled for particular OTP methods. For a method that combines PINs with OTPs, the method profile must also define the specific combination function used to yield a single element as input to TLS-PSK operation. If appropriate to support different scenarios and requirements, more than one method profile may be defined for a given underlying OTP algorithm and technology. 3.1.2. Direct use with entropy-enhancing PSK ciphersuites For this case, the OTP value is used directly as a PSK for a TLS-PSK ciphersuite. No extension to the TLS handshake is required except in the case of OTP methods that must transfer and process a server- provided challenge value before an OTP value can be generated. For this, the OTP Challenge Data extension defined in Section 3.3.2 may be used. This approach can be applied in conjunction with the DHE_PSK or RSA_PSK key exchange algorithms defined in [2], although use of the DHE_PSK key exchange algorithm without OTP hardening will expose clients to man-in-the-middle (MITM) attacks (see further Section 4). For this reason, the alternative of directly using an OTP as a PSK is not recommended for the DHE_PSK key exchange algorithm, unless MITM attacks are prevented within the operational environment by separate server authentication methods or other means. 3.1.3. Deriving a PSK through OTP hardening In this approach, a PSK is derived from a given OTP in such a way that an attack based on searching for the OTP becomes economically unattractive. This approach can be applied in conjunction with any of the key exchange algorithms defined in [2]. The key derivation mechanism recommended in this document builds on the PBKDF2 key derivation function defined in PKCS #5 v2.0 [4]. 3.2. Structure of the PSK_Identity element For purposes of this specification, the PSK_Identity field of the ClientKeyExchange message defined in [2] may carry either a user's name or the identity of the key associated with the user's token Linn & Nystroem Expires December 7, 2006 [Page 6] Internet-Draft OTP Methods for TLS June 2006 device. At least one of user and/or key identifier is required. We adopt the method of [5], Section 2.4 to represent these values and other data related to OTP-based authentication textually, defining the following prefixes: o Prefix "UI=" signifies a user identifier (e.g., username). o Prefix "KI=" signifies a key identifier. o An "OM=" prefix is used to indicate that an OTP method is being used in conjunction with TLS-PSK. This prefix may be followed by a textual identifier of the method (which may imply a need for a registry of OTP method identifiers, see Section 5), or an "OM=" element with an empty value can be used to signify that some OTP method is being used in conjunction with TLS-PSK but that the method must be identified through other means. o To provide the time associated with the OTP used in the PSK computations, the client may use the prefix "T=" and, if used, shall encode the time value as YYYYMMDDhhmmss, where YYYY denotes the year, MM the month, DD the day, and hh, mm, and ss, the hour, minutes and seconds, respectively. The time shall always be provided as UTC. o To provide a counter value associated with the OTP used in the PSK computations, the client may use the prefix "C=" and, if used, shall provide the counter value as a UTF-8 string of decimal digits. In this notation, assuming a user with the user identifier "J. Random User" and a time-based OTP calculated based on the time 11:42:04 (UTC) December 22, 2005, but without an explicit OTP method identifier, the PSK_Identity value would become: psk_identity = "UI=J. Random User, T=20051222114204,OM="; OTP-based authentication of a user with OTP key identifier 142857 and the explicitly-identified "OTP-Counter" method with counter value 285714 would be represented with the following PSK_Identity value: psk_identity = "KI=142857, C=285714, OM=OTP-Counter"; The order of elements within a PSK_Identity field is not significant. 3.3. TLS extension definitions Linn & Nystroem Expires December 7, 2006 [Page 7] Internet-Draft OTP Methods for TLS June 2006 3.3.1. Extension types The extensions defined in this document are: challenge_data(X) /* To be defined */ otp_hardening(Y) /* To be defined */ 3.3.2. OTP challenge data This extension may be used when a TLS client wants to make use of an OTP as a PSK (whether hardened or not), and the OTP algorithm requires a challenge as input. In order to request a challenge from the TLS server, the client may include an extension of type challenge_data in the (extended) Client Hello message. The extension_data field of this extension shall contain a ChallengeData where: struct { ChallengeDataType challenge_data_type; select (ChallengeDataType) { case request: ChallengeRequestData; case response: ChallengeResponseData; } challenge_data; } ChallengeData; enum { request(0), response(1), (255) } ChallengeDataType; struct { opaque otp_algorithm<0..2^16-1>; opaque otp_user_id<0..2^16-1>; opaque otp_key_id<0..2^16-1>; } ChallengeRequestData; struct { opaque otp_challenge<1..2^16-1>; } ChallengeResponseData; In a Client Hello message, the request alternative of ChallengeData shall be used and shall provide information that the server may need in order to generate a challenge: o The otp_algorithm field of the ChallengeRequestData structure shall, when non-empty, contain a URL identifying the OTP algorithm that needs the challenge. Linn & Nystroem Expires December 7, 2006 [Page 8] Internet-Draft OTP Methods for TLS June 2006 o The otp_user_id field of the ChallengeRequestData structure shall, when non-empty, contain a user identifier (e.g., username) that enables the server to generate a correct challenge. Note that use of this field may disclose the user identifier to eavesdroppers. o The otp_key_id field of the ChallengeRequestData structure shall, when non-empty, contain an identifier of the OTP generation key with which a requested challenge is to be used. As for the otp_user_id field, this field may be subject to eavesdropping. At least one of the otp_algorithm, otp_user_id, or otp_key_id fields must be non-empty in a ChallengeRequestData value; when feasible, both otp_algorithm and at least one of otp_user_id and otp_key_id should be provided. The otp_key_id field shall refer to a key for the given user when both the otp_key_id and the otp_user_id fields are non-empty. If the otp_user_id or the otp_key_id (or both) alternatives of ChallengeRequestData are non-empty, then a subsequently sent psk_identity value must match these values. Servers that receive a Client Hello containing the challenge_data extension may use the information contained in the extension to generate an appropriate challenge to return to the client. In this event, the server shall include an extension of type challenge_data in the (extended) Server Hello. The extension_data field of this extension shall contain a ChallengeData value and the response alternative of the ChallengeData shall be used to provide the challenge to the client: o The otp_challenge field of the ChallengeResponseData structure shall contain the requested challenge. o Servers that receive a Client Hello containing the challenge_data extension but are unable to generate an appropriate challenge based on the information provided by the client shall abort the handshake with an illegal_parameter alert. 3.3.3. OTP hardening extension This extension may be used when a TLS client wants to make use of an OTP as a PSK and the OTP needs to be hardened before being used as a PSK. OTP hardening is achieved by applying the PBKDF2 from [4] on the OTP, using a negotiated iteration count. A TLS client may include an extension of type otp_hardening in the (extended) Client Hello message in order to establish hardening parameters with the TLS server. The extension_data field of this Linn & Nystroem Expires December 7, 2006 [Page 9] Internet-Draft OTP Methods for TLS June 2006 extension shall contain an OTPHardeningData where: struct { uint16 iteration_count; } OTPHardeningData; The client indicates its highest supported value for the iteration count c in PBKDF2 through the iteration_count field of the OTPHardeningData. Servers that receive a Client Hello containing the otp_hardening extension may use the information contained in the extension to provide a selected iteration count in return to the client. In this event, the server shall include an extension of type otp_hardening in the (extended) Server Hello. The extension_data field of this extension shall contain an OTPHardeningData value with the selected iteration count. Clients that receive a Server Hello containing the otp_hardening extension must do a sanity and policy check on the provided iteration_count value. If the check passes, the client shall compute a PSK using PBKDF2 from [4] as follows ("||" denotes string concatenation): PSK = PBKDF2 (OTP, RS || RC, iterationCount, keyLen) Where: o OTP is the current one-time password, o RS and RC are the server_random value from the Server Hello message and the client_random value from the Client Hello message, respectively, o iterationCount is the iteration_count value from the otp_hardening extension in the Server Hello message, and o keyLen shall be set to 16 (128 bits). The PBKDF2 PRF algorithm shall be the TLS PRF, using the US-ASCII string "OTP hardening" as the label. Servers that receive a Client Hello containing the otp_hardening extension but are unwilling or unable to engage in an OTP hardening operation shall ignore the extension. In this case, TLS client (and TLS server) policy will determine whether the handshake will continue or not. Linn & Nystroem Expires December 7, 2006 [Page 10] Internet-Draft OTP Methods for TLS June 2006 3.4. Error alerts This section defines new error alerts for use with the OTP TLS method defined in this document. For compatibility reasons, these alerts must not be sent unless the sending party has received, from the party they are communicating with, an extended hello message or a key exchange message indicating use of OTPs in TLS-PSK as defined by this document. o "unsupported_otp_algorithm" - this alert is sent by servers that receive a key exchange message (or a "challenge_data" extension) which indicates use of an OTP algorithm that is not supported by the server. This message is always fatal. o "otp_key_lost" - this alert is sent by servers that receive a key exchange message (or a "challenge_data" extension) which indicates use of an OTP key that has been reported as lost. This message may or may not be fatal depending on server policy. o "otp_key_expired" - this alert is sent by servers that receive a key exchange message (or a "challenge_data" extension) which indicates use of an OTP key that has expired. This message may or may not be fatal depending on server policy. o "otp_key_blocked" - this alert is sent by servers that receive a key exchange message (or a "challenge_data" extension) which indicates use of an OTP key that has been blocked. This message is always fatal. o "otp_key_unknown" - this alert is sent by servers that receive a key exchange message (or a "challenge_data" extension) which indicates use of an OTP key unknown to the server. This message is always fatal. o "pin_change_required" - this alert is sent by servers that also maintain user PINs associated with OTP keys when they receive a key exchange message (or a "challenge_data" extension) based on a key for which the user PIN needs to be replaced. This message may or may not be fatal depending on server policy. These new error alerts are conveyed using the following syntax: Linn & Nystroem Expires December 7, 2006 [Page 11] Internet-Draft OTP Methods for TLS June 2006 enum { /* Only listing error alerts defined in this document here */ unsupported_otp_algorithm(TBD), otp_key_lost(TBD), otp_key_expired(TBD), otp_key_blocked(TBD), otp_key_unknown(TBD), pin_change_required(TBD) } AlertDescription; Linn & Nystroem Expires December 7, 2006 [Page 12] Internet-Draft OTP Methods for TLS June 2006 4. Security considerations This document is a profile of [2] and all security considerations discussed in [2] apply. In particular, since OTPs usually are relatively short, the risk of PSK compromise due to brute-force searching applies when an OTP is used directly as the PSK and the PSK key exchange algorithm or (in the case of an MITM attack) the DHE_PSK key exchange algorithm is used. This document therefore recommends OTP hardening whenever the PSK key exchange algorithm is suggested by the client, or when there is a risk for a MITM attack and the DHE_PSK key exchange algorithm is suggested by the client. When, per Section 3.1.3 of this document and Section 2 of [2], a symmetric PSK is established through hardening of an OTP value, an attacker obtaining that PSK would become able to decrypt data from its protected TLS session. If the encrypted session was recorded, its underlying plaintext could be revealed once the PSK was obtained. It is important, therefore, that the level of hardening applied to protect the PSK against searching attacks on the OTP space be consistent with the data's value, its useful lifetime, and the anticipated level of computational resources to be applied against the PSK. If a suitable hardening level cannot be achieved, use of the entropy-enhancing ciphersuites as discussed in Section 3.1.3 of this document and Sections 3 and 4 of [2] is recommended. It should be noted, however, that the use of OTPs provides perfect forward secrecy: Even if a particular OTP is compromised, an attacker will not be able to apply its value to decrypt any other conversation than the one where the OTP was used as a basis for a PSK. Linn & Nystroem Expires December 7, 2006 [Page 13] Internet-Draft OTP Methods for TLS June 2006 5. IANA considerations This document does not contain any considerations for IANA. A registry may be required for OTP method identifiers as introduced in Section 3.2, however. No other IANA actions are anticipated. Linn & Nystroem Expires December 7, 2006 [Page 14] Internet-Draft OTP Methods for TLS June 2006 6. Intellectual property considerations RSA Security makes no patent claims on the general constructions defined by this document, although specific underlying techniques may be covered. RSA Security has US patents (and foreign counterparts) on certain underlying techniques, in particular US Patent Nos. 4,885,778; 4,856,062; 5,097,505; 5,168,520; 5,367,572 and 5,657,388. Additional patents are pending. As this specification can be implemented without the use of these underlying techniques, it is RSA Security's position that the technology covered by these patents and applications is not required to implement this specification. Linn & Nystroem Expires December 7, 2006 [Page 15] Internet-Draft OTP Methods for TLS June 2006 7. Acknowledgements Thanks to all the participants at the OTPS workshops where this proposal has been discussed and on the OTPS mailing list for their review and comments related to this document. 8. Normative References [1] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006, . [2] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005, . [3] Blake-Wilson, S., Nystroem, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003, . [4] RSA Laboratories, "Password-Based Cryptography Standard", PKCS #5 Version 2.0, March 1999, . [5] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 4279, December 1997, . Linn & Nystroem Expires December 7, 2006 [Page 16] Internet-Draft OTP Methods for TLS June 2006 Appendix A. Example messages A.1. Example syntax The syntax of the examples in this appendix loosely follows the presentation language syntax defined in [1]. A.2. Client Hello In this example, the client suggests use of either the TLS_DHE_PSK_WITH_AES_128_CBC_SHA or the TLS_RSA_PSK_WITH_AES_128_CBC_SHA ciphersuite, both defined in [2]. The client also asks the server for a suitable iteration count for the OTP hardening, and indicates it cannot support an iteration count above 20,000. message_type = client_hello; length = ...; body = { client_version = 3.1; random = { gmt_unix_time = 1135069786; random_bytes = 0xa243edfeed12adef...; }; session_id = ; /* Empty */ cipher_suites = {{0x00, 0x8F},{0x00,0x94}}; compression_methods = {null}; client_hello_extension_list = { { extension_type = otp_hardening; extension_data = { iteration_count = 20000; } } } }; A.3. Server Hello Continuing with the previous example, the server responds positively to the client hello message, selects the Diffie-Hellman PSK cipher suite, and sets the iteration count to 20,000: Linn & Nystroem Expires December 7, 2006 [Page 17] Internet-Draft OTP Methods for TLS June 2006 message_type = server_hello; length = ...; body = { server_version = 3.1; random = { gmt_unix_time = 1135069787; random_bytes = 0x2143287432987321dbc321...; }; session_id = 0x4321defeadcbbdbe213...; cipher_suite = {0x00, 0x8F}; compression_method = null; server_hello_extension_list = { { extension_type = otp_hardening; extension_data = { iteration_count = 20000; } } } }; Linn & Nystroem Expires December 7, 2006 [Page 18] Internet-Draft OTP Methods for TLS June 2006 Appendix B. About OTPS The One-Time Password Specifications are documents produced by RSA Laboratories in cooperation with secure systems developers for the purpose of simplifying integration and management of strong authentication technology into secure applications, and to enhance the user experience of this technology. RSA Laboratories plans further development of the OTPS series through mailing list discussions and occasional workshops, and suggestions for improvement are welcome. As for our PKCS documents, results may also be submitted to standards forums. For more information, contact: OTPS Editor RSA Laboratories 174 Middlesex Turnpike Bedford, MA 01730 USA otps-editor@rsasecurity.com http://www.rsasecurity.com/rsalabs/ Linn & Nystroem Expires December 7, 2006 [Page 19] Internet-Draft OTP Methods for TLS June 2006 Authors' Addresses John Linn RSA Laboratories Email: jlinn@rsasecurity.com Magnus Nystroem RSA Security Email: magnus@rsasecurity.com Linn & Nystroem Expires December 7, 2006 [Page 20] Internet-Draft OTP Methods for TLS June 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. Linn & Nystroem Expires December 7, 2006 [Page 21]