Mutual Entity Authentication for LTE

Geir M. Kien
Dept. of Engineering and Technology
University of Agder, Norway
Email: geir.koien@uia.no

AbstractIn this paper we outline the Authentication and Key

Agreement protocol (EPS-AKA) found in Long-Term Evolution
(LTE) systems. This architecture is the 3GPP version of a 4G
access security architecture. The LTE security architecture is a
mature evolved architecture, with both strengths and weaknesses.
In this paper we propose an amendment to the EPS-AKA
protocol to make it a full mutual (online) entity authentication
protocol. We also analyze the proposal, highlighting both the
improvements and the drawbacks of the new AKA protocol.
Index TermsAccess Security, Mutual Authentication, 4G,
LTE, EPS-AKA;

I. I NTRODUCTION
In this paper we outline the LTE system architecture and associated Authentication and Key Agreement (AKA) protocol.
The protocol, known as EPS-AKA, is based on its predecessor
the UMTS AKA protocol, which again was based on the GSM
AKA protocol, which dates back to the late 1980ies. Within
3GPP the acronym EPS (Evolved Packet System) is sometimes
used in place of LTE. Backwards compatibility is an important
factor in getting acceptance, but it may also hinder progress
and limit the design freedom. Thus, there are issues with the
EPS-AKA protocol, like lack of online authentication, which
can be traced back to its evolved history. In this paper we
propose a slightly modified version of the EPS-AKA protocol
which provides online authentication and true mutual entity
authentication, while still only requiring minor modifications
to the access security architecture.
II. T HE LTE/EPS S YSTEM A RCHITECTURE
In this section we briefly outline the LTE/EPS system
architecture [1]. The security architecture is defined in [2].
A. Overview of the System Architecture
The principal parties are the Home Public Land Mobile
Network (HPLMN), the Visited Public Land Mobile Network
(VPLMN) and the user/subscriber. The user is represented
by the user equipment (UE), which consists of the mobile
equipment (ME) and the subscriber module (UICC/USIM).
Figure 1 depicts the LTE system architecture for a roaming
subscriber, with routing of user data towards the HPLMN.
Figure 2 outlines the LTE radio access network (E-UTRAN).
B. Nodes Participating in the EPS-AKA Protocol
1) Home Subscriber Server (HSS): The HSS is the central
subscriber database at the home network (HPLMN). The
authentication credentials in LTE are called the EPS Authentication Vector (EPS-AV). The HSS forwards the EPS-AV

978-1-4577-9538-2/11/$26.00 2011 IEEE

Fig. 1.

LTE System Architecture

towards the MME during the AV-forwarding part of the EPSAKA protocol.
2) Mobility Management Entity (MME): The MME is
located in the visited network (VPLMN). It is the network
termination for the challenge-response part of the EPS-AKA
protocol. The MME is the host for the Access Security
Management Entity (ASME), which handles access security.
In practice one tend only to refer to MME when one means
MME and/or ASME. The outcome of a successful EPS-AKA
run is the EPS Security Context, which is the main
security context for a roaming subscriber. Security for system
signaling between MME/ASME and the UE is covered by the
NAS Security Context.
3) eNodeB (eNB): The eNB is the radio access point in
LTE and it belongs to the visited network (VPLMN). The
eNB is an active party in LTE access security, and is the
network termination of the AS Security Context. This
security context contains session keys (data integrity/data confidentiality) for protection of the over-the-air interface (LTEUu). The eNB may protect communications within E-UTRAN
(X2-interface) and towards the core network (S1-U interface),
but this is optional and left for the operators to decide.
4) The Subscription Module (UICC/USIM):
The
UICC/USIM is required for access to E-UTRAN. The
aging GSM SIM smart-card was permitted for access
to UTRAN/UMTS for backwards compatibility reasons.
However, the GSM SIM is limited to GSM security and a

689

M M E

M M E

S -G W

H S S
A u t h e n t ic a t io n d a t a r e q u e s t ( I M S I , S N I d e n t it y , N e t w o r k T y p e )

S 1 -U

S 1 -M M E

A u t h e n t ic a t io n d a t a r e s p o n s e ( E P S - A u t h e n t ic a t io n V e c t o r ( s ) )

e N B

X 2

E -U T R A N

X 2

e N B

Fig. 3.

X 2

unique network identity. The HSS binds the KASM E to the

PLMN ID, and this binding is new to the EPS-AKA protocol.
The EPS-AV, depicted in Fig. 4, also includes a separation
indicator in the AU T N.AM F field. The separation bit is used
to distinguish the UMTS AKA vs. EPS-AKA protocols.

e N B
L T
E U
u

W e lc o m e to th e
w o r ld o f L T E

U E

Fig. 2.

Distribution of EPS-AV from HSS to MME

The E-UTRAN Architecture

single 64-bit cipher key (Kc). For use in UMTS one had
to convert the 64-bit key (Kc) into the two 128-bit keys
(CK, IK). Cryptographically, this is nonsense. The GSM
SIM is thus not allowed for access to E-UTRAN.
5) Mobile Equipment: In UMTS the ME was only responsible for the over-the-air encryption. In LTE the ME is also
responsible for deriving the key hierarchy based on the output
from the UMTS AKA part of the EPS-AKA protocol.
III. T HE EPS-AKA P ROTOCOL
The authentication part of the EPS-AKA protocol is based
directly on the authentication part of UMTS AKA. The
challenge-response procedure is executed between the UE and
the MME and the forwarding of authentications credentials is
done from the HSS to the MME (S6a interface).
A. Authentication in UMTS
The UMTS AKA protocol is specified in TS 33.102 [4]. The
UMTS AKA is a delegated protocol in which the home network delegates authentication authority to the visited network.
The home network is off-line with respect to the challengeresponse part of the protocol. The challenge-response procedure is a one-pass protocol and relies on a sequence number
scheme to provide mutual authentication. Therefore it can only
verifies that the challenge is authentic and that the sequence
number is current. The outcome of UMTS AKA includes the
two 128 bit wide session keys CK and IK. Rekeying in
UMTS requires the UMTS AKA protocol to be re-run.

EPS Authentication Vector = {

RAND :
128 bit; Random challenge
XRES :32-128 bit; Expected response
Kasme:
256 bit; EPS security context master key
AUTN :
128 bit; Authentication token = {
SQN : 48 bit; Sequence number
AMF : 16 bit; Auth. mngt. field (w/separation bit)
MAC-A: 64 bit; Signature to authenticate challenge}

Fig. 4.

The EPS Authentication Vector (EPS-AV)

C. The Challenge-Response Procedure

The challenge-response scheme in EPS-AKA is similar to
the UMTS AKA version, except for the key set identifier
(eKSI) in the challenge. There are two eKSI types, and the
KSIASM E is used to indicate a native EPS security context
while the KSISGSN is used to indicate a mapped security
context. Another difference is the before mentioned separation indicator. During EPS-AKA the mobile equipment (ME)
verifies that the AM F separation bit is set for E-UTRAN
access. The EPS authentication sequence, Fig. 5, is otherwise
similar to its UMTS counterpart. With respect to the USIM,
the AKA procedure is exactly as it would be for UMTS.
M M E

U E
U s e r a u t h e n t ic a t io n r e q u e s t ( R A N D , A U T N , K S I

A S M E

U s e r a u t h e n t ic a t io n r e s p o n s e ( R E S )

U s e r a u t h e n t ic a t io n r e je c t ( C A U S E )

Fig. 5.

EPS Authentication

B. The Authentication Vector Forwarding

The authentication credentials in UMTS and LTE is called
the Authentication Vector (AV). The LTE version is called
EPS-AV and differs from UMTS in that the session keys
(CK, IK) are replaced with the KASM E master key.
The AV forwarding takes place between the MME and the
HSS over the Diameter based S6a interface (see Fig. 1). Figure
3 illustrates the EPS-AV forwarding. The requesting MME
specifies what type of AV it wants to be returned. This is
indicated in the Network Type parameter, which is set to
E-UTRAN for EPS-AKA. The request includes the PLMN
ID (SN Identity) of the requesting MME. This is a globally

D. The EPS Key Hierarchy

The LTE/EPS key hierarchy consists of a set of symmetric
secret-key keys, which are organized according to security
context. Amongst the keys are two key deriving keys, the
master key KASM E and the over-the-air root key KeN B .
There are independent session key sets for the user plane
(UP), the RRC protocol and the NAS protocol. All derived
keys are 256 bit wide, but session keys are truncated to 128 bit.
The enc extension indicates a data confidentiality key while
int indicates a data integrity key. There is no data integrity key
for user data. Fig. 6 outlines the key hierarchy.

690

U I C C /U S I M
a n d H S S

(N A S

M E a n d H S S
(E P S S e c u r ity C o n te x t)

M E a n d M M E
S e c u r ity C o n te x t)

A. Defined Authentication Goals

K

C K , I K
K

P re -sh a re d
a u th e n b tic a tio n
se c re t

P ro d u c e d b y
" U M T S A K A "
p a rt

P ro d u c e d b y
S 1 0 k e y d e riv a tio n

R R C i n t

R R C e n c

U P e n c

e N B

P ro d u c e d b y
S 1 1 k e y d e riv a tio n
(a ls o S 1 2 a n d S 1 3 )

Fig. 6.

N A S e n c

M E a n d e N o d e B
(A S S e c u r ity C o n te x t)

A S M E

IV. A NALYSIS OF THE EPS-AKA P ROTOCOL

N A S i n t

EPS Key Hierarchy

E. Security Context
There are three types of native EPS security contexts. The
main context is the EPS Security Context, which is the
outcome of successful EPS-AKA execution.

EPS Security Context

The main context. Contains the master key KASM E .
NAS Security Context
System signaling context between MME and UE. Based
on KASM E . May exists when the UE is idle (i.e. not
connected over-the-air).
AS Security Context
Covers all over-the-air traffic (UEeNB). Only exists
when UE is in connected state. The KeN B is the root
key for this context.

F. Key Derivation and Key Chaining

The key derivation is LTE is by means of a standardized key
derivation function (KDF), which is defined in Annex A in TS
33.401 [2]. The derivation of the master key KASM E and the
NAS Security Context keys are relatively straightforward. The KASM E is derived as follows (abridged):
KDFkey (N etworkId, SQN AK) KASM E

(1)

The key is the (CK, IK) output from the USIM and the
SQN AK element is the sequence number masked with an
anonymity key (AK). The N etworkId is the network identity
(PLMN-ID) of the MME. The NAS Security Context
keys are derived in similar fashion, with the KASM E as the
input key.
The handling of the AS Security Context and the
way one refresh/chain this context is fairly complicated. The
initial version of the AS Security Context is created
when the UE goes into connected state, and it is based on
KASM E and NAS protocol context data. The AS Security
Context can be chained and this happens whenever there is
a handover (HO) event. The outcome of a chaining event (HO
event) is that a new KeN B root key is generated and that all
dependent keys are freshly derived.
Given that we focus of improvements to the authentication
part of the EPS-AKA protocol we shall refrain from further
discussion of the EPS key hierarchy and the key derivations.

For the UMTS security architecture the goals and objectives

were well defined [3, 5]. The UMTS requirements still apply
for LTE and TS 33.401 [2] defines the capabilities of the
security architecture. The basic task of the EPS-AKA protocol is to provide mutual entity authentication between the
USIM and the network. This is achieved through a challengeresponse scheme that authenticates the UE to the network and
which authenticates the challenge (w/validation of sequence
number). Furthermore, the EPS-AKA protocol binds the master key KASM E to the network identity of the MME. The
cryptographic binding is done by the HSS and the ME on
the basis of data provided by the MME. The data provided to
the HSS over the S6a-interface is assumed to be authentic and
thus the ME can verify that the claimed (over-the-air) network
identity is consistent with the challenge data.
B. LTE Improvements with respect to 3G
There are several improvements with respect to the UMTS
access security architecture [2, 9]. These include:
Deprecation of the GSM SIM: The GSM SIM and the
associated GSM AKA protocol are considered inadequate
for use with LTE/E-UTRAN.
Authentication: The inclusion of the MME network
identity in the KASM E derivation binds the EPS-AV to
a specific network.
Explicit Separation: The separation of user data traffic
and system signaling is dictated by the overall LTE/EPS
architecture, but it is beneficial to separate user data and
system signaling since they have (or may have) different
protection needs.
Key Hierarchy: There are several aspects to the key
hierarchy, but we note the following benefits:
No need to re-run AKA for key renewal (important)
Session keys generated on demand locally
Need to know: The home network no longer derives
keys that are only to be used in visited network.
Fast local key derivation at eNB (assisted by MME)
C. Weaknesses and Omissions
The EPS-AKA protocol is very much an evolved design,
and the basic message exchange scheme is virtually identical
to the more than 20 years old GSM AKA protocol. One a
protocol-element level EPS-AKA is very similar to UMTS
AKA, which is also aging (defined in 1999). One of the main
problems with the GSM AKA, the UMTS AKA and now EPSAKA protocols are that they are delegated protocols. That is,
almost all authentication authority is delegated from the home
network to the visited network. The delegation is such that
HSS may forward up to 5 authentication vectors and that the
HSS may be entirely off-line with respect to the challengeresponse part of the protocol. This requires a very high trust
level between the operators. This could perhaps be justified
back in the late 1980ies in Europe when/where the GSM AKA

691

protocol was devised, but with an ever increasing number of

roaming partners the original trust assumptions seem outdated.
There is also a problem with AV revocation. If all is well
and the visited networks are all honest and well-behaved
there is no problem, but if one has a misbehaving VPLMN
then revocation of AVs is problematic since the VPLMN may
ignore the cancel subscriber command (there is no cancel
AV command). We highlight the following weaknesses [9]:
1) Lack of mutual authentication: The authentication of
the network(s) is indirect, and only amounts to proving
that the AV is authentic, used in the intended network
and that the challenge is current.
2) Delegated Authentication/Off-line Authentication:
The HPLMN is off-line with respect to the challengeresponse and it delegates authentication authority to the
VPLMN.
3) Sequence Number Management: The timeliness
(and replay protection) of the challenge depends on
the quality and configuration of the sequence number
management scheme.
V. T HE E NHANCED EPS-AKA P ROTOCOL
We now outline the proposed Enhanced EPS-AKA protocol
(EAKA). Primarily we propose a new 3-party online authentication protocol, with full mutual authentication between the
UE and the HSS (HPLMN). The EAKA protocol is designed
to be as similar to the EPS-AKA protocol as possible to
minimize adverse system impacts, but it must also provide
significant benefits.
As a design restriction we retain the challenge-response
sequence and the AV concept, but permit ourselves to include
new message elements and redefine the authentication token
(AU T N field). One necessary change is the introduction of
new subscriber module, the ESIM, which replaces the USIM.
A. Online Requirement
We propose to let the EAKA protocol be an online protocol
with respect to the home network, but to have the home network online for the AKA execution is potentially problematic
with respect to round-trip delays.
With UMTS AKA one had to re-run the AKA protocol to
derive new keys, but with EPS-AKA this is not necessary.
One can derive new NAS Security Contexts without
running EPS-AKA and one routinely (for every handover
event) create new AS Security Contexts. In fact, one
need only run the EPS-AKA protocol whenever the MME
anchor-point changes, and in that case the MME will need to
carry out signaling with the HSS anyway. The additional (timedelay) cost of running the full AKA protocol at that point is
therefore relatively low. One may of course also need to run
the AKA protocol periodically, but this can be done without
service interruption through the existing EPS-AKA scheme
for current and non-current security contexts. Therefore, if
we retain the key derivation scheme used in EPS-AKA the
round-trip delay drawback can be effectively mitigated. Consequently, the need for global round-trips will be infrequent

and to some extent they will be required irrespectively of

EAKA needs. We therefore conclude that performance-wise
the online requirement is not problematic.
B. Key Hierarchy
In this paper we focus on improvements to the authentication part of the EPS-AKA protocol. A proposal for key
hierarchy improvements is made in [6], but we make no
recommendation for key hierarchy improvements here.
C. Outline
As for the EPS-AKA protocol we rely on the MMEHSS connection to be fully secured. Likewise, we rely on
the subscriber and HSS to have a pre-shared authentication
secret (K), which is associated with the permanent subscriber
identity (IM SI)
The standard (RAN D, RES) elements are known and used
by the MME. They are thus not suitable for exclusive and
direct authentication between the ESIM and the HSS. We have
therefore had to add an initial challenge from the ESIM to the
HSS. Similarly, we have added an explicit response from the
ESIM to the HSS, which the MME cannot compute.
In our proposal the subscriber provides a random challenge
(RAN DU E ) in the (already existing) identity presentation
sequence. The identity presentation naturally occurs in the subscriber registration phase when the ME accesses the network.
So there is an opportunity to forward the subscriber challenge
to the network without changing the message flow itself.
In EAKA the AU T N.M ACA and AU T N.SQN fields
have become redundant. We can therefore reuse these fields.
Thus, we can let the MME assign a pseudo-random context identity (CID) to the EPS Security Context. The
CID is forwarded from the MME to the HSS, and the
HSS includes the CID in the authentication token (AU T N ),
where it replaces the SQN field. The AU T N.M ACA field,
which contained the signature of the challenge data, has been
replaced with the AU T N.RESU E field. It is used to permit
the HSS a direct response to the ESIM. Similarly, there is a
new element, RESHSS , which is used as a response from the
ESIM to the HSS.
It is noted that the message flow of EAKA is identical
to EPS-AKA, save for the explicit HSS acknowledge that
we have provided. The acknowledge message can however
be integrated with the response to the identify presentation
sequence or with the acknowledge message to the registration sequence. Thus, there is no need for new messages. The
changes are otherwise the triggering event (identify presentation w/challenge), the modifications to AU T N and the added
response element (RESHSS ).
D. The ESIM Subscription Module
The authentication procedure is the realm of the subscriber
module (and not the ME). The USIM cannot support true
mutual entity authentication protocol and we therefore propose
a new subscriber identification module called the ESIM. The
ESIM is a superset of the USIM and is able to execute

692

UMTS AKA natively when needed. For compatibility with

GSM/GPRS we suggest that the ESIM execute UMTS AKA
protocol and then convert the UMTS context with the standard
conversion functions (defined in [4]). The ESIM operates in
ESIM-mode when it is inserted in an ME which recognizes
its ESIM capabilities, otherwise it must run in USIM mode.

4)
5)

E. An Enhanced Authentication Vector (EAV)

1) AKA Protocol Identification: We need to distinguish the
EPS-AKA and the EAKA protocol(s), and the obvious way
to do this is to extend the separation-bit scheme defined
for EPS-AKA. The separation-bit indication is therefore
replaced with an AKA Protocol Identifier (P I) block of 4 bits.
Coding of P I is consistent and compatible with the separation
bit coding.

6)

Code:
0XXX
1000
1001

Protocol ID:
UMTS AKA
EPS-AKA
EAKA

Comment:
The standard UMTS AKA protocol
The standard EPS-AKA protocol
The EAKA protocol described here

7)

2) The EAV: The authentication vector has been partially redefined for EAKA. The AU T N.M ACA field
has been replaced with the response field AU T N.RESU E .
The AU T N.SQN is replaced with a context identity
AU T N.CID, which is supplied by the MME/ASME. The
purpose of CID is to provide the MME/ASME with an index
to the EPS Security Context. The minimum size of
(RES) has been increased to 64 bit (from 32). The EAV, see
Fig. 7, is otherwise identical to the EPS-AV.
Enhanced Authentication Vector = {
RAND :
128 bit; Random challenge (from HSS)
RES :64-128 bit; Expected Response
Kasme:
256 bit; EPS security context master key
AUTN :
128 bit; Modified AUTN {
CID
: 48 bit; MME/ASME EPS Context Identity
AMF
: 16 bit; Auth.mngt. field(w/4 bit PI block)
RESue : 64 bit; Response to the ESIM challenge

Fig. 7.

The Enhanced Authentication Vector (EAV)

d) res2K (Block) RES

e) res3K (Block) RESHSS
f) AU T N := CID||AM F ||RESU E
g) EAV := {RAN D, RES, KASM E , AU T N }
HSSMME: M3(EAV )
MMEESIM: M4(RAN D, AU T N )
ESIM: Receive (RAN D, AU T N ) and SN ID
from ME:
a) res1K (Block) RESU E
b) Verify: RESU E = AU T N.RESU E .
c) res2K (Block) RES
d) res3K (Block) RESHSS
e) kdfK (Block) KASM E
ESIMMME: M5(RES, RESHSS )
MME: Verify RES from ESIM matches RES
from HSS.
MMEHSS: M6(CID, RESHSS )
HSS: Verify RESHSS and inform the MME.
HSSMME: M7(CID)

The CID is not assumed to be secret per se, but we

nevertheless propose to conceal it with an anonymity key
similar to how the SQN is concealed in the UMTS AV and the
EPS-AV. We have not shown this in the above EAKA outline.
VI. A NALYSIS OF THE E NHANCED EPS-AKA P ROTOCOL
A. Properties of the EAKA Protocol
The EAKA protocol provides mutual entity authentication
between the ESIM and the HSS. The sequence number mechanism has been dispensed with. The protocol provides an
authenticated context identity, CID, which is decided by the
MME. Since the CID is included as input to the cryptographic
functions, the MME will have direct influence on the EPS
Security context, including the KASM E master key.
The ESIM and MME have also been authenticated to each
other (not so with EPS-AKA). The KASM E is derived directly
and one no longer need the intermediate step of first deriving
the (CK, IK) keys (as for the EPS-AKA protocol).

F. Cryptographic Functions at the ESIM

B. Brief Security Analysis

The new functions we need are a pseudo-random function

prf () (at the UE), a set of response functions resK () and a
key derivation function kdf () (see also LTE kdf in [2]).

The EAKA provides mutual authentication between the

ESIM and the HSS in a fairly straight forward way, quite
similar to other double challenge-response protocols. The
following analysis uses BAN-like language [8], but is nevertheless only an informality analysis. Note that the HSS has
security jurisdiction over the ESIM and that ESIM and HSS
shares the permanent authentication secret K.
In M1 the ESIM forwards its identity (ID) and the
(fresh) random challenge (RAN DU E ). The MME receives
M1 and sees it. The MME proceeds to generate the (fresh)
pseudo-random context identity CID. It then forwards M2 to
HSS (over a protected and authenticated channel). The HSS
therefore believes that MME once said M2. The HSS then
constructs the EAV w/use of CID and forwards it to the
MME (in M3). The MME, who knows that CID is fresh,
can now believe the EAV . The MME then forwards the
challenge (RAN D, AU T N ) to the ESIM in M4. The ESIM,
who knows that (RAN DU E ) was fresh can now verify that
that the response (RESU E ) is correct. The ESIM can then

G. Outline of the EAKA Protocol

The subscriber identity (which we denote ID) in
LTE is either the permanent identity (IMSI) or the
globally unique temporary identity (GUTI). The symbol
indicates a secured authenticated channel. Also, let
Block = (AM F, SN ID, CID, RAN DU E , RAN D).
Successful EAKA in augmented Alice-Bob notation:
1) ESIM: prf () RAN DU E
ESIMMME: M1(ID, P I, RAN DU E )
2) MME: Generate context identity;
prf () CID
MMEHSS: M2(IM SI, P I, RAN DU E , SN ID, CID)
3) HSS: Generate EAV (w/P I in AM F )
a) prf () RAN D
b) kdfK (Block) KASM E
c) res1K (Block) RESU E

693

believe that the HSS is online. The response is computed over

the whole Block. The ESIM can therefore believe that MME
once said CID and SN ID, and it can believe that RAN D
originated with HSS. The ESIM also computes RES (for the
MME), the RESHSS and the KASM E .
When the MME receives M5 is sees the RES. Given the
HSS jurisdiction over the ESIM it can believe that the ESIM
once said RES provided that it matches the RES contained
in the EAV . The MME knows that CID is fresh and so it
can believe in RES, which in turn means that it can support
a belief in CID as a shared context identity (with the ESIM).
The basis for KASM E was provably fresh for both ESIM and
MME, and they can thus immediately start using it.
Message M6 is necessary in order for the HSS to verify
that the ESIM is authenticated/online, while M7 is included
so that the MME can believe that HSS believes that the ESIM
is authenticated/online.
C. Real-Time Performance of the EAKA Protocol
The following is brief analysis of the performance of the
EAKA protocol for attach and tracking area update events
(see ch.5 in [1]). For these events one must complete the
full EAKA protocol before the subscriber can consume any
services. For other EAKA triggering events one can use
the current/non-current context concept defined for EPSAKA (see [2]), and these events are thus not time critical.
Furthermore, as for EPS-AKA, ordinary re-keying does not
involve executing the EAKA protocol.
1) Computational Overhead: Only symmetric cryptographic methods are necessary for the EAKA protocol. The
only additional burden on the ESIM is to generate RAN DU E
(pre-computation possible) for message M1, to compute two
additional responses during step 5). The ESIM platform,
a smart-card, can easily accommodate these needs without
undue delay. The MME and HSS are big servers and computational overhead of a few additional symmetric cryptographic
operations is not problematic and will not induce undue delays.
2) Signaling Overhead: For attach and tracking area
update events the UE must signal the MME and the MME
must signal the HSS. Step 1) and 2) are therefore required
irrespective of EAKA needs. Step 3) and step 4) would be
similar to the forwarding of the EPS-AV. Step 5) is identical
to the response part of EPS-AKA.
Step 6) and step 7) are new to the EAKA protocol, but are
not time critical since the UE and MME has sufficient assurance to proceed with protected communications in parallel
with transfer of message M6 and M7. Thus, effectively, the
EAKA protocol will not introduce additional round-trip delays
compared to the EPS-AKA protocol.
D. Assessment of Impact
We observe that the EAKA protocol introduces:
The need for a new subscriber module (the ESIM)
Inclusion of ESIM should not (technically) be problematic, but operational deployment could be an issue.
Changes to the message exchange

To add a challenge to the identity presentation should

not be a major problem, but it introduces the need for
compatibility between EAKA and non-EAKA identity
presentation. There is a change in the response (message
M 5) with and added field (the RESHSS ). There is also
the added response w/confirmation (M 6,M 7), but this is
a minimal change and it only affects the S6a-interface.
New Interworking Requirements
The EAV is not directly compatible with the EPS-AV
(or the UMTS AV), but [2] already contains interworking
functions and these can be applied for the EAKA derived
EPS Security Context too.
One also needs to implement the EAKA procedures at the
HSS and MME. Still, overall the impact seems well contained
and the EAKA approach appears to be feasible.
E. Further Work
We have demonstrated that the proposed EAKA protocol
can provide full mutual authentication in LTE However, there
are many details left to resolve, in particular with respect to
interworking. The EAV and the UMTS-AV are not directly
interchangeable, and one must also ensure that there arent any
subtle problems with supporting both EPS-AKA and EAKA.
A formal model of the EAKA protocol is planned, using the
HLPSL language and the AVISPA toolset [10].
VII. C ONCLUSION
In this paper we have described the LTE access security
architecture and we have identified omissions and potential
weaknesses of the LTE access security architecture. To address
the shortcomings we proposed a new authentication protocol
between the ESIM and the MME/HSS. The new EAKA
protocol provides full (online) mutual entity authentication
between ESIM and HSS, has the MME influence the outcome of the EAKA execution, and removes the need for
delegated authentication. This was achieved with relatively
minor changes to the system architecture. We thus consider
the EAKA approach feasible for future releases in 3GPP.
R EFERENCES
[1] 3GPP, TS 23.401, General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network (E-UTRAN)
access, Sophia Antipolis, France, 06-2010.
[2] 3GPP, TS 33.401, 3GPP System Architecture Evolution (SAE); Security
architecture, Sophia Antipolis, France, 06-2010.
[3] 3GPP, TS 21.133, 3G Security; Security Threats and Requirements,
France, 01-2002.
[4] 3GPP, TS 33.102, 3G security; Security architecture, Sophia Antipolis,
France, 03-2010.
[5] 3GPP, TS 33.120, 3G Security; Security principles and objectives, 042001.
[6] D. Forsberg, LTE Key Management Analysis with Session Keys Context,
Computer Communications, 10-2010
[7] G.M. Kien, An Introduction to Access Security in UMTS. IEEE Wireless
Comm. Vol.11 No.1, 818, 2004.
[8] M. Burrows and M. Abadi and R. Needham, A Logic of Authentication,
DEC Systems Research Center, Reseach Report no.39, USA, 02-1990
[9] G.M. Kien, Entity Authentication and Personal Privacy in Future
Cellular Systems, River Publishers, ISBN 978-87-92329-32-5, 2009.
[10] AVISPA project, Automated Validation of Internet Security Protocols
and Applications (AVISPA); Deliverable D2.1: The High Level Protocol
Specification Language, AVISPA IST-2001-39252, 2003

694