Network Working Group T. Otto Internet-Draft TU Braunschweig Expires: Juli 2, 2005 January 2005 The EAP-SKL protocol draft-otto-eap-skl-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 Juli 2, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document describes EAP-SKL, an Extensible Authentication Protocol (EAP) method which provides authenticated key establishment based on a pre-shared key. EAP-SKL relies on SKEME (Secure Key Exchange MEchanism protocol), and hence may benefit from its simplicity and the provable security. EAP-SKL is designed to be a minimalistic EAP method comparable to EAP-MD5 by offering more flexibility and more security. In fact, EAP-SKL complies with the mandatory requirements for an EAP method which is intented for deployment in Wireless LAN environments. Otto Expires Juli 2, 2005 [Page 1] Internet-Draft The EAP-SKL protocol January 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Requirements notation . . . . . . . . . . . . . . . . . . 4 1.2 EAP Terminology . . . . . . . . . . . . . . . . . . . . . 4 2. Cryptographic Considerations . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 4. Packet formats . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 7.2 Informative References . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 A. T-PRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Otto Expires Juli 2, 2005 [Page 2] Internet-Draft The EAP-SKL protocol January 2005 1. Introduction IEEE 802.11i makes use of IEEE 802.1X which in turn choose the Extensible Authentication Protocol (EAP) for carrying authentication messages. EAP itself is only a framework, and runs over various link layers, like IEEE 802.3 Ethernet, IEEE 802.11 Wireless LAN or PPP. In fact, the proper authentication is performed by so called EAP methods. Currently, more than 40 EAP methods are defined, but only three of them are standardized, namely EAP-MD5, EAP-GTC and EAP-OTP, which have their origin in RFC 2284. Only one further method has the status of an Informational RFC, namely EAP-TLS. In 1998, when RFC 2284 was adopted, an usage of EAP outside of wired networks was not taken into account. EAP was thoroughly reviewed, which yielded in May 2004 in RFC 3748. For compatibility reasons, these three EAP methods are still part of the EAP specification, even if declared as deprecated. EAP-MD5, for instance, lacks of mutual authentication and derivation of session keying material, as mandated in [RFC3748]. It has been widely recognized that this state is dissatisfying. In particular, it lacks of a pre-shared key EAP method, which is simple (that is lightweight in terms of bandwidth, latency and computational costs as well as easy in deployment) and, at the same time, provides enough security strength to be used in hostile environments like the Internet or Wireless LAN. Such an EAP method could possibly serve as a replacement for the deprecated EAP-MD5. EAP-SKL attempts to be minimalistic EAP method, that is to provide as much features as needed but as few as possible. More precisely, EAP-SKL takes all mandatory requirements into account, with main focus on mutual authentication and proper session key derivation. Current pre-shared key EAP methods are EAP-FAST, EAP-SIM/AKA, EAP-PSK, EAP-PAX, EAP-TLS (with appropriate extensions) as well as EAP-IKEv2, where EAP-SKL claims to be the simplest one. Further informations about EAP methods can be found in the comprehensive compilation [I-D.bersani-eap-synthesis-sharedkeymethods]. Furthermore, EAP-SKL relies on only one cryptographic primitive, namely the hash function SHA-1 ([FIPS.180-1.1994]) and optionally the Diffie-Hellman key agreement ([RFC2631]). The choice of SKEME an appropriate key establishment protocol makes it possible to fully abstain from block ciphers and stream ciphers. Of course, this restricts EAP-SKL's ability to solely perform the mutual authentication task, and does not allow for encrypted communication, like, for instance, EAP-PSK does so. The author is convinced that there are many deployment scenarios, where indeed nothing more than minimalistic functionality is required and desired. Consequently, Otto Expires Juli 2, 2005 [Page 3] Internet-Draft The EAP-SKL protocol January 2005 and in contrast to many other EAP methods, EAP-SKL does not implement, for instance, version negotiation, fragmentation, session resuming, protected result indication or end-user identity hiding. The rest of this document is organized as follows. In the remaining section 1, some terminology is introduced. Section 2 highlights the cryptographic background of EAP-SKL. Section 3 and 4 cover the EAP-SKL protocol and the packet format of the messages. Section 5 and 6 are IANA considerations and Security Considerations, respectively. 1.1 Requirements notation 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 [RFC2119]. 1.2 EAP Terminology This section contains variables and abbreviations which will be referenced in later sections. For the exact meaning of the roles "peer", "Supplicant", "backend authentication server" and "EAP server" please refer to the EAP specification [RFC3748]. In this document, the words peer and client are used equivalently. The EAP conversation takes place between the client and the EAP server. Ko: 160-bit symmetric key; shared between client and EAP server. Ko is the most longlife credential within EAP-SKL. MK: Master Key; shared between the client and EAP server from which all other EAP method session keys are derived. MSK: Master Session Key; generated from the MK and exported by the EAP method to the authenticator. EMSK: Extended Master Session Key; also generated from the MK. It contains additional keying material. G: public Diffie-Hellman group g: public generator of group G x: 256-bit nonce generated by the client y: 256-bit nonce generated by the server ||: string or binary data concatenation. Otto Expires Juli 2, 2005 [Page 4] Internet-Draft The EAP-SKL protocol January 2005 "": NULL string F_Ko: arbitrary hash function keyed with Ko H: hash function SK: session key id_P: client's identity id_S: EAP server's identity The corresponding instantiation by EAP-SKL is described in Section 2. Otto Expires Juli 2, 2005 [Page 5] Internet-Draft The EAP-SKL protocol January 2005 2. Cryptographic Considerations This section describes the cryptographic design of EAP-SKL. The cryptographic protocol SKEME was chosen to realize mutual authentication and session key establishment. SKEME provides four operational modes, which offers high flexibility. More precisely, it allows the usage of PKIs, KDC and manual (pre-shared) distribution of keying material for an initial keying relationship. Since EAP-SKL is a pre-shared key authentication method, only the respective two modes are implemented. The one, from now on referred to as "mode 1", provides Perfect Forward Secrecy (PFS) and hence incorporates a Diffie-Hellman (DH) Key Exchange, which is known to be computational expensive. If this property is not needed, the other mode, referred to as "mode 2", is chosen. This mode achieves freshness by exchanging random values (nonces), and in absence of asymmetric cryptography mode 2 is notably efficient. In a nutshell, mode 1 provides a better security strength but higher computational costs, whereas mode 2 performs very fast but with fewer security strength. The notation introduced by [SKEME] is maintained to avoid confusion. There is a collision-resistant hash function, H, a keyed-hash function, F_Ko and as parameters for the DH key exchange g, x, y, m, where x and y are the client's and EAP server's private DH key, respectively. EAP-SKL choose SHA-1 as H and HMAC-SHA1 as F_Ko. The output SHA-1 and thus of HMAC-SHA1 is 160 bit. Furthermore, SK corresponds to the EAP Master Key (MK), which remains solely within the EAP method. Finally, the DH key exchange parameters have been chosen in accordance to [RFC3766]. The strength of the DH key exchange is based on the modulus size as well as the exponent size. An 3000-bit MODP public-key scheme corresponds roughly to a 128-bit symmetric-key scheme. EAP-SKL utilizes the 3072-bit MODP Group (id 15), defined in [RFC3526]. According to [RFC3526], the exponent size used in the DH key exchange should have double the entropy of the strength of the entire system, in particular the size of any symmetric key that will be derived from it (SK, MSK, EMSK). Since EAP-SKL has an effective key strength of 128 bit, the DH exponents (private keys) MUST have at least 256 bit. As cyclic group, g=2 is chosen. The rest of this section describes how EAP-SKL implements the two modes. Before any run of EAP-SKL, client and EAP server must agree on some 160-bit pre-shared key, referred to as Ko. How Ko is established, is Otto Expires Juli 2, 2005 [Page 6] Internet-Draft The EAP-SKL protocol January 2005 beyond the scope of EAP-SKL and thus must be realized by some secure out-of-band mechanism. At the end of a successful authentication, both client and EAP server have independently derived a session key, SK, in length of 160 bit. This key in turn is adequately expanded to generate the required keying material, that is a 64-byte MSK and a 64-byte EMSK. This is realized by a pseudorandom function, T-PRF, which is based on SHA-1 and widely accepted. EAP-FAST and PEAP make use of this function, too. Please see Appendix A for internals of T-PRF. T-PRF is invoked with the parameters (Key, S, OutputLength), where S = label + 0x00 + seed. Figure 1 shows the instantiation of these parameters by EAP-SKL. Since T-PRF generates in each iteration 20 byte random data, EAP-SKL let T-PRF iterate 7 times and then skip the last 12 byte. +--------------+-----------------+ | T-PRF | is set to | +--------------+-----------------+ | Key | Ko | | label | "EAP-SKL" | | seed | SK | | OutputLength | 128 | +--------------+-----------------+ Figure 1 Figure 2 illustrates the keying material in EAP-SKL. Otto Expires Juli 2, 2005 [Page 7] Internet-Draft The EAP-SKL protocol January 2005 +---------+ | Ko | 160 bit +---------+ | +===================+ | | | EAP-SKL | | | +===================+ | +---------+ | SK | 160 bit +---------+ | | +---------+ | T-PRF | pseudorandom function +---------+ | | 128 byte 0..127 | | +---------+ -+ +-----------| MSK | 64 byte | | 0..63 +---------+ | exported | | by EAP-SKL | +---------+ | +-----------| EMSK | 64 byte | 64..127 +---------+ -+ Figure 2 Otto Expires Juli 2, 2005 [Page 8] Internet-Draft The EAP-SKL protocol January 2005 3. Protocol Overview The message flow of EAP-SKL is shown in Figure 3. The conversation begins with the exchange of EAP Identity messages, where "id" is reserved for special tasks, like routing purposes or session resumption. peer P EAP Server S ------ ------------ <--- EAP-Request/Identity (1) EAP-Response/Identity(id) ---> (2) <--- EAP-Request/SKL-Start (value_S) (3) EAP-Response/EAP-SKL (id_P,value_P, F_Ko(value_S. value_P.id_P.id_S)) ---> (4) EAP-Request/EAP-SKL (F_Ko(value_P. <--- value_S.id_S.id_P)) (5) EAP-Response/SKL (F_Ko("success".SK)) ---> (6) <--- EAP-Success (7) where . denotes simple string concatenation. Figure 3 The respective values of value_S and value_P and thus the derivation of SK depend on the chosen mode (Figure 4). | PFS | value_P | value_S | SK | H | F_Ko -------+-----+---------+---------+-----------+-------+---------- mode 1 | yes | g^x | g^y | H(g^xy) | | -------+-----+---------+---------+-----------+ SHA-1 | HMAC-SHA1 mode 2 | no | nonce_P | nonce_S | F_Ko(arg) | | -------+-----+---------+---------+-----------+-------+---------- where arg = F_Ko(value_S.value_P.id_P.id_S). Figure 4 The choice of the mode is left solely to the EAP server. The client finds this out by the type of the received TLV payload in message (3). If the client does not agree with the proposed mode, he Otto Expires Juli 2, 2005 [Page 9] Internet-Draft The EAP-SKL protocol January 2005 indicates this by sending EAP-Response/Nak. Subsequently, the authentication conversation is aborted. The EAP server does not explicitely send his identity id_S. Instead of using the payload of EAP-Response/Identity, the client sends his NAI, id_P, as the first TLV in the payload of message (4). It follows the mutual authentication. This is realized by exchanging two message authentication codes (MACs), which are keyed with the pre-shared key Ko and thus proves knowledge of this key. Message 4 carries the client's MAC to the EAP server, which performs the same computation and check if both results are equal. In message 5, the EAP server sends his MAC to the client. Both client and EAP server compute the MAC over the same values, but concatenated in a different order. As a consequence, the client is sure to talk to the desired EAP server and, vice versa, the EAP server is sure to talk to the client identified by id_P. If mutual authentication fails, that is, one party can not verify the received MAC, the authentication conversation MUST be aborted. However, a successful authentication is followed by the derivation of SK on both sides. In mode 1, SK is g^(xy). In mode 2, the client's MAC (referred to as "arg" above) is MAC'ed again. Note that the client has already computed "arg" in message (4) and thus can reuses the result, which saves computational costs. Message 6 is probably not necessary, but is introduced because of EAP's Request-Response paradigma. It can serve as proof of a correct derived session key SK. Figure 5 and Figure 6 illustrates both modes from a cryptographic point of view. peer P EAP Server S ------ ------------ <--- g^y id_P; g^y; HMAC-SHA1(Ko; g^y.g^x.id_P.id_S) ---> HMAC-SHA1(Ko; g^x.g^y.id_S.ip_P); <--- id_S.id_P) HMAC-SHA1(Ko; "success".SK)---> Figure 5 Otto Expires Juli 2, 2005 [Page 10] Internet-Draft The EAP-SKL protocol January 2005 peer P EAP Server S ------ ------------ <--- nonce_S id_P; nonce_P; HMAC-SHA1(Ko; nonce_S.nonce_P.id_P.id_S) ---> HMAC-SHA1(Ko; nonce_P.nonce_S. <--- id_S.id_P) HMAC-SHA1(Ko; "success".SK)---> Figure 6 Otto Expires Juli 2, 2005 [Page 11] Internet-Draft The EAP-SKL protocol January 2005 4. Packet formats EAP-SKL messages are encapsulated within the payload of EAP-Request and EAP-Response frames, respectively. Therefore, a generic Type-length-value (TLV) attribute format is chosen (figure Figure 7). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type | length | value : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : value (contd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 Length contains the length of the TLV in byte. ---------------+-------------+------------------------ attribute name | type number | used for ---------------+-------------+------------------------ AT_ID | 0 | id_P AT_RAND | 1 | nonce_P, nonce_S AT_PUB | 2 | DH public key, g^x, g^y AT_MAC | 3 | HMAC-SHA1 (160 bit) ---------------+-------------+------------------------ Figure 8 That is, the EAP packet payload of messages (2)-(6) consists of one or more TLVs, as shown in Figure 9. In case of mode 1, messages (3) and (4) contain AT_PUB TLVs, in case of mode 2 AT_RAND TLVs. peer P EAP Server S ------ ------------ <--- AT_RAND/AT_PUB (3) AT_ID . AT_RAND/AT_PUB . AT_MAC ---> (4) <--- AT_MAC (5) AT_MAC ---> (6) Figure 9 Otto Expires Juli 2, 2005 [Page 12] Internet-Draft The EAP-SKL protocol January 2005 5. Security Considerations This section analyzes the security of EAP-SKL. In particular, it is shown that EAP-SKL complies with all mandatory requirements for EAP methods used in IEEE 802.11 wireless LAN deployments, as outlined in [I-D.walker-ieee802-req]. Mechanism: EAP-SKL belongs to the category of pre-shared key EAP methods. Mutual authentication: EAP-SKL provides mutual authentication. If both parties can verify the received HMAC, the other side is identified and authenticated. Since the MAC is computed over a string which contains fresh random values previously generated, both MACs are interlocked adequately. Replay protection: Assume an attacker has captured a whole, successful conversation of EAP-SKL. First, we investigate what happens if the attacker wants to impersonate the legitimate client. If value_S of the captured session is different from the current one, the attack fails in computing the MAC in message (4). Suppose now, value_S is the same. It follows that replay of the captures message (4) as well as (6) are recognized as valid ones by the EAP server and thus the attacker will receive an EAP-Success. Unfortunately, he can not derive from HMAC-SHA1(Ko;"success".SK) the session key SK and thus can not derive MSK and EMSK. The attack ends here, that is although the EAP authentication has been successful, subsequent conversation attempts will fail. This replay attack is avoided by strengthening the server's implementation. The space for value_P is large enough to reject any authentication request with the same value_P. Therefore, the server implementation should maintain a table with all previously received (id_P,value_P) pairs. With this precaution, a replayed session is recognized as a such and appropriate countermeasures can take place. Confidentiality: EAP-SKL does not provide confidentiality in terms of [RFC3748], section 7.2.1. The term "confidentiality" refers to encryption of EAP messages and successful and failure result indications. Key derivation: EAP-SKL generates the required keying material, namely a 64 byte MSK and a 64 byte EMSK, which are exported for derivation of further keying material. Key strength: The effective key strength of EAP-SKL is 128 bit (see also Section 2). Otto Expires Juli 2, 2005 [Page 13] Internet-Draft The EAP-SKL protocol January 2005 Resistance to dictionary attacks: EAP-SKL relies on a pre-shared key, which consists of random data. It is highly discouraged to generate this random data from a dictionary entry by applying some pseudorandom function. Protection against man-in-the-middle attacks: If the link layer is a shared media, there is generally a possibility for a third party (MitM) to place between two parties who want to communicate. The trust relation is established by deriving some common secret, which a third party can not derive from the captured conversation. For EAP-SKL, this is the session key SK, whose lifetime is the session. Without knowledge of Ko this common secret can not be derived. And without knowledge of Ko and SK, both MSK and EMSK can not be derived. Assume now, a MitM sits between peer and EAP Server, and intercepts all server messages and relays them to the peer. This works fine for the whole conversation, that is for messages (1) to (7). But, since the MitM does not know SK, this attack has only denial-of-service character. Protected ciphersuite negotiation: EAP-SKL does not support ciphersuite negotiation. Fast reconnect: EAP-SKL does not support fast reconnect. Cryptographic binding: EAP-SKL performs exactly one authentication and hence this technique is not applicable. Fragmentation: An EAP method may assume a mimimum EAP MTU of 1020 byte. Message (4) is the largest one. An EAP Request or Response packet begins with four fields (Code, Identifier, Length and Type), with total 5 byte, followed by the payload. value_P as modulo 3072 can be at most 384 byte, and finally HMAC-SHA1 produces a 20-byte MAC. These are 409 byte, so that AT_ID MAY NOT exceed 1020-409=611 byte. The encapsulated id_P thus may not exceed 611-4=607 byte. End-user identity hiding: EAP-SKL does not provide end-user identity hiding. The identity of the client is sent in plaintext. Otto Expires Juli 2, 2005 [Page 14] Internet-Draft The EAP-SKL protocol January 2005 6. IANA Considerations This document introduces one new IANA consideration. It requires IANA to allocate a new EAP Type for EAP-SKL. Otto Expires Juli 2, 2005 [Page 15] Internet-Draft The EAP-SKL protocol January 2005 7. References 7.1 Normative References [FIPS.180-1.1994] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, May 1994. [I-D.cam-winget-eap-fast] Salowey, J., "EAP Flexible Authentication via Secure Tunneling (EAP-FAST)", draft-cam-winget-eap-fast-01 (work in progress), October 2004. [I-D.walker-ieee802-req] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements for Wireless LANs", draft-walker-ieee802-req-04 (work in progress), August 2004. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", June 1996. 7.2 Informative References [I-D.bersani-eap-psk] Bersani, F., "The EAP-PSK Protocol: a Pre-Shared Key EAP Method", draft-bersani-eap-psk-06 (work in progress), November 2004. Otto Expires Juli 2, 2005 [Page 16] Internet-Draft The EAP-SKL protocol January 2005 [I-D.bersani-eap-synthesis-sharedkeymethods] Bersani, F., "EAP shared key methods: a tentative synthesis of those proposed so far", draft-bersani-eap-synthesis-sharedkeymethods-00 (work in progress), April 2004. [I-D.clancy-eap-pax] Arbaugh, W., "EAP Password Authenticated Exchange", draft-clancy-eap-pax-01 (work in progress), September 2004. [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. Author's Address Thomas Otto TU Braunschweig 38106 Braunschweig Germany Phone: EMail: t.otto@tu-bs.de Otto Expires Juli 2, 2005 [Page 17] Internet-Draft The EAP-SKL protocol January 2005 Appendix A. T-PRF The following description of T-PRF corresponds to [I-D.cam-winget-eap-fast], Appendix A. PRF(key, label, seed) = HMAC-SHA1(key, label + "\0" + seed) Where '+' indicates concatenation and "\0" is a NULL character. Label is intended to be a unique label for each different use of the T-PRF. To generate the desired OutputLength octet length of key material, the T-PRF is iterated as follows: T-PRF (Key, S, OutputLength) = T1 + T2 + T3 + T4 + ... Where S = label + 0x00 + seed; and T1 = HMAC-SHA1 (Key, S + OutputLength + 0x01) T2 = HMAC-SHA1 (Key, T1 + S + OutputLength + 0x02) T3 = HMAC-SHA1 (Key, T2 + S + OutputLength + 0x03) T4 = HMAC-SHA1 (Key, T3 + S + OutputLength + 0x04) OutputLength is a two octet value that is represented in big endian order. The NULL character, 0x00 shall be present when a label string is provided. Also note that the seed value may be optional and may be omitted as in the case of ...XXXXX TODO XXX Since each Ti generates 20 byte of keying material, the last Tn is truncated to accommodate the desired length specified by OutputLength. EAP-SKL has to derive 128 byte, so i is set to 7 and the last 12 byte are skipped. Otto Expires Juli 2, 2005 [Page 18] Internet-Draft The EAP-SKL protocol January 2005 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Otto Expires Juli 2, 2005 [Page 19]