[IEEE 2007 IEEE Globecom Workshops - Washington, DC, USA (2007.11.26-2007.11.30)] 2007 IEEE Globecom Workshops - UMTS-AKA and EAP-AKA Inter-working for Fast Handovers in All-IP Networks

Download [IEEE 2007 IEEE Globecom Workshops - Washington, DC, USA (2007.11.26-2007.11.30)] 2007 IEEE Globecom Workshops - UMTS-AKA and EAP-AKA Inter-working for Fast Handovers in All-IP Networks

Post on 06-Mar-2017

213 views

Category:

Documents

1 download

Embed Size (px)

TRANSCRIPT

<ul><li><p>UMTS-AKA and EAP-AKA Inter-working for Fast Handovers in All-IP Networks </p><p>M.S Bargh, R.J. Hulsebosch and E.H. Eertink Telematica Instituut </p><p>Enschede, The Netherlands </p><p>J. Laganier, A. Zugenmaier and A.R. Prasad DoCoMo Communications Labs Europe GmbH </p><p>Munich, Germany </p><p>Abstract3GPP Service Architecture Evolution (SAE) / Long Term Evolution (LTE) activity sets the requirement of provisioning secure and seamless handover. In handover, however, key management (i.e., key derivation and key transfer) and mutual authentication form a significant source of latency. Together with the seamlessness requirement 3GPP also requires the reuse of Universal Subscriber Identity Module (USIM) and the existing authentication and key management procedure or Authentication and Key Agreement (AKA). </p><p>In this paper we consider UMTS-AKA and Extensible Authentication Protocol-AKA (EAP-AKA) as the two USIM-based authentication and key management protocols. We propose an architecture that can be used in SAE/LTE for efficient inter-working between UMTS-AKA and EAP-AKA during handover. Efficient inter-working here translates to avoiding signaling with the home domain during handover. Our focus is on the top-level key management aspect and we do not address derivation of child keys. Our solution speeds up handover signaling by one Round Trip Time (RTT) to the home domain. We investigate also the relevance of key hierarchy solutions proposed in IETF for speeding up re-authentications. </p><p>Keywords- key management, seamless handovers, security, wireless networks, IP. </p><p>I. INTRODUCTION Generation Partnership Project (3GPP) standardization </p><p>body is developing specifications for next generation mobile communication systems under its System Architecture Evolution (SAE) / Long Term Evolution (LTE) activity [1]. The SAE/LTE architecture aims at integrating multiple wireless network technologies to deliver secure services to users. A key requirement for such integration of wireless network technologies is to support seamless handovers between these technologies without adversely affecting the security. During a handover it is desired by the user to continue receiving the service seamlessly. This requires the overall handover latency to be contained within 50ms [2] and TR25.932-[1]. Unfortunately, the vast majority of the handovers do not currently meet this goal due to the latencies associated with, for example, signaling, authentication, and reconfiguration overhead [3]. </p><p>The delay associated with the process of mutual authentication of mobile-devices and network and with key management, i.e., keying material establishment and distribution contributes significantly to the total handover </p><p>latency when switching between wireless network technologies and domains. The process enables mutual authentication of the mobile device and target network, handover authorization, as well as keying material establishment and distribution. The keying material is then used to secure subsequent communications. </p><p>There are many protocols for realizing the process of network authentication and key distribution, which are often specific to the wireless network technology. It is required for SAE/LTE to have a security level at least the same as that of Universal Mobile Telecommunications System (UMTS) and it is required to base the security protocols on Universal Subscriber Identity Module (USIM) TR23.882-[1]. There are two main USIM based protocols for authentication and key management, namely: UMTS Authentication and Key Agreement (AKA), specified in TS33.102-[1], and Extensible Authentication Protocol (EAP) AKA (EAP-AKA, specified in RFC4187-[4]). UMTS-AKA is the protocol adopted by 3GPP for UMTS and is seriously considered for LTE [12]. EAP-AKA, which uses the AKA protocol of UMTS as the authentication method on top of the generic EAP framework, can be used for accessing a vast variety of wireless networks like Wi-Fi (IEEE 802.11) and WiMAX (IEEE 802.16). Having a fast EAP-AKA requires using an efficient handover key management solution. Such a solution is being specified in the Internet Engineering Task Force (IETF) Handover Keying (HOKEY) Working Group (WG) [4]. HOKEY intends to make home server authentication obsolete by defining a key hierarchy in visited domains. </p><p>In this contribution we aim at accelerating the mutual authentication and key management process for handovers between two environments that are based on UMTS-AKA and EAP-AKA. Example handover scenarios include handover from Wi-Fi to UMTS and vice versa. Our objective is to eliminate signaling to the home domain when a User Equipment (UE) roams between UMTS-AKA and EAP-AKA environments in a foreign domain. Moreover, in case of EAP-AKA, we aim at reducing the number of referrals to the EAP-server that executes the full AKA method. The latter objective requires integrating AKA-based solutions with HOKEY solutions. We identify two possible solutions and indicate their impacts on the SAE/LTE architecture. </p><p>The rest of this paper is organized as follows. Section II presents an overview of SAE/LTE and its requirements on secure handover. Section III gives an overview of the relevant </p></li><li><p>protocols for network access authentication. Section IV proposes solutions for inter-working between the existing solutions and their impacts on the SAE/LTE architecture. Finally, Section V draws some conclusions and outlines future directions. </p><p>II. SAE/LTE SYSTEM OVERVIEW 3GPP is developing the specifications of next generation </p><p>wireless networks within its SAE/LTE activities. An overview of SAE/LTE is given in this section, for detail see [6-19]. </p><p>A. Scope LTE specifies the Evolved UMTS Terrestrial Radio Access </p><p>(E-UTRA) and Evolved UMTS Terrestrial Radio Access Network (E-UTRAN). It is expected that in LTE there will be support for (1) shared networks during mobility and initial access, (2) various cell sizes and planned or ad-hoc deployments, and (3) efficient mobility with an intra-LTE handover interruption time of 30ms [6]. LTE will provide data rates up to 100 Mbps with end-to-end Quality of Service (QoS) support to ensure that the Voice over IP (VoIP) latency is no more than that of the voice traffic over Circuit Switched (CS) UMTS. </p><p>The SAE activity focuses on enhancing the 3GPP core network to cope with the growth in IP traffic. The enhancement includes reduced latency, higher data rates, improved capacity and coverage, and reduced cost for the operator. From the 3GPP core network based services will be provided through various access technologies together with mechanisms to support seamless mobility between them [18]. </p><p>B. Architecture In the LTE architecture, the enhanced NodeBs (eNBs) are </p><p>interconnected by X2 interfaces and to the Evolved Packet Core (EPC), i.e., the SAE architecture, by the S1 interface [6]. The EPC includes the Mobility Management Entity (MME) and User Plane Entity (UPE), see Figure 1. </p><p>eNB eNB </p><p>eNB </p><p>MME/UPE MME/UPE </p><p>S1 </p><p>X2 </p><p>X2 </p><p>X2 </p><p>SAE </p><p>LTE </p><p>Figure 1. LTE architecture. </p><p>The LTE architecture differentiates between User plane (U-plane) and Control plane (C-plane). The eNB hosts the radio resource management unit that includes the connection mobility control. </p><p>The SAE architecture for non-roaming case is given in Figure 2. The MME in Figure 2 provides Non Access Stratum (NAS) signaling, NAS security, and inter core-network-node </p><p>signaling for mobility between 3GPP access networks, etc. The Serving Gateway (or UPE) is the interface towards E-UTRAN with the function of the Local Mobility Anchor (LMA) point for inter-eNB handover, mobility anchoring for inter-3GPP mobility, packet routing and forwarding, etc. The functions of the Public Data Network (PDN) Gateway include amongst others policy enforcement, per-user packet filtering, charging support, and IP-address allocation. 3GPP decided to proceed with two specifications for SAE; one that is based on the existing mobility management protocol for packet communications, i.e., the GPRS Tunneling Protocol (GTP) [14], and the other based on IETF protocols [15]. SAE architectural principles are described in [8] and [19]. </p><p> Trusted/Untrusted* </p><p> Non-3GPP IP Access or 3GPP Access </p><p>SGi </p><p>PCRF </p><p>S7 </p><p>S6a </p><p>HSS </p><p>ePDG </p><p>S2b </p><p>Serving Gateway </p><p>Wn* </p><p>3GPP AAA Server </p><p>Operators IP Services </p><p>(e.g. IMS, PSS etc.) </p><p>Wm*</p><p>Wx*</p><p>Untrusted Non-3GPP IP </p><p>Access</p><p>Trusted Non-3GPP IP </p><p>AccessWa*</p><p>Ta*</p><p>HPLMN </p><p>Non-3GPP Networks </p><p>S1-U </p><p>S1-MME</p><p>EUTRAN</p><p>2G/3G SGSN </p><p>S4 </p><p>S3 </p><p>S5 S6c </p><p>Rx+ </p><p>S2a </p><p>PDN Gateway </p><p>MME S11</p><p>S10</p><p>UE</p><p>S2c </p><p>* Untrusted non-3GPP access requires ePDG in the data </p><p>Figure 2. Non-roaming architecture for SAE. </p><p>C. Security and Seamless Handovers in SAE/LTE In terms of security [12-13], NAS signaling requires </p><p>confidentiality and integrity protection. U-plane must be confidentiality protected (between UE and eNB), while the necessity of integrity protection is still under study. For Access Stratum (AS) signaling: Medium Access Control (MAC) security and requirement for confidentiality protection of Radio Resource Control (RRC) signaling are yet to be studied, while integrity protection of RRC is required. </p><p>SAE will support mobility between heterogeneous wireless networks with service continuity in Packet Switched (PS) domains while maintaining the same capabilities of access control (i.e., authentication and authorization), privacy, and charging between different technologies [6-8]. A few principles regarding security and mobility in SAE are: </p><p> Subscriber security procedures in SAE/LTE shall assure at least the same level of UMTS security; </p><p> Access to the network should be possible using the Release 99 USIM; </p><p> Authentication framework should be independent of the wireless network technology; </p><p> Mobility management should not degrade security. </p></li><li><p>Thus USIM will be used in SAE/LTE and it is agreed to use AKA. For AKA there are two methods: UMTS-AKA and EAP-AKA. Some access technologies make use of EAP-AKA (like Wi-Fi) while others utilize UMTS-AKA, like LTE. So there is a challenge regarding efficient inter-work during handover between technologies supporting UMTS-AKA and EAP-AKA. Efficient inter-working means being fast (to support seamless handovers), which in turn means avoiding the necessity to communicate with the home network to establish and distribute keying material. </p><p>III. NETWORK AUTHENTICATION OVERVIEW This section provides an overview of the related protocols </p><p>and explains their core functionality relevant to the scope of this paper. </p><p>A. UMTS-AKA The security architecture of 3G UMTS is specified in [20]. </p><p>Main features that are defined for providing secure network access are: user identity confidentiality, user authentication, network authentication, confidentiality of user data, confidentiality of signaling data, and integrity and origin authentication of signaling data. </p><p>UMTS-AKA is a mechanism which allows mutual authentication of the UE and visited network, and establishment of a secret Cipher Key (CK) and an Integrity Key (IK) between UE and Serving GPRS Support Node (SGSN) in the visited network. It is based on a long-term pre-shared secret key k available only to the USIM and the Home Subscriber Server (HSS) in the users home environment. UMTS-AKA message sequence in a visited network is shown in Figure 3, where SGSN is replaced by MME. </p><p> UE RAN CN-visited CN-homeHSSeNodeB MME</p><p>AV[i]: i=1, , n</p><p>using AV[i+1]</p><p>CK[i], IK[i]</p><p>new MMEa handoverwith MME relocation</p><p>CK[i+1], IK[i+1]</p><p>context transfer AV[j], j=i+1,...,n</p><p>(0) Service req.</p><p>(1) Authentication data req.</p><p>using AV[i] for the i-thservice req. </p><p>using AV[1]</p><p>(3) User authentication req.</p><p>(4) User authentication res.</p><p>(5) Security mode command</p><p>(2) Authentication data res.</p><p>CK[1], IK[1]</p><p>k k</p><p>UE RAN CN-visited CN-homeHSSeNodeB MME</p><p>AV[i]: i=1, , n</p><p>using AV[i+1]</p><p>CK[i], IK[i]</p><p>new MMEa handoverwith MME relocation</p><p>CK[i+1], IK[i+1]</p><p>context transfer AV[j], j=i+1,...,n</p><p>(0) Service req.</p><p>(1) Authentication data req.</p><p>using AV[i] for the i-thservice req. </p><p>using AV[1]</p><p>(3) User authentication req.</p><p>(4) User authentication res.</p><p>(5) Security mode command</p><p>(2) Authentication data res.</p><p>CK[1], IK[1]</p><p>k k</p><p>Figure 3. UMTS-AKA message sequence diagram. </p><p>As shown in Figure 3, the first authentication transaction result in transferring a number of Authentication Vectors (AVs) from the HSS to the serving MME. Each AV includes a pair of CA and IK as well as some other parameters. A serving MME uses a fresh AV every time authentication is requested or after the lifetime of the current CK and IK is expired. If MME changes due to handover, the serving MME may transfer the unused AVs to the target MME, thus avoiding one RTT to the HSS in the authentication latency. </p><p>B. EAP-AKA 3GPP has also obtained publication by the IETF of the </p><p>EAP-AKA method for authentication and session key management [21]. EAP-AKA allows the usage of AKA over the EAP protocol, which in turn can be carried on diverse types of link layers (e.g. 802.11). This allows USIM-based authentication and key management between an UE and a non-3GPP access network such as Wi-Fi. EAP-AKA protocol entities and steps are shown in Figure 4. </p><p> UE RAN CN-visited CN-homeHSSAuthenticator EAP-server</p><p>AV</p><p>new Authenticator</p><p>a handoverwith Authenticator change</p><p>(0) EAP req. Identity</p><p>(1) Authentication data req.</p><p>EAP-AKA Re-authenticationusing the same MK and thus the same AV</p><p>using AV</p><p>(3) EAP-req AKA Challenge</p><p>(5) EAP Success</p><p>(2) Authentication data res.</p><p>MSK1</p><p>k kUSIM</p><p>(0) EAP res. Identity</p><p>(4) EAP-res AKA Challenge</p><p>using CK and AKMKMK</p><p>MSKi</p><p>(3) EAP-req AKA Re-Authentication</p><p>(4) EAP-res AKA Re-Authentication</p><p>EAP-AKA Re-authenticationusing the same MK and thus the same AVMSKi+1</p><p>UE RAN CN-visited CN-home</p><p>HSSAuthenticator EAP-server</p><p>AV</p><p>new Authenticator</p><p>a handoverwith Authenticator change</p><p>(0) EAP req. Identity</p><p>(1) Authentication data req.</p><p>EAP-AKA Re-authenticationusing the same MK and thus the same AV</p><p>using AV</p><p>(3) EAP-req AKA Challenge</p><p>(5) EAP Success</p><p>(2) Authentication data res.</p><p>MSK1</p><p>k kUSIM</p><p>(0) EAP res. Identity</p><p>(4) EAP-res AKA Challenge</p><p>using CK and AKMKMK</p><p>MSKi</p><p>(3) EAP-req AKA Re-Authentication</p><p>(4) EAP-res AKA Re-Authentication</p><p>EAP-AKA Re-authenticationusing the same MK and thus the same AVMSKi+1 </p><p>Figure 4. EAP-AKA message sequence diagram. </p><p>In EAP-AKA, the UE mutually authenticates with an EAP-server located at the network side. On successful mutual authentication, both derive CK and IK which are subsequently used to derive the EAP Master Key (MK), from which the EAP Master Session Key (MSK) is derived. The MSK is pushed to the Authenticator (e.g., Access Point (AP)) and used to protect further communications. Figure 4 also illustrates the EAP-AKA re-authentication process which allows derivation of a new MSK from the MK upon handover or when the MSK lifetime is exceeded. This process does not use the AKA method to derive the new MSK and thereby saves a round trip to the home network with respect to the full AKA method. Figure 4 shows a typical deployment where the EAP-server is located in the visited doma...</p></li></ul>

Recommended

View more >