Internet Draft Madjid Nakhjiri draft-nakhjiri-eap-ho-00.txt Motorola Labs Category: Internet draft June 2005 Expires: December 2005 EAP keying and handover support Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 3, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The current EAP documentation set, such as [EAP3748], [EAPKEY6], and [RADEAP3579] provide a powerful framework for performing combined authentication and key management using an EAP server and an AAA Nakhjiri et. al. EAP keying and handover support [Page 1] infrastructure. The framework competently deals with many issues related to network-access control and link security setup. However, when it comes to deploying these specifications for mobile wireless environments, where a peer is required to perform fast and/or heterogeneous handovers, the current framework can be extended with more clear guidelines and possibly specifications in ways that prevent interoperability or security issues. This draft intends to explore some of the complications in deploying the EAP framework for handovers and analyze a few solution alternatives. Further threat analysis of each alternative or providing trade-off guidelines for support of handover may be part of the future revisions of this document. Conventions used in this document 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 RFC-2119. Table of Contents 1. Introduction...................................................3 2. Terminology and Assumptions....................................4 3. Key derivation overview........................................5 3.1 Key transport timing issues................................7 3.2 Channel binding issues.....................................7 3.3 Life times.................................................8 4. Key distribution architecture alternatives.....................9 4.1 AAA server-based...........................................9 4.1.1 Initial EAP authentication and key distribution 9 4.1.2 Handover 10 4.1.3 Pros and Cons 12 4.2 Local Key distribution Center.............................13 4.2.1 Initial authentication 14 4.2.2 Handover 16 4.2.3 Pros and Cons 17 4.3 EAP Proxy approach (multi-hop peer-NAS link)..............17 4.3.1 Initial authentication 18 4.3.2 Handover 19 4.3.3 Pros and Cons 19 4.4 AAA-proxy approach........................................20 4.4.1 Handover procedure 20 5. Security considerations.......................................21 6. References....................................................21 Nakhjiri et. al. EAP keying and handover support [Page 2] 1. Introduction EAP key management framework [EAPKEY6] defines a 3 phase procedure for performing EAP-based authentication and key management. These phases are discovery, authentication and secure association protocol (SAP) phases: EAP peer Authenticator Auth. Server -------- ------------ -------- |<----------------------------->| | | discovery phase | | |<----------------------------->|<---------------------------->| | EAP auth (phase 1a) | AAA pass-through (optional) | | | | | |<---------------------------->| | | AAA-Key transport | | | (optional; phase 1b) | |<----------------------------->| | | Secure association protocol | | | (including a nonce exchange) | | Figure 1: 3 phases of EAP authentication and key management. . In the discovery phase, the peer locates the authenticators. This phase is considered out of scope of [EAPKEY6], however, it may have an impact on some of proposals discussed in this document as explained later. . During the EAP authentication phase, as part of an EAP-method, EAP master key (MSK) and extended master key (EMSK) are established between the EAP server and EAP peer. Furthermore, a AAA key can be established between the peer and EAP server. In cases where authenticator is separate from the EAP server, the AAA-key is transported to the authenticator. The AAA-key or a derivate key, called Pair-wise master key (PMK) residing at the authenticator and the peer can be used for the next phase . During the Secure association phase the peer and the authenticator engage in an exchange, by which they prove the possession of AAA-key (or PMK) and at the same time use this key as a medium term secret to establish short term so called transient session keys (TSK). In order to assure that the transient session keys are fresh and to avoid the domino effect possibly caused by attacks on weak session keys (leading to compromise of AAA key or PMK), the secure association protocol typically includes a nonce exchange between the authenticator and the peer every time new (or refreshed) session keys are required. The secure association protocol (SAP) phase is also considered out of scope for [EAPKEY6]. Nakhjiri et. al. EAP keying and handover support [Page 3] In networks offering mobility services, network attachment is typically provided by a point of presence (PoP), sometimes called a base station (BS) or an access point (AP). From this point on, for convenience we call the PoP, a BS. An exact definition of BS is provided in the terminology section. In a wireless environment, a peer can attach to the network through a BS after going through an EAP authentication procedure with the backend authentication server and then a secure association procedure with the BS. A mobile wireless peer may need change its serving BS due to its geographical/ topological mobility. For simplicity at this point we assume that the mobility scenario does not require roaming between different AAA domains. Mobility enabled security architectures should be designed in a way that full EAP authentication exchanges should not be required during handovers. In other words if the new BS for the peer is itself served by the same AAA infrastructure as the old BS and if the master keying material (MSK, EMSK and/ or AAA key) established during the EAP authentication phase through the initial BS is still valid, the EAP authentication phase (at least in large part) should be skipped for the new BS. This way only security association establishment procedures between the peer and new BS are required, which means a substantial reduction in the latency involved in handover security procedures. The problem however is that the security association protocols typically use a nonce-in the clear-exchange along with the keying material derived from full EAP authentication process. If the derivation of temporary session keys is based on the AAA-key directly, it would require that AAA-key must be shared with each BS. Once the AAA-key is shared with one BS, that BS is able to derive the session keys between the peer and its neighboring BSs pair, as long as the BS can hear the over the air security association exchange. This would lead to a security compromise. For that reason we propose to use a slightly modified key derivation mechanism (as suggested in previous versions of [EAPEXT]). 2. Terminology and Assumptions In this document we refer to a network point of attachment as base station (as defined below). For simplicity in presentation of the different problems and solution approaches, we assume that a mobile peer does not roam outside a single administrative domain consisting of a AAA infrastructure where all the AAA entities trust each other. We also assume that the functionality of EAP authentication server Nakhjiri et. al. EAP keying and handover support [Page 4] resides at the AAA server. The functionality of an EAP authenticator or a AAA NAS may or may not reside at a direct point of attachment. Base Station (BS) A network point of presence with layer-2/1 MAC/PHY capability towards the peer (acts as an AP), and layer-3 capability (IP) towards the backend infrastructure. EAP-method The EAP-based authentication method that is used during a full EAP authentication between the peer and the EAP server. EMSK (Extended Master Session Key) The Keying material that is derived between the EAP peer and server and exported by the EAP method. The EMSK is never shared with a third party. Derivation of EMSK is EAP-method dependent. MSK (Master Session Key) The Keying material that is derived between the EAP peer and server and is exported by the EAP method. Derivation of MSK is EAP-method dependent. Home AAA server (AAAH) The AAAH is a AAA server that operates in the home network. The home network is the network that holds the user record. 3. Key derivation overview As mentioned earlier, to avoid the security issues related to the key-sharing between the BSs, the initial master keying materials, such as AAA-key not be shared directly with each BS. Instead we suggest using a key specific to each point of attachment, we call BS master key (BSMSK). The key derivation example can be as follows AAA-Key = MSK (0,63) AMSK = KDF (EMSK, "EAP AAA-Key derivation for multiple attachments", length) BSMSK-A = prf (AMSK (0, 63),"EAP AAA-Key derivation for multiple attachments", AAA-Key, BS-A-Id, Peer-Id, length) BSMSK-B = prf (AMSK (0, 63),"EAP AAA-Key derivation for multiple attachments", AAA-Key, BS-B-Id, Peer-Id, length) Where: Peer-Id = Peer link address Nakhjiri et. al. EAP keying and handover support [Page 5] BS-A-Id = AP/BS A link address BS-B-Id = AP/BS B link address prf = HMAC-SHA1 KDF = can be defined according to the security policies length = length of derived key material As mentioned earlier the derivation of MSK and EMSK is method dependent. For example for EAP-TLS, MSK and EMSK are derived as follows MSK = TLS-PRF-64(TMS, "client EAP encryption", client.random || server.random) EMSK = second 64 octets of: TLS-PRF-128(TMS, "client EAP encryption", client.random || server.random) Where: TLS-PRF-X= TLS PRF function defined in [RFC2246] computed to X octets client.random = Nonce generated by the TLS client. server.random = Nonce generated by the TLS server. As shown from above, following the initial EAP authentication, the AAA key and BSMSK can be derived and the BSMSK is transported over to the BS to which the peer is attached to. Once the peer and the BS receive notification about the completion of the EAP authentication process and the transport of BSMSK to the BS, they can engage in a security association protocol, as described below. The security association protocol is typically controlled by the standard body defining the wireless link between the peer and the base station. In the following we provide a generic example of a security association protocol for illustration purposes: . After receiving the EAP success and receiving the BSMSK from the infrastructure, the BS sends a SAP-request to the peer, including a BSrandom (an unrepeated random nonce generated by the BS) and BS-ID (an identifier according to the specification of the L2 link between the peer and the BS). . The peer calculates BSMSK for the BS-ID, generates an MSrandom (an unrepeated random nonce generated by the MS) and calculates temporary session encryption keys (TSEK) and authentication keys (TSAK). The peer then generates a SAP-Response for the BS, including MSrandom, BSrandom, MSID, BSID and an HMAC signature using the calculated TSAK. . The BS calculates the TSAK, TSEK based on the received information from SAP-response from the peer, confirms the HMAC Nakhjiri et. al. EAP keying and handover support [Page 6] signature from the peer and if there is a match, it sends a SAP- confirm message back to the peer, including an HMAC of its own. The process above can include authenticated negotiations of TSEK and TSAK life times as well. The TSEK and TSAK for BS-A can for example be calculated as follows: TSEK-A = KDF (BSMSK-A,"Temporary Session Encryption Key derivation", BS-A-Id, Peer-Id, BSrandom, MSrandom, length), TSAK-A = KDF (BSMSK-A,"Temporary Session Message Authentication Key derivation", BS-A-Id, Peer-Id, BSrandom, MSrandom, length) The problem that this draft is tackling is how to lay out the authentication architecture so that the BSMSK delivered to the BS in time for security association protocol procedures. In the following we discuss various alternatives for this architecture. However, first we like to point a few issues that will possibly be common to most of the alternatives suggested below. 3.1 Key transport timing issues One issue with the framework defined in [EAPKEY6] is that, when a AAA client (EAP authenticator) acts as a pass-through, the timing of the EAP success sent to the authenticator relative to the timing of the AAA message carrying the BSMSK (in [EAPKEY6]: AAA-key) is not clear: . If the authenticator simply forwards the EAP success, received from the EAP server, to the peer without waiting for reception of the BSMSK from the EAP server, the subsequent security association protocol may fail, due to race conditions. . If on the other hand, the authenticator waits with forwarding of the EAP-Success to the peer, until it has received the BSMSK from the server, then the authenticator is not really acting as a pass-through. One simple solution to this problem is for the AAA/ EAP server to simply wait until it has successfully transmitted the BSMSK or AAA key to the authenticator and then send an EAP-Success to the authenticator. However, as we see below, some of the solutions proposed in this document assume that the BSMSK is transported from some entity other than the EAP server to the authenticator. In that case, more specific triggering/ notification procedures need to be used to prevent such race conditions. 3.2 Channel binding issues Nakhjiri et. al. EAP keying and handover support [Page 7] The EAP key management framework recommends the AAA-key scope to be defined by peer ID and authenticator ID, assuming that the peer ID is conveyed securely to the authenticator and the authenticator ID is conveyed securely to the peer. Beside the fact that the secure exchange of IDs may have practical implications, it seems that the binding needs to be known to the AAA server as well. Typically the peer may only know the authenticator ID that the authenticator uses over the link layer between the peer and the authenticator and this ID may be different from the ID (e.g. NAS ID or NAS IP) that the authenticator uses when communicating with the EAP/ AAA server. Extending the framework to distribute BSMSKs would require definition of scope for BSMSK. We recommend the BSMSK scope be defined between the peer and the BS, based on identifiers that are used over the peer-BS communication link. However, this may mean that these identifiers have to be transferred in a protected manner to whichever entity (AAA server/ LKDC/ EAP proxy) that is to generate BSMSK and define its scope. Using AAA protocols for this purpose would require specific channel-binding-attributes. It is not clear whether it is practical to inform the AAA servers about the BSMSKs and their scope, even in cases where the BSMSKs are generated outside the AAA/ EAP servers. 3.3 Life times The life time of BSMSK may need to be defined based on the link layer technology operator authorization policies. However, the life time of a BSMSK cannot be longer than that of the AAA-key, from which the BSMSK is derived. When the AAA server is not responsible for generation of BSMSK, the AAA server cannot be responsible for enforcement of BSMSK lifetime, either. In such cases, generic BSMSK life time policies may be stored at the AAA server and conveyed to the BS as well as the entity responsible for generation/ distribution of BSMSK in out-of-band manners. The key distribution entity would then be responsible for life time management and enforcement as well. The life time of AAA-key itself should be negotiated and communicated properly. It is stated that the root service SA, that is established as a result of the EAP-authentication and AAA-key transport, defines the AAA-key lifetime. However, [EAPKEY6] states that ææEAP does not support negotiation of key life time of exported or derived keysÆÆ. Furthermore, it is stated that ææto support the method-independence, key management of the exported or derived keys SHOULD NOT be provided within EAP methodsÆÆ. Except defining the maximum allowed life time for all the exported keys through the ææsession-timeoutÆÆ attribute, method-independent mechanisms for negotiation of AAA-key life time are not defined. Furthermore, a AAA attribute is required to transfer the key life time information to the authenticator. Nakhjiri et. al. EAP keying and handover support [Page 8] 4. Key distribution architecture alternatives 4.1 AAA server-based This alternative assumes that the BS acts as the Authenticator during the initial EAP authentication process (as shown in figure below), but does not receive the AAA-key from the authentication server. Instead the server calculates the BSMSK and sends it to the serving BS over a AAA protocol. |Pre-EAP: Long term credentials | |< ----------------------------------------- > | | No pre-EAP trust | Pre-EAP shared key | |< ----------------->|<----------------------> | | | +-+-+-+-+ L2 +-+-+-+-+-+ AAA +-+-+-+-+ | EAP |----------| BS |---------------|EAP AS | | Peer | | EAP Athr| BSMSK |AAAH | | | | NAS |< -------------| | +-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+ Figure 2a: Pre-existing trust relationships in a AAA-based key distribution model 4.1.1 Initial EAP authentication and key distribution The initial EAP authentication is performed between the EAP peer and the authentication server, using the BS (authenticator) as a pass- through. . Once the EAP authentication process between the EAP peer and Authentication server is complete, the server sends the BSMSK to the serving BS over a AAA message. The exact RADIUS/ Diameter attribute that carries the BSMSK over to the authenticator is to be defined. . Our recommendation is that, the authentication server waits with sending an EAP-Success to the authenticator until after the BSMSK is complete. . The authenticator forwards the EAP-Success to the EAP peer and either initiates the Security association protocol or waits for the peer for that initiation. Nakhjiri et. al. EAP keying and handover support [Page 9] EAP peer BS/ Authenticator Auth. Server -------- ------------- ---------- | | | |<----------------------------->|<--------------------------->| | EAP auth (pass through) | | | |<--------------------------->| | | BSMSK-Key transport | | |<--------------------------- | | | EAP success | |<----------------------------- | | | EAP Success | | |<----------------------------->| | | Secure association protocol | | Figure 2b: combined EAP authentication and key management during network entry 4.1.2 Handover As the peer determines the need for handover to a new BS, it can send a handover request to the new BS directly. The new BS then needs to inquire the proper keying material (BSMSK-N) from the Authentication server to start security association establishment with the peer. The main issue with this approach is that it inserts the BSMSK-fetch procedure in the handover timing critical path. Instead we recommend that the peer engages the current (serving) BS to start the handover security procedures as shown in the following figure. EAP peer old BS new BS Auth. Server -------- -------- -------- ------------ | | | | | HO-Key-request | RADIUS Access Request | |------------------>|---------------------------------------->| | | RADIUS Access Accept (E[BSMSK-N]) | | |<----------------------------------------| | | CTXP | | | |(E[BSMSK-N]) | | | |<--------- > | | | | HO-Key-Ack | | | HO-Key-Confirm |<---------- | | |< ---------------- | | | | Secure association protocol | | |<-----------------------------> | | | | | | Figure 2c: key material acquisition during handover Nakhjiri et. al. EAP keying and handover support [Page 10] . As the peer determines the need for handover to a new BS, or when it discovers a new BS (or a set of candidate BSs) as part of its scanning process, it can send a HO-Key-request to serving (old) BS to request the authentication server to create a BSMSK- N for the new BS. This message needs to include MSID and BSID for the new BS. If more than one new BS is involved, the messaging described hereon should support inclusion of information for more than one BS. . The old BS creates a AAA request (format TBD, e.g. RADIUS Access Request, or a RADIUS Authorization-only request) and includes the MSID and BSID for the BSs included in the message attributes (TBD) from the peer. The BS may also include additional BSIDs to this list based on its own databases on its neighbor BSs. . The authentication server looks up the entries for the peer based on the received MSID. If the server can verify that peer has performed the initial EAP authentication, created the keying material (MSK, EMSK, AAA-key), it check the validity of the keying material (life time not expired). The authentication server then examines the received BSIDs. If the server has security associations with BSs listed, or determines that it can establish security associations with these BSs, the server generates the BSMSK for any BS, whose BSID is included in the request. The reason for the latter restriction, is that the BSMSK for each BS must be encrypted with an encryption key (called AAA-BS key) that is only shared by the AAA server and that BS. This way the old serving BS, that receives the BSMSK, cannot extract the BSMSK for any other BSs. E[BSMSK] denotes an encrypted BSMSK. Once, the authentication server received confirmation about establishment of security association with the new BS (acquired AAA-BS key), the AAA server sends the (BSID, E[BSMSK]) pairs (in a TBD attribute) for each BSID in a AAA response (RADIUS Access Accept) to the old BS. The (BSID, E[BSMSK]) should also be signed by the AAA server by a key recognizable by the target BS. The BSMSK information may include life time information as well. . The old BS sends the signed (BSID, E[BSMSK]) pair to any BS that it can communicate with, possibly using a context transfer process (CXTP). . Once the CXTP is complete, the new BS receives the (BSID, E[BSMSK]), verifies the AAA server signature and decrypts the BSMSK, it is ready to engage in a security association procedure with the peer as the peer arrives. The new BS sends a HO-Key-Ack to the old BS. The new BS may opt to send HO-Key-Ack simply before verification of the keying material (due to timing constraints). . Upon receiving the HO-key-Ack from the new BS, the old BS sends a HO-Key-confirm message to the peer. . The peer can start the signaling of security association protocol with the new BS at this point. Nakhjiri et. al. EAP keying and handover support [Page 11] It should be noted that the process described above assumes that server-initiated messaging is not supported. If server-initiated messaging is supported (Diameter), the authentication server can simply send the BSMSK to the new BS, without the need for going through the old BS. 4.1.3 Pros and Cons This method has the following advantages: . Transport of EAP signaling over the link layer (EAP over L2 methods, such as EAPOL, PKMV2) and between the BS and AAA server (EAP over RADIUS or Diameter) is well defined. . The AAA-key does not leave the EAP/ AAA server or the peer. Only BSMSK that is bound to a specific (peer, BS) pair is shared with entities outside the initial authentication exchange. In case a BS is compromised, only the BSMSK for that BS is compromised. . Proactive and timely BSMSK acquisition signaling can reduce the delays related to handover security establishment significantly. . The AAA server can directly define BSMSK life time and send this information to the BS. . The AAA server is fully aware of the BSMSK key scope. The disadvantages of a AAA-based approach are as follow . Since the AAA server must create BSMSK for every new BS, to which the peer intends to connect to, the AAA server needs to be involved in every handover and this may increase the load on AAA server significantly. . The AAA server must store information on both AAA-key and BSMSK. . Acquisition of BSMSK in conjunction to handover requires accurate timing with other handover signaling. This typically is a tricky process. We suggested a procedure through which the new BS can acquire its keys through the old BS and based on a trigger provided by the mobile peer. In cases the old and new BS do not have a direct line of communication/ trust relationship, or the peer cannot provide adequate triggers, this may not be possible. That means the new BS needs to directly acquire the BSMSK for the peer from the server. Two approaches comes to mind: 1) The new BS can receive BSMSK regarding peers long in advance. The AAA server can deliver the BSMSK to several BSs at once. Since it is not practical for the AAA server to maintain groupings of BSs, it is possible that the serving BS during the initial authentication, requests BSMSKs for a number of neighbors. This can be potentially inefficient since the peer may never move to some BSs. 2) the new BS can directly place a request with the AAA server based on a trigger that it receives from the peer. Such triggers are only available when the peer is in the coverage area of the new BS and this is typically does Nakhjiri et. al. EAP keying and handover support [Page 12] not allow enough time for the roundtrip to the AAA server for acquisition of the BSMSK. . The AAA server must be aware of the identifiers the peer and the BS use over the L2 link (peer-ID and BS-ID). This may require additional complexity to the AAA infrastructure data base, in case the peer and BS are using other types of identity (such as NAI or IP addresses) towards the AAA server. For peers capable of multiple technologies and thereby multiple L2 identifiers, this problem may become even more complicated. 4.2 Local Key distribution Center According to this alternative, the peer will perform an EAP authentication through a BS acting as EAP authenticator and AAA NAS. The peer and EAP/AAA server both generate the EAP MSK/EMSK and AAA- key as described previously. However, the EAP key management procedure is modified slightly: +-+-+-+-+-+ AAA-key | LKDC |<------- +-+-+-+-+-+ \ | \ |BSMSK \ V \ +-+-+-+-+ L2 +-+-+-+-+-+ AAA --+-+-+-+-+ | EAP |----------| BS |---------------|EAP AS | | Peer | | EAP Athr| |AAAH | | | | NAS | | | +-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+ Figure 3a: Key distribution architecture using LKDC . The EAP server forwards the AAA-key to a local key distribution center (LKDC) instead of to the BS/ authenticator. . The EAP server is no longer involved in generation of BSMSK from the AAA-key. . The LKDC will instead calculate the BSMSK from the received AAA- key and send the BSMSK over a secure link to the BS/ authenticator. Each BS receives its keying material from only one LKDC (or two for failover support). The BS can be configured with the identity of the LKDC for which it receives its keying material from and the trust relationship that it needs to use when communicating with LKDC. . To simplify the AAA server architecture, it is not required of the AAA server to store the LKDC-BS mappings. This information can be provided during the EAP key management procedure, but using AAA signaling. The AAA server is however required to have a trust relationship and security association with the LKDC so Nakhjiri et. al. EAP keying and handover support [Page 13] it can communicate with the LKDC securely (to send the AAA-key for instance). . Also note that the LKDCs may have trust relationship with different AAA servers if required to support roaming. - AAA1- AAA2 / | \/ / | /\ / | / \ / |/ \ LKDC1 LKDC2 LKDC3 / | \ / \ /| \ / | \ / \ / | \ NAS1 NAS2 NAS3 Figure 3b: Relationships between LKDC and other AAA entities An important note is due: the LKDC is an off-path entity for EAP authentication process. The serving BS still acts as an EAP authenticator during EAP authentication and as a AAA NAS for access control procedures, which means that the BS needs to have a direct security association (such as RADIUS shared secret) with the AAA server. The LKDC only comes in the process when it is time for distribution of BSMSK to the BSs as described below. 4.2.1 Initial authentication The initial authentication is performed as follows: . The EAP peer starts the EAP authentication with the EAP server through the serving BS that acts as an EAP authenticator and AAA client. . Once the EAP authentication is complete, the BS and the peer receive EAP success indications. . The EAP server now needs to send the AAA-key to the LKDC (not to the authenticator) over a secure link. However the EAP server needs to know the address and identity of the LKDC first. There are two alternatives solutions for this problem: . In a Diameter infrastructure or a RADIUS infrastructure where server-initiated messaging is possible, the NAS simply needs to include the identity of the LKDC in a AAA message (TBD message) while the EAP authentication for the peer is being completed. When the server completes the authentication, it can proactively send the AAA-key to the LKDC. . In a typical RADIUS infrastructure, where server-initiated messaging is not possible, the LKDC can acquire the AAA-key from the RADIUS server based on a request-accept exchange, started by the LKDC (as shown the figure above). The trigger for this process can be provided by the NAS (shown as ææEAP Success notificationÆÆ in the figure). Nakhjiri et. al. EAP keying and handover support [Page 14] EAP peer BS/Authen AAA server LKDC -------- ----------- ------------ ---------- | | | | |<------------------->|<------------->| | |EAP auth | AAA pass-thru | | | | | | |<------------------- |<------------- | | | EAP success | EAP success | | | |----------------------------------> | | | EAP Success notification | | | | <---------------- | | | | AAA-Key request | | | | ----------------> | | | | AAA-Key transport | | |<--------------------------------- | | <------------------ | BSMSK transport | |SAP trigger/1 st msg | | | |<------------------> | | | | SA protocol | | | Figure 3c: EAP authentication and key distribution using LKDC Channel binding and key scope issues Since the AAA-key is not known to the authenticator, it should not be bound to the authenticator either. The AAA-key scope in this case should be defined by (peer ID, LKDC ID) pair, rather than (peer ID, authenticator ID) pair. The identifiers are as understood by AAA infrastructure. However, the peer does not and need not know the identifier of the LKDC, since the peer does not have any direct contact with the LKDC. If the peer is required to store the scope for the AAA-key, it needs to receive the LKDC ID from the EAP/ AAA server. In that case the LKDC ID needs to be communicated with EAP signaling (since the peer has no AAA functionality) to the peer and possibly through secure EAP method signaling. The AAA server controls the scope of AAA-key and hence needs to know the LKDC ID through signaling from NAS. The AAA messaging and attributes for this purpose needs to be defined. The BSMSK scope on the other hand should be defined by (peer ID, BS ID, LKDC ID) triplets. The LKDC ID and BS ID needs to be send to the peer in an authenticated manner within the EAP method or as part of secure association protocol signaling. The alternative would be to base the BSMSK scope on (peer ID, BS ID) pairs to allow the use of link-specific methods. The suitability of each method needs to be further studied. In either case, it is not practical for the EAP server/ AAA server to store information on BSMSK, so this information will be stored at the LKDC. Nakhjiri et. al. EAP keying and handover support [Page 15] 4.2.2 Handover An example of a handover signaling is shown below. . To expedite the handover process, we suggest that the peer sends a trigger for new BSMSK acquisition to the old BS, which in turn forwards the request to the LKDC. . If the new BS is within the region controlled by LKDC (which also means the LKDC and new BS have a trust relationship and encryption/ authentication keys established), the LKDC can simply send the BSMSK-N for the new BS directly to the new BS. . If the new BS is outside the LKDC control, the old LKDC must locate the new LKDC for the new BS and if an ææold LKDC-new LKDCÆÆ trust relationship exists, send the AAA key and related information (e.g. life time) over the new LKDC. The new LKDC will then calculate the new BSMSK for the new BS and holds the AAA-key for future use. All this assumes that the old LKDC can locate the new LKDC based on the new BS information provided by the old BS. This is not an unreasonable assumption given that the LKDC is aware of mobility topology and should be aware of its neighbor LKDCs. . If the old LKDC cannot find the new LKDC, or the new LKDC and old LKDC do share a trust relationship, or sharing AAA-key is against AAA policies, the BSMSK request needs to be referred to the AAA server (procedure not included here). . Once the new BS receives the BSMSK (in encrypted form) and extract the key, it can send a notification to the old BS, which in turn forwards a similar notification to the peer. . Upon receiving the notification, the peer can engage in security association procedure with the new BS. Note that the peer may not be able to wait for such notifications. In such cases the delay associated with the new BS response to the security association procedure initiated by the peer cannot be predicted easily. EAP peer old BS new BS LKDC -------- -------- -------- ------------ | | | | | HO-Key-request | BSMSK Request | |------------------>|------------------------------------>| | | | BSMSK (E[BSMSK-N]) | | | BSMSK-Ack |<----------------------| | HO-Key-Confirm |< -----------| | |< ---------------- | | | | Secure association protocol | | |<-----------------------------> | | | | | | Figure 3d: Handover key distribution using LKDC Nakhjiri et. al. EAP keying and handover support [Page 16] 4.2.3 Pros and Cons The advantages of this model are as follows: . The AAA/ EAP server is off-loaded from having to generate BS- specific keys for a large number of BSs and being involved in every inter-BS handover. . The AAA-key is not revealed to possibly physically insecure BSs. . The initial EAP authentication is performed in a typical way with the first hop network device (BS) acting as an EAP authenticator as well as a AAA client. This would mean EAP can be run over the L2 link directly. . It is possible to co-locate LKDCs with mobility management entities or make the LKDCs aware of the mobility patterns or BS- neighbor lists. This way the LKDC can proactively send BSMSKs to BSs in the vicinity of the serving BS. . When the BSMSK acquisition is performed based on requests by old or new BS, the BS-LKDC roundtrip can be expected to be much shorter than the BS-AAA server roundtrip. Disadvantages . The need for secure backhaul communication protocol between the BS and the LKDC. . Depending on the implementation, the AAA server may not be able to enforce control over the usage of AAA-key by LKDC. For instance, the lifetime of BSMSK based on the parent AAA-key is not controlled directly by the AAA server. This control may be enforced by including life time information in the calculation of BSMSK or by separate authorization signaling performed with the NAS using a AAA protocol. . The timing of EAP-success and acquisition of BSMSK by BS from LKDC may create race conditions for start of secure association protocol. Specific triggers may be required for this process. . Inter-LKDC handovers may still require consultation to the AAA- server. 4.3 EAP Proxy approach (multi-hop peer-NAS link) In this approach, the EAP authenticator and AAA client (NAS) functionality does not reside at the same physical box as the BS. Instead the BS simply acts as an ææEAP proxyÆÆ forwarding EAP messaging from the peer to the NAS. On the peer side, the BS must encapsulate the EAP messaging inside the link layer protocol, while on the NAS side, the BS must encapsulate the EAP messaging into the protocol between BS and NAS (possibly a deployment specific protocol). The EAP will run between the peer and the server transparent to the existence of the EAP proxy. Nakhjiri et. al. EAP keying and handover support [Page 17] 4.3.1 Initial authentication . Initial authentication is performed in a manner similar to the AAA-based approach described earlier. However, in order to allow for control of AAA-key and BSMSK scope and life time, the NAS may have to obtain and include two sets of identifiers for peer and BS as AAA protocol attributes or EAP attributes. The two sets of identifiers are: L2 ID, (such as MAC address) for peer and BS, and ID as specified at the AAA server database (NAI or other ID). . Once the authentication is complete, the AAA server sends the AAA-key to the NAS, which in turn calculates the BSMSK for the BS and sends it over to the BS. . The AAA server will send an EAP success towards the peer. The AAA server should send the EAP success after it transmitted the AAA-key to the NAS. Ideally the EAP peer should receive the EAP success as a trigger to start the Secure association protocol. This in turn means the NAS should wait until it creates the BSMSK for the BS before passing the EAP success along to the BS for forwarding the peer. However, this may not always be possible, so the peer may have to wait for a more explicit trigger for start of secure association protocol. The timing of EAP success should be further studied. EAP peer BS/ EAP Proxy NAS Auth. Server ------- ------------- --- ---------- | | | | |<----------------->|<----------->|<------------------->| | EAP auth/L2 | EAP/TBD | EAP/AAA pass-thru | | | pass-thru | | | | |<------------------- | | | | AAA-Key transport | | | |<------------------- | | | | EAP Success | | |<------------| | | | BSMSK trans.| | |<--------------------------------| | | EAP success | | |< ------------ > | | | | SA protocol | | | Figure 4a: EAP authentication and key management using an EAP proxy. Channel Binding and key scope issues Again, the scope of the BSMSK and AAA-keys should be different. The AAA-key scope should be based on (peer ID, NAS ID) pair. The peer may need to receive the NAS ID from the authentication server in a secure manner and as part of EAP signaling. The BSMSK scope Nakhjiri et. al. EAP keying and handover support [Page 18] should be based on (peer ID, BS ID, NAS ID) triplets. The authentication server should not be kept aware of the BSMSK scope. 4.3.2 Handover The new BS needs to acquire its BSMSK from a NAS that holds the AAA key in manner similar to that of the LKDC approach. No EAP signaling is required during handover. No signaling with the AAA server is required as long as both BS are served by the same NAS, or two NASes that can share AAA-keys (as explained for LKDC approach). When the two BSs do not share an LKDC, the same complications as those described for LKDC case will arise and very similar approaches can be used to resolve the issues. EAP peer old BS new BS NAS -------- -------- -------- ------------ | | | | | HO-Key-request | BSMSK Request | |------------------>|------------------------------------>| | | | BSMSK (E[BSMSK-N]) | | | BSMSK-Ack |<----------------------| | HO-Key-Confirm |< -----------| | |< ---------------- | | | | Secure association protocol | | |<-----------------------------> | | | | | | Figure 4b: Handover key distribution with EAP proxy approach. 4.3.3 Pros and Cons Advantages . The AAA/ EAP server is off loaded from having to generate BS- specific keys for a large number of BSs and being involved in every inter-BS handover. . The AAA-key is not revealed to possibly physically insecure BSs. . No EAP authenticator or AAA client functionality is required from the BS. Disadvantages . The BS has to perform EAP encapsulation protocol translation from EAP over L2 to EAP over a TBD protocol. Since the TBD protocol is being used instead of a AAA protocol to carry EAP messaging, the TBD protocol must provide security mechanisms equivalent to those provided by the AAA protocol. Furthermore, the TBD protocol may be deployment- or access technology specific, and this can cause interoperability issues for NASes that need to support BS from different manufacturers/ operators or access technologies. . The AAA server cannot become aware of the existence or identity of the BS, as the BS simply acts as a proxy behind the EAP Nakhjiri et. al. EAP keying and handover support [Page 19] authenticator, unless the BS information is explicitly provided to the AAA server by the NAS. . The AAA server may not be able to control the binding, scope or life time of BSMSKs. . The timing of EAP-success and acquisition of BSMSK by BS from EAP proxy may create race conditions for start of secure association protocol. Specific triggers may be required for this process. 4.4 AAA-proxy approach The final approach is to use a AAA proxy between the AAA server and the authenticator. The AAA server will send the AAA-key to the AAA proxy (instead of to the authenticator). The function of AAA proxy for creation of BSMSK for each base station during initial authentication and handover is as described for LKDC in the previous step. EAP BS/EAP Auth AAA Authentication peer /NAS proxy Server ---- ---------- ------- ---------- | | | | |<------------->|<---------------->|<------------------->| | EAP auth (phase 1a) AAA pass-through | | | | | | | |<------------------- | | | | AAA-key trans | | |<---------------- | | | | BSMSK transport | | | |----------------> | | | | BSMSK confirm | ------------------> | | | | key trans. confirm | |<------------- |<---------------- |<------------------- | | | | EAP Success | |<------------->| | | | Secure assoc.| | | | protocol | | | Figure 5a: EAP authentication and key management using AAA proxies. Channel binding and scope issues The issues are similar to those described earlier. 4.4.1 Handover procedure Nakhjiri et. al. EAP keying and handover support [Page 20] As seen in the figure below, the AAA proxy function during handover is exactly the same as the LKDC. EAP peer old BS new BS AAA proxy -------- -------- -------- ------------ | | | | | HO-Key-request | BSMSK Request | |------------------>|------------------------------------>| | | | BSMSK (E[BSMSK-N]) | | | BSMSK-Ack |<----------------------| | HO-Key-Confirm |< -----------| | |< ---------------- | | | | Secure association protocol | | |<-----------------------------> | | | | | | Figure 5b: Handover key distribution with AAA proxies. The AAA proxy will have to have key generation and distribution capabilities in addition to the traditional functionalities defined for AAA proxies. The list of pros and cons is otherwise similar to that for LKDC approach. 5. Security considerations Most of the security issues are discussed while providing each of the solution alternatives. Among the most important issues are: . Transport of AAA-key or BSMSK through AAA protocols is not well- specified yet. AAA messages and attributes need to be investigated for this purpose. . Definition of scope, naming, and life time for AAA-key and BSMSK needs to be investigated further. . Synchronization between EAP-Success and AAA messaging that carries keying material needs to be examined further. 6. References [EAPKEY6] B. Aboba, Et. Al., ææExtensible Authentication Protocol (EAP) Key Management FrameworkÆÆ, Internet Draft, IETF, draft-ietf- eap-keying-06 (work in progress), April 2005. [EAPKEY5] B. Aboba, Et. Al., ææExtensible Authentication Protocol (EAP) Key Management FrameworkÆÆ, Internet Draft, IETF work in progress, draft-ietf-eap-keying-05, February 2005. Nakhjiri et. al. EAP keying and handover support [Page 21] [EAPEXT], B. Aboba, ææExtensible Authentication Protocol (EAP) Key Management ExtensionsÆÆ, Internet Draft, IETF work in progress, draft- aboba-eap-keying-extens-00, April 2005. [EAP3748], B. Aboba, Et. Al., ææExtensible Authentication Protocol (EAP)ÆÆ, RFC 3748, IETF, June 2004. [RADEAP3579], B. Aboba, P. Calhoun, ææRADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)ÆÆ, RFC 3579, IETF, September 2003. [MOBTERM3753], J. Manner, M. Kojo, ææMobility Related TerminologyÆÆ, RFC 3753, IETF, June 2004. Acknowledgments . Author's Addresses Madjid Nakhjiri Motorola Labs Contact Email: Madjid.Nakhjiri@motorola.com 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. Nakhjiri et. al. EAP keying and handover support [Page 22] 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 (2005). 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. This Internet-Draft will expire January 2006. Nakhjiri et. al. EAP keying and handover support [Page 23]