UMTS-AKA and EAP-AKA Inter-working for Fast Handovers in All-IP Networks

M.S Bargh, R.J. Hulsebosch and E.H. Eertink Telematica Instituut

Enschede, The Netherlands

J. Laganier, A. Zugenmaier and A.R. Prasad DoCoMo Communications Labs Europe GmbH

Munich, Germany

Abstract—3GPP 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).

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.

Keywords- key management, seamless handovers, security, wireless networks, IP.

I. INTRODUCTION Generation Partnership Project (3GPP) standardization

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].

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

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.

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.

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.

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

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.

II. SAE/LTE SYSTEM OVERVIEW 3GPP is developing the specifications of next generation

wireless networks within its SAE/LTE activities. An overview of SAE/LTE is given in this section, for detail see [6-19].

A. Scope LTE specifies the Evolved UMTS Terrestrial Radio Access

(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.

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].

B. Architecture In the LTE architecture, the enhanced NodeBs (eNBs) are

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.

eNB eNB

eNB

MME/UPE MME/UPE

S1

X2

X2

X2

SAE

LTE

Figure 1. LTE architecture.

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.

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

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].

Trusted/Untrusted*

Non-3GPP IP Access or 3GPP Access

SGi

PCRF

S7

S6a

HSS

ePDG

S2b

Serving Gateway

Wn*

3GPP AAA Server

Operator’s IP Services

(e.g. IMS, PSS etc.)

Wm*

Wx*

Untrusted Non-3GPP IP

Access

Trusted Non-3GPP IP

AccessWa*

Ta*

HPLMN

Non-3GPP Networks

S1-U

S1-MME

EUTRAN

2G/3G SGSN

S4

S3

S5 S6c

Rx+

S2a

PDN Gateway

MME S11

S10

UE

S2c

* Untrusted non-3GPP access requires ePDG in the data

Figure 2. Non-roaming architecture for SAE.

C. Security and Seamless Handovers in SAE/LTE In terms of security [12-13], NAS signaling requires

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.

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:

• Subscriber security procedures in SAE/LTE shall assure at least the same level of UMTS security;

• Access to the network should be possible using the Release 99 USIM;

• Authentication framework should be independent of the wireless network technology;

• Mobility management should not degrade security.

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.

III. NETWORK AUTHENTICATION OVERVIEW This section provides an overview of the related protocols

and explains their core functionality relevant to the scope of this paper.

A. UMTS-AKA The security architecture of 3G UMTS is specified in [20].

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.

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 user’s home environment. UMTS-AKA message sequence in a visited network is shown in Figure 3, where SGSN is replaced by MME.

UE RAN CN-visited CN-homeHSSeNodeB MME

AV[i]: i=1, …, n

using AV[i+1]

CK[i], IK[i]

new MMEa handoverwith MME relocation

CK[i+1], IK[i+1]

context transfer AV[j], j=i+1,...,n

(0) Service req.

(1) Authentication data req.

using AV[i] for the i-thservice req.

using AV[1]

(3) User authentication req.

(4) User authentication res.

(5) Security mode command

(2) Authentication data res.

CK[1], IK[1]

k k

UE RAN CN-visited CN-homeHSSeNodeB MME

AV[i]: i=1, …, n

using AV[i+1]

CK[i], IK[i]

new MMEa handoverwith MME relocation

CK[i+1], IK[i+1]

context transfer AV[j], j=i+1,...,n

(0) Service req.

(1) Authentication data req.

using AV[i] for the i-thservice req.

using AV[1]

(3) User authentication req.

(4) User authentication res.

(5) Security mode command

(2) Authentication data res.

CK[1], IK[1]

k k

Figure 3. UMTS-AKA message sequence diagram.

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.

B. EAP-AKA 3GPP has also obtained publication by the IETF of the

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.

UE RAN CN-visited CN-home

HSSAuthenticator EAP-server

AV

new Authenticator

a handoverwith Authenticator change

(0) EAP req. Identity

(1) Authentication data req.

EAP-AKA Re-authenticationusing the same MK and thus the same AV

using AV

(3) EAP-req AKA Challenge

(5) EAP Success

(2) Authentication data res.

MSK1

k kUSIM

(0) EAP res. Identity

(4) EAP-res AKA Challenge

using CK and AKMKMK

MSKi

(3’) EAP-req AKA Re-Authentication

(4’) EAP-res AKA Re-Authentication

EAP-AKA Re-authenticationusing the same MK and thus the same AVMSKi+1

UE RAN CN-visited CN-home

HSSAuthenticator EAP-server

AV

new Authenticator

a handoverwith Authenticator change

(0) EAP req. Identity

(1) Authentication data req.

EAP-AKA Re-authenticationusing the same MK and thus the same AV

using AV

(3) EAP-req AKA Challenge

(5) EAP Success

(2) Authentication data res.

MSK1

k kUSIM

(0) EAP res. Identity

(4) EAP-res AKA Challenge

using CK and AKMKMK

MSKi

(3’) EAP-req AKA Re-Authentication

(4’) EAP-res AKA Re-Authentication

EAP-AKA Re-authenticationusing the same MK and thus the same AVMSKi+1

Figure 4. EAP-AKA message sequence diagram.

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 domain. In EAP-AKA, key derivation uses a single AV and a unique AKA peer in the network; and

there are no AV transfer between different AKA peers like in UMTS-AKA.

C. Generic EAP Re-authentication EAP-AKA supports a re-authentication mechanism that

avoids full EAP-AKA authentication, while most other EAP methods do not have such support. Recently the HOKEY WG of IETF has been setup to extend the EAP framework with a generic low-latency re-authentication mechanism that is independent of the EAP method. Currently the WG is specifying EAP Re-authentication Protocol (ERP) [22] that avoids repeating the entire EAP authentication process when the UE moves to another Authenticator. When the UE is in a foreign network, the ERP allows re-authentication with a local server and thus it avoids signaling to the home network. Figure 5 illustrates a typical message sequence diagram of ERP in combination with the EAP-AKA protocol, in this figure the UE is in visited domain.

UE RAN CN-visited CN-home

HSSAuthenticator ERP-server

new Authenticator

a handoverwith Authenticator change

(1) and (2)

MSK, DSRK

k kUSIM

(0) EAP req. and res. Identity

MSK, DSRK

rMSKi

EAP-AKA server

DSRK

(3) and (4)

based on an MK derived from AVrRKrRK

MSK

ERP re-authenticationusing the same rRK, thus the same MK and AV

(5)

(6)

UE RAN CN-visited CN-home

HSSAuthenticator ERP-server

new Authenticator

a handoverwith Authenticator change

(1) and (2)

MSK, DSRK

k kUSIM

(0) EAP req. and res. Identity

MSK, DSRK

rMSKi

EAP-AKA server

DSRK

(3) and (4)

based on an MK derived from AVrRKrRK

MSK

ERP re-authenticationusing the same rRK, thus the same MK and AV

(5)

(6)

Figure 5. EAP Re-authentication Protocol message sequence diagram when the UE is in a visited domain.

AKA results in a MK that is used to derive a MSK and a EMSK. The peers then derive a Domain Specific Root Key (DSRT) from EMSK [22-23]. The EAP-AKA-server (from now on it will be called “EAP-server” for short) pushes DSRK and MSK to the ERP-server in the visited domain. The MSK is further pushed to the Authenticator. The DSRK is used by the ERP-server to derive a re-authentication Root Key (rRK). The UE and the ERP-server use rRK to derive a re-authentication Integrity Key (rIK). When the UE attaches to another Authenticator in the visited domain, the UE and the ERP-server produces a new MSK, indicated by rMSKi (i=1, 2, …) in Figure 5, from rRK as the result of the ERP. The rMSKi is pushed to the new Authenticator. When EAP-server and the ERP-server are collocated in a domain then [22] allows deriving the rRK directly from the EMSK. Compared to the re-authentication of EAP-AKA, the ERP requires one local RTT (i.e., RTT between UE and ERP-server) less.

D. Analysis and Paper Objective Both UMTS-AKA and EAP-AKA protocols have

provisions to avoid a round-trip to the home network when a re-authentication or a new session key is required. To achieve that, top-level keys are transferred from the HSS to an entity in the visited access network. In 3GPP SAE/LTE this entity is called Access Security Management Entity (ASME, see TR33.821-[1]). The ASMEs in UMTS-AKA and EAP-AKA are assumed to be MME and EAP-server respectively. Transferring top-level keys to ASME speeds up the re-authentication process by one RTT to the home network. For handover optimization, it is imperative to preserve the same property when doing handovers between UMTS-AKA and EAP-AKA to facilitate seamless inter-technology handovers (e.g., between LTE and Wi-Fi). Thus the aim is to eliminate (or minimize) the interaction between the UE and its home network during handovers between environments supported by UMTS-AKA and EAP-AKA. For this we will develop a solution for handover between EAP-AKA and UMTS-AKA and propose modification in the two AKA solutions.

It is also important to note that the key characteristics of UMTS-AKA and EAP-AKA for key generation and distribution differ. UMTS-AKA relies on having multiple AVs, transferring the remaining (i.e., unused) AVs from the serving MME to the target MME, and using a new AV from the pool of the remaining AVs by a serving MME for re-authentication. EAP-AKA relies on one AV, from which the MK and the resulting keys are derived, and it may generate new session keys from MK according to HOKEY specifications. Here we assume that there is one EAP-server per (visited) domain.

The HOKEY WG ERP solution for re-authentication and key distribution relies on key hierarchy and thereby it saves 0.5 RTT in the local network, compared to EAP-AKA re-authentication procedure. Thus, we will also consider possible ways to efficiently integrate ERP and EAP-AKA architectures.

IV. INTER-WORKING SOLUTIONS In this section we propose solutions for including EAP- and

ERP-servers in SAE/LTE architecture and for distributing AKA keys. We start with investigating how ERP- and EAP-servers can be integrated, and then proceed with possible solutions for inter-working of UMTS-AKA and EAP-AKA. Finally, we sketch the impact of the suggested solutions on the SAE/LTE architecture.

A. Deployment of EAP- and ERP-servers As shown in Figure 5, the ERP-server is a peer entity for

deriving a new session key and for executing any re-authentication interaction if a handover occurs or a session key renewal is required. Therefore, the ERP-server must be at the visited network to limit the scope of signaling to the local network being visited (assuming that the UE moves inside EAP enabled environment).

The EAP-server may be at the home network or visited network. Now consider the case where the UE, while being in the visited domain, switches between EAP-AKA and UMTS-AKA. Based on the principle of authentication state re-use, the

remaining AVs must somehow be exchanged between the EAP-server and MMEs because our sole assumption is that they are allowed to hold the AVs. If the EAP-server were in the home network, a complete RTT to the home network would be required. This is completely against our main requirement and, therefore, the EAP-server must be located at the visited network. The underlying assumption here is that the visited domain is trusted for receiving/using AVs.

When both ERP- and EAP-servers are collocated at the visited network, the difference between ERP based and EAP-AKA-based (re-)authentication is (a) ERP-server acts as an intermediary in every full authentication process (b) ERP based re-authentication, if opted for, takes half local RTT less time than EAP-AKA re-authentication does. This difference does not influence the key distribution latency when doing handovers from UMTS-AKA environments to EAP-AKA environments. This is because a full EAP-AKA must be carried out in such first entrance cases to establish a new MK. Therefore, without loss of generality; we will base further discussion on having only EAP-servers.

B. Key Distribution for efficient Handovers Here we assume that there is only one EAP-server in the

visited network. For handovers between EAP-AKA and UMTS-AKA enabled environments in a given visited domain, the authentication state must be reused, i.e., the remaining AVs should be used in the upcoming MMEs or in the revisits of the EAP-server. This requires interaction between MMEs and the EAP-server in the visited domain. From the viewpoint of key hierarchy, we identify three types of relationships between MMEs and the EAP-server: MMEs and the EAP-server as peers, the EAP-server as the parent node, and MMEs (or an MME) as the parent node.

Figure 6 illustrates the case where MMEs and the EAP-server in a visited domain are peers. This model resembles the peer relationship between SGSNs in the native UMTS-AKA specified in TS33.102-[1].

EAP-AKA

server

AVs

MME1

MME2

MME3

EAP-AKA

server

MME4

EAP to UMTS

transfer of the remaining AVs

UMTS to EAP

legend:

EAP-AKA

server

AVs

MME1

MME2

MME3

EAP-AKA

server

MME4

EAP to UMTS

transfer of the remaining AVs

UMTS to EAP

legend:

Figure 6. MMEs and EAP-server as peers.

Figure 7 illustrates the case where the EAP-server in the visited domain acts as a parent node that holds AVs, i.e., as the ASME node in the visited domain. Upon request or handover, the EAP-server distributes the AVs one by one to MMEs or uses one of the AVs within the EAP-AKA environment.

EAP-server

AVs

MME1

MME2

EAP to UMTS

transfer of one of the remaining AVs

UMTS to EAP

legend:

MME3

EAP to UMTS

EAP-server

AVs

MME1

MME2

EAP to UMTS

transfer of one of the remaining AVs

UMTS to EAP

legend:

MME3

EAP to UMTS

Figure 7. EAP-server as the parent node.

The case where a MME is the parent node is not a valid option because there are many MMEs in a visited domain and no hierarchical relation is defined for SGSNs in the UMTS architecture nor is defined such a relation among MMEs in the current SAE/LTE architecture.

C. Discussion Using the key distribution methods showed in Figure 6 and

Figure 7, a UE is not required to contact the home network in handovers between EAP-AKA and UMTS-AKA. This saves authentication and key management one RTT to the home network.

Making EAP-server as the parent node for holding and distributing AVs puts extra burden on the server and gives a central role to the server. The peer model, however, inflicts some communication load between MMEs and the EAP-server to transfer the context information including unused AVs. In either model, there must be secure channels, like IPsec security associations, between MMEs and the EAP-server, which inflicts administrative burden to establish trust relationships.

In TR33.821-v0.3.0-[1] and exclusively from security perspective, it is argued that AVs shall not be pushed to the SAE/LTE entities (like MMEs), nor shall AVs be transferred between MMEs and the SGSNs of UMTS. This is based on the conclusion that “a lapse in security in an LTE or any other SAE access technology shall not compromise security of pre-SAE access technologies, and vice versa” TR33.821-v0.3.0-[1]. Here we argue that from handover performance viewpoint it is required to push AVs to the visited SAE core network. We think the model of EAP-server as the parent node complies better with the conditions mentioned from TR33.821-v0.3.0-[1]. This model does not allow exchanging AVs between, for

instance LTE and UMTS, access networks and always keeps the EAP-server in charge of key distribution among various access networks. As the EAP-server resides in middle of the evolved packet core network, it can be assumed secure with respect to AV compromise (like SGSNs in UMTS).

Finally, we indicate the impact of using the key distribution methods suggested in Figure 6 and Figure 7 on the SAE/LTE architecture in Figure 8. An EAP-server, optimally collocated with a (HOKEY) ERP-server, is introduced in the SAE/LTE architecture in each domain. Note that Figure 8 shows the case when the UE is in a visited domain. The EAP-AKA protocol (together with EAP-ERP) is run over the S6 interface.

Serving SAEGateway

SGi

hPCRF

S7

S6a

HSS

ePDGS2b

Wn*

3GPP AAA Proxy

Operator’s IP Services

(e.g. IMS, PSS etc.)

Wm*

Wx*

UntrustedNon-3GPP IP

Access

TrustedNon-3GPP IP

Access Wa*

Ta*

PDN SAEGateway

S8bHPLMN

Wd*

Non-3GPP Networks

vPCRF

S9

S7

S6d

3GPP AAA Server

VPLMN

Rx+

S2aS2a

S2b

S6c

S1-U

S1-MME

LTE RAN

2G/3G SGSN

S4

S3

MMES11

S10

UE

Trusted/Untrusted*Non-3GPP IP Access

or 3GPP Access

S2c

S2c

ERP + EAP server

S6-EAP

S6b

Serving SAEGateway

SGi

hPCRF

S7

S6a

HSS

ePDGS2b

Wn*

3GPP AAA Proxy

Operator’s IP Services

(e.g. IMS, PSS etc.)

Wm*

Wx*

UntrustedNon-3GPP IP

Access

TrustedNon-3GPP IP

Access Wa*

Ta*

PDN SAEGateway

S8bHPLMN

Wd*

Non-3GPP Networks

vPCRF

S9

S7

S6d

3GPP AAA Server

VPLMN

Rx+

S2aS2a

S2b

S6c

S1-U

S1-MME

LTE RAN

2G/3G SGSN

S4

S3

MMES11

S10

UE

Trusted/Untrusted*Non-3GPP IP Access

or 3GPP Access

S2c

S2c

ERP + EAP server

S6-EAP

S6b

Figure 8. The impact on the SAE/LTE architecture.

V. CONCLUSIONS Provisioning of secure and seamless handovers between

wireless network technologies in SAE/LTE requires a fast authentication and key management process. In this contribution we considered how to speed up the inter-working between UMTS-AKA and EAP-AKA protocols. This is a necessary step towards providing seamless handovers between two wireless networks that are supported by these protocols. We identified that there were two relationships possible between the MMEs and the EAP-server in a visited domain: peer-to-peer relation and the EAP-server as the parent node. The proposed inter-working solutions save one RTT to the home domain that can be in order of a few hundred milliseconds. Moreover, we showed that integrating HOKEY’s ERP with EAP-AKA requires co-locating ERP- and EAP-servers in the visited domain. Re-authentication based on ERP saves 0.5 local RTT in time compared to the re-authentication method of EAP-AKA. This is a saving of about a few tens of milliseconds. Finally we illustrated the impact of the proposed solution on the SAE/LTE architecture. Our future work aims at

integrating the proposed solution in a complete IP level solution (mobility protocols) for handovers between two wireless network technologies.

REFERENCES [1] Third Generation Partnership Project (3GPP) specifications and reports,

TRxx.xxx (Technical Report) or TSxx.xxx (Technical Spec) available at http://www.3gpp.org/ftp/Specs/html-info/xxxxx.htm.

[2] Mobile IT Forum 4G mobile system requirements document (ver. 1.1), retrieved on 30/05/2007 from http://www.mitf.org/public_e/archives/4G_req_v110E.pdf.

[3] A. Mishra, M. Shin and W. A. Arbaugh, “Pro-active key distribution using neighbor graphs”, IEEE Wireless Communication Magazine, vol. 11, no. 1, pp. 26-36, February 2004

[4] The Internet Engineering Task Force (IETF) main homepage at http://www.ietf.org/, and RFCxxxx (Request for Comments) available at http://www.ietf.org/rfc/rfcxxxx

[5] 3GPP Gantt Chart, http://www.3gpp.org/ftp/Specs/html-info/GanttChart-Level-2.htm#32085

[6] 3GPP TR 25.913: “Requirements for Evolved UTRA (E-UTRA) and Evolved UTRAN (E-UTRAN)”, release 7, 2007.

[7] 3GPP TR 25.912: “Feasibility study for Evolved UTRA and UTRAN”, release 7, 2006.

[8] 3GPP TS 36.300: “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access (E-UTRAN); Overall description; Stage 2”, release 8, 2007.

[9] UTRA-UTRAN Long Term Evolution (LTE) and 3GPP System Architecture Evolution (SAE), http://www.3gpp.org/Highlights/LTE/LTE.htm, 2006.

[10] mITF: “Mobile IT Forum 4G mobile system requirements document,” Ver. 1.1, October 2005.

[11] 3GPP TR 25.814: “Physical layer aspects for evolved Universal Terrestrial Radio Access (UTRA)”, release 7, 2006.

[12] 3GPP TR 33.821: “Rationale and track of security decisions in Long Term Evolved RAN/3GPP System Architecture Evolution”, release 8, 2007.

[13] 3GPP TS 33.922: “Security aspects for inter-access mobility between non 3GPP and 3GPP access network”, release 8, 2007.

[14] 3GPP TS 23.401: “General Packet Radio Service (GPRS) enhancements for Long Term Evolution (LTE) access”, release 8, 2007.

[15] 3GPP TS 23.402: “3GPP System Architecture Evolution (SAE): Architecture enhancements for non-3GPP accesses”, release 8, 2007.

[16] 3GPP TS 22.258: “Service requirements for an All-IP Network (AIPN); Stage 1”, release 7, 2007.

[17] 3GPP TR 22.978: “All-IP Network (AIPN) feasibility study”, release 7, 2005.

[18] 3GPP TR 23.882: “3GPP System Architecture Evolution: report on technical options and conclusions”, release 7, 2007.

[19] 3GPP TR 21.902: “Evolution of 3GPP system”, release 6, 2003. [20] 3GPP TS 33.102: “Technical Specification group services and system

aspects, 3G security; Security Architecture”, release 7, 2006. [21] J. Arkko and H. Haverinen, “Extensible aAuthentication Protocol

method for 3rd Generation Authentication and Key Agreement (EAP-AKA)”, RFC 4187, January 2006.

[22] V. Narayanan and L. Dondeti, “EAP Re-authentication Extensions,” Internet draft draft-ietf-hokey-erx-01, expires November 5, 2007.

[23] J. Salowey, L. Dondeti, V. Narayanan, and M. Nakhjiri, “Specification for the derivation of root keys from an Extended Master Session Key (EMSK),” IETF draft draft-ietf-hokey-emsk-hierarchy-01.txt., work in progress, 2007.