Network Working Group M. Nakhjiri Internet-Draft Motorola Labs Expires: December 23, 2006 June 21, 2006 A Keying hierarchy for managing Wireless Handover security draft-nakhjiri-hokey-hierarchy-02 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 December 23, 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 December 23, 2006 [Page 1] Internet-Draft Handover Keying Hierarchy Description June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Assumptions . . . . . . . . . . . . . . . . . 6 3. Key Hierarchy and Generation . . . . . . . . . . . . . . . . . 7 4. Architectural choices . . . . . . . . . . . . . . . . . . . . 11 5. messaging and AAA attributes . . . . . . . . . . . . . . . . . 13 5.1. Intra-ADC AN-handover . . . . . . . . . . . . . . . . . . 14 5.2. Inter-ADC AN-handover . . . . . . . . . . . . . . . . . . 14 6. Security report Card . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative references . . . . . . . . . . . . . . . . . . 17 Appendix A. Appendix A: channel binding . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Nakhjiri Expires December 23, 2006 [Page 2] Internet-Draft Handover Keying Hierarchy Description June 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 (link security keys, LSKs are established between the peer and the AN). This typically involves exchange of authentication signaling between the peer and a backend AAA server through the AN, followed by execution of a security association protocol (we call this link security association protocol, LSAP). The LSAP can derive the LSKs between the peer and the AN, but relies on a pre-existing trust, defined in large part by a so called LSAP master key (LSAP_MK) ( [I-D.nakhjiri-aaa-hokey-ps]). Provisioning of the peer and the AN with LSAP_MK is a challenge that affects the design and scalability of the wireless network. It is desired that LSAP_MK is unique for a peer-AN pair and is fresh for each communication session. 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 single intermediary called pass-through authenticator. The idea here is to use the initial EAP authentication for generation of MSK and EMSK and then build a key hierarchy to arrive at fresh LSAP_MKs that are unique for the peer-AN pair and for the specific authenticated session. The LSAP_MK would be delivered to the AN, while the peer would be able to derive the LSAP_MK based on previously derived key material. The peer and AN could then engage in a key management schema (LSAP) to establish a secure link with the peer (sharing LSKs). The challenge with using the current EAP keying specification is several fold: First the AN, through which the peer performs an EAP authentication, needs to have a role in the EAP pass-through authenticator architecture (as a authenticator port). From keying perspective (the fact that the AN needs an LSAP_MK to run LSAP with the peer) these two functions are almost orthogonal. Second EAP keying recommends transport of MSK to the pass-through authenticator. The role of an authenticator port in the key transport and keying is not quite clear. The common wisdom from the SDOs that are further along with implementation of EAP keying is that the AN would act as an authenticator port. This would mean the current AN (authenticator port) would be the entity receiving the MSK. This would mean the current AN will need to act as a key holder for MSK and create an LSAP_MK for use with the peer. As other ANs would require different Nakhjiri Expires December 23, 2006 [Page 3] Internet-Draft Handover Keying Hierarchy Description June 2006 LSAP-MKs with the same peer, this would require a cryptographic separation between the LSAP_MKs and therefore the separation between the storage of MSK and the LSAP_MK for each AN. However, the current AN, since it is acting as an MSK holder still has visibility to the LSAP-MK for all ANs for which it acts as an MSK holder. This is not desirable in case the AN is under a threat of physically or logically being hijacked. This would lead to a design where the MSK should possibly be held by a key holder (or as called in PS draft an access domain controller, ADC). The ADC would then create LSAP_MK for all of the ANs in an access domain. The third problem with using EAP keying is that a handover to an new ADC will require creation of a new MSK at the new ADC, as using the same MSK at the new AN will violate the principle of least privilege [I-D.housley-aaa-key-mgmt] and can result in a so-called domino effect. Creating a new MSK at the new ADC, on the other hand could require execution of another round of lengthy EAP method authentication exchange, which could be detrimental to handover performance, especially when real time services are in active session. Based on the discussion above, it would seem reasonable to have multiple ANs grouped in an access domain controlled by an access domain controller, ADC. Following an EAP authentication and creation of MSK/EMSK, a handover root key could be generated and passed on to the AAA server. The AAA server would then create ADC-specific master keys (ADMSK) and forward the ADMSK to each ADC based on request or proactively. Keying and authentication for handover between ANs within an access domain will be handled by the managing ADC, while the same for handovers between access domains can be handled through the AAA server, but without requiring a full EAP authentication. This can be accomplished if specific fast re-authentication keys can be generated (from the handover root key) for the sole purpose of authentication for handover between ADs and authorization for handover keying within the new access domain. This key will of course be kept hidden from each of the ADCs, while a new ADMSK will be sent to the new ADC, which in turn can cache the ADMSK and derive LSAP_MK for each of the ANs within its domain as needed. This approach will have some practical problems as well. First: the physical placement of the pass-through authenticator with respect to AN versus ADC needs to be determined. The pros and cons of each alternative are discussed later on in the draft. For now, we suffice to say that pass-through authenticator, AN and ADC are treated as three separate entities to not loose any generality. Second, regardless of the physical placement of the authenticator with respect to the AN, a design choice has to be made when it comes to derivation of a handover root key: Nakhjiri Expires December 23, 2006 [Page 4] Internet-Draft Handover Keying Hierarchy Description June 2006 1. MSK as handover root key: If we use MSK as the root key, we need to generate per-ADC keys from MSK and send those keys to each ADC instead. When the ADC contains a pass-through authenticator, this is in direct conflict with the existing deployments of EAP keying specification. 2. AMSK as the handover root key: We can create an application master key (AMSK) for handover from the EMSK as described in [salowey-eap-emsk-deriv] . The per-ADC master keys (ADMSK) will be generated from this AMSK and forwarded to each ADC. This is also in conflict with existing deployment examples of EAP keying. As one can see, we have introduced the term handover root key (HRK) as the root key for handover keying in this draft. This naming is introduced to reduce the dependency of a handover keying solution on the choice of MSK versus AMSK (Note: HRK was referred to as XMSK in [I-D.nakhjiri-aaa-hokey-ps]). The HRK may be either the MSK or the AMSK, depending on the EAP WG or IETF decision on permissions and/or requirements placed on MSK and EMSK from EAP methods. As seen above, regardless of what key is used as HRK (MSK or an AMSK) is used as a root key for handover keying, neither will result in a behavior that is consistent with the current definition of authenticator in the EAP keying documentation. The preference here is to generate the HRK from the EMSK in the same manner as an AMSK could be generated (HRK could be called handover AMSK). Furthermore, without dueling much on the placement of the pass-through authenticator, we introduced the key holder (KH) into the ADC (shown in Figure 1) as an entity that can cache ADMSK and generate LSAP_MKs as needed. In order for the ADC to be able to receive the ADMSK from the AAA server, the ADC must also be able to act as a AAA client with respect to the AAA server generating the ADMSK. Transport of LSAP_MK from the ADMSK to the ANs may under hand be done through a non-AAA protocol to be designed or determined later on. The keys at each level (ADMSK or LSAP_MK) can be generated per request or proactively (if all the required parameters are available). Nakhjiri Expires December 23, 2006 [Page 5] Internet-Draft Handover Keying Hierarchy Description June 2006 (HRK,AAA_REAUTH_KEY) <--------------------------------------------> (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 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 December 23, 2006 [Page 6] Internet-Draft Handover Keying Hierarchy Description June 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]. HRK: Handover root key is a key that will be used as the root key to solve the handover keying problem. 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 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. 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. 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. ADC Identifier (ADCID): The identifier for the ADC serving the peer. 3. 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. From this EMSK, an AMSK designated for handover keying application can be generated. We called this AMSK, the HRK. HRK=HRK-PRF (EMSK, "AMSK for Handover" | EAP session ID | Key_ID | Nakhjiri Expires December 23, 2006 [Page 7] Internet-Draft Handover Keying Hierarchy Description June 2006 AAA server ID) The HRK-PRF may be specified by any documentation (possibly [I-D.ietf-eap-keying]) that governs the caching/ usage of EMSK. AP session ID is supposed to be unique between peer and the server, identified by the peer-ID and EAP server ID, respectively. Note that the HRK is only known to the peer and the AAA server, but not known to any of the ADCs. After its generation, the HRK will be available at the AAA server and can be cached until expiration, but will not be transported to any other entities. The HRK is then used to the rest of keys within the handover key hierarchy: AAA_REAUTH_KEY: This is a key that does not leave the AAA server and is not exposed to any other entity in the network. AAA_REAUTH_KEY can be used by the peer, to sign a ADC handover request (ADC-HO- REQ) for handover to an area served by a new ADC or possibly to perform a new fast authentication when the initial EAP session is expired. Proof of possession of this key allows for a quick re- authorization (typically called fast re-authentication) of the peer in the either an inter-ADC handover, or session expiration, without requiring a new EAP. Aside from the re-authorization, the ADC-HO-REQ 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 proactively) 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. AAA-REAUTH_KEY= HO-PRF (HRK, "Key for re-authentication to AAA server" | EAP session ID | Key_ID ) ADMSK_i The key that is used as a root key for branch of key hierarchy within each access domain. 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 as follows: ADMSK_i= HO-PRF (HRK, "ADMSK generation" | EAP session ID | Key ID | ADCID) As seen, AAA_REAUTH_KEY and ADMSK are both generated at the AAA server based using a HO_PRF that can be supported by the crypto- engines at both MN and the AAA server. Note that the peer may not have knowledge of the ADC identifier Nakhjiri Expires December 23, 2006 [Page 8] Internet-Draft Handover Keying Hierarchy Description June 2006 (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. The AAA server now can send the ADMSK_i to the ith ADC through a secure transport (possibly a secured AAA message). The AAA server can delete the ADMSK_i after the transport to the ADC, if required for compliance with principle of least privilege. The ith ADC (ADCi) receives the ADMSKi. ADMSKi is meant to be a temporary key (within the interval that the current EAP session is valid) only known to the ADC_i and the peer. ADMSK_i is only cached at the key holder of ADC i and at the peer and is not distributed to any other entities. From this point on, we refer to this key as ADMSK. The key holder of an ADC uses the ADMSK as 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: LSAP_MKs: LSAP_MKs, as explained 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. The peer is able to perform the same calculation and arrive at the same copy of LSAP_MKn prior to performing the LSAP. ADC_REAUTH_KEY: To provide more flexibility in optimizing handover keying delay, we can allow for externally-triggered requests (from the peer through old or new ANs) to the ADC for generation of LSAP_MK by provisioning an ADC_REAUTH_KEY at the ADC and at the peer. A few uses cases for ADC_REAUTH_KEY can be envisioned: 1. Intra-ADC handover authorization (fast re-authentication to ADC): The peer can use the ADC_REAUTH_KEY for the current ADC to sign a request for authorization to a new AN (served by the same ADC) and at the same time trigger the ADC to generate and send the LSAP_MK for the new AN. This way intra-ADC handovers can be easily handled at the ADC without involving lengthy exchanges with the backend AAA servers. 2. Inter-ADC handover keying: If a new ADC (ADC_j) has been provisioned with ADMSK_j through proactive provisioning using the AAA infrastructure, the peer can using ADC_REAUTH_KEY for the new ADC sign a request for authorization to move into the access domain and thereby prepare to handover to ANs served by that ADC. Especially if the new ADC (ADCj) is provisioned with ADMSK_j before hand, the AAA interaction that is required for inter-ADC handovers can be moved out of the timing Nakhjiri Expires December 23, 2006 [Page 9] Internet-Draft Handover Keying Hierarchy Description June 2006 critical path for handovers. The proactive provisioning of the ADMSK_j can be part of a pre-authentication study. 3. Channel Binding: ADC_REAUTH_KEY and the authorization signaling can help channel binding purposes. It is important to note that both the peer and the ADC 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 ADC 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 ADC) 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. The ADC_REAUTH_KEY can be calculated as follows: ADC_REAUTH_KEY= ADC-PRF (ADMSK_i, "Key for re-authentication to ADC" | EAP session ID | Key_ID| ADCID ) LSAP_MKn for nth AN served by the KH of the ith ADC is generated as follows: LSAP_MKn = ADC-PRF (ADMSK_i, "LSAP master key generation" | EAP Session ID | Key-ID | ANn-Device-Id) 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 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 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. In the following we assume ADC i is the ADC 1 shown Figure 1) and the first AN the peer is connecting to is AN1. So the ADC1 creates the LSAP_MK1 for the (peer-AN1) interaction as follows: As the mobile node hands off from AN1 to another AN (AN2), through some method that we do not discuss at this point, the ADC is notified Nakhjiri Expires December 23, 2006 [Page 10] Internet-Draft Handover Keying Hierarchy Description June 2006 about the move and about the device ID of AN2. The ADC may require proof of possession of the ADC_REAUTH_KEY from the peer. The key holder of the ADC calculates the LSAP_MK2 for the AN2: LSAP_MK2 = ADC-PRF (ADMSK-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 ADC1 encrypting and signing the keying material for the AN2 through a (ADC1-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 ADC could then send signed (peer ID, AN-ID, encrypted(LSAP_MK)) triplets for each of the ANs. 4. 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. The first choice to be made is to determine where the ADC function needs to be located with respect to the AN. One important security goal at hand, is prevention of domino effect, so that if the LSAP_MK at one AN is compromised, the LSAP_MK at other ANs must not be compromised as a result. Creation of LSAP_MKs from the ADMSK that is at the higher level in the key hierarchy, partly serves this goal, by providing cryptographic separation unless ADMSK is compromised. However, to protect ADMSK from compromise, it is advised to follow the principle of least privilege, i.e. ADMSK should not be made available to a party unless absolutely needed. This would mean ADMSK should not be made available to processing entities that otherwise should only have access to LSAP_MK. This will leave two alternatives when it comes to physical placement of the key holder with respect to Nakhjiri Expires December 23, 2006 [Page 11] Internet-Draft Handover Keying Hierarchy Description June 2006 the ANs. 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). 2. Integrated 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 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 backhaul 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. The other choice to be made is the positioning of the ADC with respect to EAP signaling and AN. The EAP signaling will physically go through AN and EAP pass-through authenticator, so the pass-through authenticator defines the path for EAP signaling. Hence by off-path ADC we mean a scenario where ADC is not on the EAP signaling path and contacts AAA server through a separate AAA channel. 1. Off-path ADC: According to the handover keying solution, the ADMSK (and not the MSK) is sent to the ADC. This means ADC and an EAP pass-through authenticator are logically different entities and do not need to be collocated. This also means ADC does not necessary have to be on the EAP signaling path. In the off-path ADC arrangement, the pass-through authenticator can be located at the serving AN, also acting as a AAA client when encapsulating EAP packets into AAA messages. This is the most generic arrangement, but the downside of this arrangement is that Nakhjiri Expires December 23, 2006 [Page 12] Internet-Draft Handover Keying Hierarchy Description June 2006 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. +-+-+-+-+-+ | ADC | | AAAC |-----+ +-+-+-+-+-+ \ | \ | \ V \ +-+-+-+-+ +-+-+-+-+-+ \ +-+-+-+-+-+ | | | Athr | +-| | | EAP |--------| AAAC |------------| EAP/AAA | | Peer | | AN | | Server | +-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ Figure 2: 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 entity as described above. In the integrated scenario, the pass- through authenticator, AN and ADC will all be located in one physical entity. In the standalone case, where ADC is disjunct from the AN, a choice on placement of pass-through authenticator in AN versus in ADC has to be made. 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. 5. messaging and AAA attributes Design of messaging and message attributes to accomplish handover keying will be based on requirements placed on security and Nakhjiri Expires December 23, 2006 [Page 13] Internet-Draft Handover Keying Hierarchy Description June 2006 performance of that process at a later date. For now, we provide some examples to depict the type of issues involved in the design on performance-optimized handover security signaling. The message sequence diagrams are shown for a few different scenarios below. The message names are chosen for maximum simplicity and need to be enhanced later on. 5.1. Intra-ADC AN-handover In this case, as the peer moves from coverage area of AN1 to coverage area of AN2, it sends an handover authorization request to AN1 (using the available link to AN1). The AN1 will send a KEY-REQ message to the ADC to have the ADC proactively deliver the LSAP_MK2 to the AN2 as part of a KEY_REP message. The AN2 can optionally send a KEY-Conf message to the AN1 to inform that it now has received LSAP_MK2 regarding the peer. This indication can be conveyed to the peer by an HO-Auth-ack message from the AN1 to the peer, as shown in the figure. Alternatively the same KEY-Conf message from the AN2 can be encapsulated to the peer through AN1-peer link. The peer and AN2 can now engage in an LSAP exchange to establish security associations needed to secure the peer-AN2 link. peer AN1 AN2 ADC -------- -------- ------- ---------- | HO-Auth-REQ | | | | ----------->| KEY-REQ | | | | -------------------------> | | | | KEY-REP | | | KEY-Conf | <--------- | | HO-Auth-ack | <-------- | | | <-----------| | | | LSAP | | <----------------------------------- > | Figure 3: Intra- ADC handover, peer-AN1 link up 5.2. Inter-ADC AN-handover In this case the peer mobility pattern will bring the peer to the coverage area of AN3, which is part of an access domain served by ADC2. The KEY_REQ sent by the AN1 to the ADC1 is encapsulated in a message to the AAA server. This is a case where a fast re- authentication procedure with the AAA server is required. The need for fast re-authentication may be indicated back to the peer, which in turn will send a new authentication request out, but we leave the details for later on. At this point we assume the KEY-REQ from the ADC1 to the AAA server includes proper signatures to allow the AAA server to authorize a handover to the domain controlled by ADC2. Nakhjiri Expires December 23, 2006 [Page 14] Internet-Draft Handover Keying Hierarchy Description June 2006 Following this successful authentication and authorization, the AAA server sends the ADMSK2 to the ADC2 within a KEY_REP message. The ADC2 informs the ADC1 and subsequently the AN1 and the peer of the received authorization. The ADC2 will also calculate LSAP_MK3 for the AN3 and send this key to AN3, which awaits the indication by the peer to start an LSAP process. peer AN1 ADC1 AN3 ADC2 AAA ----- ----- ----- ---- ----- ------- | HO-Auth-REQ | | | | | | ----------->| KEY-REQ | | | | | | ---------->| | | | | | | KEY-REQ | | | | |--------------------> | | | | | KEY-REP | | | | KEY-Conf | <------ | | | KEY-Conf |<-------- | | | HO-Auth-ack |<-----------| |KEY_REP| | | <-----------| | |<---- | | | LSAP | | <---------------------------- > | | | Figure 4: Inter- ADC handover, peer-AN1 link up 6. 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 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. Nakhjiri Expires December 23, 2006 [Page 15] Internet-Draft Handover Keying Hierarchy Description June 2006 Handover Vulnerabilities: The key hierarchy introduced here, provides a hierarchy in authorization as well, e.g. AAA_REAUTH_KEY versus ADC_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-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. 7. 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. 8. IANA consideration This document does not require any actions by IANA. 9. Acknowledgements The author would like to thank Jari Arkko for useful suggestions on generation of AMSK for handover key hierarchy and Mohan Parthasarathy for providing feedback. 10. References Nakhjiri Expires December 23, 2006 [Page 16] Internet-Draft Handover Keying Hierarchy Description June 2006 10.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-13 (work in progress), May 2006. [I-D.nakhjiri-aaa-hokey-ps] Nakhjiri, M., "AAA based Keying for Wireless Handovers: Problem Statement", draft-nakhjiri-aaa-hokey-ps-02 (work in progress), May 2006. 10.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-02 (work in progress), March 2006. 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 December 23, 2006 [Page 17] Internet-Draft Handover Keying Hierarchy Description June 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 KH of an ADC, 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 ADC and peer can before generation of LSAP_MK verify that the AN is providing the same identity to both peer and ADC (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 ADC 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 architecture 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 ADC 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 (ADC in this case): one directly from the AN to the ADC and one through the peer, so that the ADC 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(ADC_REAUTH_KEY, channel binding info, "peer hash"). The peer can now send an authorization-request towards the ADC 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 December 23, 2006 [Page 18] Internet-Draft Handover Keying Hierarchy Description June 2006 technology messaging needs to include the peer-ANID-Hash described above. The AN now needs to forward the authorization request to the ADC. The AN can include this request inside a message (defined by protocol between AN and ADC) that also includes a request for LSAP_MK. We can call this message AN-ADC-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-ADC-AN-ID. Providing integrity protection for this identity is part of AN-ADC messaging protocol. Our goal is to make sure AN-to-peer-AN-ID and AN-to-ADC-AN-ID are the same. The ADC after receiving AN-ADC-KEY-REQ message, by using the AN-to- ADC-AN-ID from the AN calculate the channel binding tuple. Using the channel binding tuple and the ADC_REAUTH_KEY, the ADC can calculate its own hash signature (we call this signature ADC-ANID-hash): ADC-ANID-hash=KDF(ADC_REAUTH_KEY, channel binding tuple, "server hash") If there is match between ADC-ANID-hash calculated by ADC and the peer-ANID-hash reported by the peer, then not only the peer has proved it holds the ADC_REAUTH_KEY, but also the ADC can make sure the AN has reported the same identity to the peer. To provide the same assurance to the peer, the ADC can sends a copy of ADC-ANID-hash to the AN along with its response to the AN (AN-ADC- KEY-RESP). The ADC can also include the LSAP_MK for the AN in this message, since the ADC is now sure that AN is truthful. The AN can now forward the ADC-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 ADC-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 possess ADC-REAUTH_KEY and hence cannot modify any of the signatures exchanged between ADC 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 December 23, 2006 [Page 19] Internet-Draft Handover Keying Hierarchy Description June 2006 Author's Address Madjid Nakhjiri Motorola Labs Email: Madjid.nakhjiri@motorola.com Nakhjiri Expires December 23, 2006 [Page 20] Internet-Draft Handover Keying Hierarchy Description June 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 December 23, 2006 [Page 21]