INTERNET DRAFT Category: Standards Mohamed Khalil Title: draft-mkhalil-mobileip-ipv6-sap-02.txt Haseeb Akhtar Date: April 2001 Emad Qaddoura Expires: October 2001 Nortel Networks Dynamic Security Association Establishment Protocol For IPv6 Status of this Memo This document is an individual contribution for consideration by the mobile-IP Working Group of the Internet Engineering Task Force. Comments should be submitted to the mobile-ip@sunroof.eng.sun.com mailing list. Distribution of this memo is unlimited. 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. Khalil, Akhtar, Qaddoura expires October 2001 [Page 1] INTERNET DRAFT April 2001 Table of Contents 1.0 Introduction 1.1 Copyright Statement 1.2 Requirements language 1.3 Terminology 2.0 Dynamic Security Establishment Protocol 2.1 Overall Protocol Description 2.1.1 The MN Starts SA Establishment 2.1.2 The CN Receives the SA Request Message 2.1.3 MN Receives a SA Response Message 2.1.4 MN Sends BU to the CN 2.1.5 CN Sends BA to the MN 2.2 Primary Mode 2.3 Secondary Mode 3.0 Re-Establishment Of MN-CN Security Association 4.0 Security Features 4.1 Denial of Service (DoS) Attack Protection 4.2 Replay Protection 4.3 Non-repudiation 4.4 Message Integrity 5.0 Message Extensions 5.1 The Transform Sub-option 5.2 The Key Payload Sub-option 5.3 The HAsh Sub-option 5.4 The Notification Payload Sub-option 5.5 The Digital Signature (DIGSIG) Sub-option 5.6 The Nonce (NONCE) Sub-option 5.7 The FQDN Sub-option 6.0 References 7.0 Acknowledgements 8.0 Author Information 9.0 Full Copyright Statement Khalil, Akhtar, Qaddoura expires October 2001 [Page 2] INTERNET DRAFT April 2001 Abstract A protocol is proposed to allow a fast establishment of Security Association between the Mobile Node (MN) and Correspondent Node (CN). Once this Security Association is established, it can be used to authenticate any control message exchanged between these two nodes (e.g. Binding Update and Binding Acknowledgement). 1.0 Introduction This draft outlines a protocol that allows a dynamic establishment of Security Association (SA) between two nodes: the MN and the CN. The proposed protocol doesn't depend on its operation on a global or centralized PKI (Public Key Infrastructure) or KDC (Key Distribution Center). The existing Mobile IPv6 [2] messages are used to piggyback the security extensions required to negotiate the SA between the MN and the CN. This results in a usage optimization for the RF interface. The whole idea behind this protocol is to protect the messages between the MN and the CN (e.g. Binding Update, Binding Acknowledgement etc.). If the attacker resides on the link between the MN and the CN, the attacker then has no interest in intercepting and/or changing the messages (e.g. Binding Warning, Binding Update and Binding Acknowledgement) that are exchanged (since the attacker already has access to the traffic). If the attacker is off the link, then the attacker is interested in intercepting the messages (e.g. Binding Update) in order to direct the CN's traffic to the attacker. An assumption is made here that the attacker who is on the link is really not applicable to this problem. The security features provided by the proposed protocol are discussed in details in section 4.0, which include DoS protection, replay protection, non-repudiation, and message integrity. 1.1 Copyright Statement Copyright (C) The Internet Society 1999. All Rights Reserved. 1.2 Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [13]. Khalil, Akhtar, Qaddoura expires October 2001 [Page 3] INTERNET DRAFT April 2001 1.3 Terminology This document frequently uses the following terms: y It indicates that "x" is encrypted with the key "y". [x] It indicates that x is optional. [x]y It indicates that "x" is decrypted with the key "y". BA Binding Acknowledgement message BU Binding Update message BW Binding Warning message CKY_m Cookie generated by the Mobile Node. CKY_c Cookie generated by the Correspondent Node. CM_b Body of the control message. CM_x Control message sent by the node x. FQDN_x The Fully Qualified Domain Name for node x. It is in the form a.b.c.d HASH_x Hash calculated by x. IIP Initiator's IP address. LSV_x Locally generated secret value by node x. Khalil, Akhtar, Qaddoura expires October 2001 [Page 4] INTERNET DRAFT April 2001 N_x Nonce generated by node x. PBk_x Diffie-Hellman's public key generated by node x. PFS Perfect Forward Security. prf (key,msg) It is the keyed pseudo-random function used to generate a deterministic output that appears pesudo-random. It is used for key derivation, and for authentication (i.e. as a keyed MAC) [3]. PRk_x Diffie-Hellman's private key generated by node x. RAND_x Random number generated by x. MNIP MN's IP address. SA (Security Association) An SA is a relationship between two or more nodes that allows those nodes to communicate between each other over any public or private IP based network wihtout compromising integrity of any of the packets transferred. SIG_x It is a data signed by the node x private key. Xid X node identification. Khalil, Akhtar, Qaddoura expires October 2001 [Page 5] INTERNET DRAFT April 2001 2.0 Dynamic Security Establishment Protocol In this section two modes (primary and secondary) are described to establish a SA between the initiator (e.g. MN) and a responder (e.g. CN). The primary mode provides PFS (Private Forward Security) using Diffie-Hellman while the secondary mode provides more efficiency at the cost of the PFS feature. 2.1 Overall Protocol Description The SA establishment protocol is a protocol to establish an SA between any two nodes; the MN and CN. The protocol goes through three message exchanges. The first two messages are used to negotiate policy, exchange key materials (such as Diffie-Hellman public values, ancillary data necessary for the exchange etc.) and identities. The third and the last message is used to authenticate the MN and CN and to provide a proof of participation in the exchange. 2.1.1 The MN Starts SA Establishment: The MN starts the SA establishment by sending a SA request message (e.g. Binding Warning [1]) to a CN. The SA request message MUST include the MN cookie CKY_m, N_m and other attributes depending on the mode covered by sections 2.2 and 2.3. 2.1.2 The CN Receives the SA Request Message When the CN receives the SA request message (e.g.Binding Warning) from the MN, the CN receives the MN cookie (CKY_m), MN nonce (N_m) and Security Association payload (SA). The CN will check the MN nonce (N_m) to make sure that the message is not a replay for an old one. It will select a Security Association which is compatable with the CN security capability. The CN then forms an SA response message (e.g. Binding Request) destined to the initator which MUST include MN cookie (CKY_m), CN cookie (CKY_c), the agreed on Security Association payload (SA) and the CN Diffie-Hellman (PBk_m), the initator nonce (N_m) and the CN nonce (N_m), and other attributes depending on the modes covered in sections 2.2 and 2.3. 2.1.3 MN Receives a SA Response Message When the MN receives an SA response message (e.g. Binding Request) from the CN, it verifies the CN nonce (N_c) to make sure that the message is not a replay of an older message. If the verification is successful, the MN then proceeds on to calculate the SSK according to the modes covered by sections 2.2 and 2.3. Khalil, Akhtar, Qaddoura expires October 2001 [Page 6] INTERNET DRAFT April 2001 2.1.4 MN Sends Binding Update to the CN The MN sends a Binding Update (BU) to the CN with the MN's current Care-of address (COA). The MN MUST include the MN and CN cookies (CKY_m and CKY_c), the intiator and CN nonces (N_m, N_c), and the authenticator. This message is used as a proofas the proof of participation in the exchange (between the MN and the CN), and to update the CN with the current MN's COA. 2.1.5 CN Sends Binding Acknowledgement to the MN This optional message MUST be sent by the CN to the MN, if the MN has previously requested the BU to be acknowledged. The Binding Acknowledgement (BA) message is used to confirm the completion of the SA negotiation session. The BA message SHOULD include the CKY_m, CKY_c and MUST include the MN and CN nonces (N_m,N_c), the authenticator as define in sections 2.2 and 2.3. 2.2 Primary Mode This Primary Mode follows the protocol framework mentioned in section 2.1. The Primary Mode is based on Diffie-Hellman. The MN starts the SA establishment by sending a SA request message (e.g. Bingding Warning) to the CN. The MN calculates the CKY_m when it sends a SA response message to the CN (e.g. Binding Request) as follows: CKY_m = prf (LSV_m, MNIP | CNIP) When the CN receives an SA request message from the MN, it performs the same steps defined for receiving an SA request message from the MN defined in section 2.1.2 and it will calculate its cookie as follows: CKY_c = prf (LSV_c, MNIP | CNIP) When the MN receives the SA response message from the CN it follows the same steps defined in section 2.3 that are performed after receiving a SA response message from the CN and will calculate the SSK as follows: SSK = prf (g^(PRk_m X PBk_c), N_m | N_c) The MN sends a BU to the CN as a proof of participation in the SA establishement session and to update the CN with the MN's current Khalil, Akhtar, Qaddoura expires October 2001 [Page 7] INTERNET DRAFT April 2001 care-of address. The BU MUST include CKY_m, CKY_c, N_m, N_c and the message authenticator (HASH_m). The message authenticator is calculated as follows: HASH_m = prf (SSK, CMm_b) The CN MUST send a BA to the MN if the MN has requested for an acknowledgement in the previous BU message. The BA SHOULD include CKY_m and CKY_c and MUST include the MN and CN nonces (N-m, N_c), and the authenticator (HASH_c). The authenticator is calculated as follows: HASH_c = prf (SSK, CMc_b) The CN calculate the SSK as follows: SSK = prf (g^(PRk_c X PBk_m), N_m | N_c) Khalil, Akhtar, Qaddoura expires October 2001 [Page 8] INTERNET DRAFT April 2001 The Primary Mode (wihtout digital signature) is summarized as follows: MN CN [1] CMm: CKY_m, N_m,SA ------> [2] <------ CMr: CKY_c, CKY_m, N_c, N_m, SA, PBK_c [3] BU: CHY_m, CKY_c, ------> N_m, COA, HASH_m [4] BA: (optional,if BU A = 1)<------ BA: CHY_m,CKY_c, N_c, N_m, COA, HASH_c If the MN and CN exchanges the PublicKey_m and the PublicKey_r, then the SIG_m and SIG_c are calculated as follows: SIG_m = PrivateKey_m SIG_c = PrivateKey_c The Primary Mode (wiht digital signature) is summarized as follows: MN CN [1] CMm: CKY_m, N_m,SA,PublicKey_m ------> [2] <------ CMr: CKY_c, CKY_m, N_r, N_m, SA,PBK_r, PublicKey_r, [3] BU: CKY_m, CKY_c, COA, N_m, SIG_m ------> [4] BA: (optional,if BU A = 1) <------ BA: CKY_m, CKY_c, N_r, N_m,COA, SIG_c Khalil, Akhtar, Qaddoura expires October 2001 [Page 9] INTERNET DRAFT April 2001 2.3 The Secondary Mode The Secondary Mode follows the protocol framework mentioned in section 2.1. The Secondary Mode is efficient in execution time but but does not provide PFS. The MN starts the SA establishment by sending an SA request message (e.g. Binding Warning [1]) to the CN. The MN calculates the CKY_m when it sends the SA request message to the CN as follows: CKY_m = prf (LSV_m, MNIP | CNIP) When the CN receives an SA request message (e.g. Binding Warning) from the MN, it follows the same steps as defined in section 2.1.2 for receiving an SA request message from the MN. The CN then calculates SSK and AUTH_r as follows: CKY_c = prf (LSV_c,MNIP | CNIP) When the MN receives the SA response message from the CN it follows the same steps defined in section 2.1.3 that are performed after receiving an SA response message from the CN. The MN calculates the SSK as follows: SSK = prf (RAND_c, MNIP | CNIP | [ PublicKey_m] |[ PublicKey_r ]) The MN sends a BU to the CN as a proof of participation in the SA establishement session and to update the CN with the MN's current care-of address. The BU MUST include CKY_m, CKY_c, N_m, N_c and the message authenticator (HASH_m). The message authenticator is calculated as follows: HASH_m = prf (SSK, CMm_b) The CN MUST send a BA to the MN if the MN has requested for an acknowledgement in the previous BU message. The BA SHOULD include CKY_m and CKY_c and MUST include the N_c, N_m and the authenticator (HASH_c). The authenticator is calculated as follows: HASH_c = prf (SSK, CMr_b) The CN calculate the SSK as follows: SSK = prf (RAND_c, MNIP | CNIP | [ PublicKey_m ] |[ PublicKey_c ]) Khalil, Akhtar, Qaddoura expires October 2001 [Page 10] INTERNET DRAFT April 2001 The Secondary Mode is summarized as follows: MN CN [1] CMm: CKY_m, N_m SA,PublicKey_m ----> [2] <---- CMc: CKY_c, CKY_m, SA, N_c, N_m, < RAND_c > PublicKey_m, PublicKey_c, PublicKey_m [3] BU: CKY_m, CKY_c, N_m, -----> COA, (HASH_m | SIG_m) [4] BA: (optional,if BU A = 1) <------ BA: CKY_m, CKY_c, N_c, N_m, COA, (HASH_c | SIG_c) Khalil, Akhtar, Qaddoura expires October 2001 [Page 11] INTERNET DRAFT April 2001 3.0 Re-Establishment Of MN-CN Security Association When the SA between the two nodes (e.g. MN and a CN) is about to expire,the MN (e.g. MN) MAY start to re-establish the SA with the other node (e.g. CN). One of two modes described in section 2.2 and 2.3 MAY be used as follows: a - Primary Mode: SA request and SA response messages are exchanged according to the guidelines defined in section 2.2. The exchange of these messages is described as follows: MN CN CMm: N_m, SA, PBK_i, (HASH_m | SIG_m) ----> <---- CMc: N_c, N_m, SA, PBk_c, (HASH_c | SIG_c) HASH_m = prf(SSK, CMm_b) HASH_c = prf(SSK, CMc_b) SIG_m = PrivateKey_m SIG_c = PrivateKey_c b - Secondary Mode: SA Request and SA Response messages are exchanged according to the guidelines described in section 2.3. The exchange of these messages is described as follows: MN CN CMm: N_m,SA, < RAND_m > SSK, HASH_m ----> <---- CMc: N_c,SA, < RAND_c > SSK, HASH_c HASH_m = prf(SSK, CMm_b) HASH_c = prf(SSK, CMc_b) new SSK = prf (HASH (RAND_m | RAND_c), N_m | N_c | MNIP | CNIP) Khalil, Akhtar, Qaddoura expires October 2001 [Page 12] INTERNET DRAFT April 2001 4.0 Security Features This section discusses some of the security features of the proposed protocol based on the assumption mentioned in section 1.0. 4.1 Denial Of Service Attack (DoS) Protection In this type of attacks the opponent forges the source address of a legitimate user and sends a public Diffie-Hellman key to the victim. The victim then performs a modular exponentiation to compute the secret key. Repeated messages like this can clog the victim's system with useless work. The CN can validate the MN's cookie at the end of the three messages that are exchanged between the MN and the CN as mentioned in this draft. If the sender cookie is not valid, the messages are ignored silently. If the sender's cookie is valid then the receiver performs the following steps: a - the receiver does not perform the modular exponentiation for the same PBK_x twice and the message will be ignored silently. b - If PBk_x is different but the the sender is sending too many messages within a short period of time (may be a configurable parameter), those extra messages are ignored silently. 4.2 Replay Protection This type of attacks involves capturing of data unit and retransmitting of the same data in the future to cause unauthorized effect. The proposed protocol provides Nonce Sup-option which contains data such as timestamp to help the nodes detect old messages that have been retransmitted before. Upon detection of such messages the nodes ignore them silently. 4.3 Non-repudiation The proposed protocol prevents either sender or receiver from denying a transmitted message. As described earlier, the proposed protocol requires each node to provide a digital signature that contains the sender's identity signed by its private key. 4.4 Message Integrity Khalil, Akhtar, Qaddoura expires October 2001 [Page 13] INTERNET DRAFT April 2001 The proposed protocol provides an Hash Sub-option that includes data based on hashing message fields with secret material known only by the sender and the receiver. Any modification of any message field are detected by the receiver. 5.0 Message Extensions This section describes the message extensions to be used for the protocol. 5.1 The Security Association (SA) Sub-option The Security Association sub-option is used to define the hash function type and the SPI involved in the Security Association. 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 | Hash Type | rsv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA Length The length of the option not including the type and length fields in units of 8 octets. Hash Type 0 MD5 (default) rsv reserved and MUST set to 0 SPI Security Parameter Index used index the Security Association defined between two nodes such as mobile node and correpondent node. 5.2 The Key Payload Sub-option Key Payload Sub-option contains data Data required to generate a secret key or it might contain a public key. Khalil, Akhtar, Qaddoura expires October 2001 [Page 14] INTERNET DRAFT April 2001 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 | sub-type | key data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA Length The length of the option not including the type and length fields in units of 8 octets. Sub-type 0 MN-CN secret key 1 MN public key 2 CN public key Key info the secret or public key 5.3 The Hash Sub-option The Hash Sub-option data is generated by the hash function (selected during the SA establishment exchange), over some part of the message. This payload may be used to verify the integrity of the data in an ISAKMP message or/and for authentication of the negotiating entities. Khalil, Akhtar, Qaddoura expires October 2001 [Page 15] INTERNET DRAFT April 2001 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 | Sub Type | rsv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | authenticator +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA Sub Type this field is 0 Length The length of the option in units of 8 octets not including the type and length field. SPI Security Parameter Index. authenticator (variable length) - Data that results from applying the hash routine to certain field of the message. 5.4 The Notification Payload Sub-option The Notification Payload can contain status or error informatio resulted from the Security Association negotiation. Khalil, Akhtar, Qaddoura expires October 2001 [Page 16] INTERNET DRAFT April 2001 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 | status | Notification data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA Length The length of the option not including the type and length fields in units of 8 octets. status contains error or status code information Notification Data (variable length) - Informational or error data. 5.5 The Digital Signature (SIG) Sub-option The digital signature sub-option carries the digital signature created as a result of encrypting a specific data with a node's private key. 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 | DIG_SIG data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA Length The length of the option not including the type and length fields in units of 8 octets. DIG_SIG is the digital signature data. 5.6 The Nonce (NONCE) Sub-option Khalil, Akhtar, Qaddoura expires October 2001 [Page 17] INTERNET DRAFT April 2001 The Nonce Payload contains random data used to guarantee liveness during an exchange and protect against replay attacks. 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 | Nonce Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA Length The length of the option not including the type and length fields in units of 8 octets. Nonce Data Contains the random data generated by the transmitting entity. 5.6 The FQDN Sub-option The FQDN Payload contains the Fully Qualified Domain Name for the node. This information is useful in such cases where the node has a secure communication with DNS and may retreive public information about its peer using this secure access to such global data base (e,g, DNS). Khalil, Akhtar, Qaddoura expires October 2001 [Page 18] INTERNET DRAFT April 2001 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 | FQDN Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA Length The length of the option not including the type and length fields in units of 8 octets. FQDN Data FQDN data in the form of x.y.z.w 6.0 References [1] Charlie Perkins, Binding Key Establishment for Mobile IPv6 [2] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in progress), draft-ietf-mobileip-ipv6-13.txt, October 2000 7.0 Acknowledgements 8.0 Author Information: Mohamed Khalil Nortel Networks Inc. 2201 Lakeside Blvd Richardson, TX 75082-4399 Phone: +1 972 685-0564 E-mail: mkhalil@nortelnetworks.com Haseeb Akhtar Nortel Networks Inc. 2201 Lakeside Blvd Richardson, TX 75082-4399 Phone: +1 972 684-8850 E-mail: haseeb@nortelnetworks.com Khalil, Akhtar, Qaddoura expires October 2001 [Page 19] INTERNET DRAFT April 2001 Emad Qaddoura Nortel Networks Inc. 2201 Lakeside Blvd Richardson, TX 75082-4399 Phone: +1 972 684-2705 E-mail: emadq@nortelnetworks.com 9.0 Full Copyright Statement Copyright (C) The Internet Society (1999). 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 implmentation 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 docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Inter- net 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 permis- sions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 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 WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Khalil, Akhtar, Qaddoura expires October 2001 [Page 20]