TCPM Working Group B. Weis Internet-Draft C. Appanna Expires: June 5, 2006 D. McGrew A. Ramaiah Cisco Systems December 2, 2005 TCP Message Authentication Code Option draft-weis-tcp-mac-option-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 June 5, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo describes a TCP [RFC0793] extension to enhance security for BGP [I-D.ietf-idr-bgp4] and other TCP-based protocols requiring message authentication. It provides message authentication using a Message Authentication Code (MAC), which is a superior authentication method to the keyed MD5 method previously used. The option also includes provision for automatic generation and distribution of MAC Weis, et al. Expires June 5, 2006 [Page 1] Internet-Draft TCP MAC Option December 2005 keys. A set of MAC algorithms are specified, as well as guidance when to use each one. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Option Header . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. MAC Algorithm ID Types . . . . . . . . . . . . . . . . 6 3.2. Authentication Data . . . . . . . . . . . . . . . . . . . 7 3.2.1. Authentication Data Size . . . . . . . . . . . . . . . 8 3.3. Encrypted Key . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. KEK Algorithm ID Types . . . . . . . . . . . . . . . . 8 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Key Management Methods . . . . . . . . . . . . . . . . . . 10 4.1.1. Locally Managed MAC Keys . . . . . . . . . . . . . . . 10 4.1.2. Automatic Generation of Keys . . . . . . . . . . . . . 10 4.2. MAC Option Size . . . . . . . . . . . . . . . . . . . . . 11 4.2.1. Authentication Data Only . . . . . . . . . . . . . . . 11 4.2.2. Adding an Encrypted Key . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Weis, et al. Expires June 5, 2006 [Page 2] Internet-Draft TCP MAC Option December 2005 1. Introduction The TCP MD5 Signature Option [RFC2385] specifies an option to provide integrity protection to BGP sessions using the MD5 algorithm and a key in a keyed MAC construction. MD5 does not provide a sufficient level of security, and recently published attacks motivate its replacement. Also, the keyed hash MAC construction used by RFC2385 has serious cryptographic weaknesses. An attacker who can find a collision in the underlying hash function can forge a message authentication code using a simple chosen-message attack [MACS]. This proposal describes a set of message authentication codes used to verify integrity of a TCP message. Message authentication codes are a well-accepted method of verifying message integrity. This proposal can use message authentication codes that require unique nonces. This is important because at present the best- performing MACs all have this requirement. The MAC Option can also securely transport new key material between end-points, using a long- lived encryption key. Neither of these options is mandatory to implement, in order to ensure that the MAC Option can easily be implemented in current TCP stacks. 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. Terminology Key Encrypting Key (KEK). A key used with a cryptographic algorithm to encrypt another key. Message Authentication Code (MAC). A keyed cryptographic checksum on data that uses a secret key to detect modifications of a message (e.g., a TCP segment). An attacker who does not know the secret key is unable to generate the MAC corresponding to a particular message, with very high probability. This is true even when the attacker can perform a chosen-message attack, and cause a legitimate user of the system to authenticate messages of its choice. Weis, et al. Expires June 5, 2006 [Page 3] Internet-Draft TCP MAC Option December 2005 2. Proposal This proposal describes a means of using a Message Authentication Code (MAC) algorithm to authenticate a TCP segment. Modern MAC algorithms were developed specifically for detecting modification to data (e.g., TCP segments) and are significantly stronger cryptographic methods than the TCP MD5 Signature Option. A number of MAC algorithms may be used, each of which has different strengths and weaknesses (described later in this proposal). The key used to create the MAC is assumed to be known only to the TCP end-points. The MAC authentication data is created by applying a MAC algorithm and a key to the following data: 1. the TCP pseudo-header (in the order: source IP address, destination IP address, zero-padded protocol number, and segment length) 2. the TCP header, excluding options, and assuming a checksum of zero 3. the TCP segment data (if any) Creating a MAC in this manner, an attacker does not only need to create a valid TCP segment (including a valid TCP sequence number), but also must be able to create a valid MAC. Creating a valid MAC requires knowledge of the key used to create the MAC. Unlike RFC 2385, this proposal does not apply the MAC algorithm to the key in the same manner as the MAC algorithm is applied to the TCP pseudo-header, header, and data. The MAC algorithms defined for this option use the key as a direct input to the algorithm, so there is no need to additionally include it in the MAC data. Additionally, including the key in the hashed data may weaken the MAC. This is because using the key as part of the message interferes with the reduction-based methods used to design encryption algorithms and to prove their security [KDM]. This proposal includes an option for passing the MAC key in-band, encrypted under a Key Encrypting Key (KEK) known to both TCP end- points. When an encrypted key is included in a TCP option, it is used to authenticate the current segment, and all subsequent segments in the TCP exchange until a new key is chosen by one or the other of the TCP end-points. Algorithms used with the KEK MUST be strong enough so that an attacker observing the segment cannot determine the key in a reasonable amount of time. One strong KEK algorithm is described below. Weis, et al. Expires June 5, 2006 [Page 4] Internet-Draft TCP MAC Option December 2005 Several methods of key management are possible with this proposal, and are discussed later in this document. Weis, et al. Expires June 5, 2006 [Page 5] Internet-Draft TCP MAC Option December 2005 3. Syntax This option has three parts: TCP option header, authentication data, and an optional encrypted key for use verifying integrity of this and future segments within this TCP flow. 3.1. Option Header The option header has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind | Length | MAC Alg ID |K| Key ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| o Kind (8 bits). Value that identifies this option as the Cryptographic Option. o Length (8 bits). Length in octets of the option, including its header. o MAC Alg ID (7 bits). Unique identifier describing the cryptographic algorithm and mode to be used as the MAC algorithm. o K (1 bit). When set to 1, signals that an encrypted key is included in the option. o Key ID (8 bits). A value identifying a particular key to both the sender and receiver. If K is set to one, the Key ID identifies the KEK used to protect encrypted MAC key. A value of 0 indicates that the key in use has no identifier. 3.1.1. MAC Algorithm ID Types The following MAC Algorithms are strong MAC algorithms suitable for use with this option. o HMAC-SHA-1-96. HMAC with the SHA-1 hash function, with output truncated to 96 bits [FIPS.198.2002]. This algorithm MAY be implemented for an implementation to conform to this option. o AES-128-GMAC-96. AES [FIPS.197.2001] with a 128-bit key in the GMAC [GMAC] mode of operation, with a 96-bit tag. This algorithm requires a 96-bit unique nonce. The nonce is formed as follows. The leftmost 56 bits are all set to zero. The next eight bits contain a direction byte; its binary value is 00000000 for the sender, and 00000001 for the receiver. The rightmost 32 bits are Weis, et al. Expires June 5, 2006 [Page 6] Internet-Draft TCP MAC Option December 2005 copied from the Sequence Number field. This algorithm MAY be implemented for an implementation to conform to this option. o AES-128-CMAC-96. AES with a 128-bit key in the CMAC mode of operation [FIPS.800-38B], with output truncated to 96 bits. The AES-128-CMAC-96 algorithm MUST be implemented for an implementation to conform to this option. o AES-128-UMAC-96. The UMAC-96 message authentication code [UMAC] with a 96-bit output tag. This algorithm also requires a nonce. For the purposes of this document the nonce will be 40 bit nonce. The nonce is formed as follows. The first eight bits contain a direction byte; its binary value is 00000000 for the sender, and 00000001 for the receiver. The rightmost 32 bits are copied from the Sequence Number field. This algorithm MAY be implemented for an implementation to conform to this option. 3.2. Authentication Data The authentication data provides segment integrity. If the MAC algorithm does not requires a nonce, then the Authentication Data is simply comprised of the MAC bytes, as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Message Authentication Code ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Message Authentication Code (variable). The size of the MAC varies according to the MAC algorithm (see table at the end of this section). If the MAC algorithm requires a nonce for its operation, it MUST be included at the beginning of the Authentication data, as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Message Authentication Code ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Sequence Number (32 bits). A unique monotonically increasing value used as a base for a nonce for algorithms requiring a unique value for each ICV value generated with a particular key. When a sequence number reaches the maximum value, the key MUST NOT be Weis, et al. Expires June 5, 2006 [Page 7] Internet-Draft TCP MAC Option December 2005 used to authenticate any further packets. o Message Authentication Code (variable). The size of the MAC varies according to the MAC algorithm (see table at the end of this section). 3.2.1. Authentication Data Size The size of the authentication data field varies depending on the output of the MAC algorithm and whether or not the MAC algorithm requires a sequence number field. The following table lists the MAC algorithms identified in this proposal and the resulting size of the authentication data field. +-----------------+---------------------------------+ | MAC Algorithm | Authentication Data Size (bits) | +-----------------+---------------------------------+ | HMAC-SHA-1-96 | 96 | | AES-128-GMAC-96 | 128 | | AES-128-CMAC-96 | 96 | | AES-128-UMAC-96 | 128 | +-----------------+---------------------------------+ 3.3. Encrypted Key When K is set to 1, the encrypted key is included in the TCP MAC Option following the authentication data. The length of the key can be determined from the algorithm type, and need not be explicitly included in the option. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ KEK Alg ID | Encrypted Key ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o KEK Alg ID (8 bits) -- This field contains an algorithm type to be used with the key encrypting key. o Encrypted Key (variable). The size of the encrypted key field depends upon the size of the encrypted key (see below). 3.3.1. KEK Algorithm ID Types The following algorithms are suitable to be used with a key encrypting key. Weis, et al. Expires June 5, 2006 [Page 8] Internet-Draft TCP MAC Option December 2005 AES-128-ECB. The MAC key is encrypted using an AES 128-bit key encrypting key, resulting in a 128-bit encrypted key. Use of ECB mode is acceptable because only one block is being encrypted. This algorithm MUST NOT be used to encrypt a MAC key larger than 128 bits. (An example of an algorithm that could be used to encrypt a MAC larger than 128 bits is the NIST Key Wrap [KEYWRAP].) Weis, et al. Expires June 5, 2006 [Page 9] Internet-Draft TCP MAC Option December 2005 4. Discussion 4.1. Key Management Methods Experience with key management for RFC 2385 have shown that key management for TCP option keys is subject to varying operational constraints. A single pre-configured MAC key is neither secure, nor operationally sound. This proposal provides for several different methods of managing multiple MAC keys, depending on the operational requirements of the communicating TCP end-points. Two of these methods are described in detail below. 4.1.1. Locally Managed MAC Keys In this method, two TCP end-points each configure one or more MAC keys. When keys have a unique Key ID, it is placed in the option header to declare which key was used to calculated the MAC. In order to guarantee that keys are not used longer than their cryptographic lifetime, keys must be periodically changed. Some methods of changing keys is described in [I-D.ramaiah-key-rollover]. When locally managed MAC keys are used, the proposed option only contains the option header and authentication data. K in the option header is never set to 1 when locally managed MAC keys are used. A MAC algorithm requiring a nonce MUST NOT be used in this mode due to the risk of re-using a nonce. 4.1.2. Automatic Generation of Keys In this method, the two TCP end-points configure one or more KEKs having a long lifetime. A KEK is used to encrypt a randomly generated MAC key, which is then included in the Encrypted Key portion of the TCP option. This allows for the scheduled automatic generation of keys that can be periodically replaced or based on the policy of either TCP. Each KEK has a Key ID associated with it. When a particular KEK is used to generate a MAC key, the TCP endpoint places its Key ID in the option header to declare which key was used to encrypt the MAC key. When a TCP end-point begins to send with a new key, it SHOULD retain the previous key until the peer also begins to encrypt using the new key. Doing so allows a continued receipt of TCP segments from the peer, including ack messages indicating that the segment with the new MAC key was not received. MAC algorithms requiring a nonce can be used safely, since the keys are randomly chosen. Weis, et al. Expires June 5, 2006 [Page 10] Internet-Draft TCP MAC Option December 2005 4.2. MAC Option Size The cumulative number of TCP option bytes is currently limited to 40 bytes. The TCP MAC Option can consume more or fewer bytes, depending on a number of factors. The following sections describe several scenarios. 4.2.1. Authentication Data Only The option consumes four bytes for the option header. If K is not set to one, then the total size of the TCP MAC option is only the additional number of bytes needed by the MAC algorithm. All MAC algorithms described in this proposal not requiring a nonce require 12 bytes. This gives a total of 16 bytes for the TCP MAC option, which is four bytes less than used by RFC 2385. MAC algorithms requiring a nonce require an additional four bytes to carry a sequence number in the authentication data portion of the option. This results in a total of 20 bytes. However, MAC algorithms requiring a nonce tend to consume fewer software and/or hardware resources than other MAC algorithms. Using a MAC algorithm requiring a nonce trades off of an additional four bytes in the segment for a faster cryptographic algorithm. 4.2.2. Adding an Encrypted Key If K is set to one, then the encrypted key field is added to the MAC option. This adds the ability to do in-band keying, and simplify key management operations, but with a cost of additional TCP option bytes. When an encrypted key is included, one byte is always needed to describe the KEK algorithm used to encrypt the MAC key. The KEK algorithm also determines the number of bytes needed for the encrypted MAC key. The one KEK algorithm defined in this proposal requires 16 bytes, which results in a total of 17 bytes for the encrypted key. Thus, 33 bytes total bytes are required when paired with a MAC algorithm not needing a nonce (although 36 bytes may be used if padding is added). A total of 37 bytes are required when paired with a MAC algorithm needing a nonce (or 40 bytes if padding is added). However, the encrypted key is only required when one of the TCP end- points requires a new key (i.e., at the start of a TCP session, or when the security policy mandates a change later on in the session.) All other segments in the TCP session contain only the Authentication Data portion, which remains a modest size. Weis, et al. Expires June 5, 2006 [Page 11] Internet-Draft TCP MAC Option December 2005 5. IANA Considerations The terms "Standards Action" and "Private Use" in this section indicate the polices described for these terms in [RFC2434]. A new TCP Option Kind value must be defined in the IANA TCP Parameters registry. The option header contains an 8-bit message type, for which IANA is to create and maintain a registry entitled "MAC Algorithm IDs". This document defines the following message authentication code types: MAC Algorithm ID Value ---------------- ----- RESERVED 0 HMAC-SHA-1-96 1 AES-128-GMAC-96 2 AES-128-CMAC-96 3 AES-128-UMAC-96 4 Standards Action 5-64 Private Use 65-127 The option header contains an 8-bit message type, for which IANA is to create and maintain a registry entitled "Key Encrypting Key Algorithm IDs". This document defines the following KEK types: KEK Algorithm ID Value ---------------- ----- RESERVED 0 AES-128-ECB 1 Standards Action 2-128 Private Use 129-254 Note to RFC Editor: this section may be removed on publication as an RFC. Weis, et al. Expires June 5, 2006 [Page 12] Internet-Draft TCP MAC Option December 2005 6. Security Considerations This proposal describes a strong authentication method for authenticating TCP segments. It defines the use of cryptographic MAC algorithms, which are considered state-of-the-art. As such, their expected lifetime of usefulness extends for several years. But cryptographic algorithms have an effective lifetime, depending on advancing processor speed and cryptographic research. This proposal provides for the future addition of new MAC algorithms as they are needed. MAC algorithms requiring a unique nonce per segments (e.g., AES-128- GMAC-96) MUST NOT be used be used with manually configured keys. If the sequence number used as an input to the nonce wraps (or is re- initializing after a system reboot), a single nonce would be used multiple times with a single key. This would cause a catastrophic cryptographic failure, with the amount of damage dependant upon the actual algorithm. Management of RFC 2385 keys has been a significant operational problem, both in terms of key synchronization and key selection. Current guidance [RFC3562] warns against sharing RFC 2385 keys between systems, and recommends changing keys according to a schedule. The same general operational issues are relevant for the management of MAC keys. This proposal allows for in-band automatic re-keying, which provides the following key management benefits: o Automated key lifetime management. A system can rollover keys triggered by any means chosen by the system (e.g., volume lifetime, time lifetime). o Automated key selection. Keys chosen with a good random number generator are superior in quality to manually chosen keys. o Keys are chosen for use of a particular TCP session, and not shared between TCP session to different peers. Use of in-line key management requires a static KEK with a long lifetime. Whereas the KEK needs to be changed periodically, the length of the period should be very long, compared to the lifetime of the MAC keys. Weis, et al. Expires June 5, 2006 [Page 13] Internet-Draft TCP MAC Option December 2005 7. References 7.1. Normative References [FIPS.197.2001] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, < http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>. [FIPS.198.2002] National Institute of Standards and Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198, March 2002, . [FIPS.800-38B] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication", FIPS PUB 800-38B, May 2005, . [GMAC] McGrew, D. and J. Viega, "Galois/Counter Mode of Operation (GCM)", Submission to NIST modes of operation, May 2005, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 7.2. Informative References [I-D.ietf-idr-bgp4] Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-26 (work in progress), October 2004. [I-D.ramaiah-key-rollover] Ramaiah, A., Mynam, S., and C. Appanna, "Key rollover schemes for TCP-based routing applications", draft-ramaiah-key-rollover-00 (work in progress), Weis, et al. Expires June 5, 2006 [Page 14] Internet-Draft TCP MAC Option December 2005 November 2005. [KDM] Black, J., Rogaway, P., and T. Shrimpton, "Encryption- Scheme Security in the Presence of Key-Dependent Messages", Selected Areas in Cryptography 2002 (SAC 2002), Lecture Notes in Computer Science, vol. 2595, Springer- Verlag, 2003., May 2002, . [KEYWRAP] "Draft NIST AES Key Wrap Specification", November 2001, . [MACS] Bellare, M., Canetti, R., and H. Krawczyk, "Keying Hash Functions for Message Authentication", Proceedings of Crypto'96 , LNCS 1109, pp. 1-15., June 1996, . [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003. Weis, et al. Expires June 5, 2006 [Page 15] Internet-Draft TCP MAC Option December 2005 Authors' Addresses Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA Phone: +1-408-526-4796 Email: bew@cisco.com Chandrashekhar Appanna Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA Phone: +1-408-526-6198 Email: achandra@cisco.com David McGrew Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA Phone: +1-301-349-5815 Email: mcgrew@cisco.com Anantha Ramaiah Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA Phone: +1-408-525-6486 Email: ananth@cisco.com Weis, et al. Expires June 5, 2006 [Page 16] Internet-Draft TCP MAC Option December 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. Weis, et al. Expires June 5, 2006 [Page 17]