Network Working Group Feng BAO INTERNET-DRAFT Robert DENG Expires: December 8, 2004 Ying QIU Network Working Group Jianying ZHOU Institute for Infocomm Research(I2R) June 9, 2004 Certificate-based Binding Update Protocol (CBU) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 8, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document proposes a comprehensive security solution for mobile IPv6 networks including secure binding update, secure fast handover, user authentication and session key management for data security. In our proposal, one of the home agent's functions is to act as security proxy for its mobile nodes. The authentication is based on the home agent's certificate and the secret session keys are generated by strong cryptosystems. Our proposal avoids many security obstacles in the Return Routability protocol and provides a simple, integrated and efficient security solution for mobile communication. Expires: December 8, 2004 [Page 1] Internet Draft CBU June 9, 2004 Table of Contents 1. Introduction ................................................. 2 2. Notations .................................................... 4 3. Certificate-based Binding Update Protocol(CBU) ............... 4 4. Use of CBU: Secure Binding Update between Two Mobile Nodes .. 10 5. Use of CBU: Implementation of CBU in HMIPv6 ................. 11 6. Security Considerations ......................................13 7. Conclusion ...................................................13 References .......................................................14 Authors' Addresses ...............................................15 Intellectual Property and Copyright Statements ...................16 1. INTRODUCTION The demand for mobile communication requires a solution for efficient authentication of mobile nodes and protection of communications between mobile nodes. Presently, the IETF mobile working group has submitted two major drafts on mobile connection: i) "Mobility Support in IPv6 (MIPv6)"[1], which specifies a protocol that allows mobile nodes to remain reachable while moving around in the IPv6 Internet, and ii) "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)"[2], which introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Figure 1 illustrates the topology of communications among Mobile Node (MN), Correspondent Node(CN), Home Agent(HA) and Mobility Anchor Point (MAP). Under this architecture, the major security issue is how to authenticate MN by CN and MAP and how to protect communications in channels of MN-HA, MN-CN, HA-CN, MAP-MN and MAP-HA. CN ------ HA | /| | / | | / | | / | MN ----- MAP Figure 1: Topology and protected channels in MIPv6. Expires: December 8, 2004 [Page 2] Internet Draft CBU June 9, 2004 In the Mobile IPv6 [1], a method of Return Routability(RR) is used to process Binding Updates(BU). However, RR cannot provide satisfied level of security. Therefore, the working group suggests to bundle IKE[3] for improving the authentication ability and protecting the communication channel MN-HA. The original goal of RR was to provide a simple way to protect the signals of binding update. But it is now used with IKE and IPSec for higher security requirement. Consequently, many patches for RR are introduced to solve the above issues, and the RR solution becomes more and more complicated. For example, in order to handle the scenario of two mobile nodes in simultaneous movement, a new RR model is introduced: one deals with fixed CN while another deals with mobile CN. Even worse, due to the heavy computing overheads, IKE is not suitable for mobile devices (e.g., mobile phone, etc.) with very limited computing power and battery lifetime. In this document, we propose a comprehensive security solution for mobile IPv6 networks and try to provide a simple, integrated and efficient security solution for mobile communication. In our solution, all the security features, such as secure binding update, seamless secure fast handover, user authentication, session key management for data security, etc., are provided within one framework. In this solution, the home agent handles strong authentication for its mobile nodes and the authentication process is mainly run between wired devices (i.e., a home agent and a wired correspondent node or the home agent of a mobile correspondent node). Moreover, the complicated session key management and security association management are also deployed on the home agent. The motivation behind this is that home agents are fixed machines with rich computing capability and are connected to wired networks with a much broader bandwidth and more stable connection than mobile networks. Therefore, our solution could keep the balance well between the strong security requirements for e-commerce and the weak capability of mobile devices in terms of computing power and communicating speed. Expires: December 8, 2004 [Page 3] Internet Draft CBU June 9, 2004 2. NOTATIONS The notations used throughout this paper are listed below for easy reference: h(): a one-way hash function, such as MD5 or SHA. prf(k, m): a keyed pseudo random function -- often a keyed hash function. It accepts a secret key k and a message m, and generates a pseudo random output. This function is used for both message authentication and cryptographic key derivations. e(k ,m): encryption of message m with a secret key k. Px/Sx: a public and private key pair of node X in a digital signature scheme such as RSA or DSS. Sig(Sx, m): node X's digital signature on a message m using a private key Sx. m|n: concatenation of two messages m and n. 3. CERTIFICATE-BASED BINDING UPDATE PROTOCOL(CBU) In CBU protocol, the digital signature cryptosystem is used. The public/private key pair of HA is denoted by PK_HA and SK_HA. The private key SK_HA is kept by HA in the home link, probably inside a tamper-resistant hardware of cryptogram processing device. The home link obtains a public key certificate, Cert_HA = {HLSP, PK_HA, Valid_Interval, SIG_CA} from a Certification Authority(CA), where HLSP is the home link subnet prefix, Valid_Interval is the valid duration of the certificate, and SIG_CA is CA's signature on HLSP, PK_HA and Valid_Interval. Figure 2 shows message exchange between a mobile node MN, its home agent HA and its correspondent node CN in CBU protocol. The existence of and operations performed by HA are made transparent to CN. The use of cookies during the key exchange is a weak form of protection against an attacker who generates a series of request packets, each with a different spoofed source IP address, and sends them to a protocol party. For each request, the protocol party will first validate cookies before performing computational expensive public key cryptographic operations. Below is a detailed description of the CBU protocol. When a mobile node MN wants to start route optimization operation with a correspondent node CN, it sends a route optimization request Expires: December 8, 2004 [Page 4] Internet Draft CBU June 9, 2004 MN HA CN | | | |=====REQ=====>|===COOKIE0===>| | | | | |<===COOKIE1===| long term | | | messages | |====EXCH0====>| | | | |<=====REP=====|<====EXCH1====| | | | ------------------------------------------------------ | | | |======BU====================>| | | | short term |<====================BA======| message for BU | | | ------------------------------------------------------ | | | |===REQ_KEY===>|===EXCH0'====>| short term | | | message for k_EN |<====NEWKEY===|<===EXCH1'====| | | | Figure 2. Message exchange in CBU protocol. REQ = {Src=HoA, Des=HA, e(k_HA, HoA, CoA, CN, N0 )} to HA via IPSec-protected secure tunneling. Here, HA represents both the home agent and its IP address while CN represents both the correspondent node and its IP address. N0 is a nonce used to match the reply message REP. k_HA is a session key for the IPSec secure tunnel, its initial value is a pre-shared secret value z which is generated by HA before MN leaves its home link. How to update the session key will be described later. IPSec provides replay protection only when dynamic security association establishment is used. This may not always be possible and manual keying might be preferred in certain circumstances. For this reason, a random number N0 is included in order to counter message replay. After decrypting the REQ message and verifying HoA, HA creates a cookie C0 and sends COOKIE0 = {Src=HoA, Des= CN, C0} to CN. In reply, CN generates a nonce N1 and a cookie C1, and sends Expires: December 8, 2004 [Page 5] Internet Draft CBU June 9, 2004 COOKIE1 = {Src=CN, Des=HoA, C0, C1, N1} to MN. Note that the destination address in COOKIE1 is MN's home address HoA. As a result, this message is delivered to MN's home link and intercepted by HA using IPv6 Neighbor Discovery. Upon receiving COOKIE1, HA checks on the validity of C0, generates a nonce N2 and a Diffie-Hellman secret value x < p, computes its Diffie-Hellman public value g^x and its signature SIG_HA = Sig(SK_HA, HoA | CN | g^x | N1 | N2 | TS) using home link's private key SK_HA, where TS is a time stamp. This time stamp does not have to be checked by the recipient during the message exchange. It will be used to trace back the culprit should a malicious mobile node flooding attack have occurred. Finally, HA replies CN with EXCH0 = {Src=HoA, Des= CN, C0, C1, N1, N2, g^x, TS, SIG_HA, Cert_HA}, where Cert_HA is the public key certificate of the home link as defined before. Note that the values of N1 and N2 are included in the signature SIG_HA in order to counter replay of old signatures and to resist chosen message attacks to the signature scheme, respectively. When CN receives EXCH0, it validates the cookies, the home link's public key certificate Cert_HA, the signature and more importantly, checks for equality of the home link subnet prefix strings embedded in both Cert_HA and HoA. If all the validations and checking are positive, CN can be confident that the home address HoA of MN is authorized by its home link and the Diffie-Hellman public vaule g^x is freshly generated by MN's home link. CN next generates its Diffie-Hellman secret value y < p. It then computes its Diffie- Hellman public value g^y, the Diffie-Hellman key k_DH = (g^x)^y, a master secret k_master = prf(k_DH, N1 | N2 ), and three secret session keys k_BU = prf(k_master, N1 | N2 | 0), k_BA = prf(k_master, N1 | N2 | 1), k_EN = prf(k_master, N1 | N2 | 2), Expires: December 8, 2004 [Page 6] Internet Draft CBU June 9, 2004 where k_BU is the binding key used for authenticating binding update messages from MN to CN, k_BA is the acknowledgement key used for authenticating binding acknowledge messages from CN to MN, and k_EN is the encryption key used for encrypting/decrypting packets between MN and CN. Then CN sends MN EXCH1 = {Src=CN, Des= HoA, C0, C1, g^y, SIG_CN, Cert_CN}, where SIG_CN = Sig(SK_CN, CN | HoA | g^y | EXCH0). and Cert_CN = {CN, PK_CN, Valid_Interval, SIG_CA} is CN's certificate from CA, and CN could be CN's IP address (if CN is a wired terminal node) or CN's home link subnet prefix (if CN is a server-supported mobile node). Therefore, both parties MN and CN could identify each other, which will be useful for setting up access control on MN (or HA) and CN. Again, this message is intercepted by HA, which first validates the cookies, calculates the Diffie-Hellman key k_DH = (g^y)^x and the master secret k_master = prf(k_DH, N1|N2). HA also generates the secret session keys k_BU = prf(k_master, N1|N2|0), k_BA = prf(k_master, N1|N2|1), k_EN = prf(k_master, N1|N2|2) and k_HA-next = prf(z, N0 | N1 ), where k_HA-next is the IPSec session key used for the IPSec- protected tunnel between MN and HA. Then HA sends REP = {Src= CN, Des=CoA, payload} to MN through IPSec-protected secure tunneling, where payload = e(k_HA, N0, k_BU, k_BA, k_EN, k_HA-next). Please note, we use the current k_HA to encrypt the next k_HA-next, which will be kept by both MN and HA for next use when MN sends a new REQ to HA. Expires: December 8, 2004 [Page 7] Internet Draft CBU June 9, 2004 Considering the REP message might be lost during the transfer, HA should keep the previous k_HA until it confirms MN had used the new k_HA. If MN did not receive the REP message after a reasonable interval, it will resend the REQ message. First, HA use its current k_HA(i.e. k_HA-next here) to decrypt the REQ message. If HA cannot get a HoA that is belonged to its home link subnet, it will use the previous k_HA(i.e. k_HA here) to decrypt the REQ message again. After verifying HoA, HA can simply resend the REP message to MN. After receiving REP, MN decrypts the payload with the current k_HA and checks whether N0 is the same as the one it sent out in REQ. If so, MN proceeds to send a binding update message BU = {Src=CoA, Des=CN, HoA, Seq#, LT_BU, MAC_BU} to CN, where MAC_BU = prf(k_BU, HoA | CoA | Seq# | LT_BU) is a MAC generated with k_BU to authenticate the BU message, Seq# is a sequence number used to detect replay attack, and LT_BU is the lifetime of the binding. If BU is verified positive, CN may reply with a binding acknowledgement message BA = {Src=CN, Des=CoA, HoA, Seq#, LT_BA, LT_EN, MAC_BA}, where Seq# is copied from the BU message, LT_BA is the granted lifetime of the binding, LT_EN is the lifetime of k_EN, and MAC_BA = prf(k_BA, CoA | CN | Seq# | LT_BA | LT_EN) is a MAC generated with k_BA to authenticate the BA message. Then, CN will create a binding cache entry for HoA which includes the care-of-address, session keys, lifetimes, etc. Now CN can start sending packets encrypted with k_EN to MN at CoA address. When the binding expires, which is defined by LT_BA or MN changes its domain, MN and CN can use messages BU and BA to update the binding. Meanwhile, when k_EN expires, which is defined by LT_EN, MN sends HA a message REQ_KEY = {Src=HoA, Des=HA, e(k_HA, HoA, CoA, CN, N0', REQKEN)} where REQKEN indicates to update k_EN. After decrypting the REQ_KEY message and verifying HoA, HA generates a new nonce N1' and sends Expires: December 8, 2004 [Page 8] Internet Draft CBU June 9, 2004 EXCH0' = {Src=HoA, Des=CN, N1', MAC_EXCH0'} to CN, where MAC_EXCH0' = prf(k_EN, HoA | N1' ). If EXCH0' is verified positive, CN also generates a new nonce N2' and replies EXCH1' = {Src=CN, Des=HoA, N1', N2', LT_EN, MAC_EXCH1'} to HA, where MAC_EXCH1' = prf(k_EN, CN | N1' | N2' | LT_EN ); After verifying and getting the new nonces N0' and N1', both HA and CN compute the new encryption key respectively k_EN-new = prf(k_master, N1' | N2' | 2 ), then HA forwards the new encryption key NEWKEY = {Src=CN, Des=CoA, e(k_HA, N0', k_EN-new, LT_EN )}. to MN for following packets between MN and CN . As the messages of REQ_KEY and NEWKEY might get lost during the transfer, MN could resend the requst message REQ_KEY if it does not receive the NEWKEY message after a resonable interval. In this proposal, messages for a new binding update request (referring to Figure 2.) are long-term, i.e., throughout a communication session or even across multiple sessions, while messages for the follow-up binding updates and the IPSec session keys are short-term, which are decided by their lifetimes LT_BA and LT_EN, respectively. In most of time, when MN changes its CoA, it only needs to send the BU message to CN. Therefore, our protocol could get high performance in the handover process. In the CBU protocol, as described above, the security association (binding cache entry) is based on the addresses of CN and CoA. Therefore, the IPSec could be used as usual. On the contrast, in RR bundled IKE method, the security association is based on addresses of CN and HoA, the IPSec cannot be used without modification because HoA is not deployed as source/destination address in the header of IP packets. Expires: December 8, 2004 [Page 9] Internet Draft CBU June 9, 2004 A major feature of our CBU protocol is provision of key management in the IKE style for protecting the channels of MN-HA, MN-CN and HA-CN. 4. SECURE BINDING UPDATE BETWEEN TWO MOVING MOBILE NODES In this section, we discuss how to use CBU protocol in the scenarios of two mobile nodes in simultaneous movement. In Figure 3, CN_MN is a mobile correspondent node with home address CN_HoA and care-of-address CN_CoA while CN_HA is its home agent. The messages between NM, HA and CN_HA are the same as those shown in Figure 2 but the CN's address is replaced by CN_HoA. MN HA CN_HA CN_MN | | | | |=====REQ=====>|===COOKIE0===>|----TEST---->| | | | | | |<===COOKIE1===|<---ALIVE----| | | | | | |====EXCH0====>| | | | | | |<=====REP=====|<====EXCH1====|====KEYS====>| | | | | |======BU====================>|====FWD=====>| | | | | |<====================BA====================| | | | | Figure 3. Message exchange between two mobile nodes. Messages TEST and ALIVE are optional for testing whether CN_MN is alive. TEST = {Src=CN_HA, Des=CN_CoA, test_flag} ALIVE = {Src= CN_CoA, Des=CN_HA, N3} where N3 is a nonce generated by CN_MN. After computing secret session keys k_BU, k_BA and k_EN, CN_HA also sends these keys KEYS = {Src=CN_HA, Des=CN_CoA, e(k_CN, N3, k_BU, k_BA, k_EN)} Expires: December 8, 2004 [Page 10] Internet Draft CBU June 9, 2004 to CN_MN through their own IPSec-protected tunnel, encrypted with their preset IPsec session key k_CN. When CN_HA intercepts the binding message BU from MN, CN_HA simply forwards the message to CN_MN through the reserved tunnel FWD = {Src=CoA, Des= CN_CoA, HoA, Seq#, LT_BU, MAC_BU}. Upon receiving FWD and checking the validity of MAC_BU, CN_MN Returns BA = {Src=CN_CoA, Des=CoA, CN_HoA, Seq#, LT_BA, LT_EN, MAC_BA} to MN in order to inform MN of its current care-of-address CN_CoA. MAC_BA is calculated as MAC_BA = prf(k_BA, CoA | CN_CoA | Seq# | LT_BA | LT_EN). After receiving the messages of BU and BA, MN and CN_MN will create a binding cache entry for each other, respectively, which includes care-of-addresses of the both peers, session keys, lifetimes, etc. Then the two mobile nodes can start sending packets encrypted with k_EN to each other at their CoA addresses. As described above, the home agent always negotiates with a fixed peer, either a fixed CN or the home agent (CN_HA) of a mobile CN. When the initial mobile node (MN) sends its current CoA in the BU message to the correspondent home agent (CN_HA), CN_HA will forward MN's CoA to its mobile node (CN_MN), and CN_MN will send its current CoA to MN directly. Therefore, from MN's point of view, it never takes care whether the correspondent node is a moving node or not. On the contrary, in the RR protocol, a special message type is used to process the scenario of two mobile nodes in simultaneous movement. 5. IMPLEMENTATION of CBU in HMIPv6 In the protocol of HMIPv6 [2], the concept of Mobility Anchor Point (MAP) is introduced. MAP is a router located in a domain visited by the mobile nodes. MAP provides the localized mobility management for the visiting mobile nodes. Every mobile node bundles three addresses: Home Address (HoA), Regional Care-of-Address (RCoA), and On-Link Care-of-Address (LCoA). RCoA is an address on the MAP subnet, and obtained by the mobile Node (MN) from the visited domain. LCoA is configured on a MN's interface based on the prefix advertised by its default router. In fact, it is a care-of-address in normal MIPv6. Figure 4 shows the architecture of HMIPv6. Expires: December 8, 2004 [Page 11] Internet Draft CBU June 9, 2004 +----+ +----+ | HA | | CN | +----+ +----+ | | +---+ +---+ | | +-------+ | MAP | +-------+ | | +---+ +---+ | | +-----+ +-----+ LCoA1 | AR1 | | AR2 | LCoA2 +-----+ +-----+ +----+ | MN | movement +----+ ---------> Figure 4. Hierarchical MIPv6 domain. In HMIPv6, when CN sends packets to MN's RCoA, MAP intercepts the packets and forwards the packets to MN's LCoA. However, as the binding update message from MN to MAP is not authenticated when MN changes its Access Router (AR), attackers can easily launch "Redirect Attacks", i.e., the attacks which redirect the traffic from MAP to fake destinations chosen by the attackers. Therefore, in this section, we propose an approach to protect the binding update message from MN to MAP. When MN roams in the MAP domain, as soon as MN attaches to another AR and gets a new LCoA, MN will send a BU message to MAP with its certificate and signature BU = { Src=LCoA, Des=MAP, HoA, RCoA, SIG_MN, Cert_MN } where SIG_MN = Sig{SK_MN, LCoA | MAP | HoA | RCoA}, and Cert_MN = {HoA, PK_MN, Valid_Iinterval, SIG_HA}. SK_MN and PK_MN are a private and public key pair for MN. MN's public key certificate is issued by its home agent (HA). Here, SIG_HA is HA's signature on HoA, PK_MN and Valid_ Interval. Expires: December 8, 2004 [Page 12] Internet Draft CBU June 9, 2004 After MAP got the message, if MAP does not have HA's public key certificate, MAP will send a request for certificate to HA, REQ_Cert = {Src=MAP, Des=HA, request_cert}. Then, HA will return to MAP its public key certificate issued by a CA, REP_Cert = {Src=HA, Des=MAP, Cert_HA}. Upon getting HA's public key certificate, MAP can verify HA's signature SIG_HA and trust the MN's public key certificate Cert_MN. With Cert_MN, MAP can further verify MN's signature. After double checking the equality of home link's subnet prefix string embedded in both Cert_HA and HoA, MAP can finally trust MN's new binding update message BU. 6. SECURITY CONSIDERATIONS The proposal of Certificate-based Binding Update (CBU) solves many security issues in mobile networks, i.e. the secure binding update, seamless secure fast handover, user authentication, session key management for data security, etc. With the use of a digital signature scheme and the Diffie-Hellman key exchange algorithm, the CBU protocol can prevent the Session Hijacking attacks (an intruder hijacks an existing session between a mobile node and a correspondent node and redirects the correspondent node's traffic to a malicious location) and the Malicious Mobile Node Flooding attacks (a mischievous mobile node sets up communication sessions with correspondent nodes, and then redirect traffic from the correspondent nodes to flood a victim node or network). For the detail analysis, please refer to [4]. 7. CONCLUSION As described in this document, the CBU protocol provides a key management scheme to protect all the channels, e.g., the channels of MN-HA, MN-CN, HA-CN as well as MN-MAP, HA-MAP in mobile IPv6 networks. For the channel MN-HA, because HA acts as a security agent for MN and they share a secret value, our scheme provides a dynamic encryption key for this IPSec channel. For the channel MN-CN, our scheme manages both the long-term security associations for authentication and the short-term security associations for packet encryption in the channel. For the channel HA-CN, authentication is also provided. Expires: December 8, 2004 [Page 13] Internet Draft CBU June 9, 2004 Thanks to a strong cryptosystem used in the proposal, in most of time, MN can simply send the authenticated binding update messages (BU) to its CN when it enters into other subnets, without re-establishing new authentication keys via HA. So it is more suitable for fast handover in mobile networks. Due to the dynamic security associations (SA) for IPsec channels based on CoAs of these two nodes, our scheme can avoid the indexical problem that RR protocol must face, in which IP addresses in IP packets do not match the IP addresses in the SA database. As both CoAs of two nodes are never involved in the process of security negotiation in our scheme, either fixed CN or mobile CN can be dealt with the same method. Contrastively, RR protocol has to provide different methods to process these two scenarios. Because the major security negotiation in our scheme is carried out on the fixed machines (home agents or fixed CNs) connected with the wired networks, our solution can significantly reduce the computing and communication requirements on the mobile nodes. Therefore, our proposal could keep well a balance between the strong security requirements for e-commerce and the weak capability of mobile devices, and provides a more tidy, integrated, practical and efficient security solution for mobile networks. REFERENCES [1] D. B. Johson and C. Perkins, "Mobility Support in IPv6", IETF INTERNET-DRAFT, July 2003. [2] H. Soliman and K. El-Malki, "Hierarchical MIPv6 Mobility Management (HMIPv6)", July 2003. [3] D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [4] R. Deng, J. Zhou and F. Bao, "Defending against Redirect Attacks in Mobile IP", Proceedings of 9th ACM Conference on Computer and Communications Security, pages 59--67, Washington, DC, November 2002, ACM Press. Expires: December 8, 2004 [Page 14] Internet Draft CBU June 9, 2004 Authors' Addresses Feng BAO Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-8456 EMail: baofeng@i2r.a-star.edu.sg Robert DENG Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-7862 EMail: deng@i2r.a-star.edu.sg Ying QIU Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-6742 EMail: qiuying@i2r.a-star.edu.sg Jianying ZHOU Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-8543 EMail: jyzhou@i2r.a-star.edu.sg Expires: December 8, 2004 [Page 15] Internet Draft CBU June 9, 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Expires: December 8, 2004 [Page 16] Internet Draft CBU June 9, 2004 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Expires: December 8, 2004 [Page 17]