Network Working Group M. Nakhjiri Internet-Draft Huawei USA Expires: April 16, 2007 C. Wan, Ed. Huawei Technologies October 13, 2006 Specification for use of EAP EMSK in deriving Mobile IP root keys draft-nakhjiri-eap-mip-usrk-00.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 April 16, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract [USRK] proposes a new mechanism for deriving cryptographically separate usage specific root keys (USRK) from the EAP extended master session key (EMSK). This document follows the procedure suggested in [USRK] to derive root keys for Mobile IPv4, Mobile IPv6, and proxy Mobile IP. Nakhjiri & Wan Expires April 16, 2007 [Page 1] Internet-Draft MIP root key October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Key Distribution function (KDF) . . . . . . . . . . . . . . . 7 4. Mobile IPv6 USRK derivation . . . . . . . . . . . . . . . . . 9 5. Mobile IPv4 USRK derivation . . . . . . . . . . . . . . . . . 12 6. security considerations . . . . . . . . . . . . . . . . . . . 16 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Nakhjiri & Wan Expires April 16, 2007 [Page 2] Internet-Draft MIP root key October 2006 1. Introduction Many network protocols require keys for supporting various security mechanisms associated with these protocols. With the growing number of users and devices, manual configuration of such keys is no longer feasible due to system scalability and cost requirements set for networks today. This calls for dynamic key management mechanisms for most of these protocols so that the administrative burden of configuring devices with the required keys is reduced. However, with the increasing number of protocols needing short term keys and employing dynamic key management, both the implementation burden of deploying various key management mechanisms and the amount of real time spent executing these mechanisms during a power up are becoming issues. Extensible authentication protocol authentication [RFC3748] and key management framework [EAPkeying] provide a powerful tool for key management by authenticating an end client to a central AAA/ EAP server and establishing a master session key (MSK) and an extended master session key (EMSK). However, EAP documentations [RFC3748] and [EAPkeying] do not provide any specification for use of EMSK. There has been several proposals within and outside IETF to use EMSK to arrive at the so called application master session keys (AMSK) for various applications or later called as usage specific root keys (USRK) [USRK]. There has been a growing tendency to use EMSK resulting from the EAP exchange to derive keys for other network protocols and thereby reduce the need for multiple key management mechanisms. Different specifications have been using arbitrary key derivation functions (KDF), arbitrary KDF inputs, and arbitrary key labels, legitimizing the following imminent concerns: 1) At no circumstance should the compromise of an USRK for an application lead to the compromise of the parent EMSK, since this would lead to jeopardizing all other applications. This is called cryptographic separation of EMSK from the child-USRKs for all the application that have used that EMSK. This means a strong key derivation function should be used. For instance deriving an EMSK from a known USRK should be as complex as reversing a hash function. 2) Deriving USRK-1 for usage 1 (application 1) from an EMSK, should not jeopardize the integrity of keys for other usages that have used the same EMSK to derive their USRKs. This would not only mean strong KDF functions should be used, but also that different derivations using the same EMSK do not arrive at the same USRKs. Therefore, to assure cryptographic separation between different USRKs and to reduce the over all key management implementation burden in a system, it is Nakhjiri & Wan Expires April 16, 2007 [Page 3] Internet-Draft MIP root key October 2006 desired that all the usages within the system use the same default KDF. Furthermore, since a KDF always produces the same output for the same input, various usages need to follow a standardized procedure in using the KDF. [USRK] is the latest attempt towards specific keys for various usages in a coordinated manner to address the aforementioned concerns. This draft discusses the use of procedures in [USRK] to specify USRK derivations for both Mobile IPv4 and Mobile IPv6 security needs. Note that the draft may not go into the details of using the USRK in deriving all the keys within the Mobile IPv4 and Mobile IPv6 key hierarchy. Nakhjiri & Wan Expires April 16, 2007 [Page 4] Internet-Draft MIP root key October 2006 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 [RFC2119]. The following terms are taken from [RFC3748]: EAP Server, peer, authenticator, Extended Master Session Key (EMSK). HA Home agent. It is defeined in Mobile IPv4 [RFC3344] and Mobile IPv6 [RFC3775] specifications. FA Foreign Agent, It is defined in Mobile IPv4 [RFC3344] specification. MSA Mobility Service Authorizer. It is defined in mip6 bootstrapping problem statement [RFC4640] specification. MSP Mobility Service Provider. It is defined in mip6 bootstrapping problem statement [RFC4640] specification. USRK Usage specific root key. It is keying material derived from the EMSK for a particular usage definition. It is used to derive child keys in a way defined by its usage definition. MIP4_USRK MIP4_USRK is the root key for mip4 protocol usages. It is derived from the EMSK, while other child keys for mip4 usage are derived from MIP4_USRK. MIP6_USRK MIP6_USRK is the root key for mip6 protocol usages. It is derived from the EMSK , while other child keys for mip6 usage are derived from MIP6_USRK. KDF Nakhjiri & Wan Expires April 16, 2007 [Page 5] Internet-Draft MIP root key October 2006 KDF is the abbreviation of key derivation function. The USRK key derivation function (KDF) derives an USRK from the Extended Master Session Key (EMSK) . The USRK KDF is expected to give the same output for the same input. PRF/PRF+ Pseudo random function. PRF and PRF+ are defined in [RFC4306]. MIP6_MN_HA_key MIP6_MN_HA_key is used for protecting Mobile IPv6 signaling between MN and HA. MIP6_IKEv2_key MIP6_IKEv2_key is the IKEv2 pre-shared key which is used in the IKEv2 exchange needed for establishment of an MN-HA IPsec SA. MN_HA_MIP4_key MN_HA_MIP4_key is used for protecting Mobile IPv4 signaling between MN and HA. PMN_HA_MIP4_key PMN_HA_MIP4_key is used for protecting proxy MIP4 signaling between proxy mobile node and HA. MN_FA_MIP4_key MN_FA_MIP4_key is used for protecting Mobile IPv4 signaling between MN and FA. Nakhjiri & Wan Expires April 16, 2007 [Page 6] Internet-Draft MIP root key October 2006 3. Key Distribution function (KDF) We are following the [USRK] recommendation on KDF. KDF = PRF(key, US_data) [USRK] suggests the use of PRF+ from IKEv2 specification [RFC4306] as a default PRF for derivation of USRK for derivations of root keys for all usage definitions, unless otherwise specifically stated. "US_data" stands for usage specific data and will be defined shortly. The PRF+ is defined as follows: prf+ (Key, US_Data) = T1 | T2 | T3 | T4 | ... Where: T1 = PRF (Key, US_Data | 0x01) T2 = PRF (Key, T1 | US_Data | 0x02) T3 = PRF (Key, T2 | US_Data | 0x03) T4 = PRF (Key, T3 | US_Data | 0x04) The notion of PRF+ means the same PRF will be executed over and over to provide as long keying material as needed (T1, T2, T3, etc). In deriving Mobile IP usage specific root keys (MIP4_USRK, MIP6_USRK), we will follow this recommendation and suggest the use of HMAC_SHA- 256 as PRF (defined in [SHA256]). for deriving USRKs from the EMSK. Furthermore, the "key" above is the extended master session key (EMSK) derived from execution of an EAP method. So the expression for PRF+ used in Mobile IP USRK derivations is defined as follows prf+ (EMSK, US_Data) = T1 | T2 | T3 | T4 | ... Where: T1 = HMAC-SHA-256 (EMSK, US_Data | 0x01) T2 = HMAC-SHA-256 (EMSK, T1 | US_Data | 0x02) T3 = HMAC-SHA-256 (EMSK, T2 | US_Data | 0x03) T4 = HMAC-SHA-256 (EMSK, T3 | US_Data | 0x04) The usage_specific data (US_Data) is defined as follows. US_data=Key label + "\0" + op-data + length Nakhjiri & Wan Expires April 16, 2007 [Page 7] Internet-Draft MIP root key October 2006 Key label = ASCII key label The ASCII key label will be defined for each usage (Mobile IPv4 and Mobile IPv6) in the relevant sections of this document later on. op-data = optional data The "optional data" will be defined for each usage (Mobile IPv4 and Mobile IPv6) later in this document. length = 2 byte unsigned integer in network byte order '\0' = is a NUL byte (0x00 in hex) + denotes concatenation It should be noted that only the USRKs for Mobile IPv4 and Mobile IPv6 (MIP4_USRK, MIP6_USRK) need to follow this procedure; it is not required for each of these applications to use the same PRF+ in creating further child keys from the USRKs. For instance, the Mobile IPv4 function may use a different PRF when deriving MN-HA-key from MIP4_USRK, if necessary. The mandate on use of PRF+ for the Mobile IP USRK, while allowing for use of weaker PRFs for usage specific child keys, assures the EMSK and the USRK for other non-Mobile IP usages are not compromised unnecessarily. Nakhjiri & Wan Expires April 16, 2007 [Page 8] Internet-Draft MIP root key October 2006 4. Mobile IPv6 USRK derivation Section 3 defines the USRK formula. This section will explain the mip6 usage specific data according to the USRK formula. The MIP6- USRK is generated below: MIP6_T1 = HMAC-SHA-256 (EMSK, "MIP6 USRK derivation"|| |EAP session ID| MN_ID| 128 | 0x01 ) MIP6_T2 = HMAC-SHA-256 (EMSK, MIP6_T1 | "MIP6 USRK derivation" | || EAP session ID| MN_ID|128 | 0x02) MIP6_USRK=MIP6_T1 | MIP6_T2 The details are explained as follows: -The MIP6_USRK is generated from EMSK. -We assume a key length of 256 bits is sufficient for MIP6_USRK. -SHA256 [SHA256] creates 128 security bits and hence we will create both MIP6_T1 and MIP6_T2 to have a total of 256 security bits, even though the result of the hash after running PRF twice would be 512. -The key label of MIP6_USRK is "MIP6 USRK derivation" -op-data = | |EAP session ID| MN_ID <> indicates that an attribute is optional. MSA is Mobility service authorizer (can be AAA server authorizing MN for MIP6 service) and MSP is mobility service provider providing MIP6 service to the MN. So it is up to deployment scenario and operators policy to include these identifiers in the key generation data. MN_ID is an identifier for the MN, so that the MN is recognizable by the entity that generates the MIP6_USRK. Depending on the MIP6 bootstrapping scenario and instance and entity at which the MIP6_USRK is being generated and the MIP6 service to MN is being authorized at, the MN_ID may be different. A number of alternatives for MN_ID is as follows: -FQDN for the MN. -NAI for the MN. -IPv6 HoA address for MN. Nakhjiri & Wan Expires April 16, 2007 [Page 9] Internet-Draft MIP root key October 2006 EAP session ID is used for identifying the EAP session. The MIP6-USRK key name is defined below: MIP6 USRK key name = HMAC-SHA-256( EAP Session-ID, "MIP6_USRK derivation"| 64) All other MIP6 related keys, including MN-HA key and IKEv2 pre-shared key are derived as child keys of the MIP6-USRK. Even though, it is not required to use the same KDF in derviation of these child keys, for simplicity, we use HMAC_SHA_256 in those derivation. MN-HA key is required in [RFC4285] which is used for building security association between mobile node and Home Agent. IKEv2 pre-shared key is required in [RFC3776] which is used for generating AUTH value. Figure 1 shows the key hierarchy of the mip6 key: --------- |MIP6_USRK| --------- | +---------------------------------+ | | | | | | | | | -------------- -------------- --------------- |MIP6_MN_HA_key| |MIP6_IKEv2_key| |other MIP6 keys| -------------- -------------- --------------- Figure 1 Mip6 key hierarchy The MIP6_MN_HA_key key generation formula is shown below: MIP6_MN_HA_key = HMAC-SHA-256(MIP6_USRK, "MN-HA key derivation"| | MN_ID | 128) The details are explained as follows: - [RFC4285] requires the MIP6_MN_HA_key length must be 16 octets. -The key label of MIP6_MN_HA_key is "MN-HA key derivation" -op-data = | MN_ID <> indicates that an attribute is optional. Nakhjiri & Wan Expires April 16, 2007 [Page 10] Internet-Draft MIP root key October 2006 MN_ID and HA_ID is used for identifying the two entities who share the key. The MN_ID should match that used in Mobile IPv6 signaling or bootstrapping. Depending on whether at the time of the key derivation an HA is assigned to the MN, The HA_ID may be left out. It is however recommended that MN_HA_keys are derived including HA_ID and after the HA is assigned to assure proper key scoping. The MIP6_IKEv2_key key generation formula is shown below: MIP6_IKEv2_key=HMAC-SHA-256(MIP6_USRK, "IKEv2 pre-shared key derivation" | MN_ID| HA_ID | 128) The details are explained as follows: - [RFC4306] requires the length of the IKEv2 pre-shared key to rely on the length requirement of the negotiated prf. If the pre-shared key length does not match the requirement of prf, the key will be truncated or padded with zeros as necessary. So we set the default length of the IKEv2 pre-shared key to 128 bits. -The key label is "IKEv2 pre-shared key derivation" -op-data = MN_ID| HA_ID MN_ID and HA_ID are used for identifying the two entities who share the key. The MN_ID should match that used in Mobile IPv6 signaling or bootstrapping. MN_ID and HA_ID are both important, since they are used for IKEv2. It is possible that MIP6 application or its related protocols, such as fast Mobile IPv6 will require other keys for their operation. Such keys can be generated in a similar manner from the MIP6_USRK as shown in figure 1. Nakhjiri & Wan Expires April 16, 2007 [Page 11] Internet-Draft MIP root key October 2006 5. Mobile IPv4 USRK derivation The mobile ipv4 key generation is similar to mip6 key generation. This section explains the mip4 usage specific data according to the USRK formula defined in section 3. The MIP4_USRK is generated below: MIP4_T1 = HMAC-SHA-256 (EMSK, "MIP4 USRK derivation"|AAAH_ID |MN_ID| EAP session ID| 128 | 0x01 ) MIP4_T2 = HMAC-SHA-256 (EMSK, MIP4_T1 | "MIP4 USRK derivation" | AAAH_ID| MN_ID|EAP session ID| 128 | 0x02) MIP4_USRK=MIP4_T1 | MIP4_T2 The details are explained as follows: -The MIP4_USRK is generated from EMSK. -We assume a key length of 256 bits is sufficient for MIP6_USRK. -SHA256 [SHA256] creates 128 security bits and hence we will create both MIP4_T1 and MIP4_T2 to have a total of 256 security bits, even though the result of the hash after running PRF twice would be 512. -The key label of MIP4_USRK is "MIP4 USRK derivation". -op-data = AAAH_ID |MN_ID|EAP session ID AAAH_ID is used for identifying the operator attributes. So it is up to deployment scenario and operators policy to include these identifiers in the key generation data. MN_ID is an identifier for the MN, so that the MN is recognizable by the entity that generates the MIP4_USRK. Depending on the MIP4 bootstrapping scenario and instance and entity at which the MIP4_USRK is being generated and the MIP4 service to MN is being authorized at, the MN_ID may be different. A number of alternatives for MN_ID is as follows: -FQDN for the MN -NAI for the MN -IPv4 HoA address for MN EAP session ID is used for identifying the EAP session. The MIP4-USRK key name is defined below: Nakhjiri & Wan Expires April 16, 2007 [Page 12] Internet-Draft MIP root key October 2006 MIP4 USRK key name = HMAC-SHA-256( EAP Session-ID, "MIP4 USRK derivation"| 64) All other MIP4 related keys including MN-HA-MIP4-key, MN-HA-PMIP4- key,FA-MIP4-root-key and MN-FA-MIP4-key are derived as child keys of the MIP4-USRK. Figure 2 shows the MIP4 key hierarchy. --------- |MIP4_USRK| --------- | +----------------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | | | -------------- --------------- -------------- --------------- |MN_HA_MIP4_key| |FA_HA_MIP4_Root| |MN_FA_MIP4_key| |PMN_HA_MIP4_key| -------------- --------------- -------------- --------------- Figure 2 Mip4 key hierarchy The MN_HA_MIP4_key key generation formula is shown below: MN_HA_MIP4_key = HMAC-SHA-256(MIP4_USRK, "MN-HA key derivation"| | MN_ID | AAAH_ID |128) The details are explained as follows: -The length of MN_HA_MIP4_key is set default to 128 bits. -The key label of MN_HA_MIP4_key is "MN-HA key derivation". -op-data = | MN_ID | AAAH_ID <> indicates that an attribute is optional. AAAH_ID is used for identifying the operator attributes. So it is up to deployment scenario and operators policy to include these identifiers in the key generation data. MN_ID and HA_ID is used for identifying the two entities who share the key. The MN_ID should match that used in Mobile IPv4 signaling or bootstrapping. Depending on whether at the time of the key derivation an HA is assigned to the MN, The HA_ID may be left out. It is however recommended that MN_HA_keys are derived including HA_ID Nakhjiri & Wan Expires April 16, 2007 [Page 13] Internet-Draft MIP root key October 2006 and after the HA is assigned to assure proper key scoping. The PMN_HA_MIP4_key key generation formula is shown below: PMN_HA_MIP4_key = HMAC-SHA-256(MIP4_USRK, "PMN-HA key derivation"| | PMN_ID | AAAH_ID |128) The details are explained as follows: -The length of PMN_HA_MIP4_key is set default to 128 bits. -The key label of MN_HA_PMIP4_key is "PMN-HA key derivation". -op-data = | PMN_ID | AAAH_ID AAAH_ID is used for identifying the operator attributes. So it is up to deployment scenario and operators policy to include these identifiers in the key generation data. PMN_ID and HA_ID is used for identifying the two entities who share the key. The PMN_ID should match that used in proxy Mobile IPv4 signaling. The MN_FA_MIP4_key key generation formula is shown below: MN_FA_MIP4_key = HMAC-SHA-256(MIP4_USRK , "MN-HA MIP4 key derivation"| FA_ID | MN_ID | AAAH_ID |128) The details are explained as follows: -The key label of MN_FA_MIP4_key is "MN-HA MIP4 key derivation". -The length of MN_FA_MIP4_key is set default to 128 bits. -op-data = FA_ID | MN_ID | AAAH_ID AAAH_ID is used for identifying the operator attributes. So it is up to deployment scenario and operators policy to include these identifiers in the key generation data. MN_ID and FA_ID is used for identifying the two entities who share the key. The MN_ID should match that used in Mobile IPv4 signaling or bootstrapping. The FA_HA_MIP4_Root key generation formula is shown below: FA_HA_MIP4_Root = HMAC-SHA-256(MIP4_USRK, "FA-MIP4 root key derivation"| HA_ID|FA_ID | AAAH_ID |128) Nakhjiri & Wan Expires April 16, 2007 [Page 14] Internet-Draft MIP root key October 2006 The details are explained as follows: -The length of FA_HA_MIP4_Root is set default to 128 bits. -The key label of FA_HA_MIP4_Root is "FA-MIP4 root key derivation". -op-data = HA_ID| FA_ID | AAAH_ID AAAH_ID is used for identifying the operator attributes. So it is up to deployment scenario and operators policy to include these identifiers in the key generation data. FA_ID and HA_ID is used for identifying the two entities who share the key. This key be used as is, or as a pre-shared key for an FA-HA IKE. So FA_ID and HA_ID are both important. Nakhjiri & Wan Expires April 16, 2007 [Page 15] Internet-Draft MIP root key October 2006 6. security considerations This draft recommends the use of a default PRF (PRF+) according to [RFC4306] for deriving all USRKs from an EMSK. There may be cases where a system operator has specified a policy and/or configured devices within a system to use a different system-wide PRF. The other exception to this rule would be if Mobile IPv4 or Mobile IPv6 had specific messaging process for PRF negotation, but this is not the case. Nakhjiri & Wan Expires April 16, 2007 [Page 16] Internet-Draft MIP root key October 2006 7. IANA considerations This document does not require actions by the IANA. Nakhjiri & Wan Expires April 16, 2007 [Page 17] Internet-Draft MIP root key October 2006 8. Acknowledgement Thank Joe Salowey for his valuable input. Nakhjiri & Wan Expires April 16, 2007 [Page 18] Internet-Draft MIP root key October 2006 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", August 2002. [RFC3748] Aboba , B. and Et. Al., "Extensible Authentication Protocol (EAP)", June 2004. [RFC3775] Johnson, D. and Et. Al., "Mobility Support in IPv6", June 2004. [RFC3776] Arkko, J. and Et. Al., "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", June 2004. [RFC4285] Patel, A. and Et. Al., "Authentication Protocol for Mobile IPv6", January 2006. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", December 2005. [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for Bootstrapping Mobile IPv6 (MIPv6)", September 2006. [SHA256] , National Institute of Standards and Technology., "Secure Hash Standard", August 2002. 9.2. Informative References [EAPkeying] Aboba, B. and Et. Al., "Extensible Authentication Protocol (EAP) Key Management Framework", May 2006. [USRK] Salowey, J. and Et. Al., "Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK)", June 2006. Nakhjiri & Wan Expires April 16, 2007 [Page 19] Internet-Draft MIP root key October 2006 Authors' Addresses Madjid Nakhjiri Huawei USA 12040, 98th AVE NE, suite 200B, Kirkland, WA 98033 USA Email: mnakhjiri@huawei.com Changsheng Wan (editor) Huawei Technologies Site A,Floor 10,HuiHong Mansion,No.91 BaiXia Rd. Nanjing, Jiangsu 210001 China Phone: 86-25-84565415 Email: wanchangsheng@huawei.com Nakhjiri & Wan Expires April 16, 2007 [Page 20] Internet-Draft MIP root key October 2006 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 (2006). 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. Nakhjiri & Wan Expires April 16, 2007 [Page 21]