Is the Session Mix-up Attack on the UMTS/LTE AKA Protocol Practical?

(1)

Is the Session Mix-up Attack on the UMTS/LTE AKA Protocol Practical?

Ashim Bhusal

Master of Telematics - Communication Networks and Networked Services (2 Supervisor: Stig Frode Mjølsnes, ITEM

Department of Telematics Submission date: Januar 2013

Norwegian University of Science and Technology

(2)

(3)

Is the Session Mix-up Attack on the UMTS/LTE AKA Protocol Practical?

TTM4905 Report Master Thesis

Project Member :

Ashim Bhusal (bhusal@stud.ntnu.no)

Supervisor : Joe-Kay Tsay, NTNU ITEM (joe.k.tsay@item.ntnu.no)

Responsible Professor : Professor Stig Frode Mjølsnes, NTNU ITEM (stig.mjolsnes@item.ntnu.no)

Norwegian University of Science and Technology

Autumn 2012

(4)

(5)

Abstract

The real time implementation of theoretically proven facts is a challenging task.

Not all the theoretically shown results are valid in real practice. The standards defining the policies leave lot of space for specific implementation, hence a vulnerability seen in case of some protocols defined by some specific standards may not exist in practical. The flaw may be totally or partially masked by other protocols running in conjunction with the so called vulnerable protocol. Also there is possibility that those unspecified steps in the standards are implemented by the operators. This work extends the project title: Validation of attacks on the UMT- S/LTE AKA protocol, where the vulnerability found by Stig Frode Mjølsnes and Joe-Kay Tsay , presented in several seminars and explained inA Vulnerability in the UMTS and LTE Authentication and Key Agreement Protocolswas theoretically proven.

The previous works had analysed the mechanisms ofAuthentication and Key Agreement (AKA) protocol as defined in the 3^rd Generation Partnership Project (3GPP)specifications. This thesis work tries to solve the questions raised by the findings of those prior works regarding AKAprotocol. Here, the theoretically shown vulnerability is analysed based on information about other protocols like Internet Protocol (IP) Security (IPsec), Diameter, Signalling System 7 (SS7)andMobile Application Part (MAP) Security (MAPsec)running along withAKAprotocol. Several people from different operators were contacted so as to find the facts about which protocols are used and how these protocols are implemented.

Here the session related parameters, Session-Id in case ofLong Term Evo- lution (LTE) and Invoke-Id and Transaction Id in case of Universal Mobile Telecommunication System (UMTS)are discussed to show if they are capable of withstanding the session mix-up vulnerability. The sessions of a user or service operations are uniquely identified by these identifiers. But the number of bits used by the identifiers and their formats have left the place to suspect if session mix-up attack is still attainable. The conclusions derived here are not compli- mented by the information from real implementation scenario, so, as far as it

i

(6)

ii

is possible to obtain information about real implementation mechanisms from some operators, this work can be further extended to compare the strength of Session Mix-up attack against the mechanisms implemented by the operators.

(7)

Preface

This report documents the Master’s thesis work entitled "Is the Session Mix-up Attack on the UMTS/LTE AKA Protocol Practical? ", which was carried out under the Faculty of Information Technology, Mathematics and Electrical Engi- neering, Department of Telematics(ITEM), Norwegian University of Science and Technology (NTNU), during Autumn 2012. This thesis work holds the weigh- tage of 30 study credits and serves for the partial fulfilment of Masters of Sci- ence(MSc) degree in Telematics at NTNU. The objective of this work is to find whether theoretically proven session mix-up attack is attainable in real world scenario or not.

I would like to extend my sincere gratitude to Professor Stig Frode Mjølsnes and supervisor Joe-Kay Tsay at Department of Telematics, NTNU, for their regular and valuable guidance, feedbacks and suggestions. I would like to thank Profes- sor Dr. Do van Thanh of NTNU/Telenor for the document he provided which worked to boost up the initial phase of this work. My thanks goes to Sebastien Decugis for his continuous support with the use and debugging of the software f reeDiameter.

I wish to appreciate the help provided by my friends, relatives and family mem- bers throughout the period of this thesis work. As a consequence, this work has been successfully accomplished and the desired results have been obtained.

Ashim Bhusal, Trondheim, January 2013.

iii

(8)

(9)

List of Figures

2.1 LTE Security Architecture with Interfaces. . . 8

2.2 Authentication and Key Agreement Protocol. . . 11

2.3 Session Mix-Up Attack. . . 13

2.4 Overview of Zd, Ze and Zf interfaces. . . 15

2.5 AH encryption of IP packet in different modes. . . 20

(a) Transport Mode. . . 20

(b) Tunnel Mode. . . 20

2.6 IP packet secured by ESP.. . . 20

2.7 The Diameter Applications on top of Diameter Base Protocol . . . 21

2.8 The Diameter Header Format . . . 22

2.9 General Message Diagram for Diameter Authentication . . . 24

2.10 Diameter Message Exchange. . . 25

2.11 Application of Diameter for AKA process. . . 26

2.12 The S6 Interface . . . 27

2.13 The S6a Control Plane . . . 27

3.1 IP traffic secured with IPsec ESP. . . 34

3.2 Screenshot showing Diameter traffic. . . 38

3.3 Screenshot showing Session-Id AVP. . . 39

3.4 General model used for implementation. . . 42

4.1 The S6 Protocol Stack. . . 46

4.2 The MAP Protocol Stack. . . 46

C.1 Wireshark Snapshot showing IPsec headers.. . . 78

vii

(12)

(13)

List of Tables

2.1 Terms used in AKA process. . . 10

2.2 Elements of AV for GSM, UMTS and EPS. . . 12

2.3 MAP_SEND_AUTHENTICATION_INFO parameters. . . 16

2.4 Some Terms related to IPsec. . . 18

3.1 Ubuntu based Commands. . . 33

3.2 Intended Diameter Parameters and their values. . . 37

3.3 Mapping of entities of LTE system to the modelled system. . . 41

A.1 Contacted people and their field . . . 63

ix

(14)

(15)

Acronyms

2G Second Generation.3,13 3G Third Generation.3,9,13

3GPP 3^rdGeneration Partnership Project.i,1,3,7–9,14,16,17,19,23–27,29,40, 41,43,47,48,51,52

4G Fourth Generation.2,7

AAA Authentication, Authorisation, and Accounting. 20–22 AH Authentication Header.18,19,34

AIA Authentication Information Answer.25,26,28,29,40,43 AIR Authentication Information Request. 25,26,28,29,40,43

AKA Authentication and Key Agreement. i, vii, 1–3, 5, 7–14, 19, 24, 26, 28, 45–47,51,52

AS Access Stratum. 10

AuC Authentication Centre. 3,8,9,14,31

AV Authentication Vector. 8–12,14,19,26,27,29,40,42,43,52 AVP Attribute Value Pair. 22,29,30,43,47

BS Base Station.7

CN Core Network.13,14,17 DNS Domain Name System. 27

DTLS Datagram Transport Layer Security. 23 eNodeB Evolved NodeB.7,8

xi

(16)

xii ACRONYMS

EPS Evolved Packet System.2,9,11,16,51

ESP Encapsulating Security Payload.18,19,34,47

ETSI The European Telecommunications Standards Institute.1,25,27,51 EUTRAN Evolved UTRAN.13,29

FQDN Fully Qualified Domain Name.22,29

GERAN GSM/EDGE Radio Access Network. 29,30

GSM Global System for Mobile communication.2,3,7,11,13,16,53 HLR Home Location Register.8,9,14,16

HN Home Network.1,7–10,12,31,41,45,47,48

HSS Home Subscriber Server.7–9,12,13,16,19,25–28,31,40–43 IANA Internet Assigned Numbers Authority.27,37

IETF The Internet Engineering Task Force.1,3,14,17,21,23,26,27,51 IKE Internet Key Exchange. 15,18

IMSI International Mobile Subscription Identity.10,25

IP Internet Protocol.i,xii,1–3,5,13,14,17–19,23,25,27,31–34,36,42,46,51 IPsec IPSecurity. i,1,3,5,8,14,17–19,23,31–34,36,37,41–43,45,47,51

ITU-T International Telecommunication Union-Telecommunication. 1, 3, 14, 16,47,51

KAC Key Administration Centre. 15

LTE Long Term Evolution. i, 2, 3,5, 7–9,11, 13,14, 17, 23, 24, 28,29, 31,41–43, 45,46,51–53

MAC Message Authentication Code.15

MAP Mobile Application Part.i,xii,1,5,14–16,25,45,47,48,51,52 MAPsec MAPSecurity. i,1,3,5,14–16,42,45,48,51,53

MME Mobility Management Entity. 8–10,12,13,16,19,24–28,31,40–42 NAS Network Access Server.23

(17)

xiii

nAS non Access Stratum. 10

NDS Network Domain Security. 5,13,14,18,19,23,28,46 NE Network Element.15,16

NTNU Norwegian University of Science and Technology. 3 OS Operating System.32,35

PC Personal Computer.32

PLMN Public Land Mobile Network. 15,25 PTI Procedure transaction identity.17,48

RADIUS Remote Authentication Dial In User Service. 20 RFC Request for Comment. 3,7,17,21,26,40,51

S-GW Serving Gateway. 7,8 SA Security Association.15,16,18

SCTP Stream Control Transmission Protocol. 23,27 SGSN Serving GPRS Support Node. 14,16,25,26

SN Serving Network.1,7–12,16,26,28,29,31,41,45,47,48 SPI Security Parameter Index.18,34

SS7 Signalling System 7.i,5,13,14,25,42,45,47,51 TCAP Transaction Capabilities Application Part. 5,14,47 TCP Transmission Control Protocol. 23

TLS Transport Layer Security. 23,36,37,42 TS Technical Specification.7,17,25,27 UE User Equipment.1,7–10,41

UMTS Universal Mobile Telecommunication System. i, 2, 3, 5, 7–9, 11, 13, 14, 16,19,42,45,47,51–53

USIM User Subscriber Identity Module. 7–10,12,41

UTRAN UMTS Terrestrial Radio Access Network. 13,29,30 VLR Visitors Location Register. 8,9,14,16

(18)

(19)

Chapter 1 Introduction

1.1 Problem Description

There are some protocols running between three entities:User Equipment (UE), Serving Network (SN) and Home Network (HN) before a requested service is granted to a user(mobile devices). The Authentication and Key Agreement (AKA) Protocol, where the users are authenticated to respective HN and the keys for subsequent communication are derived and exchanged between these entities, is one of them. The AKA protocol does not specify any mechanisms for session management. Exploring this, a session mix up attack on this protocol has been found. In this attack, an attacker has a control over all the traffic going in and out of Serving network and the attacker itself is one of the participating mobile user. The attacker uses a session of AKA established for a genuine user to authenticate itself and thus has ability to carry on subsequent communication on behalf of a genuine user. Although unspecified inAKA, it is believed that there are some specific session management or other security protocols running underneath of AKA (probably IP Security(IPsec), MAP Se- curity(MAPsec), Radius/Diameter may be some of them) which may prevent this attack. These protocol may vary depending upon the owner ofSN. If the SN belongs to theHN of the user, the protocol may be vendor specific or specific to service provider whereas if theSNis acquired by otherHNthan the one to which user is attached, some agreed protocol or some standard protocols are defined and used.

The 3^rd Generation Partnership Project (3GPP), The Internet Engineering Task Force (IETF),International Telecommunication Union-Telecommunication (ITU-T),The European Telecommunications Standards Institute (ETSI)and other bodies define and recommend the standards to be used. The attack may not be feasible in case the standards are implemented as recommended. But in non roaming case where application of these standards depend upon the operator

1

(20)

2 CHAPTER 1. INTRODUCTION

the attack may be possible. The aim of this work is to find the protocols running belowAKAfor inter and intra domain communication. In case of inter domain communication, conclusions will be derived based on study of several specifications, relevant documents and recommendations from some operators. These documents and specifications are discussed in chapter2. In the case of intra domain communication, the conclusions are highly based on the information provided by people from different service providers. The liveliness of Session Mix up Attack in real world is than tested depending upon the mechanisms mandated or recommended in relevant specifications and based on the information provided by several service provider. The other objective of the work is to construct a software simulation based on analysis of collected information, showing if the proposed session mix-up attack can be attainable in practice. Shortly, the main tasks expected in this thesis work are listed below:

• Gathering of information from people related to telecommunication operators from different location

• Finding the recommended standards from several specifications and recommendations.

• Analysing the gathered information and study the possibility of session mix-up attack based on those information.

• Construct a scenario (software based model) to implement the recent practice based on specifications and information from several people.

1.2 Motivation

The use of Long Term Evolution(LTE) based wireless communication system, also termed asEvolved Packet System (EPS)andFourth Generation (4G)system is increasing. TheLTEsystem being allInternet Protocol(IP) based system has been taken as a solution to shortcomings of legacy systems, Global Sys- tem for Mobile communication (GSM) and Universal Mobile Telecommunica- tion System(UMTS). There are various aspects in which this new system is su- perior to its predecessors. One of the aspect in which our study will focus is a security aspect. It is a known fact that there were no network domain security in case of Global System for Mobile communication (GSM) and also mutual authentication ofUMTSwere not able to protect some attacks when working in GSMenvironment. Irrespective of all the previously found attacks onGSMand UMTS, a protocol level session mix-up attack has been detected by Mjølsnes and Tsay. This attack aims towardsAuthentication and Key Agreement(AKA) protocol ofUMTSandLTE. Exploiting some unspecified steps inAKAprotocol the attack has theoretically been proven. The attack has been presented in several

(21)

1.3. RESEARCH METHODOLOGY 3

workshops and seminars [1, 2, 3] and was theoretically shown in a project carried out under Department of Telematics,Norwegian University of Science and Technology (NTNU). But the questions regarding the possibility of this session mix-up vulnerability in real world scenario were still to be solved and left as an extension to the project.

This thesis work will try to solve those unsolved questions by acquiring information from different operators, studying of several documents, specifications, standards and recommendations and developing (implementing) a real scenario based on acquired information and study. Here some other protocols belowAKAare studied to find if the attack is attainable even after implementation of those protocols. A brief description of the task is discussed below.

1.3 Research Methodology

The method adopted for this thesis are theoretical studies, acquisition of data and information and experimental set ups. The theoretical studies are mainly based on the 3GPP specifications, IETF Request for Comment (RFC)s, ITU-T recommendations and other relevant articles and books. The related specifications, in many cases, do not provide complete information regarding implementation and has left the proper techniques of implementation to be dependent on the service providers. So, the information from people of different operators is required to compliment the information drawn from specifications and documents. In order to find the actual implementation technique, people working in different telecommunication operator were contacted. The expected information from those people are the answers to the following questionnaire:

• What are the communication and security layers belowAKAin case ofIP based network (LTE),UMTSandGSM?

• What mechanisms are used by operators underneath the protocol stack to protect the sessions between different calls?

• What communication security techniques are used between the serving and home network in the roaming situation, and within each mobile operator domain communication with theAuthentication Centre (AuC)?

• Which communication security techniques are used to secureSecond Gen- eration (2G)/Third Generation (3G)user roaming in3G/2Genvironment or vice-versa?

• Which of security techniques like: IPsec, MAPsec, Radius/Diameter etc.

are chosen/used by operator?

(22)

4 CHAPTER 1. INTRODUCTION

The tableA.1in AppendixAcontains the list of people from different coun- tries who were contacted.

Unfortunately, the sought information was not obtained. The only information obtained was not enough to derive a conclusion. This vacuum compelled us to model a system based only on the information derived from several specifications. After developing a model, different tools to implement this model were searched. Owing to the time taken to understand the tool, unanticipated limita- tion of the selected tool to perform the required and expected implementation, the inability of alternate tools to cope those limitations and the time boundary to carry out this thesis work, the last objective, i.e. to construct a simulation tool, of the thesis work could not be achieved as desired. Although the desired construction of software simulation was not successful, the explanation of the protocols are assisted by the experimental set ups as described in chapter3.

1.4 Scope of the work

This thesis work is intended to check the possibility of Session Mix-up attack in real scenario. The analysis is based on the information provided by the several specifications. This work do not perform any computational and cryptographic analysis, rather the decisions are based on protocol level analysis. The analysis of protocols are assisted by minimum implementation of them. The required software simulation are not coded and developed on our own effort but pre developed tools were searched. The derived conclusions are not tested in the real world implementation. This work attempts to find the relevant information from specialised people and standards and use the information to construct a model. Thus, developed model is tried to implement and test by use of some pre built open source tools.

1.5 Review of Report

The report contains five main chapters, references and the appendices. The summary of each chapter is provided below:

• Chapter 1: Introduction

This chapter explains the problem in simple words and presents the motivation to carry out this work. Finally this chapter describes the structure of report and summarises the overall report.

• Chapter 2: Background Theory

The theories which provide basic understanding of the terms, protocols and their working relevant to this thesis work are explained in this chapter.

(23)

1.5. REVIEW OF REPORT 5

This chapter elaborates the background literature based on several specifications, documents, books and various sources. Here, the UMTS/LTE AKAprotocol, the Session Mix-up attack,Network Domain Security (NDS), LTEbased protocols likeNDS-IP(IPsec) and Diameter andUMTS related protocols likeMobile Application Part(MAP) ofSignalling System 7(SS7), Transaction Capabilities Application Part (TCAP) and MAPsec are explained. These explanations are the base for the modelling, implementation and discussion part of this thesis.

• Chapter 3: Lab Experiments

This chapter explains about the tools used to obtain the implementation phase. Here the protocols Diameter andIPsecare explained with help of simple implementation. The latter part of this chapter explains about the model developed, attempts to implement the model, problems faced and some suggestions for further work.

• Chapter 4: Discussion and Evaluation of the work

This chapter presents the discussions related to session mix-up attack and its possibility based on the theories provided in Chapter2. TheAKApro- tocol stacks i.e. S6a application forLTEand MAP application forUMTS are illustrated. With the help of session specific parameters the findings are discussed.

• Chapter 5: Conclusions and Further Extensions

The concluding remarks of the overall thesis work, the limitations and the future works to mitigate those limitations are discussed in this chapter.

(24)

(25)

Chapter 2 Background Theories

The wireless communication system has passed through three major phases and reached the fourth phase,4G, also popular with nameLTE. The major portion of this study covers the description and analysis based on the current phase LTE and its predecessor UMTS. The working of UMTS and LTE, where our study is concerned is pretty similar. So, some of the explanations details only one of these system, in most cases it is LTE. The LTEbeing the latest system is supposed to surpass the shortcomings of older and hence is given more preference in this work. Here, in depth study of the protocols carrying and securingAKA messages betweenHNand SNis provided. In this chapter, first a view to LTE components and interfaces between components are presented. Then, theories and various processes based on several specifications,RFC’s, papers, books and recommendations are elaborated in order to clarify several related terms and overall objectives of the work.

2.1 UMTS/LTE Components and Interfaces

The basic components of LTEsystem and the interfaces between these components is shown in figure 2.1. The components and interfaces for UMTS system are defined in 3GPP specification3GPP Technical Specification (TS) 09.02 [4]. The different components of the figure are obtained from several sources through internet. The figure comprises of three parts, i) the User side, ii) Serv- ing Network side and iii) Home Network side. The user side consists of UE andUser Subscriber Identity Module (USIM), which are in the hands of users.

TheEvolved NodeB (eNodeB) is equivalent toBase Station (BS)ofGSM and Serving Gateway (S-GW)serves the purpose of routing user data, handling of inter-eNodeBhandover and act as anchor for mobility. The third part HNcon- tains Home Subscriber Server (HSS) where all the subscription data of users reside. Any service, either voice or data is the result of interaction of the entities

7

(26)

8 CHAPTER 2. BACKGROUND THEORIES

of these three parts. The link betweenUE/USIMand eNodeB(the blue line) is termed asU uinterface by3GPP. The link fromeNodeBtoMobility Management Entity (MME)and S-GW, denoted by green line in figure areS1−M M E and S1−U interfaces respectively. The communication in the interfacesS1−M M E and S1− U is protected by IPsec. The "Authentication and Key Agreement"

portion ofAKAruns fromUSIMtoMMEas shown in figure. The interfaceS11 betweenMMEandS-GWis not discussed here. Finally the link marked by red line in figure between MMEand HSSis theS6a interface. TheAKAmessages between MME and HSS are transported through this interface. The diameter protocol is implemented in this interface. The authentication data request for an user is sent toHSSbyMMEand theAuthentication Vector (AV)s generated for respective users are sent toMMEbyHSSusing diameter protocol. The details onS6ainterface and the Diameter protocol is explained in subsequent sections.

Also the diameter protocol is more clarified by its implementation in further chapters. The communication betweenMMEand HSSas shown inside dotted box "Implementation part" was supposed to be modelled and implemented.

User Side

Serving Network

Home Network S6a

Mutual Authentication and Key Agreement Authentication Data Transfer

Implementation part UE Uu

USIM

Diameter eNodeB

IPsec S1-MME

IPsec S1-U

S11

Figure 2.1: LTE Security Architecture with Interfaces.

2.2 The AKA protocol

The Authentication and Key Agreement protocol is a three parties handshake between User(UE/USIM), SN(MME or Visitors Location Register (VLR)) and HN(Home Location Register (HLR)orHSS/AuC). In this protocol the user requesting for service and the network providing the service are authenticated to each other and keys for subsequent communication are derived. TheAKApro- cess forUMTSandLTEare almost similar except that the participating entities and some exchanged parameters are termed differently. In order to generalise

(27)

2.2. THE AKA PROTOCOL 9

AKAprocess for bothUMTSandLTEwe have used some terms to represent entities of both system in a common way. The termSNdenotes bothVLRofUMTS andMMEofLTE; the termHNrepresentsHLR/AuCofUMTSandHSSofLTE andU seris used to denoteUE/USIMin our description. The above mentioned related terms may be interchangeably used in further part of this report.

TheAKA protocol for the case of3G UMTS is detailed in specification [5] and specification [6] and book [7] describes the procedure for case ofLTE/EPS. The termEvolved Packet System (EPS) representLTEsystem in case of 3GPPwire- less communication. So these terms may be interchangeably used in further discussions of this report. The detailed explanation of the protocol is also presented in [8]. This thesis work is continuation to the work carried on [8]. The summary ofAKAprocess follows as: theSNfetches user specific parameters fromHNto which the user has subscription. Some of these parameters are transferred to U ser where further elements are derived and transported back again toMME.

The U ser part derives further elements only after validating the freshness of the parameters and successful network authentication. Now theSN makes the authentication decision based on the comparison of the elements received from HNandU ser.

The protocol completes in two phases: 1) Distribution ofAVs and 2) Authen- tication and key Agreement. Several terms related to AKAand their meaning listed in table2.1will be used in further explanation ofAKA.

Terms Name Purpose

IM SI Permanent Subscriber

Identity identify a user on the radio path

K₀

secret key shared between theU SIM

and theAuC

used to derive other Authentication parameters

RAN D Random Number

Generated inAuC used to derive other parameters and sent to USIM as an element of AV

SQN Sequence number to ensure the freshness of the vectors

(X)M AC (Expected) Message

Authentication Code M AC and XM AC are compared inUSIM Continued on next page ...

(28)

Table 2.1 – continued from previous page

Terms Name Purpose

(X)RES (Expected) user

response RES and XRES are

compared in MME to authenticate the user AU T N Authentication Token one of AV parameter;

SQNH and M AC are extracted from AU T N inUSIM

CK Cipher Key generated in UE; used

to encrypt the messages

IK Integrity Key generated in UE; used

for integrity protection K_{ASM E} Key Access Security

Management Entity used in generation of Access Stratum (AS) and non Access Stra- tum (nAS) ciphering and integrity keys AK Anonymity Key conceals theSQN but is

optional SN_id Serving Network

Identity used to compute

K_{ASM E} and to authenticate serving network Table 2.1: Terms used in AKA process.

Based on all above mentioned specifications, book and report, theAKAis pictured in figure2.2and the process is summarised as below:

• Phase 1: Distribution ofAV

1. SNrequests user id fromU ser(this step is not always performed and not shown in figure).

2. U sersendsInternational Mobile Subscription Identity (IMSI)as user id response toSN.

3. SN sends authentication data request to HN. Along with this message, identities of both user i.e. IMSI and serving network i.e SN_id are sent.SN_idis required to deriveK_{ASM E}.

4. HNgeneratesAVs and sends it toSNalong with authentication data response. The generation ofAVs is not described here.

(29)

2.2. THE AKA PROTOCOL 11

Thus receivedAVs are stored inSNand used for the further authentication of theU ser. Here completes the first phase ofAKA. The elements ofAVs differ forGSM,UMTSandEPS. The table2.2lists the elements comprising AVin all three cases.

USER SN HN

User id response

(TMSI/IMSI) auth data request

(IMSI, SNid)

new RAND

MAC← f1,K0 (SQNH || RAND) XRES ← f2,K0 ( RAND) CK ← f3,K0 ( RAND) IK ← f4,K⁰( RAND) AUTN←(SQNH ||MAC) generate Skey auth data response

(RAND, AUTN, XRES, Skey) User auth request

(RAND, AUTN) XMAC← f1,K⁰(SQNH || RAND)

Verify MAC = XMAC check (SQNH, SQNU) RES ← f2,K0 ( RAND) CK ← f3,K0 ( RAND), IK ← f4,K0

(RAND)

User auth response (RES) RES ?=XRES

?

Phase1:

Distribution of Authentication Vector

Phase2:

Authentication and Key Agreement

Figure 2.2:

Authentication and Key Agreement Protocol [8].

Here,

Skey ←CKkIKforUMTSand

Skey :=K_{ASM E} ←KDF(SQN_HkCKkIKkSN id)forLTE.

(30)

GSM UMTS EPS

Elements of AV authentication triplets

1. RAND 2. XRES 3. Kc

authentication quintuplets

1. RAND 2. AUTN 3. XRES 4. CK 5. IK

authentication quadruplets

1. RAND 2. AUTN 3. XRES 4. KASM E

Table 2.2: Elements of AV for GSM, UMTS and EPS.

• Phase 2: Authentication and Key Agreement

1. Now SN sends two elements (RAN D and AU T N) of AV to U ser along with authentication request message.

2. InU serside,XM ACandRESare computed. Thus computedXM AC is verified with the one ofHSSsent by MME(contained in AU T N).

Another verification also takes place here. That is verification ofSQNH

andSQN_U. Only if both verifications pass, U sergeneratesRES and sends it toSNas user authentication response.

3. NowSNcompares theRESfromU serandXRESfromHN. User authentication is successful if both are equal. Thus authenticated users can only participate in further communication and serving network serves for the communication procedure.

There are several functions used to generate or compute the elements related toAKA. These functions and processes are already detailed in report [8]. The standard [5, p.23] defines these functions and their use for computation ofAKA related values. In [5, p.22-25] generation ofAVs and authentication function in USIMare explained with help of figures.

2.3 The Session Mix-up Attack

In the session mix-up attack two concurrent sessions of AKA in SN for two different users are swapped by the attacker. The one of the user of which session is swapped is attacker himself. Thus, after being authenticated in a session of an honest user the attacker can now carry on subsequent communication steps on behalf of the genuine user. Figure 2.3 shows the session mix up attack. In the figure, A is the attacker, S is SN, H is HN, U is a U ser and U⁰ is a user under control of attacker. The details on session Mix-up attack is described in document [1]. Also a brief scenario of attack is explained in [8].

(31)

2.4. NETWORK DOMAIN SECURITY (NDS) 13

Figure 2.3: Session Mix-Up Attack [1].

As explained in [8], the attack is against AuthenticationDataResponse. If we look in the figure2.2ofAKA, this message "AuthenticationDataResponse" is a message fromHSStoMME. This message contains all the keys and parameters corresponding to the user. In the attack described above, this message generated by HSSfor a genuine user is supposed to be utilised by user under control of attacker. Thus, the existence and the purpose of this attack is only fulfilled if the HSSreally fails to detect the swap in session of two users. In order to check this, here we are trying to construct a real scenario of message exchange betweenHSS andMME. TheNDSdeals with the security of nodes ofCore Network (CN)in case ofUMTS Terrestrial Radio Access Network (UTRAN)orEvolved UTRAN (EUTRAN). Hence the next step of this work proceeds with the further study of NDSin case ofUMTSandLTE.

2.4 Network Domain Security (NDS)

The GSM networks lack security in transfer of messages within the network.

The specification [9] states that:"The absence of security inSS7networks is an identified security weakness in 2Gsystems". Also in the same specification it is mentioned that it is a goal of3Gsystems to protect theCNsignalling protocols. The 2Gand nonIPbasedUMTSrun onSS7signalling whileLTEandIPbasedUMTS core use IP. So there is a need of security solutions for both SS7and IPbased protocols. The protection forSS7based protocols are done in application layer and forIPbased protocols protection is at network layer [10]. The protection of the signalling messages within network domain thus varies requiring separate

(32)

procedures forUMTS(non-IPbased core) andLTE(IPbased core). The further discussions provided below show that in case ofUMTSwhereSS7signalling is used, protection ofMAP termed asMAPsec is used, while for the case of LTE andIPbasedUMTScore native IPbased protection termed as IPsecis applied.

The 3GPPspecifies both of these protocols with terms NDS-MAP and NDS-IP in several specifications. The overview to these protocols based on3GPP specifications and other defining bodies likeIETFforIPsecandITU-TforMAP-SS7 is provided in sections below.

2.4.1 NDS-MAP and MAPsec

From the document [11] provided by Prof. Do Van Tanh, it is known thatMAP is used to carryAVs fromHLR/AuC to VLRin case of UMTS. In [12, p.74], it is further confirmed thatMAP is the mobile specific part of SS7. In [7, p.40] it is mentioned that MAPprotocol carries the control messages for UMTS AKA.

The document [10] further states that:"After careful analysis, it was found that one could only afford to protect theMAPprotocol in this way". "..in this way"in the statement hints towards protection in application layer. Thus,MAPsec[9] can be an ultimate choice forSS7based networks which require protection at application layer. The major drawback of protection at application layer is that it requires modification of target protocol itself in cost of expenses and time and the procedure is to be repeated for every target protocols [10]. The statement: "MAP is a crucial core network protocol that provides mobility management services and dis- tributes the AV security data from the HLR/AuC to the VLR/Serving GPRS(Global Packet Radio Service) Support Node (SGSN)"in [11], a report from Telenor¹by the same author of [10] supports the adoption ofMAPin case ofUMTS AKA.

In SS7 signalling, theTCAP protocol, defined in ITU-T recommendations Q.771-Q.775 facilitates concurrent dialogs between same sub-systems [13]. The Transaction IDs are used to differentiate these concurrent dialogs. A specific operation invocation is identified by invoke-ID [14]. The detailed description and operation of TCAP, invoke-ID and Transaction IDs can be found in ITU- Trecommendations Q.771-Q.775 ([15, 14, 16, 17, 18]). TheITU-Tspecifications Q.770-Q.849 deals with SS7 signalling. Although no3GPP specifications were found mandating the use of MAP in case of UMTS, the information obtained from [11, 12, 7] suggest thatMAP is used asCNprotocol in case of UMTS. As the MAP in case of 3GPP bears sensitive functions like carrying session keys, authentication data etc., theMAPmessages are to be protected. The3GPPspec- ification [9] provides the mechanisms and procedures to protect MAPprotocol and the actual implementation ofMAPcan be found in [19].

1Telenor is a Norwegian mobile operator and also one of the world’s major mobile operators

(33)

Based on the specification [9] and [12, p.74-76] general working ofMAPsec can be defined as follows. The keys, algorithms and protection profiles for the protection ofMAPare defined by establishing and negotiatingSecurity Associ- ation (SA)s betweenMAPelements [9]. Now using thisSA, the plaintextMAP is encrypted and the encryptedMAPmessages are placed inside anotherMAP message along with the cryptographic checksum (i.e. Message Authentication Code (MAC)) [12]. TheMAPsec SAs are distributed and negotiated inKey Ad- ministration Centre (KAC)s usingInternet Key Exchange (IKE). Thus achieved protection byMAPsecprovides following security services:

• Connectionless (cryptographic) data integrity of the MAP messages.

• Data origin authentication for the MAP messages.

• Replay protection for the MAP messages.

• Confidentiality (encryption) for the MAP messages (Optional).

The figure 2.4 show the entities and interfaces of MAPsec. The terms used in figure are shortly described below:

Figure 2.4: Overview of Zd, Ze and Zf interfaces [20].

• Zd-interface (KAC-KAC): to negotiateMAPsec SAs between two security domains or twoPublic Land Mobile Network (PLMN)s.

• Ze-Interface (KAC-NE): used to transport negotiatedMAPsec SAs and relevant. security policy information fromKAC toMAP-Network Element (NE)under same security domain.

(34)

• Zf-interface (NE-NE): For the MAPsec transactions within NEs of same domain or different domains. ReceivedSAs are used to protectMAPop- erations betweenNEs.

The specification [19, p.98] lists the Authentication parameters for GSM/

UMTS. The clause 8.5 of specification [19] details MAP based Authentication Management services. VLRandHLR; SGSNandHLR; MMEandHSSuse service MAP_SEND_AUTHENTICATION_INFO parameters to retrieve Authenti- cation Information fromHLRorHSS. TheHSSreturnsEPSauthentication vectors in case the requester isMMEand user is aUMTSuser else if the node is not MME,HLRshall return authentication quintuplets forUMTSuser and authentication triplets forGSMuser [19]. The table2.3lists the parameters of

MAP_SEND_AUTHENTICATION_INFO service as shown in table 8.5/2 of [19].

Table 2.3: MAP_SEND_AUTHENTICATION_INFO parameters [19, p.146].

The invoke id (invoke-ID), the first parameter in the list2.3, is mandatory in all four services. In 3GPP specification, invoke-ID is defined as :"This parameter identifies corresponding service primitives. The parameter is supplied by the MAP service-user and must be unique over each service-user/service-provider interface." [19, p.63]. The procedures for service invocation is described in clause 15.5.1 of [19]. This confirms that there is a unique identifier for each user service request tracked and maintained by theSNside.

The invoke-ID is detailed in ITU-T standards. The invocation, operation of invoke-ID, as defined inITU-Tstandard Q.775 [18] should be different from other concurrent invocations. The concurrent invocations may be of either same operation or different operations [18, p.5]. Hence invoke-ID is an identifier of particular activation of operation. TheITU-Tstandard Q.775 in section 2.3.1 also states that the invoke-ID may take any value which can be mapped to integer and encoded to one octet. Thus, the invoke-ID is only one octet long (value ranging from -127 to 127 [18]). The Transaction IDs which uniquely identifies

(35)

a dialogue can range from 1 to 4 octets as specified in [18, p.16]. The 3GPP specification [19, p.403] defines Transaction IDs as follow:

1 TransactionId ::= OCTET STRING (SIZE (1..2))

-- This type carries the value part of the transaction identifier which is used in the

3 -- session management messages on the access interface. The encoding is defined in

-- 3GPP TS 24.008

Thus, the length of Transaction IDs used in case of3GPP operations is upto 2 octets. Again, the3GPPspecification [21] in clause 11.2.3.1.3 indicates that only 4 bits (5-8 bits of first octet) of standard L3(layer 3) message contains Transaction Identifier. The same specification also defines, an octet longProcedure transaction identity (PTI), in clause 11.2.3.1a. The function of both transaction ID and PTIare distinguish message flows.

The discussion above concludes that in3GPPone octet invoke-ID is used while the length of transaction-ID may extend upto 2 octets.

2.4.2 NDS-IP and IPsec

Microsoft definesIP Security(IPsec) [22,23] as"Internet Protocol security (IPSec) is a framework of open standards for ensuring private, secure communications over In- ternet Protocol (IP) networks, through the use of cryptographic security services."[24].

TheLTEsystem is an allIPbased system. So, the communication between nodes inCNis also IP based and nativeIP based protection applies to the traffic between the nodes. The security architecture for IP based network core in case of 3GPP networks is described in specification 3GPP TS 33.210 [25]. The protocol to protect nativeIPcommunication is termed as (IPsec) and is defined in IETF based RFC-4301 [22] which obsoletes RFC-2401 [26]. The IPsec provides security in the network (IP) layer [25, 12, 22]. The secured network layer not only provides protection at IP but also protects upper layers [22]. The IPsec provides integrity, data origin authentication, replay protection, confidentiality and limited protection against traffic flow analysis if confidentiality is applied [22, 27, 25]. The IPsec is mandated in IPv6 while it is also supported in IPv4 [12]. The details onIPsecand its operations are not mentioned here. However the working ofIPsecis explained with a simple example of IPsecimplementa- tion later in chapter3. There are set of IETF based RFC’s detailing security of nativeIPbased systems. The terms related toIPseclisted and described in table 2.4below simplifies the understanding of working ofIPsec.

Terms Purpose

Security Domain networks managed by a single adminis- trative authority

Continued on next page ...

(36)

Table 2.4 – continued from previous page

Terms Purpose

Security Gateway (SEG)

entities on the borders of security domains; NDS/IP traffic enters and leaves security domain via SEG

Security Associations (SAs)

establishment of shared security at- tributes between two network entities Security Policy

Database (SPD)

decides which security services are to be offered and in what fashion

Security Association Database (SAD)

Database containing parameters associated to the active security associations Internet Key Exchange

(IKE)

responsible for negotiation, establishment and maintenance of Security As- sociations

Table 2.4: Some Terms related to IPsec.

TheIKE protocol [28, 29,30] is implemented between the peers to negoti- ate the security parameters required to establish a secure connection [31]. Thus, established secure channel or tunnel is then used to exchange security parameters which are required to transmit user data [31]. Both the negotiation and exchange of security parameters are based on SA [32]. SA describes the rela- tionship between two or more entities about the utilization of security services to communicate securely [32]. EachSAis identified bySecurity Parameter Index (SPI), IPDestination Address and security protocol identifier [25]. As, NDS/IP always useEncapsulating Security Payload (ESP) protocol,IPDestination Ad- dress and security protocol identifier are ESP SA endpoint and ESP protocol respectively.

There are two protocols: 1)Authentication Header(AH) [33] and 2)Encap- sulating Security Payload (ESP) [34] used by IPsecfor various operations. The Authentication Header (AH)provides connectionless integrity and data origin authentication for IP datagrams and to optionally provide protection against replays [33] whileESPprovides confidentiality, data origin authentication, connectionless integrity, an anti-replay service and limited traffic flow confidentiality [34]. TheIPseccan be implemented in two modes:

1. Transport Mode: This mode is the default mode of IPsec where only the payload of IP packet is encrypted [35, 27]. This mode is used for end to end communication [27]. The figure2.5a illustrates that AH is added in between IP payload and IP header. This AH provides integrity and authentication to that packet as explained in [27]. Similarly figure 2.6 illustrates theESPencryption ofIPpacket in transport mode.

(37)

2. Tunnel Mode: In this mode both the IP headers and IP payload are encapsulated by IPsec. This mode protectsIP traffic between different networks. The figure2.5b shows an IP packet encrypted by AHof IPsec in tunnel mode. Here the outerIP header contains the addresses of tunnel end points while the inner (encapsulated)IPheader are used to route the traffic to final destination [27]. The figure2.6shows theESPprotection in tunnel mode.

The clause 11 of specification [36] mandates the use of integrity and confidentiality protection in accordance to NDS/IP (3GPP specification TS 33.210 [25]) in case of interfaces S3, S6a and S10. The S6a interface is the interface between MME and HSS. This interface carries on AKAprocess where theAV parameters are transported fromHSS toMME. The mechanism ofIPsec in case of3GPP is provided in specification [25] and book [12] explains this mechanism in case ofUMTS. The specification [25, p10.]

states that: "For NDS/IP-networks theIPsec security protocol shall always be ESP. ForNDS/IP-networks it is further mandated that integrity protection/message authentication together with anti-replay protection shall always be used.".

(38)

IP Header Authentication Header

IP Payload

(a) Transport Mode.

IP Header Authentication Header

IP Payload IP Header

IP Packet Signed by Authentication Header

(b) Tunnel Mode.

Figure 2.5: AH encryption of IP packet in different modes (modified from [27]).

Figure 2.6: IP packet secured by ESP [37].

2.5 The Diameter Protocol

Diameter is a solution to the shortcomings of Remote Authentication Dial In User Service (RADIUS)protocol and is used in case ofAuthentication, Autho-

(39)

2.5. THE DIAMETER PROTOCOL 21

risation, and Accounting (AAA) purposes of network elements. Diameter in general (Diameter Base Protocol) is defined in IETF RFC 6733 [38]. This RFC 6733 [38] obsoletes RFC 3588 [39]. The major portion of the study was made before [39] was obsoleted, so some of the points described here based on RFC 3588 may contradict the latest specification RFC 6733. But, major changes in RFC 3588 included in RFC 6733 are studied and the analysis are tried to made based on latest specifications. All the diameter protocols are extensions of Diameter Base Protocol and every diameter nodes must support Diameter Base Protocol.

The figure2.7shows the various diameter application on top of Diameter Base protocol.

Mobile IP Application

NAS Application

SIP Application

Diameter Base Protocol

Figure 2.7: The Diameter Applications on top of Diameter Base Protocol [40].

The diameter protocol is better understood by defining some protocol related terms defined in RFC 6733 [38] and used in our case as below:

Useris the entity requesting service for which Diameter Client generates authentication request to server.

Diameter Clientsare diameter capable nodes attached in the edge of a network providing access control services to users in that network.

Diameter Serveris a diameter node that provides Authentication, Authorisa- tion, and Accounting (AAA)for particular realm.

Diameter Nodeis a host implementing diameter protocol. The clients, server and agents are diameter node.

Diameter Peersare those nodes with direct transport connection.

Diameter Agentprovides relay, redirect, translation services.

Sessionkeeps track of progression of a particular activity. A session ID is ded- icated to a particular session.

(40)

Realm is like a domain but has a particular naming convention. The string immediately following ’@’ of identity is the realm. The Fully Qualified Domain Name (FQDN)gives the realm.

TheAttribute Value Pairscontain header and encapsulate routing information as well asAAAinformation.

The Diameter Header format is shown in figure2.8. The above listed terms and the terms in message headers are detailed in [38].

Figure 2.8: The Diameter Header Format [38].

Some of the terms relevant to our studies are listed below. Following description is based on [38] and details on following terms can be found in [38]

itself.

Command Code is of three octets. This value is used to communicate the command associated with the message. The Command Code values 16,777,214 and 16,777,215 are used for experimental use.

Application-ID is of four octets. This value identifies the application (authentication application, an accounting application, or a vendor-specific application) for which the message is applicable.

Hop-by-Hop Identifier is an unsigned 32-bit monotonically increasing integer field, with randomly generated start value. This values helps to match requests and replies. This value MUST be unique for a given connection and the value in corresponding answer MUST be same as in request. The answer message with unknown Hop-by-Hop Identifier MUST be discarded [38].

(41)

End-to-End Identifier is an unsigned 32-bit integer field. This value is used to detect duplicate messages.

2.5.1 Protection of Diameter Messages

The RFC 6733 mandates the secure transport of Diameter messages [38, p12.].

This recommendation further statesTransport Layer Security (TLS)/Transmission Control Protocol (TCP)andDatagram Transport Layer Security (DTLS)/Stream Control Transmission Protocol (SCTP)as primary methods to exchange the diameter messages. The IPsec is mentioned to be the secondary method of se- curing Diameter messages. However,NDS-IPrelated3GPPspecifications mandates the use ofIPsecto secure nativeIPbased communication in [25, p9.]. The specification [25, p9.] states that: "For native IP-based protocols, security shall be provided at the network layer. The security protocols to be used at the network layer are the IETF defined IPsec security protocols as specified in RFC-4301 [22] and in RFC- 2401 [26].. The 3GPP specification [36, p59.] mandates the use of NDS-IP for integrity and confidentiality protection ofS6a interface. And the3GPP specification [41] mentions the use of Diameter protocol to exchange messages along S6a interface. Hence from the 3GPP specifications [25, 36, 41] it can be con- cluded that Diameter messages in case of LTEare protected by IPsec security mechanisms. The mechanisms of protecting Diameter message byTLSorDTLS are not discussed here and the details can be found in [38].

2.5.2 Working of Diameter

The message sequence diagram shown in figure2.9shows the general steps and messages exchanged between User, Diameter Client and Diameter Server. The figure and its elaboration are based on the description provided in [40]. For the connection request from user, the client node (acting as anNetwork Access Server (NAS)) gathers credentials related to user and sends the access request message to the server. Now the server, checks the information received from client and authenticates the user. After checking for authentication, the server generates the response message. The content of this message is either user’s access privileges or an error (reject) in cases of successful authentication and authentication failure respectively. The granular explanation for diameter message exchange between Diameter Client and Server is presented in implementation part in section3.4.

(42)

User

Client

^Server User connection request

Collect User Credentials

Authentication

Response message

User Client

Server

Authentication Access request message

Figure 2.9: General Message Diagram for Diameter Authentication.

The connection between Diameter nodes (client and server in our case) is required before the application specific messages (in above case Access Request message and Response message) can be exchanged. In addition, the peers (Di- ameter nodes after connection is established) may require to discover peer and are required to exchange capabilities before the application specific operations can occur. These messages as specified in RFC-6733 [38] are : 1) Peer Connec- tion, 2) Peer Discovery and 3) Capabilities Exchange. The figure2.10 illustrates a Client-Server communication with these messages. The procedure for Peer Connection, Peer Discovery and Capability Exchange is elaborated in [38] and explained with help of example in section3.4.

However the use of Diameter in case of3GPP AKAdoes not exactly match the process shown in figure2.9as the authentication process is carried onMME which is equivalent to nodeClientof Diameter. This requirement for3GPPwas a hurdle to implement Diameter protocol in case ofLTE AKA. The effect of this hurdle is explained in section 3.6. The Diameter in case of 3GPP/LTE AKA is explained in section2.5.3.

(43)

Peer Connection

Peer Discovery

Capabilities Exchange

Server Client

Application Specific Messages

Establishment of connection with peers using valid DiameterIdentity

To discover a first-hop Diameter Agent

To discover another Agent for further handling of Diameter operation Discovery of peer’s Identity and capabilities

Application related messages (AIR and AIA in case of S6a authentication information retrieval application)

Figure 2.10: Diameter Message Exchange.

2.5.3 S6a Interface and Diameter in 3GPP

Diameter in case ofIP based system is equivalent toMAPof SS7system. The specification [41] indicates that Diameter protocol is used for the exchange of messages inS6aand S6dinterfaces ofIPbased3GPPstandards and details the procedures related toMME-HSS(S6a) andSGSN-HSS(S6d) interfaces. The protocol specifications and message parameters for these interfaces are also detailed in the same document. The S6a interface as defined in 3GPP specification TS 23.401 [42] is the link betweenMMEandHSS. The same specification states that

"It(S6a) enables transfer of subscription and authentication data for authenticating/au- thorizing user access to the evolved system (AAA interface) between MME and HSS".

The specificationETSI TS129.272 [41] explains the use of diameter application for S6 interface. The functions ofMMEand HSSalong with other entities are explained in specification [42]. The clause "5.2.3" of [41] explains the Au- thentication Procedures. As explained in the specification, the Authentication Information Retrieval procedure between MME and HSS is mapped to com- mandsAuthentication Information Request (AIR)andAuthentication Informa- tion Answer (AIA)of Diameter protocol. Authentication Information fromHSS is requested usingAIRprocedure. TheIMSIand visitedPLMNID are mandated to be sent in request. TheAIAprocedure replies with Result Code and Authen-

(44)

tication Information. The other elements ofAIRandAIAand their mapping to 3GPPare tabled in [41] (Page 29). This result code is checked byMME. In case the check is success and AIAcontains Authentication Information, the AVs received are used byMME[41] for furtherAKAsteps. The Diameter application forAKAprocess is sketched in the figure2.11. The messagesAuthentication In- formation Request(AIR) andAuthentication Information Answer(AIA) of the figure2.11 are Diameter commands and listings2.1 and2.2 show message format for these commands. The messages User Authentication Request and User Authentication Response areAKAmessages exchanged betweenU ser andSN.

These messages are explained in section2.2.

User Authentication Request

User Authentication Response

Same Session maintained between nodes

User

Client

^Server Service Request

Authentication Authentication Information

Answer (AIA)

USIM MME

HSS Creation of session

for User

Generation of Authentication

Vectors Authentication Information

Request (AIR)

Authentication

Figure 2.11: Application of Diameter forAKAprocess.

The clause 7 of [41] states that a part from exceptions defined by this specification, diameter in case of3GPPis used as per Diameter Base Protocol specified in IETF RFC3588 [39] (now RFC6733 [38]). The figure 2.12 shows the implementation of S6 interface. In the figure, it is seen that the link between MME and HSS is S6a interface. The other interfaceSGSN-HSS, S6d has similar implementation as S6a interface but is beyond our interest. The figure4.1 shows the protocol stack for S6a interface. The figure shows that the AKAmessages, specifically authentication parameters are carried out by Diameter Protocol. In

(45)

addition theSCTPis used as transport protocol andIPis used in network layer.

The control-plane for S6a interface as described in specification [42] is shown in figure 2.13. The specification ETSI TS129 272 [41] in clause 7.1.8 specifies the diameter application for S6a interface. The clause defines S6a interface to be IETFvendor specific Diameter application where vendor is 3GPP with vendor identifier 10415²as assigned byInternet Assigned Numbers Authority (IANA)

3.

Figure 2.12: The S6 Interface [43].

Figure 2.13: The S6a Control Plane [42].

As this work is meant to analyse the Authentication procedure between MMEandHSSfor the exchange ofAVparameters, in depth study of the diameter protocol in case of authentication is made. The latter objectives of Diameter protocol Authorisation and Accounting are not dealt here. Our study is focused

2 The list of private enterprise numbers can be found in http://www.iana.org/assignments/enterprise-numbers

3TheIANAis responsible for the global coordination of theDNSRoot,IPaddressing, and other Internet protocol resources.

(46)

towards theNDSsecurity and particularly towards exchange ofAKAmessages.

From earlier description, it is known thatAKAmessages in case ofLTEare exchanged between MMEof SN and HSSalong S6a interface. Hence details are focused for authentication procedures betweenMMEandHSSDiameter based S6ainterface. The specification [41] in clause 5.2.3 describes the authentication procedures. The clause defines two commands: 1) Authentication Information Requestand 2)Authentication Information Answerused in case of Authentica- tion Information Retrieval. The message format for these commands are provided by same specification in clauses 7.2.5 and 7.2.6. The message format for AIR and AIA commands are shown in listings Message format 2.1 and 2.2 respectively.

Message format 2.1: Message format for AIR Command

< Authentication-Information-Request> ::= < Diameter Header: 318, REQ, PXY, 16777251 >

2 < Session-Id >

[ Vendor-Specific-Application-Id ]

4 { Auth-Session-State } { Origin-Host }

6 { Origin-Realm } [ Destination-Host ]

8 { Destination-Realm } { User-Name }

10 *[Supported-Features]

[ Requested-EUTRAN-Authentication-Info ]

12 [ Requested-UTRAN-GERAN-Authentication-Info ] { Visited-PLMN-Id }

14 *[ AVP ]

*[ Proxy-Info ]

16 *[ Route-Record ]

Message format 2.2: Message format for AIA Command

< Authentication-Information-Answer> ::= < Diameter Header: 318, PXY, 16777251 >

2 < Session-Id >

[ Vendor-Specific-Application-Id ]

4 [ Result-Code ]

[ Experimental-Result ]

6 [ Error-Diagnostic ] { Auth-Session-State }

8 { Origin-Host } { Origin-Realm }

10 * [Supported-Features]

[ Authentication-Info ]

12 *[ AVP ]

*[ Failed-AVP ]

14 *[ Proxy-Info ]

*[ Route-Record ]

(47)

In line 2 of both the Message formats, there is Session-Id. This Session-Id is defined in Diameter Base Protocol ([38, p116]). The Session-IdAttribute Value Pair (AVP) identifies a specific session. It is created by the nodes which initi- ates the session. Most of the cases it is Client and here in case of3GPP/LTEit is SN. The RFC 6733 [38] explains Session-Id as one of the content of request command issued by Client to Server whenever a user requests access to the network. The statement: "The Session-Id is a means for the clients and servers to correlate a Diameter message with a user session.", stated in [38, p98] shows that there a particular session maintained between User, Client and Server for a particular service request. This Id initiated by Client identifies different users and different services. The format of the Session-IdAVPas mentioned in [38, p117]

is< DiameterIdentity >;< high32bits >;< low32bits > [;< optionalvalue >]. Here, theDiameterIdentityis anFQDNname of a Diameter node and identifies that node andoptional valueis implementation specific.

In lines 11 and 12 of Message format 2.1, authentication information for EUTRAN and UTRAN/GERAN(GSM/EDGE Radio Access Network) are requested. TheAVPformat for Requested-EUTRAN-Authentication-info is given below:

AVP format 2.3: AVP format for Requested-EUTRAN-Authentication-info

1 Requested- EUTRAN-Authentication-Info ::= <AVP header: 1408 10415>

[ Number-Of-Requested-Vectors]

3 [ Immediate-Response-Preferred ] [ Re-synchronization-Info ]

5 *[AVP]

TheAIAcommand answersAIRwith the authentication information. This answer contains theAuthentication Vectorfor requested user. TheAVPformat for Authentication-info is shown inAVPformat2.4andAVPformat2.5contains theAVPformat forEUTRANvector.

AVP format 2.4: AVP format for Authentication-Info

1 *[ E-UTRAN-Vector ]

*[UTRAN-Vector]

3 *[GERAN-Vector]

*[AVP]

AVP format 2.5: EUTRAN Authentication vector parameters

[ Item-Number ]

2 { RAND } { XRES }

4 { AUTN } { KASME }

6 *[AVP]

(48)

Similarly,AVPformats for theUTRANandGSM/EDGE Radio Access Net- work (GERAN)are shown in sections 7.3.12, 7.3.19 and 7.3.20 of [41].

Is the Session Mix-up Attack on the UMTS/LTE AKA Protocol Practical?

Is the Session Mix-up Attack on the UMTS/LTE AKA Protocol Practical?

Ashim Bhusal

Is the Session Mix-up Attack on the UMTS/LTE AKA Protocol Practical?

TTM4905 Report Master Thesis

Project Member :

Ashim Bhusal (bhusal@stud.ntnu.no)

Supervisor : Joe-Kay Tsay, NTNU ITEM (joe.k.tsay@item.ntnu.no)

Responsible Professor : Professor Stig Frode Mjølsnes, NTNU ITEM (stig.mjolsnes@item.ntnu.no)

Norwegian University of Science and Technology

Autumn 2012

Abstract

Preface

Contents

List of Figures

List of Tables

Acronyms

Chapter 1 Introduction

1.1 Problem Description

1.2 Motivation

1.3 Research Methodology

1.4 Scope of the work

1.5 Review of Report

Chapter 2 Background Theories

2.1 UMTS/LTE Components and Interfaces

2.2 The AKA protocol

2.3 The Session Mix-up Attack

2.4 Network Domain Security (NDS)

2.4.1 NDS-MAP and MAPsec

2.4.2 NDS-IP and IPsec

2.5 The Diameter Protocol

Mobile IP Application

NAS Application

SIP Application

Diameter Base Protocol

2.5.1 Protection of Diameter Messages

2.5.2 Working of Diameter

2.5.3 S6a Interface and Diameter in 3GPP