MIP6 Working Group G. Giaretta Internet Draft I. Guardini Expires: April 2007 E. Demaria M. La Monaca Telecom Italia J. Bournelle M. Laurent-Maknavicius GET/INT October 2006 Application Master Session Key (AMSK) for Mobile IPv6 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 17, 2007. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract The Extensible Authentication Protocol (EAP) defines an extensible framework for performing network access authentication. Most EAP authentication algorithms, also known as "methods", export keying material that can be used with lower layer ciphersuites. It can be useful to leverage this keying material to derive usage specific keys that can be used to authenticate users or protect information exchange by other applications or services.For this purpose [10] proposes to derive root keys for each usage application and, then, child keys to actual be used. This document defines how to generate a Usage Specific Root Key (USRK) and a series of Application Master Session Keys (AMSKs) specific to Mobile IPv6 service. These AMSKs can be used by Mobile Node and Home Agent to bootstrap Mobile IPv6 protocol operation. Giaretta, et al. Expires - April 2006 [Page 1] Internet-Draft AMSK for Mobile IPv6 October 2006 Table of Contents 1. Introduction................................................3 2. Terminology.................................................4 3. Applicability Statement.....................................6 3.1 Bootstrapping IPsec SAs with Pre-shared keys.............6 3.2 Bootstrapping rfc4285-based SAs..........................6 4. Key derivation.............................................10 4.1 Mobile IPv6 USRK derivation.............................10 4.2 Mobile IPv6 AMSKs derivation............................10 4.3 Lifetimes...............................................11 5. Open issues................................................12 5.1 Key length (and other key related parameters)...........12 5.2 rfc4285 SAs.............................................12 5.3 Key Freshness...........................................12 5.4 Multiple EAP sessions...................................12 5.5 Identity management and key binding.....................12 6. AAA-HA interface requirements..............................14 7. Security Considerations....................................15 8. IANA Considerations........................................16 9. Acknowledgments............................................17 10. References.................................................17 10.1 Normative References..................................17 10.2 Informative References................................17 Authors' Addresses..............................................19 Intellectual Property Statement.................................20 Giaretta, et al. Expires - April 2007 [Page 2] Internet-Draft AMSK for Mobile IPv6 October 2006 1. Introduction Mobile IPv6 (MIPv6) requires that Mobile Nodes (MNs) and Home Agents (HAs) share a security association to protect binding management signaling. The MIPv6 protocol specification [1] mandates the use of IPsec for this purpose and therefore requires the MN to be provisioned with the data needed to bootstrap an IPsec Security Association (SA) with its Home Agent. This is one of the main issues of the so called Mobile IPv6 bootstrapping problem [11]. The IPsec SA between MN and HA can be established from a shared secret using IKE with Pre-Shared Key (PSK) authentication [6]. Alternatively, the Authentication Protocol for MIPv6 [5] presents a different security mechanism for Mobile IPv6 that requires a shared secret between MN and HA to authenticate the binding messages. In scenarios where network access control is based on EAP those shared secrets can be derived from the EAP key hierarchy [13]. In particular [10] specifies a mechanism for deriving cryptographically separate root keys from the EMSK, called Usage Specific Root Keys (USRK) in order to create a set of keys for usage specific needs. This document defines how to generate EAP derived key (USRK) specific for Mobile IPv6 bootstrapping. In addition, it defines how to derive application specific keys (AMSKs) both for IPsec SAs and Authentication Protocol SAs. The solution presented in this document is agnostic of the AAA-HA interface model (e.g. push/pull model). Giaretta, et al. Expires - April 2007 [Page 3] Internet-Draft AMSK for Mobile IPv6 October 2006 2. Terminology Most of the terms used in this document are defined in this section; more detailed general mobility and EAP terminology can be found in [7] and [13]. MSA Mobility Service Authorizer. A service provider that authorizes Mobile IPv6 service. ASA Access Service Authorizer. A network operator that authenticates a mobile host and establishes the mobile host's authorization to receive Internet service. Split scenario A scenario where the mobility service and the network access service are authorized by different entities (MSA!=ASA). Integrated scenario A scenario where the mobility service and the network access service are authorized by the same entity (MSA=ASA). EAP server The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server. MSK Master Session key Keying material that is derived between the EAP peer and server and exported by the EAP method. The MSK is at least 64 octets in length. EMSK Extended Master Session Key Additional keying material derived between the peer and server that is exported by the EAP method. The EMSK is at least 64 octets in length, and is never shared with a third party. USRK Usage Specific Root Key Keys derived from the EMSK which are cryptographically separate from each other. AMSK Application Master Session Key Keys derived from the USRK which are cryptographically separate from each other. MN Mobile Node A node that can change its point of attachment from one link to another, while still being reachable via its home address. Giaretta, et al. Expires - April 2007 [Page 4] Internet-Draft AMSK for Mobile IPv6 October 2006 HA Home Agent A router on a mobile node's home link with which the mobile node has registered its current care-of address. While the mobile node is away from home, the home agent intercepts packets on the home link addressed to the mobile node's home address, encapsulates them, and tunnels them to the mobile node's registered care-of address. BU Binding Update A message indicating a mobile node's current mobility binding, and in particular its care-of address. BA Binding Acknowledgement A message used to acknowledge receipt of a Binding Update. Giaretta, et al. Expires - April 2007 [Page 5] Internet-Draft AMSK for Mobile IPv6 October 2006 3. Applicability Statement The Mobile IPv6 bootstrapping problem statement [11] describes two main scenarios. In the first scenario (i.e. the split scenario), the mobility service is authorized by a different service authorizer (MSA, Mobility Service Authorizer) than the basic network access authorizer (ASA, Access Service Authorizer). In the second scenario (i.e. the integrated scenario), the mobile node's mobility service is authorized by the same service authorizer as the basic network access service authorizer. This implies that only in the integrated scenario it is possible to leverage the network access authentication to bootstrap mobility service. Therefore, the approach defined in this document applies only to the integrated scenario. This specification assumes that AAA server and the EAP server are co-located, with the latter exporting the keys to the former. As already pointed out, the solution presented here addresses both the IPsec and rfc4285-based SAs bootstrapping. 3.1 Bootstrapping IPsec SAs with Pre-shared keys The bootstrapping solution defined for integrated scenario [19] requires the mobile node to run an EAP exchange over IKEv2. In case the mobile node uses EAP for network access authentication, this implies that the MN executes two EAP exchanges, possibly with the same EAP server and using the same credentials. Therefore, in this scenario a key derived from EAP key hierarchy and named IKEv2-AMSK can be used as the IKEv2 Pre-shared Key (PSK), with the advantage that only one EAP exchange is performed (during network access authentication). The key is derived by the MN and the AAAH server and needs to be transferred to the HA (together with the MN/key identifier). Two different approaches are possible: 1. The AAAH server sends proactively the key to the HA (push approach). A requirement for this approach is that the AAAH server needs to know the HA assigned to the MN. 2. The HA requests to the AAAH the PSK during the IKEv2 exchange with the MN (pull approach). In this case the HA needs to know the AAAH server used by a specific MN for network access authentication. Figure 1 and 2 (pag. 8) show the message flow of the two models. Note that in both approaches the MN/key identifier must be sent via the AAA-HA interface and needs to be the same identifier used in IKEv2. 3.2 Bootstrapping rfc4285-based SAs Concerning rfc4285-based SAs, the keying material derived from EAP can be exploited in two different ways, since two possible authentication options are specified: 1. MN-HA Mobility Message Authentication Option. In this case a key derived from EAP key hierarchy and named MN-HA-AMSK, is used as the shared key for the security association between the MN and HA. Similarly to the IKEv2 Pre-shared key case, both the push and pull model can be envisioned for key delivery. The MN/key identifier must be sent via the AAA-HA Giaretta, et al. Expires - April 2007 [Page 6] Internet-Draft AMSK for Mobile IPv6 October 2006 interface and needs to be the same identifier to be used as Mobile Node Identifier (in the form of NAI) in the BUs. 2. MN-AAA Mobility Message Authentication Option. In this case a key derived from EAP key hierarchy and named MN-AAA-AMSK, is used as the shared-key for the security association between the MN and the AAAH server. In this case, no key delivery is needed. Giaretta, et al. Expires - April 2007 [Page 7] Internet-Draft AMSK for Mobile IPv6 October 2006 EAP PEER EAP-AUTH EAP-AUTH Server Home MN NAS Server Agent | | | | EAP session | | |<----------------------------->| | | | | | o o o | | | | | | | Access-Accept | | U A| | EAP Success, MSK | | S M| EAP Succ. |<------------------+ | R S|<----------| \ ------------ | K K| | USRK | | s| |generation | | | ------------ | | Binging Update / IKEv2 IKE_AUTH | |-------------------------------------------------------------- >| | | | | "Key-Request, MN identity" | | |<----------------------------- -| | | "keying material" | | | ----------------------------- >| | ----------- / | | | AMSKs | | | |generation | | | ----------- | Figure 1 - Pull model message flow EAP PEER EAP-AUTH EAP-AUTH Server Home MN NAS Server Agent | | | | EAP session | | Giaretta, et al. Expires - April 2007 [Page 8] Internet-Draft AMSK for Mobile IPv6 October 2006 |<----------------------------->| | | | | | o o o | | | | | | | Access-Accept | | U A| | EAP Success, MSK | "Keying material, MN identity"| S M| EAP Succ. |<------------------+------------------------------ >| R S|<----------| \ ------------ | K K| | USRK | ----------- / | s| |generation | | AMSKs | | | ------------ |generation | | | ----------- | | Binging Update / IKEv2 IKE AUTH | |-------------------------------------------------------------- >| Figure 2 - Push model message flow Giaretta, et al. Expires - April 2007 [Page 9] Internet-Draft AMSK for Mobile IPv6 October 2006 4. Key derivation The key hierarchy proposed in this document is depicted in Figure 3. Just one key (MIP6-USRK) is directly derived from the EMSK. Three different keys are then generated from the MIP6-USRK: IKEv2- AMSK, MN-HA-AMSK and MN-AAA-AMSK. The basic assumption is that the MIP6-USRK is exported by the EAP server to the AAA server that sends this key to the HA; the other keys are then derived directly from the USRK by the HA of the MSP. EMSK | MIP6-USRK | +----------------------------------+ | | | MN-AAA-AMSK MN-HA-AMSK IKEv2-AMSK Figure 3 - Proposed key hierarchy 4.1 Mobile IPv6 USRK derivation Mobile IPv6 USRK (MIP6-USRK) is derived through the general key derivation function (KDF) specified in [10]. The KDF is based on a pseudo random function shown below: KDF = PRF(key, data) where: PRF = HMAC-SHA-256 key = EMSK data = label + "\0" + op-data + length label = MIPv6-USRK-key op-data = EAP Session-ID length = 128 bit "\0" = is a NUL byte (0x00 in hex) + denotes concatenation Key name = PRF-64 (EAP Session-ID, key-label) Where PRF-64 is the first 64 bits from the output. 4.2 Mobile IPv6 AMSKs derivation Based on Mobile IPv6 USRK, the keys for Mobile IPv6 operations (IKEv2-AMSK, MN-HA-AMSK, and MN-AAA-AMSK) can be generated. These keys are derived as follows: KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ... where: T1 = prf (K, S | 0x01) T2 = prf (K, T1 | S | 0x02) T3 = prf (K, T2 | S | 0x03) T4 = prf (K, T3 | S | 0x04) prf = HMAC-SHA-256 K = USRK-MIPv6 L = key label D = application data O = output length S = L | " " | D | O The application specific parameters are set as follows: Giaretta, et al. Expires - April 2007 [Page 10] Internet-Draft AMSK for Mobile IPv6 October 2006 IKEv2 Pre-shared key AMSK (IKEv2-AMSK): key label = "MIPv6-IKEv2-key" application data = "HA Address" output length = variable (default 128) (key name = PRF-64(IKEv2-AMSK | EAP Session-ID) rfc4285 MN-HA key (MN-HA-AMSK): key label = "rfc4285-MN-HA-key" application data = "HA Address" output length = 128 bit (key name = PRF-64(MN-HA-AMSK | EAP Session-ID) rfc4285 MN-AAA key (MN-AAA-AMSK): key label = "rfc4285-MN-AAA-key" application data = "" output length = 128 bit (key name = PRF-64(MN-AAA-AMSK | EAP Session-ID) The actual key(s) to be derived by MN and HA depend on the authentication method deployed by the operator (or imposed by specific technologies). It should be possible on the operator side to differentiate users' authentication method on profile basis. The KDF does not include the home address in the application data because in this way the MN can derive the AMSK even if it does not know its home address yet. This is what might happen in some dynamic home address assignment scenarios. 4.3 Lifetimes As specified in [10] the lifetime of USRK keys must be equal to the lifetime of the EMSK. Lifetime of child keys, instead, can be different then root key’s lifetime and its specification is left to usage definition. Since the IKEv2-AMSK serves only for identity verification and not for authentication or ciphering purposes, there might be no need to re-generate the key at regular intervals. For this reason its lifetime is set equal to the MIP6-USRK lifetime. Since the MN-HA key is used to authenticate BUs and BAs messages, there is a clear need to keep these keys fresh and therefore to derive new keys periodically. This is discussed in section 5.3. Obviously all keys must be refreshed whenever a new EMSK is generated (i.e. during re-authentication events). Giaretta, et al. Expires - April 2007 [Page 11] Internet-Draft AMSK for Mobile IPv6 October 2006 5. Open issues The usage of EAP-derived keying material is still a work in progress in IETF and a good amount of study is underway to standardize generation and usage for keys generated from the EMSK. For this reason, this document leaves open some issues as input for HOKEY WG and others related WGs. 5.1 Key length (and other key related parameters) This specification doesn't address the problem of negotiating the key length; this is a general issue for AMSKs and should be solved in a generic way, not depending on the application that makes use of the keys (e.g. Mobile IPv6 bootstrapping). One very basic approach, applicable to some scenarios, is that the operator pre-provisions the user equipment with the right parameters (e.g. the right key lenght for a specific application). If an explicit negotiation is needed, a possible approach could be the one adopted in [18] that leverages the capability of some EAP methods (e.g. EAP-SIM, EAP-FAST, etc.) to carry arbitrary parameters during the authentication phase. However, it is worthwhile noting that some applications require only fixed length keys (e.g. MN-HA-AMSK and MN-AAA-AMSK for the MIPv6 Authentication Protocol) and for those applications this is not an issue. 5.2 rfc4285 SAs This document addresses only the negotiation of the shared secret among MN and HA (or AAA). Other parameters such as SPIs must be negotiated through other mechanisms. As for the key length issue this could be addressed by an explicit negotiation [18]. Another approach might be the derivation of the SPI from the EAP keying hierarchy itself. 5.3 Key Freshness While not an issue for IKEv2 PSK authentication, for rfc2485-based authentications the keys used to authenticate binding management messages should be fresh and therefore periodically changed. This document addresses only bootstrapping mechanisms and so the renewal of keying material is out of scope. A suggested solution may be that a new MN-HA-AMSK is generated at each BU/BA completed exchange (e.g. exchanging nonces in BUs and BAs). 5.4 Multiple EAP sessions In some scenarios (e.g. multi-homed terminals) a MN may have more than one active EAP session at the same time. Therefore, there is the need to define criteria for deciding which session(s) are in charge of generating AMSKs, and for which applications. 5.5 Identity management and key binding A MN can be associated to several identities at the same time (e.g. pseudonyms for identity privacy or temporary identities for EAP fast reconnect techniques like [9]). The AAAH server must be aware of the identity used by the MN in IKEv2 or rfc-4285 signaling. In pull model this is needed to allow the AAAH server to select the correct key to be delivered, upon requests, to the HA. In push model this is needed to allow the AAAH server to Giaretta, et al. Expires - April 2007 [Page 12] Internet-Draft AMSK for Mobile IPv6 October 2006 proactively deliver to the HA the correct MN identity information so that the HA can bind the subsequent authentication requests to the right key. Giaretta, et al. Expires - April 2007 [Page 13] Internet-Draft AMSK for Mobile IPv6 October 2006 6. AAA-HA interface requirements In order to fulfil the bootstrapping of MIPv6-related SAs, this document adds/modifies some requirements for the HA-AAA interface [21]: - G1.4 should use MUST (instead of SHOULD): "The AAA-HA interface MUST provide confidentiality since it may be used to transfer keying material (e.g. shared key generated during EAP authentication)" - HAs must be able to fetch keys from AAA servers (pull approach) - the AAAH server must be able to push a key into the HA (push approach) - key identifiers and lifetimes must be transferred alongside the key - in the request sent to the AAAH server in pull mode, HA must specify the HA address known be the MN, so that the AAAH server can derive the right key. Giaretta, et al. Expires - April 2007 [Page 14] Internet-Draft AMSK for Mobile IPv6 October 2006 7. Security Considerations Sending USRK for Mobile IPv6 from the AAA server to the HA requires that the protocol used for AAA-HA communication provides mutual authentication, integrity/reply protection and confidentiality. Moreover, since this document is strongly based on EAP [8] and the EAP Keying Management Framework [13], additional security considerations are bound to those valid for the EAP Keying Framework. Giaretta, et al. Expires - April 2007 [Page 15] Internet-Draft AMSK for Mobile IPv6 October 2006 8. IANA Considerations This document does not require actions by the IANA. Giaretta, et al. Expires - April 2007 [Page 16] Internet-Draft AMSK for Mobile IPv6 October 2006 9. Acknowledgments The authors would like to thank Alpesh Patel, Hannes Tschofenig, Rafa Lopez and Antonio Skarmeta for reviewing the document and the European Commission support in the co-funding of the ENABLE project, where this work is partly being developed. 10. References 10.1 Normative References [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", RFC 3776, June 2004. [3] Manner, J., Kojo, M. "Mobility Related Terminology", RFC 3753, June 2004 [4] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [5] A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006. [6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [7] Manner, J., Kojo, M. "Mobility Related Terminology", RFC 3753, June 2004 [8] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., Levkowetz, H., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [9] Haverinen, H., Salowey, J. "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, January 2006. [10] Salowey J., Dondeti L., Narayanan V., Nakhjiri M., "Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK)", draft- salowey-eap-emsk-deriv-01 (work in progress), June 2006. 10.2 Informative References [11] Patel, A. et al. "Problem Statement for bootstrapping Mobile IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in progress), July 2004. Giaretta, et al. Expires - April 2007 [Page 17] Internet-Draft AMSK for Mobile IPv6 October 2006 [12] K. Chowdhury, J. Bournelle, M. Nakhjiri, "Problem Statement for AMSK", February 2006. [13] Aboba, B., Simon, D., Arkko, J., Levkowetz, H., "EAP Key Management Framework", draft-ietf-eap-keying-14(work in progress), June 2006. [14] N.Cam-Winget, D. McGrew, J. Salowey, H.Zhou, "EAP Flexible Authentication via Secure Tunneling (EAP-FAST)", draft-cam- winget-eap-fast-00.txt (work in progress), February 2004 [15] Palekar, A. et al., "Protected EAP Protocol (PEAP) Version 2", draft-josefsson-pppext-eap-tls-eap-08 (work in progress), July 2004. [16] Haverinen, H. and J. Salowey, "Extensible Authentication Protocol Method for GSM Subscriber Identity Modules (EAP-SIM)", draft-haverinen-pppext-eap-sim-13 (work in progress), April 2004. [17] Arkko, J. and H. Haverinen, "EAP-AKA Authentication", draft- arkko-pppext-eap-aka-12 (work in progress), April 2004. [18] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., Laurent- Maknavicius, M., "MIPv6 Authorization and Configuration based on EAP", draft-giaretta-mip6-authorization-eap-02 (work in progress), October 2004. [19] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for the Integrated Scenario", draft-ietf-mip6-bootstrapping- integrated-dhc-00 (work in progress), October 2005. [20] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", draft- ietf-mip6-bootstrapping-split-01 (work in progress), October 2005. [21] Giaretta G., Guardini I., Demaria E., Bournelle J., Lopez, R., "Goals for AAA-HA interface ", draft-ietf-mip6-aaa-ha-goals-01 (work in progress), January 2006. Giaretta, et al. Expires - April 2007 [Page 18] Internet-Draft AMSK for Mobile IPv6 October 2006 Authors' Addresses Gerardo Giaretta Telecom Italia Lab via G. Reiss Romoli, 274 10148 TORINO Italy Phone: +39 011 2286904 Email: gerardo.giaretta@telecomitalia.it Ivano Guardini Telecom Italia Lab via G. Reiss Romoli, 274 10148 TORINO Italy Phone: +39 011 2285424 Email: ivano.guardini@telecomitalia.it Elena Demaria Telecom Italia Lab via G. Reiss Romoli, 274 10148 TORINO Italy Phone: +39 011 2285403 Email: elena.demaria@telecomitalia.it Michele La Monaca Telecom Italia Lab via G. Reiss Romoli, 274 10148 TORINO Italy Phone: +39 011 2285729 Email: michele.lamonaca@telecomitalia.it Julien Bournelle GET/INT 9 rue Charles Fourier Evry 91011 France Email: julien.bournelle@int-evry.fr Maryline Laurent-Maknavicius GET/INT 9 rue Charles Fourier Evry 91011 France Email: maryline.maknavicius@int-evry.fr Giaretta, et al. Expires - April 2007 [Page 19] Internet-Draft AMSK for Mobile IPv6 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. Full Copyright Statement Copyright (C) The Internet Society (2006). All Rights Reserved. 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Giaretta, et al. Expires - April 2007 [Page 20]