MIPSHOP Working Group Souhwan Jung Internet Draft Jaeduck Choi Expires: August 25, 2008 Soongsil University February 25, 2008 A Secure and Efficient Handover Authentication in FMIP6 draft-jung-mipshop-secure-efficient-handover-01.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 This Internet-Draft will expire on August 25, 2008. Jung, et al. Expires August 25, 2008 [Page 1] Internet-Draft FMIPv6 Authentication February 2008 Abstract This document describes a secure and efficient handover authentication (SEHA) protocol in FMIP6. The main idea is using the Diffie-Hellman (DH) algorithm to enhance security aspects, and is modifying the DH key exchange to reduce computational cost at the Mobile Node (MN) by delegating exponential operation to the Access Router (AR). The MN and NAR establish the handover key HK_NAR through the PAR instead of the AAA server at any convenient time while the MN belongs to the NAR domain. The HK_NAR is used for handover authentication when the MN moves from the NAR to the next NAR. The main advantage of this document is more secure and suitable to a light-weight mobile terminal than the existing handover authentication scheme using SEND. Table of Contents 1. Introduction..................................................3 2. Terminology...................................................3 3. Protocol Overview.............................................4 4. Protocol Details..............................................6 4.1. MN Behavior..............................................8 4.2. PAR Behavior.............................................9 4.3. NAR Behavior.............................................9 5. Message Formats..............................................10 5.1. Handover Authentication Request (HAReq).................10 5.2. Handover Authentication Response (HAResp)...............11 5.3. Options.................................................12 6. Security Considerations......................................13 7. IANA Considerations..........................................14 8. References...................................................14 8.1. Normative References....................................14 Author's Addresses..............................................15 Intellectual Property Statement.................................15 Disclaimer of Validity..........................................16 Copyright Statement.............................................16 Acknowledgment..................................................16 Jung, et al. Expires August 25, 2008 [Page 2] Internet-Draft FMIPv6 Authentication February 2008 1. Introduction In the mobile IP networks [2],[3], the handover authentication should be provided to protect signaling messages against security vulnerabilities such as the Denial of Service (DoS) attack or the intercept attack by packet redirection. Also, it should require less computing power to be suitable for a light-weight mobile terminal. The distributing handover key scheme using SEND [4] provides good security features without resorting to the AAA server. However, there are potential problems such as a Sybil attack (forging identities) and DoS attack due to using self-generated private/public key pairs. The Secure Neighbor Discovery (SEND) [5] based on Cryptographically Generated Addresses (CGA) [6] is weak against the Sybil attack, in which the attacker uses several invented addresses so that a legitimate node can believe many other nodes to be around. This Sybil attack also causes the AR to be vulnerable to the DoS attack. For example, if the AR receives a number of forged requests, it should perform many verification and encryption operations based on public key algorithm to distribute handover keys. Also, this scheme requires computational overhead at the MN such as RSA signature and decryption for distributing a symmetric FMIPv6 handover key. This document describes a secure and efficient handover authentication (SEHA) based on a light-weight DH key exchange without the AAA server. The MN and the NAR (AR_i+1) establish the handover key HK_NAR (HK_i+1) through the PAR (AR_i) after exchanging both the RtSolPr and PrRtAdv messages while the MN belongs to the NAR domain. The SEHA also supports a robust security feature against DoS attack than the existing handover authentication scheme using SEND. Also, it requires less computation at the MN by delegating the DH half-key generation to the AR. This document defines two messages HAResq and HAResp, and new options to carry out handover authentication. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. New terminologies are defined in this memo. Jung, et al. Expires August 25, 2008 [Page 3] Internet-Draft FMIPv6 Authentication February 2008 Handover Authentication Request (HAReq): HAReq is a message to deliver parameters for the handover authentication to the AR. Handover Authentication Response (HAResp): HAResp is a message to deliver parameters for the handover authentication to the MN, and notify the MN of the success or failure of the handover authentication. HK_i : Handover key between the MN and AR_i for securing FBU message 3. Protocol Overview In our scheme, there are two assumptions. First, the MN and AAA server perform an initial full EAP authentication [7][8] during a bootstrapping resulting that a master key is established between them. Hence, the MN and AR share a Handover Key (HK) that is derived from the master key. The second assumption is that a secure channel exists among the ARs using the TLS or IPSec to protect handover authentication messages among them. The basic idea of our scheme is using the DH key exchange to enhance security aspects, and is modifying the DH algorithm to reduce computational cost at the MN by delegating exponential operation to the AR. This feature is more secure and suitable to a light-weight mobile terminal than the existing schemes. The other idea is that the MN and the NAR (AR_i+1) establish the handover key HK_NAR (HK_i+1) through the PAR (AR_i) instead of the AAA server after exchanging both RtSolPr and PrRtAdv messages with the NAR while the MN belongs to the NAR domain. In other words, the MN establishes the new Security Association (SA) between the MN and the NAR using the old SA between the MN and the PAR. The HK_NAR (HK_i+1) is used for handover authentication when the MN moves from the NAR (AR_i+1) to the next NAR (AR_i+2). Figure 1 shows the sequential steps of a proposed SEHA scheme in FMIPv6. The AAA server takes part only in the bootstrapping authentication procedure. The MN and the AR_1 share the key HK_1 after the bootstrapping authentication. When the MN moves from the AR_1 to the AR_2, the MN protects the FBU message using the HK_1. The MN in the AR_2 domain may exchange the HK_2 with the AR_2 to protect the FBU message for the next handover. This key exchange procedure is achieved among the AR_1, AR_2, and MN without the AAA server. The Jung, et al. Expires August 25, 2008 [Page 4] Internet-Draft FMIPv6 Authentication February 2008 AR_1 authenticates the MN using the Message Authentication Code (MAC) with the HK_1. If the validation is successful, the MN and AR_2 generate a new handover key HK_2 using the DH key exchange. The MN and AR_2 SHOULD cache the HK_2 during their lifetime. The HK_2 is used for handover authentication when the MN moves from the AR_2 to the next AR (AR_3). The MN repeats the same procedure whenever it handovers. Step 1 - Bootstrapping authentication Step 2 - FBU procedure protected by HK_1 when MN moves from AR_1 to AR_2 Step 3 - Handover from AR_1 to AR_2 Step 4 - Authentication procedure between AR_1 and MN using HK_1 - Key exchange (HK_2) based on DH key exchange Step 5 - FBU procedure protected by HK_2 when MN moves from AR_2 to AR_3 Step 6 - Handover from AR_2 to AR_3 Jung, et al. Expires August 25, 2008 [Page 5] Internet-Draft FMIPv6 Authentication February 2008 _ +-----+ +--------------------->| AAA | | +-----+ | |1 | | |HK_1 HK_2 HK_i HK_i+1 +------+ 4 +------+ +------+ +------+ | AR_1 |<------| AR_2 | ... | AR_i | |AR_i+1| +------+ +------+ +------+ +------+ | ^ | ^ | | | | | |2 |4 |5 | | | | | | | | V V V V +------+ 3 +------+ 6 +------+ | MN |------>| MN |----->| MN | +------+ +------+ +------+ HK_1 HK_1, HK_2 HK_2, HK_3 Figure 1 Protocol Overview. 4. Protocol Details Figure 2 shows the protocol of the handover authentication. In Figure 2, the MN SHOULD generate and store a random number r and value g^r after a bootstrapping authentication. The MN with the HK_PAR (HK_i) moves from the PAR (AR_i) to the NAR (AR_i+1) at the time T_1. Note that the MN currently belongs to the NAR domain. The MN and the NAR MUST exchange a handover key HK_i+1 to protect the FBU message for the next handover after exchanging both RtSolPr and PrRtAdv messages with the NAR when the MN belongs to the NAR domain as shown in the following figure. Jung, et al. Expires August 25, 2008 [Page 6] Internet-Draft FMIPv6 Authentication February 2008 MN NAR (AR_i+1) PAR (AR_i) | | | r,g^r, HK_i | |HK_i | | | --- T_1 : MN handovers to NAR | | | | | | RtSolPr | | |---------------------------->| | | PrRtAdv | | |<----------------------------| | | | | x| HAReq (M_1, r+x, g^r) | | |---------------------------->| |(g^(r+x) | |g^y | /g^r) | | HAReq (M_1, r+x, g^r, g^y | =g^x | |--------------------------->| | | | | | HAResp (M_2, g^x) | | HAResp (M_2, M_3, g^x, g^y) |<---------------------------| |<----------------------------| | | | | HK_i+1 = g^(xy) HK_i+1 = g^(xy) Figure 2 Procedure of Handover Authentication. The MN generates a new random value x and computes the message M_1. And then, the MN sends the HAReq message to the NAR. The HAReq message contains following values. M_1=H(HK_i, ID_MN||ID_PAR||ID_NAR||r+x||g^r) HAReq [M_1, ID_MN, ID_PAR, ID_NAR, r+x, g^r] Upon receiving the messages, the NAR generates a random number y and computes its DH public key g^y. The NAR forwards the receiving messages with the g^y to the PAR, which means that the integrity of g^y is guaranteed by the PAR establishing the security association with the MN. The HAReq message contains following values. HAReq [M_1, ID_MN, ID_PAR, ID_NAR, r+x, g^r, g^y] The PAR caching the MN's HK_i verifies the message M_1. If the validation is successful, the PAR computes a value g^(r+x), and then extracts the value g^x by computing g^(r+x)/g^r. The PAR computes the M_2, and then replies with the HAResp message to the NAR. The PAR Jung, et al. Expires August 25, 2008 [Page 7] Internet-Draft FMIPv6 Authentication February 2008 also notifies the success of authentication to the NAR. The HAResp message contains following values. M_2=H(HK_i, ID_MN||ID_PAR||ID_NAR||g^(r+x)||g^x||g^y) HAResp ["Success", M_2, ID_MN, ID_PAR, ID_NAR, g^x] If the NAR receives the messages including the failure notification from the PAR, the NAR notifies the MN of the failure of the handover authentication. Otherwise, the NAR computes the new handover authentication key HK_i+1=(g^x)^y= g^(xy) using the private key y and the received value g^x from the PAR. The NAR computes M_3, and sends the message HAResp to the MN. Note that the NAR SHOULD cache the HK_i+1 and ID_MN for securing FBU procedure when the MN will move from the NAR (AR_i+1) to the next NAR (AR_i+2). The HAResp message contains following values. M_3=H(g^(xy), M_2||ID_MN||ID_PAR||ID_NAR) HAResp ["Success", M_2, M_3, ID_MN, ID_PAR, ID_NAR, g^x, g^y] The MN computes the g^(r+x) by computing (g^r)x(g^x), and then verifies the M_2. If a success, the MN computes the new handover authentication key HK_i+1=(g^y)^x=g^(yx) using the private key x and the public key g^y, and then verifies the M_3. If the MN fails to verify the M_2 or M_3, the authentication fails. In the future, the MN MUST perform securing FBU using the HK_i+1 when it moves from the NAR (AR_i+1) to the next NAR (AR_i+2). - Securing FBU procedure : FBU, H(HK_i+1, FBU) 4.1. MN Behavior The MN MUST share the HK_1 with the AR_1 after initial bootstrapping authentication. Also, the MN SHOULD store a random value r and value g^r, and compute the exponent operation g^x by computing g^(r+x)/g^r to reduce computational overhead. The MN MUST use the HK_PAR (HK_i) for protecting the FBU message when the MN handovers to the NAR (AR_i+1). After moving to the NAR, the MN MUST initiate a HAReq message to exchange the HK_NAR (HK_i+1) with the NAR. The authentication procedure MUST be performed after receiving the PrRtAdv message from the NAR while the MN belongs to the NAR domain. If the MN receives the HAResp message including the success notification from the NAR, the MN MUST generate the HK_i+1 and cache Jung, et al. Expires August 25, 2008 [Page 8] Internet-Draft FMIPv6 Authentication February 2008 it for next handover authentication. In the future, the MN MUST use HK_i+1 for securing FBU between the MN and NAR when the MN moves from the NAR (AR_i+1) to the next NAR (AR_i+2). The MN that belongs to the NAR (AR_i+1) domain MUST store the HK_PAR (HK_i) until the MN and AR_i+1 exchange the HK_NAR (HK_i+1). Also, the MN SHOULD cache HK_i for its life time. If the MN comes back to the PAR domain, the MN SHOULD reuse its HK_i. 4.2. PAR Behavior The channels among the ARs SHOULD be established by the IPsec or TLS. Upon receiving a HAReq message from the NAR (AR_i+1), the PAR (AR_i) MUST verify the value M_1 in the HAReq message using the HK_i shared with the MN. If the PAR fails to verify the M_1, the PAR MUST send a HAResp message including the failure of authentication to the NAR, and ignore the received HAReq message. Otherwise, the PAR MUST compute a g^x by computing g^(r+x)/g^r. And then the PAR MUST generate the message M_2. The PAR MUST send the HAResp message with the result of M_1 verification to the NAR. The PAR SHOULD store the HK_PAR (HK_i) until the MN request handover authentication. Also, the PAR SHOULD cache HK_i for its life time. If the MN returns to the PAR domain, the PAR SHOULD reuse the MN's HK_i. 4.3. NAR Behavior Upon receiving the message HAReq from the MN, the NAR MUST generate a random number y and a value g^y. Also, the NAR MUST forward the received message HAReq with the value g^y to the PAR, and create cache table including the MN_ID, NAR_ID, PAR_ID, y, and g^y. The NAR MUST compute the new handover authentication key HK_i+1 using its DH private key y in cache table and the received value g^x from the PAR, when the NAR receives the message HAResp including the success notification. Also, the NAR MUST compute the message M_3 to confirm the handover key HK_i+1 with the MN. The NAR MUST send the message HAResp including the life time of the HK_i+1 to the MN. If the NAR receives the failure of authentication from the PAR, the NAR MUST delete the MN's cache table except the DH parameters y and g^y that are not used for generating handover key. The NAR SHOULD reuse the stored value y and g^y without computing new DH public keys. The NAR MUST verify a FBU message using the HK_i+1 when the MN moves from the NAR (AR_i+1) to the next NAR (AR_i+2). Jung, et al. Expires August 25, 2008 [Page 9] Internet-Draft FMIPv6 Authentication February 2008 5. Message Formats This document defines two messages HAReq and HAResp, and new options to carry out handover authentication. 5.1. Handover Authentication Request (HAReq) The HAReq MUST be sent from the MN to the AR for the handover authentication. Receiving the HAReq message from the MN, the AR MUST forward it to another AR. The HAReq message SHOULD use Options to deliver extra variables for authentication (to be assigned by IANA). 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 Code | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 Handover Authentication Request (HAReq) Message. HAReq Fields Message Code 8-bit field indicate the handover authentication protocol, the value of which is taken from the IANA. A value of '1' (to be assigned by IANA) indicates the HAReq message. Length 8-bit field is the length of the HAReq message. Reserved 16-bit field reserved for future use. This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Jung, et al. Expires August 25, 2008 [Page 10] Internet-Draft FMIPv6 Authentication February 2008 Options Options field includes extra variables for handover authentication. 5.2. Handover Authentication Response (HAResp) The HAResp MUST be sent to the AR and MN in responding to a HAReq message. 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 Code | Length | Result Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Handover Authentication Response (HAResp) Message. HAResp Fields Message Code 8-bit field indicates the handover authentication protocol, the value of which is taken from the IANA. A value of '2' (to be assigned by IANA) indicates the HAResp message. Length 8-bit field is the length of the HAResp message. Result Code 8-bit field indicates the result of authentication. A value of '200' (to be assigned by IANA) indicates the "Success", and '400' (to be assigned by IANA) indicates the "Fail" Jung, et al. Expires August 25, 2008 [Page 11] Internet-Draft FMIPv6 Authentication February 2008 Reserved 16-bit field reserved for future use. This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Options Options field includes extra variables for handover authentication. 5.3. Options The HAReq and HAResp messages SHOULD accommodate various options 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code | Option Length | Option Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 Option Message. Option Fields Option Code 8-bit field indicates extra variables as follows. M_1 (Code number: to be assigned by IANA) M_2 (Code number: to be assigned by IANA) M_3 (Code number: to be assigned by IANA) ID_MN (Code number: to be assigned by IANA) ID_PAR (Code number: to be assigned by IANA) ID_NAR (Code number: to be assigned by IANA) Jung, et al. Expires August 25, 2008 [Page 12] Internet-Draft FMIPv6 Authentication February 2008 Random_1 (Code number: to be assigned by IANA) : This value is r+x. Random_2 (Code number: to be assigned by IANA) : This value is g^r DH_MN (Code number: to be assigned by IANA) : This value is g^x. DH_AR (Code number: to be assigned by IANA) : This value is g^y. HK_LifeTime (Code number: to be assigned by IANA) Option Length 8-bit field is the length of the Options field. 6. Security Considerations The proposed scheme assumes that there are secure channels among ARs and no secure channel between the MN and the AR. Therefore, communications between the ARs are secure against the MITM (Man-in- the-Middle) attack. When communicating with the AR, the MN secures the messages using the MAC with the HK shared with the AR. This can also protect the MN and the AR against MITM attack. The DoS attack for exhausting resource has become a major security threat. The DoS attack considered on our scheme is the CPU exhaustion attack such as exponent operation when an attacker sends a number of fake requests to the AR. In the proposed scheme, by reusing unused DH public keys, ARs protect themselves against malicious attackers who will try to exhaust their computing power. The AR_i+1 requires two exponent operations per handover procedure: a DH public value g^y and handover key (g^x)^y. Upon receiving the fake requests, the AR_i+1 will generate DH public keys and forward the fake requests with the DH public keys to the AR_i. However, the AR_i may fail to verify the fake requests due to unknown HK_i, and then it notifies the failure of authentication to the AR_i+1. For the resistance against DoS attack, if the AR_i+1 receives the failure of authentication from the AR_i, the AR_i+1 should keep the generated DH public key (g^y) to be Jung, et al. Expires August 25, 2008 [Page 13] Internet-Draft FMIPv6 Authentication February 2008 reused for the next request. The SEHA can also protect the nodes against replay attack by using a random number and caching the MN's ID and HK_i. The SEHA scheme provides the PFS, but does not provide the PBS in case of exposed HK_i. The PFS and PBS mean that even if a handover key HK_i is compromised by some reasons, it never reveals all the previous and next handover keys. We use the DH key agreement protocol to provide the PFS and PBS. In case of the PFS, if the HK_i is exposed by some attacks, an attacker gives no clues to guess the previous handover key. The reason is that the MN and AR generate the handover key HK_i using new DH private key x_i and y_i whenever the MN performs the handover authentication. If, however, the HK_i is exposed by some reasons, the SEHA does not provide the PBS since then. Note that the HK stored at the MN has the same security strength as the master handover key or private key used in the existing schemes. The SEHA scheme is robust to the ping-pong problem. If the MN quickly changes its position between the ARs, there may be the ping-pong problem. When the MN frequently moves between the AR_i and AR_i+1, the handover key HK_i and HK_i+1 should be changed according to its movement area. The SEHA scheme securely caches the MN's HK at the MN and the AR. Hence, the MN can securely reuse the HK without disclosing it and performing redundant handover authentication procedure. 7. IANA Considerations The IANA will allocate the numbers to the HAReq, HAResp, and options. 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] C Koodli, R., "Mobile Ipv6 Fast Handovers", draft-ietf-mipshop- fmipv6-rfc4068bis-05, February 2008. [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Jung, et al. Expires August 25, 2008 [Page 14] Internet-Draft FMIPv6 Authentication February 2008 [4] Kempf, J. and Koodli, R, "Distributing a Symmetric FMIPv6 Handover Key using SEND", draft-ietf-mipshop-handover-key-03, November 2007. [5] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "Secure Neighbor Discovery (SEND)", RFC 3971, March 2005. [6] Aura, T., "Cryptographically Generated Addresses", RFC 3972, March 2005. [7] Aboba, B., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [8] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-22 (work in progress), October 2006. Author's Addresses Souhwan Jung Soongsil University 511, Sangdo-dong, Dongjak-gu Seoul 156-743 KOREA Phone: +82-2-820-0714 Email: souhwanj@ssu.ac.kr Jaeduck Choi Soongsil University 511, Sangdo-dong, Dongjak-gu Seoul 156-743 KOREA Phone: +82-2-824-1807 Email: cjduck@cns.ssu.ac.kr 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 Jung, et al. Expires August 25, 2008 [Page 15] Internet-Draft FMIPv6 Authentication February 2008 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, THE IETF TRUST 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 IETF Trust (2008). 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. Jung, et al. Expires August 25, 2008 [Page 16]