Network Working Group M. Nakhjiri Internet-Draft Huawei USA Expires: July 19, 2007 January 15, 2007 A Keying hierarchy for managing Wireless Handover security draft-nakhjiri-hokey-hierarchy-03 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 July 19, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Nakhjiri Expires July 19, 2007 [Page 1] Internet-Draft A Handover Keying Hierarchy Description January 2007 Abstract The Problem of AAA-based key management for facilitating secure handovers in a wireless mobile environment as well as for optimizing re-authentications has been described in [I-D.nakhjiri-aaa-hokey-ps] and [I-D.clancy-hokey-reauth-ps]. This document provides a solution for the problems described in those drafts. Specifically an EAP initiated key hierarchy to significantly reduce handover and re- authentication latency is defined. A number of architectural and protocol trade-offs are also presented. Signaling messages, extensions and attributes for deploying the handover key hierarchy are shown in proactive and reactive modes. Document also proposes a method to solve channel binding problem. Table of Contents 1. Introduction and Problem statement . . . . . . . . . . . . . . 3 1.1. Deploying ANs and Access gateways . . . . . . . . . . . . 3 1.2. Choice of root keys . . . . . . . . . . . . . . . . . . . 4 1.3. purpose of this document . . . . . . . . . . . . . . . . . 5 2. Terminology, Assumptions and new concepts . . . . . . . . . . 5 3. Proposed architecture . . . . . . . . . . . . . . . . . . . . 7 4. Key Hierarchy and Generation . . . . . . . . . . . . . . . . . 9 5. Architecture and messaging . . . . . . . . . . . . . . . . . . 12 5.1. Inter-ADC AN-handover and fast AAA re-authentication . . . 12 5.1.1. Proactive signaling . . . . . . . . . . . . . . . . . 13 5.1.2. Reactive signaling . . . . . . . . . . . . . . . . . . 15 5.2. Intra-ADC AN-handover . . . . . . . . . . . . . . . . . . 15 5.3. channel binding . . . . . . . . . . . . . . . . . . . . . 16 5.3.1. channel binding between peer and ADC . . . . . . . . . 17 5.3.2. channel binding between peer and AN . . . . . . . . . 18 5.4. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.5. New Extensions . . . . . . . . . . . . . . . . . . . . . . 19 6. backward compatibility with EAP . . . . . . . . . . . . . . . 19 7. Security report Card . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 11.2. Informative references . . . . . . . . . . . . . . . . . . 22 Appendix A. Appendix A: Architectural choices . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26 Nakhjiri Expires July 19, 2007 [Page 2] Internet-Draft A Handover Keying Hierarchy Description January 2007 1. Introduction and Problem statement It is becoming more and more common to use the Extensible Authentication Protocol (EAP) framework ([RFC3748] ) for access control authentication and bootstrapping the wireless link security. This is done by performing an EAP method [RFC3748] that is capable of generating EAP master keys, MSK and EMSK, ([I-D.ietf-eap-keying]), which are, in turn, used to bootstrap the so called temporary session keys, TSK) for the wireless link. The typically deployed model is one where EAP authentication is performed between the peer and a backend server, without involving much intelligence from the edge of the network. At the edge, the model only uses a logical entity called pass-through authenticator, which only takes part in changing the form of encapsulation of the EAP, but is otherwise passive until the very end, where the keying material for establishment of TSKs are generated from EAP master keys and are transported to this pass- through authenticator. Deploying this model creates a number of issues that are partly listed in the problem statement drafts ([I-D.nakhjiri-aaa-hokey-ps] and [I-D.clancy-hokey-reauth-ps]); for instance, the model does suffers from the inherent lack of support for fast re-authentications in EAP when peer's session is expiring. Another issue is the way the keying material derived from the initial EAP authentication, and distributed to the pass-through authenticators does not readily allow for optimized handovers without breaking security principles. Developing mechanisms for fast re-authentications although solving the problem in cases of session expiry, may not be adequate for solving handover latency problems, since many times a round trip to the AAA/EAP server may simply be too time consuming and therefore development of a key hierarchy that readily allows for handovers may be more efficient. This part of the document intends to elaborate on several more detailed problems that are involved with use of EAP framework in a wireless mobile environment: 1.1. Deploying ANs and Access gateways Wireless Networks today deploy specific access nodes (AN) for providing link layer connectivity and other services such as policy control etc to the wireless peers. There are several reasons for the access service operators to wish to manage groups of ANs in clusters managed by a single gateway (e.g. Access Service Node gateway, ASN-GW in WiMAX architecture). In such cases, it is the gateway rather than the individual ANs that performs many mobility (Mobile IP foreign agent), AAA (AAA client), and EAP (pass-through authenticator) functions. This creates several problems Nakhjiri Expires July 19, 2007 [Page 3] Internet-Draft A Handover Keying Hierarchy Description January 2007 EAP signaling The EAP model recognizes the pass-through authenticator as the entity that terminates the link with the peer and starts the AAA signaling with the backend server (to carry EAP over the backend). In the wireless architectures, the AN is the entity that ends the physical link with the peer, but it is not the AAA client and therefore not responsible for encapsulation of EAP in AAA protocol. This means there is an AN-Authenticator link that is underspecified according to the EAP model. As we see later, this link can cause problem when it comes to distribution of key material for MN-AN TSK generation. To get around this problem, we call a domain of ANs managed by a gateway, an Access Domain and refer to the gateway as Access Domain controller. The access domain controller (ADC) may or may not be on the path of every EAP authentication, involving a peer, an AN, and an EAP server. This means the ADC and pass-through authenticator may be logically and physically separate and the pass-through authenticator could be located in an AN. key transport The EAP model also specifies the transport of EAP MSK from the EAP server to the pass-through authenticator. However, since the pass-through authenticator and AAA function is typically deployed in the gateway rather than in the AN, this means it is the gateway and not the AN that receives keying material (MSK) from the AAA server. The other reason for doing so is that only gateway to gateway handovers would lead to a need for a new MSK and thereby a new EAP authentication (if the current keying model to be deployed). key generation The introduction of the gateway, that is separate from the ANs, would potentially mean that two level of keys needs to be introduced in the hierarchy, one key at gateway (ADC) level (called ADMSK) and one key at AN level (called LSAP_MK). Supplying the peer and the AN with fresh and unique LSAP_MK to perform the exchange needed to secure their links is also a challenge. 1.2. Choice of root keys The decision on whether to use EAP MSK or EMSK as the root key for the entire handover keying and re-authentication solution. While cryptographically each might have similar characteristics, there will be different impacts on the backward compatibility with the existing Nakhjiri Expires July 19, 2007 [Page 4] Internet-Draft A Handover Keying Hierarchy Description January 2007 deployments. Choice of MSK as root means that new specifications define a new usage for MSK and transport behavior, while choice of EMSK means new specification for EMSK usage (e.g. [I-D.salowey-eap-emsk-deriv]) must be produced. 1.3. purpose of this document This document intends to provide a solution for the problems of re- authentication and handover keying described earlier. The main portion of the solution revolves around creation of a new keying architecture based on the master keys established as part of a previously valid EAP, while staying independent of the EAP signaling framework restrictions. A number of architectural choices are presented to deal with EAP limitations. A new channel binding problem is presented. Some problems remain partially or completely unsolved. Example is the transport of generated keys from the ADC to AN. Signaling required for exchange of parameters related to key derivation is still work under progress and in some cases requires extensions to non-IETF signaling mechanisms. 2. Terminology, Assumptions and new concepts 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]. Access Domain/ADC As mentioned earlier, the existence of both an AN and a gateway on the path of EAP signaling creates issues: the AN terminates the peer link, while the gateway acts as a AAA client and receives the master keys for MN-AN TSK generation. As mentioned this may lead to the need for proprietary AN-gateway protocols to carry EAP. Furthermore as mentioned before the pass-through authenticator is the entity that receives the MSK from the EAP server. To get around both these problem, we introduce a new logical entity called Access Domain Controller (ADC) managing a so called domain of ANs. The ADC would be the entity that receives any keying materials directly coming from the EAP/ AAA server and thereby managing the mobility and keying needs of the domain of ANs. However, as far as the EAP signaling goes, since EAP signaling is potentially only important during initial EAP authentication, it is possible to simply allow the gateway (ADC) to be outside the initial EAP signaling (between peer, AN and EAP server), since the existence of both AN and the gateway (acting as the ADC) on the Nakhjiri Expires July 19, 2007 [Page 5] Internet-Draft A Handover Keying Hierarchy Description January 2007 path allows for either to act as the pass-through authenticator. This means the ADC and pass-through authenticator may be logically and physically separate and the pass-through authenticator could be located in an AN. There is also a possibility where both AN, ADC and pass-through authenticator can all be collocated. An appendix for this document discusses the trade offs around HRK: Handover root key is a key that will be used as the root key to solve the handover keying problem. The HRK can be the same as MSK, a key generated from MSK, or can be a usage specific root key (USRK) derived from EMSK specifically for support of re- authentication and handover. HRK is generated using a so-called HRK_PRF in a manner that preserves cryptographic separation between EMSK, HRK and other USRKs and thus needs to comply with the requirements in [I-D.salowey-eap-emsk-deriv] HO_PRF: The PRF that is used by the MN and the AAA server for generating handover-related keys to be generated at the AAA server level. The HO_PRF needs not to comply with the requirements specified for USRK, and only needs to be supported by the crypto-engines at both MN and the AAA server. The HO_PRF can be access technology agnostic and can be pre-configured based on MN and AAA capabilities to avoid cipher suite negotiations, if desired. ADC_PRF: The PRF that is used at the key holder (KH) of the ADC and the MN for generating lower level keys at are to be generated at the KH of ADC. AAA_RK AAA Re-authentication key. A key derived at the AAA server and at the peer from the HRK and is used for fast re-authentication to the AAA server and handover authorization between the peer and the AAA server. ADMSK Access Domain Master Session Key: A key derived at he AAA server and at the peer from the HRK for a specific ADC. AAA server transports ADMSK to the ADC through secure AAA protocol transport. ADC_RK ADC Reauthentication key. A key generated at the peer and the ADC from ADMSK for the purpose of local fast re-authentication to the ADC and possibly handover authorization. Link Secure Association Protocol (LSAP): Nakhjiri Expires July 19, 2007 [Page 6] Internet-Draft A Handover Keying Hierarchy Description January 2007 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). EAP documentation [I-D.ietf-eap-keying] uses the term SAP for the protocol between the peer and authenticator. We use the term LSAP intentionally to refer to cases, where the AN may be separate from the pass-through authenticator. The actual details of the LSAP protocol exchanges may be the same as those for SAP, but the LSAP protocol uses LSAP_MK (see below) rather than MSK or the so called PMK 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 ADMSK through one or more steps in ways to be explored. This proposal also assumes that LSAP_MK is securely delivered from ADC to the AN, while the peer is able to generate the LSAP_MK. 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. EAP documentation uses the term TSK to refer to MN- authenticator temporary keys, we use LSK to distinguish a case where the AN may not be the pass-through authenticator, otherwise the LSK and TSK can be the same. ADC Identifier (ADCID): The identifier for the ADC serving the peer. This ID must unequivocally and uniquely identify the ADC to both the peer, the EAP server (and the ANs being served by the ADC, when applicable). 3. Proposed architecture The picture below describes the assumed physical architecture for the access network, including gateways performing ADC function for groups of ANs and ANs providing link connectivity to the peers. It also shows the keys that would be shared between various entities as the MN would move from one AN to the next. There may or may not be restrictions on the overlapping life times for the keys such as ADMSK and LSKs depending on the network policy. This picture does not show the placement of the pass-through authenticator. Our believe is that positioning of pass-through authenticator is important for the initial EAP authentication and not for the following keying process. Our choice is to have AN and ADC as separate entities as shown in the picture. Furthermore, we assume that the pass-through authenticator function is located within the AN, and the ADC is off the EAP Nakhjiri Expires July 19, 2007 [Page 7] Internet-Draft A Handover Keying Hierarchy Description January 2007 signaling path. This along with the choice of EMSK for derivation of HRK creates the least conflict with existing EAP specifications and deployments. A discussion around placement of pass-through authenticator, AN and ADC is provided in an appendix. (HRK,AAA_RK) <--------------------------------------------> (ADMSK,KH_REAUTH_KEY) <----------------------------> LSK,LSAP_MK <------------> +-+-+-+-+-+LSK +-+-+-+ LSAP_MK11 | MN/ |-----| AN11|---+ |EAP Peer | +-+-+-+ | +-+-+-+ +-+-+-+-+-+ +-----|ADC1 |-+ADMSK1 +-+-+-+ | +-+-+-+ | | AN12|---|LSAP_MK12 ^ +-+-+-+ | | . | | . | | +-+-+-+-+-+ +-+-+-+ | | | AAA/EAP| | AN1n|---+LSAP_MK1n +-+-+| Server | +-+-+-+ | +-+-+-+-+-+ | HRK +-+-+-+ +-+-+-+ | | AN21|---------|ADC2 |-+ADMSK2 +-+-+-+ +-+-+-+ | . . | . . | +-+-+-+ +-----+ | | ANm1|---------|ADCm |-+ ADMSKm +-+-+-+ +-+-+-+ . | . | +-+-+-+ | | ANmk|-------------+ +-+-+-+ Figure 1: A keying architecture deploying ADCs Keying (LSAP_MK generation) and authentication for handover between ANs within an access domain will be handled by the managing ADC, without the need for referring to the AAA server for re- authentication or key management. Only the handovers between access domains can be handled through the AAA server, since as the picture shows, per-ADC master keys (ADMSK) needs to be generated from the HRK Nakhjiri Expires July 19, 2007 [Page 8] Internet-Draft A Handover Keying Hierarchy Description January 2007 at the AAA server and forwarded to each ADC. Depending on the network policy, a peer re-authentication may or may not be required for a new ADMSK fetch as part of ADC handovers. This methodology reduces or in many cases eliminates the need for AAA-server referrals from the handover procedure. Still the key hierarchy presented here provides a method for fast re-authentication that can be used for session lifetime extension or re-authentication in conjunction with ADC handovers (depending on network policy). This is done by creating specific re-authentication keys (AAA_RK) from the HRK and using these keys with minimal signaling with the AAA server. The same method (using an ADC re-authentication key) can be used if re- authentication with the ADCs are required for intra-ADC handovers. 4. Key Hierarchy and Generation Upon successful completion of the EAP authentication method, the EAP server generates the EAP MSK and EMSK as defined by the method that was executed. As mentioned before, one can choose either MSK or EMSK for the handover keying problem. Our choice here is to use the EMSK. From this EMSK, an USRK designated for handover keying application can be generated. We called this USRK, the HRK. Based on the user profiles, the AAA server authorizes the user (peer) for the handover keying and fast re-authentication service and request generation of the HRK from the EAP layer key holder that holds the EMSK. The HRK is then delivered to the AAA layer (seen as AAA server in this document). The HRK is stored at the AAA server database, where it is fetched for each ADMSK derivation. The ADMSK for each ADC is kept hidden from other ADCs. EMSK | HRK _________________|___________________......______ | | | | AAA-_RK ADMSK1 ADMSK2 ADMSKm _____|__________________________ | | | ADC_RK LSAP_MK1 LSAP_MK2 Figure 2: A keying hierarchy to support handover and re- authentications HRK=HRK-PRF (EMSK, "Handover Root key derivation" | EAP session ID | Key_ID | AAA server ID) Nakhjiri Expires July 19, 2007 [Page 9] Internet-Draft A Handover Keying Hierarchy Description January 2007 Since HRK is generated as an USRK from the EMSK, the HRK-PRF may be based on a network policy decision or decision specifically for the handover process (see [I-D.salowey-eap-emsk-deriv] for details). EAP session ID is supposed to be unique between peer and the server, identified by the peer-ID and EAP server ID, respectively, but is an optional field depending on whether it is produced by the executed method. Note that the HRK is only known to the peer and the AAA server, and will be available until expiration, but is not transported to any of the ADCs or ANs. The HRK is then used for generation of keys within the next level of the handover key hierarchy, namely the AAA_RK and ADMSK_I as described below. Note that these keys are generated using HO_PRF that is supported by the crypto-engines at MN and AAA server. The HO_PRF does not have to be the same as HRK_PRF as explained earlier. 1. AAA_RK=HO-PRF (HRK, "Key for re-authentication to AAA server" | EAP session ID | Key_ID ) 2. ADMSK_i= HO-PRF (HRK, "ADMSK generation" | EAP session ID | Key ID | ADCID) AAA_RK: AAA Re-authentication key is a key that does not leave the AAA server and is not exposed to any other entity in the network. AAA_RK can be used by the peer, to sign a ADC handover request (HRQ) for handover to an area served by a new ADC or possibly to perform a new fast authentication (FRQ) when the initial EAP session is expired. Proof of possession of this key allows for a quick re-authorization of the peer without requiring a new EAP. Aside from the re-authorization, the HRQ can serve as a trigger for the AAA server to create an ADMSK for the new ADC. Depending on the timing of this message (if done pro actively) the delay related to handover keying can be significantly reduced. Note that the peer may not necessarily need to know that it has moved to a new ADC; the AAA server can (through the new AN or new ADC) request proof of possession of this key through a request. The peer is able to generate this key through knowledge of HRK. ADMSK_i ADMSK_i is the key that is used as a root key for branch of key hierarchy within each access domain and only known to MN and ADC_i. Once the AAA server knows which ADC (ADC number i: ADC_i) is going to serve the MN, it creates a ADC master session key for that specific key holder (ADMSK_i) using the HRK. Note that the peer may not have knowledge of the ADC identifier (ADCID). To allow to peer to be able to calculate the ADMSK_i, the ADC identifier should be provided to the peer through some means. We are suggesting that the ADCID be provided through broadcast advertisements provided by the ANs serving the area. Nakhjiri Expires July 19, 2007 [Page 10] Internet-Draft A Handover Keying Hierarchy Description January 2007 The AAA server now can send the ADMSK_i to the ith ADC through a secure transport (possibly through securing the AAA message with a permanent security association between the AAA server and the ADC). The AAA server can delete the ADMSK_i cache after the transport to the ADC, if required for compliance with principle of least privilege. The ith ADC (ADCi) receives the ADMSKi. ADMSKi (called ADMSK from this point on) and caches it in its key holder for all the key generation activities within its domain (i.e. For all the ANs it serves). Particularly, the KH of the ADC generates two types of keys: 1. ADC_RK= ADC-PRF (ADMSK_i, "Key for re-authentication to ADC" | EAP session ID | Key_ID| ADCID ) 2. LSAP_MKn = ADC-PRF (ADMSK_i, "LSAP master key generation" | EAP Session ID | Key-ID | ANn-Device-Id) LSAP_MKs: LSAP_MKs, as explained earlier and in [I-D.nakhjiri-aaa-hokey-ps] serve as master keys for performing Link Security Association Protocol (LSAP) exchanges between the peer and the AN to establish Link Session Keys (LSKs). LSAP_MKn for AN number n is generated at the KH of the serving ADC using ADMSK and is sent to and only to the ANn. Transport of LSAP_MK from the ADC to the ANs may be done through a non-AAA protocol to be designed or determined later on. The peer is able to calculate the LSAP_MKn as long as AN identifier is available. ADC_RK: This will be the shared secret that is used for authenticating the signaling between the peer and ADC. The authentication may be needed if fast re-authentication as part of intra-ADC handovers are required, or to trigger proactive inter- ADC handovers, or for channel binding purposes as follows: 1. A request signed using ADC_RK can trigger generation of LSAP_MKs for intra-ADC handovers without the need for interaction to AAA server. 2. A proactive request signed using ADC_RK to a new ADC can trigger LSAP_MK generation for inter-ADC handovers (as long as ADMSK is available at the new ADC) and thereby improving handover latency. 3. Channel Binding: ADC_RK and the authorization signaling can help channel binding purposes (confirming AN_link_ID at both peer and ADC). Once the LSAP_MKn is obtained by the ANn, the peer and ANn 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 Nakhjiri Expires July 19, 2007 [Page 11] Internet-Draft A Handover Keying Hierarchy Description January 2007 communications link between the peer and ANs. So the following is simply an example for creation of link session keys for encryption and message authentication: LSKE=LSK-PRF (LSAP_MKn, "Link data encryption key", EAP session ID | Key ID | peer-link-ID | ANn-link-ID | peer-nonce | ANn-nonce), LSKA=LSK-PRF (LSAP_MKn, "Link data authentication key", EAP session ID | Key ID | peer-link-ID | ANn-link-ID | peer-nonce | ANn-nonce), Where the nonces are exchanged as part of an LSAP 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. 5. Architecture and messaging In this section we attempt to describe how the earlier proposed key hierarchy can be used for improving the latency involved in handover and re-authentication. As mentioned earlier, the preferred architecture model is the model that is most widely deployed today in wireless networks, i.e. a network, where physically disjoint ADCs are managing groups of ANs within an access domain. and ADCs. Placement of ADC versus the authenticator for the initial EAP is also rather important. However, once the initial authentication is complete, as long as both the peer and the backend server generating the HRK have the ADC identifier to create the ADCID, the positioning of ADC with respect to EAP pass-through authenticator is immaterial. In the following we will discuss more details on the signaling required for handover keying and re-authentication. As the timing of handover triggers and the path the signaling can take depends on the physical conditions of the physical links between peer and previous versus new ANs (peer-AN1, peer-AN2 and AN1-AN2 links), various combination of the proactive/ reactive requests versus pull/ push key transports can be envisioned. 5.1. Inter-ADC AN-handover and fast AAA re-authentication Figure below shows a scenario where the peer changes its point of attachment from AN1 (under control of ADC1) to AN3 (under control of ADC2). Since this involves a change of ADCs, an ADMSK2 needs to be generated. As described earlier, the knowledge of both HRK and ADCID_2 is required for generation of ADMSKs. First, this means the ADMSK2 for ADC2 must be generated at the AAA server. Although a re- Nakhjiri Expires July 19, 2007 [Page 12] Internet-Draft A Handover Keying Hierarchy Description January 2007 authentication of the peer in conjunction to ADC handover is a matter of network policy and not necessarily required, we show how AAA_RK can be used during handover messaging to achieve a fast re- authentication with the AAA server. Second, the ADCID_2 needs to be communicated to both the peer and the AAA server: The peer can receive the ADCID_2 through beacon advertisements broadcast by the AN3 or possibly neighbor advertisements by the AN1. The AAA server can receive the ADCID_2, when it receives a handover and key request (HKRQ). Note, HKRQ is a new AAA command . This request can either be made reactively (after peer's handover into AN3 area) from ADC2 or pro actively (while the peer is still in AN1 area) from ADC1. 5.1.1. Proactive signaling Here, we consider a case where the peer tries to perform a proactive handover request, while still being attached to AN1. This can be considered to provide more optimized performance than a reactive request. It is however important to note that for the proactive keying to be optimized, the AAA server must receive the ADCID2 either from the peer or ADC1 at the time of key request. In the following we can assume that the ADC2 has: The peer starts by sending a handover request (HRQ) to the AN1, while including the AN3_ID as a request to attach to AN3. The peer does not know whether this is an intra- or inter-ADC handover, therefore the peer signs the HRQ with both ADC_RK and AAA_RK. The former is included inside an ADC_REAUTH_Extension, while the latter is included inside a AAA_REAUTH_Extension. If the peer has received the ADC2_ID for the ADC2 (managing the AN3) somehow (e.g. Through beacon advertisement by AN3), the MN includes the ADC2_ID inside an NEW_ADC_Extension. If the ADC recognizes AN3_ID as one of its own (intra-ADC handover), the ADC1 verifies the signature in ADC_REAUTH_Extension, using ADC_RK, and ignoring the AAA_REAUTH_Extension, the ADC1 would create an LSAP_MK3 for AN3. However, in this scenario AN3 is not served by the ADC1. Not finding AN3 in its AN_list, or finding a NEW_ADC_Extension, means the ADC needs to forward the request from the peer as an HKRQ to the AAA server and includes the AAA_REAUTH_Extension inside a HKRQ_Authorization_AVP. ADC1 extracts ADCID_2 either from its own database, or from the peer's HRQ message NEW_ADC_Extension and includes it inside an ADC_ID_AVP to the AAA server. The ADC1 protects the HKRQ with whatever security mechanism available within the AAA infrastructure between AAA server and its clients. Nakhjiri Expires July 19, 2007 [Page 13] Internet-Draft A Handover Keying Hierarchy Description January 2007 The AAA server, upon receiving the HKRQ from the ADC1, verifies the signature within HKRQ_Authorization_AVP (using AAA_RK). Using the included ADCID_2 included in ADC_ID_AVP of the HKRQ, the AAA server calculates an ADMSK2 for the ADC2. The AAA server encrypts the ADMSK2 for the ADC2 with a AAA_ADC2_key and includes the wrapped key inside an ADC_KEY_AVP and sends it along an HKRP command to the ADC1. The AAA server needs to include other information regarding the MN session (as required by ADC2 for LSAP_MK and ADC_RK derivations) inside this AVP. The ADC_KEY_AVP, may set an "ADMSK flag" to indicate that this indeed is an ADMSK and not an MSK to show that the server is using a handover key hierarchy rather than a legacy MSK. The ADC1 extracts the ADC_KEY_AVP from the HKRP, initiates a context transfer process (CTXP, see RFC 4067) )with the ADC2, delivering the wrapped key to the ADC2. The ADC2 receiving the information from the AAA server, calculates the LSAP_MK3 for AN3 and initiates a transfer of this key to AN3 (AN_KEY message).. Once the completion of CTXP is confirmed at the ADC1, ADC1 sends an handover request reply (HRP) to the peer. If the ADC1 had not received a NEW_ADC_Extension from the peer (peer did not know ADCID_2), the ADC1 includes ADCID_2 inside this extension and send it along HRP to the peer. The peer calculates LSAP_MK3 an starts an LSAP exchange with AN3 to establish link security. The proactive keying process is shown in the figure below. It should be noted that the reactive keying, i.e. When the peer requests the key directly from AN3 and ADC2 is much simpler and no context transfer process or interaction with ADC1 is required and ADCID_2 is readily available. Nakhjiri Expires July 19, 2007 [Page 14] Internet-Draft A Handover Keying Hierarchy Description January 2007 peer AN1 ADC1 AN3 ADC2 AAA ----- ----- ----- ---- ----- ------- | HRQ | | | | | | ----------->| HRQ | | | | | | ---------->| | | | | | | HKRQ | | | | |--------------------> | | | | | HKRP | | | |<-------------------- | | | | CTP | | | | HRP |<--------> | | | HRP |<-----------| | | | | <-----------| | | | | | LSAP | | | | | <---------------------------- > | | | Figure 3: Proactive Inter- ADC handover, peer-AN1 link up 5.1.2. Reactive signaling It should be noted that the reactive keying, i.e. When the peer requests the key directly from AN3 and ADC2 is much simpler and no context transfer process or interaction with ADC1 is required and ADCID_2 is readily available. peer AN1 AN3 ADC1 ADC2 AAA ----- --- ----- --- ----- ------- | HRQ | | | | ----------->| HRQ | | | | ---------->| | | | | HKRQ | | | |--------------------> | | | | HKRP | | | |<-------------------- | | | | | | | HRP | | | HRP |<-----------| | | <-----------| | | | LSAP | | | | <--------- >| | | Figure 4: Reactive Inter- ADC handover, peer-AN3 link up 5.2. Intra-ADC AN-handover Intra-ADC handovers are simply handled by the ADC without referral to AAA server and this is the benefit of the assumed architecture including ADCs and ANs. Nakhjiri Expires July 19, 2007 [Page 15] Internet-Draft A Handover Keying Hierarchy Description January 2007 As the peer moves from AN1 area to AN2, it sends an HRQ to AN2 (reactive handover) including the ADC_REAUTH_Extension. AN2 forwards HRQ to ADC2. ADC2 after verifying the signature (using ADC_RK) within the ADC_REAUTH_Extension and if successful, ADC2 creates an LSAP_MK2 for AN2 and sends it to AN2. AN2 starts LSAP process with the peer. Above, we described a reactive handover procedure this time. As mentioned before, proactive handover keying through AN1 is possible in cases where peer-AN1 is still available. The LSAP_MK2 for AN2 can be delivered from ADC2 either directly or through a secure AN1-AN2 context transfer. Alternatively, the AN1 can send a list of neighbor ANs to the ADC and request for an LSAP_MK push from ADC to those ANs. The LSAP_MK can be delivered as signed triplets of (peer ID,AN-ID, encrypted(LSAP_MK)) for each of the ANs. 5.3. channel binding This section proposes a new method independent channel binding procedure that does not add any roundtrips to the handover keying signaling. Channel binding can be defined as a procedure through which the keys generated for the between party 1 and party 2 are bound to the parameters governing that channel between party 1 and party 2. This is important both for limiting the scope of the key. The channel can defined by a set of parameters, that we notify as channel binding Tuple (CBT). CBT can simply be represented as follows: CBT=(party 1 ID, party 2 ID, other channel data) The field "Other channel data" can for instance include type of access technology. In cases where party 1 and party 2 use a trust third party to establish a shared key, without having had a prior trust relationship, it is important that the CBT is also checked by the third party, so neither party lies about its identity to the other peer. In the wireless handover and re-authentication key hierarchy presented in this document, party 1 is always the peer, while party 2 Nakhjiri Expires July 19, 2007 [Page 16] Internet-Draft A Handover Keying Hierarchy Description January 2007 is either the AN (for LSAP_MK and LSK) or ADC (for ADMSK and ADC_RK). When generating the ADMSK to shared between peer and ADC it is important to make sure that the ADC reports the same identity to the peer and to the AAA server. When generating LSAP_MK to be shared between peer and AN, it is important to make sure that the AN reports the same identity to both peer and ADC. 5.3.1. channel binding between peer and ADC The idea presented here for channel binding is simple: Lets assume the ADC were to lie about its identity to the peer and present itself as ADC_DID (down link ID), while presenting itself as ADC_UID (up link ID) to the AAA server. If the AAA server could receive two copies of the ADC_ID, one through the peer and one through the ADC itself, then the AAA server could uncover this lie. To realize this, we suggest the following procedure DCBT: The peer forms a DCBT (down link CBT) based on the ADC_DID received from the beacon advertisement DCBT=(peer_ID, ADC_DID, other data). Note that this precludes the proactive handover requests, where the peer does not know ADC_ID. In such cases the channel binding might have to happen following the HKRQ and HKRP exchange. The peer builds a Peer_CBT_Extension and adds this extension to the HRQ sent towards ADC. Note that the this extension either needs to include its own MIC or needs to be included the calculation of the MIC for the HRQ and thus the peer uses AAA_RK for the calculation of this signature. DCBT_Authenticator= HMAC_SHAX (AAA_RK, DCBT) UCBT After receiving the peer HRQ, when the ADC is ready to send an HKRQ to the AAA server, the ADC creates its own version of the CBT, that we call up link CBT (UCBT) based on ADC_UID UCBT=(peer_ID, ADC_UID, other data) The UCBT can be protected separately by the ADC-AAA trust relationship, or undergo the security provided to the HKRP (AAA messaging).However, separate protection of UCBT is preferred as it is carried as a AAA AVP. The ADC includes DCBT and UCBT inside separate AAA AVPs within HKRQ, as Peer_CBT_AVP and ADC_CBT_AVP. The AAA server can simply verify that the DCBT and UCBT in fact include the same ADC_ID (ADC_DID and ADC_UID are the same). The AAA Nakhjiri Expires July 19, 2007 [Page 17] Internet-Draft A Handover Keying Hierarchy Description January 2007 server can create a notification of the successful channel binding procedure for the peer by adding an additional AVP to the HKRP back to the ADC. The AVP can be called CBT_Confirm_AVP and include a MIC using AAA_RK again. The HKRP also includes the ADMSK for the ADC. The ADC must extract the information from CBT_Confirm_AVP inside a CBT_Confirm_extension inside the HRP message to the peer. If the peer receives the CBT_Confirm_AVP from the ADC and can verify the AAA server signature, the peer can calculate the ADMSK using the ADC_DID and install the ADMSK. Otherwise the peer considers the handover request as denied. As we can see the channel binding procedure for ADMSK does not add any additional round trip to the messaging. 5.3.2. channel binding between peer and AN The same methodology can be applied for binding the LSAP_MK to the peer and AN. D_AN_CBT: The peer forms a D_AN_CBT (down link CBT) based on the AN_DID received from the beacon advertisement D_AN_CBT=(peer_ID, AN_DID, other data). The peer builds a Peer_AN_CBT_Extension and adds this extension to the HRQ sent towards AN. Note that the this extension either needs to include its own MIC or needs to be included the calculation of the MIC for the HRQ and thus the peer uses ADC_RK for the calculation of this signature. D_AN_CBT_Authenticator= HMAC_SHAX (ADC_RK, D_AN_CBT) U_AN_CBT In this case the U_AN_CBT may not be needed, since the ADC typically has a list of the ANs that is serving and knows the AN_ID. Thus upon receiving the HRQ, the ADC verifies the MIC in the Peer_AN_CBT_Extension and then verifies that AN_DID indeed matches ADC copy of AN_ID. If there is a match, the ADC creates an AN_CBT_Confirm_extension (signed with ADC_RK) inside the HRP message to the peer. If the peer receives the AN_CBT_Confirm_AVP from the AN and can verify the ADC signature, the peer can calculate the LSAP_MK using the AN_DID and install the LSAP_MK. Otherwise the peer considers the handover request as denied. As we can see the channel binding procedure for LSAP_MK does not add any additional round trip to the messaging either. 5.4. New AVPs Nakhjiri Expires July 19, 2007 [Page 18] Internet-Draft A Handover Keying Hierarchy Description January 2007 ADC_ID_AVP: details TBD HKRQ Authorization_AVP: details TBD ADC_KEY_AVP: details TBD This AVP SHOULD include an indication that the server is requesting the peer to use the handover keying hierarchy ADMSK rather than the EAP keying MSK for keying. This indication can be done by setting an "ADMSK flag". Peer_CBT_AVP: details TBD ADC_CBT_AVP: details TBD 5.5. New Extensions New_ADC_Extension: format TBD This extension SHOULD include indications that the peer supports a handover keying hierarchy rather than a legacy EAP keying hierarchy. AAA_REAUTH_Extension: format TBD ADC_REAUTH_Extension: format TBD Peer_CBT_Extension Peer_AN_CBT_Extension 6. backward compatibility with EAP For simplicity we call a peer or server that supports handover keying "hokey-compliant". The same entity is "hokey incompliant" even if it supports EAP keying. Hokey-compliant" peere and servere can use handover root key (HRK) to generate per-ADC keys (ADMSK). A "hokey compliant" server transports the ADMSK to the ADC (potentially an authenticator). On the other hand, hokey-incompliant (legacy) peers and servers use MSK instead of both HRK and ADMSK. Authenticators may not require much change to comply with the new key hierarchy, unless they act as an ADC and are responsible for a domain of ANs, unless a "hokey compliant" ADC and AAA server need to deal with a "hokey non-compliant" peer. While running the EAP method, the authenticator does not (and does not need to) have a knowledge of whether the server and the peer are hokey-compliant. However, the peer and the server Should be able to indication their compliances to each other and possibly negotiate their preference. In other words, a "hokey compliant peer needs to identify the AAA server that it is Nakhjiri Expires July 19, 2007 [Page 19] Internet-Draft A Handover Keying Hierarchy Description January 2007 requesting a hokey key hierarchy and not a legacy key hierarchy and vice versa. We consider two major cases: 1. During the initial EAP authentication: During the initial EAP authentication, an indication for handover keying hierarchy is more difficult to achieve in a EAP method independent fashion. Using a new EAP method type just for indicating key variant may be excessive, especially since sequencing EAP methods cannot be achieved unless after a method is completed. For those reasons, it may be more practical, to simply negotiate "hokey compliance" (i.e. Use of handover keying hierarchy) after EAP Success indication. Once the peer receives an EAP Success, it can send a "Key Request" message (indicating her "hokey compliance" to the server, if the peer knows the ADC, the ADC_ID can also be included as mentioned before (this also implies ADC "hokey compliance"). The server replies with "Key Response" along with ADMSK wrapped in ADC_KEY_AVP and an "ADMSK-flag" set or with MSK, depending on its "hokey compliance". Alternatively the same can be achieved by EAP signaling and possibly a new EAP method type. However, the signaling needs to be initiated by the AAA server, possibly piggybacking on the EAP Success, the EAP Request/Hokey (the new EAP method type), to which the peer responds with EAP Response/Hokey. Regardless, of whether Hokey or EAP signaling is used, the PRF for HRK and ADMSK can be negotiated if needed. 2. During a handover: The process during a handover can be much more straightforward by using hokey signaling (HRQ and HRP), without involving EAP signaling, especially in cases where the authenticator and ADC are not collocated. This is explained in the previous sections of this document. The peer and the server can perform a fast re-authentication using the keys derived from HRK, instead of performing a full EAP authentication. There is however an issue with not using EAP and that is the lower layers, especially on the peer side needs to define encapsulation mechanisms for carrying hokey signaling. This is however minimal work, especially in cases, where the lower layer is already capable of carrying EAP. 7. Security report Card This section of the document provides a test of the provided key hierarchy against the security goals stated in the handover 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 by the principle of least privilege to prevent the domino effect. Master keys are deleted after transport. Keys generated at each level of the hierarchy are Nakhjiri Expires July 19, 2007 [Page 20] Internet-Draft A Handover Keying Hierarchy Description January 2007 unique to entities. For instance, ADMSK for each ADC is only specific to that ADC, the same as LSAP_MK for each AN. Key Naming: All keying material starting from ADMSK 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. Still, 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. AAA_RK versus ADC_RK. 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-ADC and peer-AN authentication through introduction of specific keys. AAA server-ADC, ADC-AN authentication mechanisms are outside control of this document. 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. 8. 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, ADC) and (ADC, AN) may be subject to security issues that are outside control of this document. Future revisions of this document is to provide recommendations for the transport mechanisms. 9. IANA consideration This document defines a number of new AAA AVPs that need to be standardized by IANA. It may also require a number of new Diameter command codes, if Diameter is used. In that case, allocation of new command codes needs to be done through IANA as well. Nakhjiri Expires July 19, 2007 [Page 21] Internet-Draft A Handover Keying Hierarchy Description January 2007 10. Acknowledgements The author would like to thank Jari Arkko for useful suggestions on generation of USRK for handover key hierarchy and Mohan Parthasarathy for providing feedback. 11. References 11.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] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-16 (work in progress), January 2007. [I-D.nakhjiri-aaa-hokey-ps] Nakhjiri, M., "AAA based Keying for Wireless Handovers: Problem Statement", draft-nakhjiri-aaa-hokey-ps-03 (work in progress), June 2006. [I-D.clancy-hokey-reauth-ps] Clancy, C., "Handover Key Management and Re-authentication Problem Statement", draft-clancy-hokey-reauth-ps-01 (work in progress), January 2007. [I-D.salowey-eap-emsk-deriv] Salowey, J., "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. 11.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. Nakhjiri Expires July 19, 2007 [Page 22] Internet-Draft A Handover Keying Hierarchy Description January 2007 [I-D.housley-aaa-key-mgmt] Housley, R. and B. Aboba, "Guidance for AAA Key Management", draft-housley-aaa-key-mgmt-06 (work in progress), November 2006. Appendix A. Appendix A: Architectural choices We now come to the point where we need to make decisions on physical placements of various functional elements of EAP and handover keying with respect to the physical entities in a typical wireless network. AN versus ADC: The first choice to make is whether AN and ADC can be physically collocated or should they be in separate entities. One important security goal is prevention of domino effect, which requires that LSAP_MK and ADMSK are cryptographically separate (compromise of LSAP_MK at one AN does not lead to compromise of the LSAP_MK at other ANs or the compromise of ADMSK at the ADC managing those ANs), but also must not be compromised as a result. The other security goal is the principal of least privilege, which means an AN function should only have access to LSAP_MK not to ADMSK. The other goal is simply related to mobility performance, i.e. Whether it is advantage to have an AN with ADC function to act as an anchor for future mobility of the peer within the session or have a centralized ADC. When AN and ADC (especially key holder function) functions reside inside the same physical location, care must be taken that 1. Standalone ADC: ADC located within an entity that physically disjunct from the AN. This way, one ADC can sit on a more central (hopefully physically safer location within the network) and through back-haul links serve multiple ANs. Having the same designated ADC within the domain will make the system design more robust. For instance when IPsec tunnels are needed to protect AAA or other signaling, such tunnels can be set up with the same ADC off the handover timing critical path. The handover design may be more efficient this way as well. For instance by knowing the identity of the ADC, the AN and the peer will be able to perform fast handover procedures easier (e.g. ADCID can be broadcast to peers for the purpose of key generation, or the key requests can always be sent to the same entity). Furthermore, this does not require anchoring the ADC function from the initial AN through which the peer authenticated to the EAP server. 2. Integrated AN-ADC: According to this alternative the ADC is located within the AN. This would require that the ADMSK and ADC may possibly have to be located inside a trusted platform in the memory location that is not accessible to processing entity handling LSAP and over the air encryption/ decryption. The downside of this alternative are three: First: The initial Nakhjiri Expires July 19, 2007 [Page 23] Internet-Draft A Handover Keying Hierarchy Description January 2007 AN that also acts as a pass-through authenticator and receives ADMSK needs to act as the ADC for the domain. This will make the design of the topology of the wireless network rather dynamic and the optimizations described for a static ADC cannot be achieved as easily, since any AN can at any time act as ADC for the domain. Second: Depending on the topology and arrangement of the ANs having to go back to an anchor AN for retrieving LSAP_MK can be detrimental to handover and back haul performance for wide area wireless network. Third: A compromise of the initial AN and thereby compromise of the ADMSK will put the rest of the ANs within that domain at potential risk until the peer session expires. ADC versus Pass-through Authenticator The other choice to be made is the positioning of the ADC with respect to EAP signaling and AN. The EAP signaling will have to physically go through AN. It does however not have to go through the ADC, depending on whether the ADC is part of the pass-through authenticator function or not. Furthermore, according to the handover keying solution, the ADMSK is sent to the ADC. However EAP Keying only defines the transport of MSK to the pass-through authenticator. From the keying standpoint, this makes the ADC and pass-through authenticator separate logical entities and creates a choice. 1. Off-path ADC: In the off-path ADC arrangement, the ADC is off the EAP signaling path. The pass-through authenticator can simply be located at the serving AN, also acting as a AAA client when encapsulating EAP packets into AAA messages. The transport of ADMSK to ADC from the AAA server is done through a AAA server-ADC AAA channel and this means the initial AN does not have an anchoring responsibilities. This is the most generic arrangement. This arrangement in case EMSK is chosen for HRK derivation creates a least conflict with the design of legacy EAP pass-through authenticators. But the downside of this arrangement is that ADC identifier (ADCID) must be provided and proven to both peer, AN and AAA server (the one creating ADMSK for the ADC). As mentioned earlier, the ADCID can be provided to the peer to advertisements by the AN (such as beacons), while the ADCID can be provided to the AAA server through AAA signaling (AAA attribute). The other downside is it requires AAA functionality within the AN and it requires the AAA server to deal with two different AAA clients as part of security provisioning and authentication. Specific channel binding issues might arise in this case. Nakhjiri Expires July 19, 2007 [Page 24] Internet-Draft A Handover Keying Hierarchy Description January 2007 +-+-+-+-+-+ | ADC | | AAAC |-----+ +-+-+-+-+-+ \ | \ | \ V \ +-+-+-+-+ +-+-+-+-+-+ \ +-+-+-+-+-+ | | | Athr | +-| | | EAP |--------| AAAC |------------| EAP/AAA | | Peer | | AN | | Server | +-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ Figure 5: off-EAP-path ADC function 2. On-path ADC: In this case the ADC is located on the EAP signaling path, i.e. Either integrated with an AN or as an standalone ADC entity as described previously. In this case, one needs to decide on whether the pass-through authenticator function needs to be placed inside the AN or inside the ADC. Placing the pass-through authenticator in the AN is acceptable, as long as the AN is able to encapsulate the EAP signaling into AAA signaling and the ADC is able to act as a AAA proxy for AAA signaling. Note that this alternative will imply that the master keys from the AAA server are not sent to the authenticator as it is common in IEEE 802.1x style implementations. Placing the pass-through authenticator in the ADC will possibly require specific considerations in the transfer of EAP signaling from the peer over the AN and the ADC to the EAP server. In the integrated AN-ADC scenario, the pass-through authenticator, AN and ADC will all be located in one physical entity. Author's Address Madjid Nakhjiri Huawei USA Email: mnakhjiri@huawei.com Nakhjiri Expires July 19, 2007 [Page 25] Internet-Draft A Handover Keying Hierarchy Description January 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Nakhjiri Expires July 19, 2007 [Page 26]