Network Working Group M. Nakhjiri Internet-Draft Motorola Labs Expires: September 4, 2006 March 3, 2006 A Keying hierarchy for managing Wireless Handover security draft-nakhjiri-hokey-hierarchy-01 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 September 4, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Problem of AAA-based key management for facilitating secure handovers in a wireless mobile environment has been described in [I-D.nakhjiri-aaa-hokey-ps]. The intention with this document is to provide a starting point for developing a solution for that problem by introducing a key hierarchy using EAP generated keys. An example of how the channel binding problem can be solved is also added in an appendix. Nakhjiri Expires September 4, 2006 [Page 1] Internet-Draft Handover Keying Hierarchy Description March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Assumptions . . . . . . . . . . . . . . . . . 5 3. Key Hierarchy and Generation . . . . . . . . . . . . . . . . . 6 4. Security report Card . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative references . . . . . . . . . . . . . . . . . . 12 Appendix A. Appendix A: channel binding . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Nakhjiri Expires September 4, 2006 [Page 2] Internet-Draft Handover Keying Hierarchy Description March 2006 1. Introduction Wireless networks deploy specific access nodes (AN) providing link layer service to the peers. While the primary function of the AN is provide network connectivity and operator policy enforcement on the services rendered, it can do so only after the required authentication and security procedures are successfully performed. This typically involves exchange of authentication signaling between the peer and a backend AAA server through the AN and provisioning of keys for securing the link between the peer and the AN. The Extensible Authentication Protocol (EAP) framework, including [RFC3748] and the keying framework [I-D.ietf-eap-keying] have been used to perform authentication and to generate the EAP master keys (MSK and EMSK) at both backend server and the peer. The EAP framework also allows transport of MSK to a pass-through authenticator and recommends this transport be done through a AAA protocol. When the AN implements the authenticator and AAA client function, it can then after receiving the MSK engage in a key management schema with the peer to establish a secure link with the peer. The process described above may be sufficient in an environment where the authentication, AAA client and AN are co-located and the peer does not have move between different ANs. However, it will cause difficulties when those conditions do not apply. If the MSK is transported to an AN, when the peer moves to another AN, using the same MSK at the new AN will violate the principle of least privilage [I-D.housley-aaa-key-mgmt] and can result in a so-called domino effect. Creating a new MSK at the new AN, on the other hand could require performance of another round of lengthy EAP method authentication exchange, which is detrimental to handover performance, especially when real time services are in active session. As described in [I-D.nakhjiri-aaa-hokey-ps] an architecture deploying a key holder, KH, (shown in Figure 1) that can act as a AAA client and receive the master keys transmitted by the AAA server seems to gain more acceptance in the industry due to its strength in addressing this issue more effectively. EAP working group is currently working on specification of methodology [I-D.ietf-eap-keying] that allows the use of EAP method generated master keys (MSK and EMSK) in assisting AAA-based key management procedures. The notion of application master session key (AMSK) has been recognized as a useful concept. While some basic tenets about AMSK use has been discussed in IETF EAP WG, the process of AMSK generation, caching and distribution is not yet standardized Nakhjiri Expires September 4, 2006 [Page 3] Internet-Draft Handover Keying Hierarchy Description March 2006 in IETF. In the handover problem description document [I-D.nakhjiri-aaa-hokey-ps] we tried to reduce the dependency of a handover keying solution to the AMSK for that reason by introducing the notion of XMSK as the master key that is pushed/pulled into each key holder. Distinguishing between AMSK and XMSK serves two notions: 1) from one AMSK generated for handover, multiple XMSKs (one for each key holder, KH) can be generated. This way the architecture is capable of supporting Inter-KH handovers if need be. At the same time it can comply with the concern that only the AMSK and not the EMSK can be available at the AAA server, while the EMSK needs to stay (or possibly deleted) at the EAP server. 2) The XMSK, created at the AAA server for key holder and transported to the each KH, can be deleted from AAA server cache, if required. The AMSK can on the other stay at the AAA server for future use (such as XMSK generation for other, not currently identified KHs). Nakhjiri Expires September 4, 2006 [Page 4] Internet-Draft Handover Keying Hierarchy Description March 2006 (HO-AMSK,HO-AAA-REAUTH-KEY) <--------------------------------------------> (XMSK,HO-KH-REAUTH-KEY) <----------------------------> LSK,LSAP-MK <------------> +-+-+-+-+-+LSK +-+-+-+ LSAP-MK1 | MN/ |-----| AN11|---+ |EAP Peer | +-+-+-+ | +-+-+-+ +-+-+-+-+-+ +-----|KH 1 |-+XMSK1 +-----+ | +-----+ | | AN12|---|LSAP-MK2 ^ +-----+ | | . | | . | | +-+-+-+-+-+ +-+-+-+ | | |AAA/EAP | | AN1n|---+ +--+--| Server | +-+-+-+ | +---------+ | +-+-+-+ +-----+ | | AN21|---------|kH 2 |----+XMSK2 +-+-+-+ +-+-+-+ | . . | . . | +-+-+-+ +-----+ | | ANm1|---------|kH m |----+ XMSK3 +-+-+-+ +-+-+-+ . | . | +-+-+-+ | | ANmk|-----------+ +-+-+-+ Figure 1: A keying architecture deploying key holders This document intends to provide an example of how the various keys in handover keying architecture shown in figure Figure 1 can be generated. The document leaves the transport aspects of the key distribution for future discussion. Some of our key binding ideas may be self-evident through inclusion of various identifiers in the expressions provided for generation of various keys, however, these expression will need to examined more closely through further discussions. 2. Terminology and Assumptions Nakhjiri Expires September 4, 2006 [Page 5] Internet-Draft Handover Keying Hierarchy Description March 2006 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]. For a complete description of the terminology, the reader is referred to [I-D.nakhjiri-aaa-hokey-ps] X-Master Session Key (XMSK): A key that will be used as the root key to solve the handover keying problem. Link Secure Association Protocol (LSAP): The term Link Secure Association Protocol refers to the process used between the peer and the AN to generate and manage the security associations used to protect the peer-AN link (layer 2 or layer 3). The LSAP protocol uses LSAP-MK (below) as a root key and arrives at LSKs. LSAP Master key (LSAP-MK): The master key used by the peer and the AN during LSAP run to arrive at LSKs between the peer and the AN. LSAP-MK is derived from XMSK through one or more steps in ways to be explored. Link Session Keys (LSK): The keys derived upon completion of LSAP and used to secure the access link between the peer and the AN. In a special case, where the AN and the authenticator are co-located and use the same identifiers. 3. Key Hierarchy and Generation Upon successful completion of the EAP authentiation method, the EAP server generates the EAP MSK and EMSK as defined by the method that was executed. From this EMSK, an AMSK designated for handover keying application can be generated. We call this AMSK, the HO-AMSK HO-AMSK=AMSK-PRF (EMSK, "AMSK for Handover" | EAP session ID | Key_ID | AAA server ID) EAP session ID is supposed to be unique between peer and the server, identified by the peer-ID and EAP server ID, respectively. The current assumption is that the EMSK cannot be exported from the EAP layer down to the AAA layer, but the HO-AMSK can. Hence from this point, we assume that the AAA server can maintain a cache of HO- AMSK if it needs to. The HO-AMSK is then used to create further keys: HO-AAA-REAUTH-KEY= HO-PRF (HO-AMSK, "Key for re-authentication to AAA server" | EAP session ID | Key_ID ) Nakhjiri Expires September 4, 2006 [Page 6] Internet-Draft Handover Keying Hierarchy Description March 2006 KH-MK= HO-PRF (AMSK, "master Key for all key holders" | EAP session ID | Key_ID ) HO-AAA-REAUTH-KEY is a key that can be used by the peer, if it needs to indicate to the AAA server that it has moved to an area served by a new key holder. The key allows for a quick re-authorization process in the course of inter-KH handover, without requiring a new EAP. Proof of possession of this key, authorizes the peer to receive key generation services through a new key holder. Note that the peer may not necessarily need to know that it has moved to a new key holder; the AAA server can request proof of possession of this key through a request. HO-AAA-REAUTH-KEY does not leave the AAA server and is not exposed to any other entity in the network. The peer is able to generate this key through knowledge of AMSK. KH-MK is a key that does not leave the AAA server and is used by the AAA server as a root key when generating XMSK for a key holder number i: XMSK for KH i= XMSKi= KH-i-MK= HO-PRF (KH-MK, "XMSK generation" | EAP session ID | Key ID | Key holder i ID) Note that the peer may not have knowledge of the key holder identifier, hence some sort of domain identifier corresponding to the key holder needs to be used. Such domain identifiers can be broadcast through the advertisements provided by the AN to the peer. The AAA server now can send the XMSKi to the key holder i through a secure transport (possibly a secured AAA message). The AAA server can now delete the XMSKi, if required for compliance with principle of least privilage. The key holder i (KHi) receives the XMSKi. From this point on, we refer to this key as XMSK or XMSK-current to comply with the description provided in the handover keying problem description [I-D.nakhjiri-aaa-hokey-ps] The XMSK is meant to be cached at the key holder and not distributed to any other entities. The key holder uses the XMSK as for all the key generation activities within its domain (i.e. for all the ANs it serves). In the following we assume key holder i is the key holder 1 shown Figure 1) and the first AN the peer is connecting to is AN1. So the KH1 creates the LSAP-MK1 for the (peer-AN1) interaction as follows: LSAP-MK1 = LSAPMK-PRF (XMSK-i, "LSAP master key generation" | EAP Nakhjiri Expires September 4, 2006 [Page 7] Internet-Draft Handover Keying Hierarchy Description March 2006 Session ID | Key-ID | AN1-Device-Id) The LSAP-MK1 is transported to the AN1 through a secure transport at some point in conjunction to the handover To maintain a level of integrity in the design, we provision another authorization key (we call this HO-KH-REAUTH-KEY) so that the peer can use this key to gain authorization from the key holder to handover to another key. The KO-KH-REAUTH-KEY can be calculated as follows: HO-KH-REAUTH-KEY= HO-PRF (XMSK, "Key for re-authentication to key holder" | EAP session ID | Key_ID ) The need for proof of possession of this key and the exact signaling process through which this proof is presented to the key holder as part of handover is to be tested later on. There a few possible uses for this key: 1)HO-KH-REAUTH-KEY can help the peer to obtain authorization for handover to another AN served by the same key holder and trigger the key holder to send the LSAP-MK to that AN. This way lengthy exchanges with the backend AAA servers (fast re-authentication) can be eliminated in many cases. 2)HO-KH-REAUTH-KEY and the authorization signaling can help channel binding purposes: It is important to note that both the peer and the key holder serving AN1 calculate the LSAP-MK1 based on the peer-link-ID and AN-link-ID. The peer uses an AN-link-ID advertised by the AN over the link, while the KH uses an AN-link-ID that is received from AN or through pre-configuration. If those two copies of AN-link-ID (received by peer and by key holder) do not match the LSAP-MKs will not match either and LSK will fail. In the appendix we will provide some hints on how this key can be used to provide channel binding. Once the LSAP-MK1 is obtained by the AN1, the peer and AN1 can engage in an LSAP exchange to arrive at the LSKs. The exact process of LSAP is dictated by the SDO governing the specification of the communications link between the peer and ANs. So the following is simply an example: LSK-encryption=LSK-PRF (LSAP-MK1, "Link encryption key", EAP session ID | Key ID | peer-link-ID | AN-link-ID | peer-nonce | AN1-nonce), LSK-Authentication=LSK-PRF (LSAP-MK1, "Link authentication key", EAP session ID | Key ID | peer-link-ID | AN1-link-ID | peer-nonce | AN- nonce), Nakhjiri Expires September 4, 2006 [Page 8] Internet-Draft Handover Keying Hierarchy Description March 2006 Where the nonces are exchanged as part of an exchange between the peer and AN1. The link IDs are the identifiers through which the peer and the AN recognize each other over the wireless link. As the mobile node hands off from AN1 to another AN, through some method that we do not discuss at this point, the key holder is notified about the move and about the device ID of AN2. The Key holder may require proof of possession of the HO-KH-REAUTH-KEY from the peer. The key holder calculates the LSAP-MK2 for the AN2: LSAP-MK2 = LSAPMK-PRF (XMSK-i, "LSAP master key generation" | EAP Session ID | Key-ID | AN2-Device-Id) and transports the LSAP-MK2 to AN2, which engages in LSAP with the peer as described earlier. The details of the signaling are to be explored later. For instance the timing and triggers for various authorization messaging or keying material transport needs to be fine tuned based on the physical conditions of the (peer-AN1), (peer-AN2) and (AN1, AN2) links. For instance, authorization request for handover to AN2 and even LSAP-MK2 transport may happen prior to or following a handover to AN2. The former is for instance possible through the KH encrypting and signing the keying material for the AN2 through a (KH-AN2) shared key and sending it to the AN1, which then can through a simple context transfer move to the AN2, without much security requirements. transfer. Another example is if the AN or the peer could request LSAP-MKs for a list of candidate ANs as part of the request to the key holder. The key holder could then send signed (peer ID, AN-ID, encrypted(LSAP-MK)) triplets for each of the ANs. Finally, As discussed in the problem statement draft, a key holder seems to be a necessary part of the architecture. However, the realization of this architecture can take various shapes. the recommendation here is to use the following architecture to use EAP keying framework. Nakhjiri Expires September 4, 2006 [Page 9] Internet-Draft Handover Keying Hierarchy Description March 2006 +-+-+-+-+-+ | Key Hldr| | AAAC |-----+ +-+-+-+-+-+ \ | \ | \ V \ +-+-+-+-+ +-+-+-+-+-+ \ +-+-+-+-+-+ | | | Athr | +-| | | EAP |--------| AAAC |------------| EAP/AAA | | Peer | | AN | | Server | +-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ Figure 2: off-EAP-path key holder function 4. Security report Card This section of the document provides a test of the provided key hierarchy agains the security goals stated in the kandover keying problem statement draft [I-D.nakhjiri-aaa-hokey-ps] Key Context and scope, prevention of domino effect: The context and scope for each key is defined. The entire purpose of the hierarchy is to abide with the principle of least privilage to prevent the domino effect. Master keys are deleted after transport. Keys generated at each level of the hierarchy are unique to entities. for instance, XMSK for each key holder is only specific to that key holder, the same as LSAP-MK for each AN. Key Naming: All keying material starting from XMSK and the derivatives are uniquely named, using the identity of the parties sharing the key. Key Freshness: Use of EAP session ID should provide adequate level of freshness, in cases where the identity of an entity within the architecture is not known to the peer and in case of LSAP-MK generation. Generation of link level keys (LSKs) is outside control of IETF. The examples provided in this document, use peer and AN nonces for that purpose. Handover Vulnerabilities: The key hierarchy introduced here, provides a hierarchy in authorization as well, e.g. HO-AAA- REAUTH-KEY versus HO-KH-REAUTH-KEY. This way, the entity that generates the keys is making the authorization decisions. Authentication of all the parties: The hierarchy allows for peer- AAA server, peer-key holder and peer-AN authentication through introduction of specific keys. AAA server-key holder, key holder-AN authentication mechanisms are outside control of this document. Nakhjiri Expires September 4, 2006 [Page 10] Internet-Draft Handover Keying Hierarchy Description March 2006 Channel binding: The keys introduced in this document are named in a way that allows for proper binding. Exact signaling procedures for channel binding are to be investigated. EAP method independence: The key hierarchy in this document stems from the EAP method generated keys (MSK and EMSK). As long as the method is capable of creating EMSKs, this hierarchy is method independent. 5. Security Considerations This document discusses branching a key hierarchy from root keys provided by the EAP key management in order for providing keying solutions for wireless mobile networks. Key caching and non- transport requirements (i.e. storing a key at the origin without transporting it) are discussed throughout the document. However, the solution relies on the secure (encrypted and authenticated) transport of keys. Such secure transport of keying material between pairs such as (AAA server, key holder) and (key holder, AN) may be subject to security issues that are outside control of this docuemnt. Future revisions of this document is to provide recommendations for the transport mechanisms. 6. IANA consideration This document does not require any actions by IANA. 7. Acknowledgements The author would like to thank Jari Arrko for useful suggestions on generation of AMSK for handover key hierarchy and Mohan Parthasarathy for providing feedback. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [I-D.ietf-eap-keying] Nakhjiri Expires September 4, 2006 [Page 11] Internet-Draft Handover Keying Hierarchy Description March 2006 Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-09 (work in progress), January 2006. [I-D.nakhjiri-aaa-hokey-ps] Nakhjiri, M., "AAA based Keying for Wireless Handovers: Problem Statement", draft-nakhjiri-aaa-hokey-ps-01 (work in progress), January 2006. 8.2. Informative references [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [I-D.housley-aaa-key-mgmt] Housley, R. and B. Aboba, "Guidance for AAA Key Management", draft-housley-aaa-key-mgmt-01 (work in progress), November 2005. [I-D.arkko-eap-service-identity-auth] Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", draft-arkko-eap-service-identity-auth-04 (work in progress), October 2005. [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005. Appendix A. Appendix A: channel binding Channel binding can be defined as a procedure through which the keys generated for the channel (between party 1 and party 2) are bound the parameters governing that channel. These parameters can be called channel binding tuple (CBT) and typically can be listed as CBT=(party 1 ID, party 2 ID,other information) The field Other information may even include type of access technology, if need be. In a key hierarchy solution, channel binding needs to happen for keys Nakhjiri Expires September 4, 2006 [Page 12] Internet-Draft Handover Keying Hierarchy Description March 2006 at various levels of the key hierarchy. In context of link security keying, the LSAP-MKs are used between a peer and AN to generate LSKs to secure a link. Since the LSAP-MK is generated by a KH, using peer-link-ID and AN-link-ID, in essence the channel binding for LSAP-MK is accomplished during the generation of LSAP-MK. During the LSAP exchange, the peer and AN will prove the possession of LSAP-MK. However, it is more efficient to prevent the start of LSAP, if KH and peer can before generation of LSAP-MK verify that the AN is providing the same identity to both peer and KH (the so called lying NAS problem). As the channel binding need to happen at many level of key hierarchy, it is not feasible to include channel binding information in EAP layer signaling. It is neither desirable to have keying architecture elements, such as AAA server or KH to be pre-configured with channel binding information for scalability reasons or the requirements on statefulness. The statelessness (no requirements for pre- configurations) is very desirable in roaming scenarios, where a channel binding information in a foreign domain can simply not be pre-configured in the home domain. Here we are providing an example on how the identity presented by a middle-entity in the keying arhictecture can be verified by both end to prevent the so called lying NAS problem. The example is providing verification of AN identity for both peer and KH but can be extended for use with AAA server even in roaming scenarios. The solution is based on the premise that of sending two copies of channel binding information to the key management entity (KH in this case) : one directly from the AN to the KH and one through the peer, so that the KH can compare the two and perform a check. Only after a successful check, the peer and the AN can use LSAP-MK for LSAP between the peer and the AN. The details are as follows: The AN will sends AN-link-ID to the peer as part of link layer association signaling. We call this ID, AN-to-peer-AN-ID. The peer caches AN-to-peer-AN-ID as the AN-link-ID and builds the channel binding tuple (CBT) using this ID.The peer now uses this CBT (including AN-to-peer-ID) and calculates a peer-ANID-hash as follows: peer-ANID-hash=KDF(HO-KH-REAUTH-KEY, channel binding info, "peer hash"). The peer can now send an authorization-request towards the KH to request authorization for network entry through a AN (or handover to a new AN). The format of this message depends on the access technology used between the peer and the AN, however, the access Nakhjiri Expires September 4, 2006 [Page 13] Internet-Draft Handover Keying Hierarchy Description March 2006 technology messaging needs to include the peer-ANID-Hash described above. The AN now needs to forward the authorization request to the KH. The AN can include this request inside a message (defined by protocol between AN and KH) that also includes a request for LSAP-MK. We can call this message AN-KH-KEY-REQ. The AN will includes its identifier (AN-link-ID) as part of this request. We call this version of AN identifier AN-to-KH-AN-ID. Providing integrity protection for this identity is part of AN-KH messaging protocol. Our goal is to make sure AN-to-peer-AN-ID and AN-to-KH-AN-ID are the same. The KH after receiving AN-KH-KEY-REQ message, by using the AN-to-KH- AN-ID from the AN calculate the channel binding tuple. Using the channel binding tuple and the HO-KH-REAUTH-KEY, the KH can calculate its own hash signature (we call this signature KH-ANID-hash): KH-ANID-hash=KDF(HO-KH-REAUTH-KEY, channel binding tuple, "server hash") If there is match between KH-ANID-hash calculated by KH and the peer- ANID-hash reported by the peer, then not only the peer has proved it holds the HO-KH-REAUTH-KEY, but also the KH can make sure the AN has reported the same identity to the peer. To provide the same assurance to the peer, the KH can sends a copy of KH-ANID-hash to the AN along with its response to the AN (AN-KH-KEY- RESP). The KH can also include the LSAP-MK for the AN in this message, since the KH is now sure that AN is truthful. The AN can now forward the KH-ANID-hash inside its messaging to the peer. The messaging can be one of the messages that are part of LSAP to establish LSK between the peer and the AN. The peer upon comparing KH-ANID-hash and peer-ANID-hash, can calculate LSAP-MK using the channel binding tuple that is now confirmed and engage in LSAP messaging with the AN. Note that the AN does not posess HO-KH-REAUTH-KEY and hence cannot modify any of the signatures exchanged between KH and peer. Similar channel binding procedures can be used for all level of key hierarchy as long as authorization keys are available. For instance the same mechanism can be used to provide binding for keys between the peer and the AAA server. Nakhjiri Expires September 4, 2006 [Page 14] Internet-Draft Handover Keying Hierarchy Description March 2006 Author's Address Madjid Nakhjiri Motorola Labs Email: Madjid.nakhjiri@motorola.com Nakhjiri Expires September 4, 2006 [Page 15] Internet-Draft Handover Keying Hierarchy Description March 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 Expires September 4, 2006 [Page 16]