Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Improved IP multimedia subsystem authentication mechanism in next generation networks J. Sharma, Madhu 2011

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Notice for Google Chrome users:
If you are having trouble viewing or searching the PDF with Google Chrome, please download it here instead.

Item Metadata


24-ubc_2012_spring_jsharma_madhu.pdf [ 3.58MB ]
JSON: 24-1.0072520.json
JSON-LD: 24-1.0072520-ld.json
RDF/XML (Pretty): 24-1.0072520-rdf.xml
RDF/JSON: 24-1.0072520-rdf.json
Turtle: 24-1.0072520-turtle.txt
N-Triples: 24-1.0072520-rdf-ntriples.txt
Original Record: 24-1.0072520-source.json
Full Text

Full Text

Improved IP Multimedia Subsystem Authentication Mechanism in Next Generation Networks by Madhu J. Sharma B. E. Electronics and Communication, Anna University, India, 2008 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF Master of Applied Science in THE FACULTY OF GRADUATE STUDIES (Electrical and Computer Engineering) The University Of British Columbia (Vancouver) December 2011 c©Madhu J. Sharma, 2011 Abstract The provision of IP Multimedia Subsystem (IMS) introduces important advantages for users of 3G-WLAN access networks. In order to enjoy the benefits of a stan- dardized IMS architecture, the user has to undergo authentication procedure with the access network, followed by an authentication procedure with the IMS layer. This multi-pass authentication procedure is essential for securing IMS from ma- licious users, resulting in added overhead and possible quality of service degra- dations. This approach is highly inefficient. The problem is further compounded when the user moves from one WLAN domain into another, which requires the authentication procedure to be repeated. To mitigate this problem, we present a lightweight, robust, and architecture-compatible IMS authentication protocol that implements a one-pass IMS procedure by promoting efficient key re-use for a mo- bile user. We further show how our protocol is extended to support IMS access over Long Term Evolution (LTE) -Heterogeneous network. IMS, an access network ag- nostic overlay, is adopted as a de facto standard for for delivering voice over LTE. We make use of Home Node B femtocells to perform the role of IMS proxy. To verify the feasibility of using our protocol in mobile networks, an abstract model of our protocol is derived. The abstract model is emulated using Asterisk server and virtualization techniques. The security of the proposed protocols is verified using the Automated Validation of Internet Security Protocols and Applications (AVISPA) security analyzer. We also analyze the authentication delay of our pro- posed scheme. Numerical results reveal a reduction in user authentication delay of more than 50 percent compared to the existing authentication procedure. ii Preface Some of the content in this thesis has previously been accepted for publication. Specifically. • Sharma, M.J.; Leung, V.C.M. , ”Improved IP Multimedia Subsystem Au- thentication mechanism for 3G-WLAN networks, ”Security in Computers, Networking and Communications Workshop”, 2011, IEEE Conference on, April 2011 • The extended version is published in International Journal of Security and Networks, 2011 - Vol. 6, No.2/3 pp. 90 - 100 The content contained in these publications include portions of all Chapters, except for a few sections of Chapter 2 and Chapter 3. I am the primary author for the publications listed above. My tasks included literature review, problem identification, protocol formulation, implementation and writing manuscripts. My supervisor is the secondary author, who provided invaluable guidance during the course of my research. IEEE and Inderscience Publishers hold the copyrights for the aforementioned publications. However, I hold the right to use the manuscript for my thesis. iii Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Organization of Thesis . . . . . . . . . . . . . . . . . . . . . . . 7 2 IMS Authentication in Heterogeneous Networks . . . . . . . . . . . 8 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2 IMS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1 IMS Core Network . . . . . . . . . . . . . . . . . . . . . 9 2.3 3G-WLAN Authentication . . . . . . . . . . . . . . . . . . . . . 12 2.4 IMS Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5 LTE Heterogeneous Network . . . . . . . . . . . . . . . . . . . . 20 2.5.1 Components of LTE . . . . . . . . . . . . . . . . . . . . 23 2.5.2 LTE Heterogeneous Network Authentication Procedure . . 25 iv 2.6 Problems in Existing Authentication Mechanisms . . . . . . . . . 30 2.6.1 NASS Bundled IMS Authentication . . . . . . . . . . . . 31 2.6.2 Password based Digest Authentication . . . . . . . . . . . 32 3 Proposed IMS Authentication Protocol and Emulation . . . . . . . . 33 3.1 IMS Authentication in 3G-WLAN Networks . . . . . . . . . . . . 33 3.2 End to End Authentication Protocol for IMS Access over LTE- Heterogeneous Networks . . . . . . . . . . . . . . . . . . . . . . 35 3.2.1 HeNB Authentication with IMS Layer . . . . . . . . . . . 35 3.2.2 UE Authentication with IMS Layer . . . . . . . . . . . . 36 4 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.2 Qualitative Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.3 Formal Validation using Software Tools . . . . . . . . . . . . . . 39 5 Performance Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.2 Performance Evaluation of One-Pass IMS AKA . . . . . . . . . . 46 6 Protocol Emulation and Analysis . . . . . . . . . . . . . . . . . . . . 51 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 v List of Figures Figure 2.1 IMS architecture over 3G-WLAN . . . . . . . . . . . . . . . 9 Figure 2.2 mod-EAP-AKA Authentication . . . . . . . . . . . . . . . . 15 Figure 2.3 Intra WLAN Re-Authentication Protocol . . . . . . . . . . . 18 Figure 2.4 Traditional IMS AKA Protocol . . . . . . . . . . . . . . . . . 20 Figure 2.5 LTE-femtocell Heterogeneous Network . . . . . . . . . . . . 21 Figure 2.6 LTE Security Architecture . . . . . . . . . . . . . . . . . . . 22 Figure 2.7 HeNB Authentication with LTE Secure Gateway . . . . . . . 25 Figure 2.8 LTE-AKA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Figure 2.9 UE Authentication in LTE-Heterogeneous Network . . . . . . 28 Figure 2.10 One-Pass LTE-IMS-AKA . . . . . . . . . . . . . . . . . . . 29 Figure 3.1 Proposed IMS AKA Protocol . . . . . . . . . . . . . . . . . 34 Figure 3.2 NAS Security Procedure . . . . . . . . . . . . . . . . . . . . 36 Figure 3.3 UE Authentication with IMS Layer . . . . . . . . . . . . . . 37 Figure 4.1 AVISPA Tool Summary for Improved One Pass IMS-AKA . . 43 Figure 4.2 Result of testing One Pass IMS-AKA with SATMC . . . . . . 44 Figure 4.3 Result of testing One Pass IMS-AKA with OFMC . . . . . . 45 Figure 4.4 Result of testing One Pass IMS-AKA with CL-Atse . . . . . . 45 Figure 5.1 α vs Improvement Factor over IMS-AKA . . . . . . . . . . . 48 Figure 5.2 Comparison of our protocol and Long et al’s protocol . . . . . 49 Figure 6.1 Network Topology for Protocol Implementation . . . . . . . . 52 Figure 6.2 IPSec VPN message exchange . . . . . . . . . . . . . . . . . 54 vi Figure 6.3 IKE as Captured by Wireshark . . . . . . . . . . . . . . . . . 55 Figure 6.4 A plot of packet transferred against time during ISAKMP . . . 56 Figure 6.5 SIP Registration - An Example . . . . . . . . . . . . . . . . . 57 Figure 6.6 SIP Register with Invalid User details . . . . . . . . . . . . . 58 Figure 6.7 A Plot of Message Exchange during SIP Registration with In- valid User details . . . . . . . . . . . . . . . . . . . . . . . . 59 Figure 6.8 SIP Register Process . . . . . . . . . . . . . . . . . . . . . . 60 Figure 6.9 A Plot of Message Exchange during SIP Registration . . . . . 60 Figure 6.10 SIP Unregister Process . . . . . . . . . . . . . . . . . . . . . 61 Figure 6.11 A Plot of Message Exchange during SIP Unregistration . . . . 61 Figure 6.12 3GPP Specified registration Process . . . . . . . . . . . . . . 62 Figure 6.13 A Plot of Message Exchange during 3GPP Specified SIP Reg- istration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Figure 6.14 List of request methods during call setup and teardown . . . . 64 vii Glossary The following are abbreviations and acronyms used in this thesis, listed in alpha- betical order. 3GPP 3rd Generation Partnership Project AAA Authentication, Authorization, and Accounting AIS- Artificial Immune Systems AKA Authentication and Key Agreement protocol AMPS Advanced Mobile Phone System AS Application Sever AVISPA Automated Validation of Internet Security Protocols and Applications BGCF Border Gateway Control Function CS Circuit Switched CSG Closed Subscriber Group CSCF Call Session Control Function CL-ATSE Constraint- Logic-based Attack Searcher DES Digital Encryption Standard DNS Domain Name System viii DOS Denial of Service EPC Evolved Packet Core E-UTRAN Evolved UMTS Terrestrial Radio Access Network HENB Home Node B HN Home Network HO Hand Over HEMS HeNB Management System HSS Home Subscriber Service I -CSCF Interrogating Call Session Control Function IMS IP Multimedia Subsystem IP SEC Internet protocol Security ISC IMS Service Control Interface ISIM IMS Subscriber Identity Module LTE Long Term Evolution MD5 Message-Digest algorithm 5 MME Mobility Management Entity MMS Multimedia Message Services MRFC Media Resource Function Controller NAS Non-Access-Stratum OFMC On-the-Fly Model-Checker P-CSCF Proxy Call Session Control Function QOS Quality of Service ix SAE System Architecture Evolution SATMC SAT-based Model-Checker SEGW Secure Gateway S- CSCF Serving Call Session Control Function SA Security Associations SIP Session Initiation Protocol SLF Subscriber Location Function SNMP Simple Network Management Protocol TLS Transport Layer Security TNA Trusted Node Authentication UDP User Datagram Protocol UE User Equipment UMTS Universal Mobile Telecommunication systems VOIMS Voice Over IP Multimedia Subsystem VLAN Virtual Local Area Network VPN Virtual Private Network WIMAX Wireless Interoperability for Microwave Access WLAN Wireless Local Area Network x Acknowledgments I am forever grateful to my supervisor Prof. Victor C.M. Leung. His continued support and advice made this research possible. This work has been supported in part by TELUS, the Natural Sciences and Engineering Council of Canada. I am thankful to Amma, Appa, Geetha, Uthaya, and Sriram for their support during my education, and Dr. Sergio Gonzalez for his immense help during the early stages of research. xi Chapter 1 Introduction The IP Multimedia Subsystem (IMS) is a standardized Next Generation Network (NGN) architecture defined by the European Telecommunication Standards Insti- tute (ETSI) and the 3rd Generation Partnership Project (3GPP) to provide Internet media services capability [1]. As with the Internet, NGN is built around the In- ternet Protocol (IP) and its goal is to create a unified system that offers services like video, voice and data by encapsulating them into packets. The NGN architec- ture can incorporate a variety of wireless and wireline technological alternatives for users to access the global telecommunication network. For wireless access, third generation (3G) cellular networks such as those standardized by 3GPP is be- coming pervasive for wide-area packet data access, while wireless local area net- works (WLANs) specified by the IEEE 802.11 family of standards are ubiquitous in providing high data rate low cost packet data access in local areas. Due to the complementary nature of WLANs and 3G networks, it is not difficult to envisage IMS deployed on top of a heterogeneous 3G-WLAN architecture supporting in- terworking between these two wireless access technologies to enable innovative multimedia applications that require better quality of service (QoS). End users can enjoy high speed and cost effective services. With such interworking capabilities, users can seamlessly handover from 3G cellular to WLAN and vice-versa without serious service disruption. The 3GPP service provider can offer new services to utilize the increased bandwidth brought by interworking WLANs. Latency sensi- tive applications that require better QoS like cloud gaming, video conferencing and 1 other real-time applications can be offered [2]. Although it offers plenty of options for network operators to offer innovative services, the complexity of the resulting architecture raises significant security concerns. One of the requirements of this architecture stipulates that a mobile user should follow a multi-pass authentication process to access IMS services. This is because the inherently open nature of IP-based networks exposes the User Equipment (UE) and service providers to security attacks. It has been shown that a UE authen- ticated by 3G-WLAN can impersonate another user to gain illegal access to IMS services. The multi-pass authentication procedure authenticates the IMS subscriber in both the domains of the access network and the IMS, and involves an execution of either 3GPP Authentication and Key Agreement (3GPP-AKA) with the 3G cel- lular access network or Extended Authentication Protocol-Authentication and Key Agreement (EAP-AKA) with any other access network, followed by IMS Authen- tication and Key Agreement (IMS-AKA) with IMS. However, since IMS-AKA is based on 3GPP-AKA, the operations in IMS-AKA are almost the same as that in 3GPP-AKA. It is inefficient that almost all involved steps in the multi-pass authen- tication are duplicated. This results in discernible delays and battery power drain during UE authentication, especially when UE needs to be re-authenticated mul- tiple times due to mobility or a long-lived connection. Therefore, it is desirable to develop a procedure that reduces the time required to re-authenticate the IMS subscriber without compromising the level of security provided by the existing au- thentication procedure. In order to design a foolproof authentication protocol, the following threats must be taken into account. • DNS cache Poisoning P-CSCF, just like proxy servers in HTTP are discov- ered using their domain names. DNS records are usually cached to reduce the time required for DNS lookup. DNS cache poisoning consists of chang- ing or adding records in the resolver caches, either on the client or the server, so that a DNS query for a domain returns an IP address for an attackers do- main instead of the intended domain. If the attacker destroys the DNS entry associated with P-CSCF, normal service would not be provided and the ses- sion is directed to the attacker. 2 • SIP Flood Most of flood attack aims to exhaust servers resource including but not limited to network bandwidth, processor cycles, or disk space, which prevents the server from providing legitimate users with normal services. A great amount of any kind of SIP message, which could cause one or more re- sponses from IMS, may result in a significant impact on the server capability in an IMS environment. Here we take Register as an example. IMS needs to deal with a lot of message interaction in the register process. A registra- tion flood occurs when attackers send large quantity of Register messages simultaneously. An initial Register request will get many network elements involved and different messages produced. To make matters worse, P-CSCF and S-CSCF are stateful SIP proxies, they should maintain the state of ev- ery Register message. Network servers have finite processing capability and can therefore handle a limited amount of traffic. If the volume of registration messages exceeds the device’s capacity, some messages from legal users will be dropped, meaning some users will not be able to make or receive calls. These devices may then attempt the registration again, adding more conges- tion. Depending on the design of the network, the performance of network devices, and severity of the registration flood, users may be unable to access the network for several minutes or several hours. Without doubt, the similar situation will occur, when Register is replaced by other SIP messages such as Invite, Options. • SIP Parse Attack IMS utilizes SIP as the main control protocol. The HTTP- like ASCII presentation of the SIP messages may initially be more attractive to attackers for vulnerability assessment than the rival signalling protocols with complex encodings. Malformed or sequence disordered SIP messages are used to exploit vulnerabilities in SIP parser implementations to crash the IMS servers or end- userss terminals. • Illegal Super User Authority IMS system administrator usually owns priv- ilege to operate the networks configuration and users profile. Attackers can seize root or super-users privilege by making use of the systems security leak or social engineering. For example, users service subscription can be modi- fied once attacker get super privilege of accessing HSSs database, which may 3 result in illegal user gaining extra service or legal subscriber losing normal service. IMS over LTE Long Term Evolution (LTE) is commonly referred to as a type of 4G wireless ser- vice. LTE offers superior mobile broadband service using femtocells and picocells. A deployment that supports macros, picos, femtos and relays in the same spectrum is called a Heterogeneous network. In our thesis, we present LTE-femtocell het- erogeneous network for IMS access. In the new LTE Radio and Evolved Packet Core (EPC) architecture, there is no circuit-switched domain to handle voice calls in the traditional 2G/3G way. A solution for voice over LTE will, therefore, be needed as LTE access becomes more widespread. In order to support voice calls, numerous approaches were considered. In the end, IMS became the most widely adopted approach as IMS promises much more than voice solutions. IMS is an access independent subsystem. As a result, it becomes much more easier to migrate services and solutions from one access network to another. IMS authentication over LTE networks suffers the same disad- vantages as its third generation counterpart. In order to shorten delay and provide a secure access to IMS, we extend our one-pass authentication mechanism to the realms of LTE-IMS heterogeneous networks. 1.1 Related Work There is limited literature that deals with reducing authentication costs for mobile IMS users. Just like any other IP based protocol, IMS is vulnerable to threats and security considerations[3]. The original 3GPP specifications for safeguarding IMS is a convoluted multiway procedure, and it does not suggest measures to thwart Denial of Service or malicious unregistrations. The security issues related to IP Multimedia Subsystem are briefly illustrated in [4]. IMS is based on SIP and IP protocols thats why it has inherent vulnerabilities related to them. Some of the highlighted concerned to the IMS security are DoS, gateway attacks, authentication, IPv4 vs IPv6 and NAT or IPSec. UDP Flood Attack is one of the attacks causing host based Denial of Service 4 [5]. UDP is a connectionless protocol and it does not require any connection setup procedure to transfer data. A UDP Flood Attack is possible when an attacker sends a UDP packet from a random port on the victim system. In a spoofing attack, the intruder sends messages to a computer indicating that the message has come from a legitimate system. To be successful, the intruder must first determine the IP address of a trusted system, and then modify the packet headers. N. Crespi et al. [6] proposed a new functional entity, called WLAN SIP proxy, in the WLAN that enables the latter to perform Nlocalized IMS services. This approach proves to be quite useful in LTE-Heterogeneous networks. Introduction of a SIP feature in Home Node B module would result in its participation during IMS registration sessions. A one-pass AKA working on top of WLAN is proposed in [10], which reduces the authentication costs using an International Mobile Subscriber Identity-IP Mul- timedia Private Identity (impi− imsi) pair. Unfortunately, the user becomes vul- nerable to potential spoofing attacks by rogue third party application vendors[9]. A similar scheme was proposed in [8], which involves a Universal Mobile Telecom- munications System (UMTS) authentication procedure followed by impi verifica- tion to secure IMS access. The authentication scheme proposed in [11] requires several architectural changes to IMS, whereas the secure authentication model in [7] does not require significant changes to the existing architecture. However, the policy of fetching authentication vectors induces serious delays especially when the user tries to re-associate with IMS, e.g., after moving from one access network to a different one. 1.2 Contribution 1. In contrast to the existing literature on the subject, we propose a robust one- pass IMS authentication mechanism which necessitates no change to the ex- isting standardized IMS architecture. 2. We make use of modified EAP-AKA protocol [12] for authentication with the access network. Some of the keys generated during this authentication process is reused in IMS authentication protocol, which introduces improve- ments in security and authentication delays. The resulting network protocol 5 is simple to implement and does not necessitate changes to the existing ar- chitecture. 3. To facilitate inter-networking with next generation networks, we present en- hanced packet core for unified IMS-LTE access and extend our protocol to support IMS access on top of Long Term Evolution (LTE) network. 4. The security properties of the proposed IMS-AKA are validated and exam- ined using Automated Validation of Internet Security Protocols and Appli- cations (AVISPA) security analyzer. AVISPA is a package used to test and validate the security of large- scale Internet security protocols. The mes- sage exchange is coded using a programming language understandable by AVISPA. 5. We perform detailed analysis of authentication delay to show a 50 percent improvement over the existing multi-pass authentication schemes. 6. In order to test the usability of our protocol in mobile networks, we emulate our protocol using Asterisk open source SIP server. A comparative study of results of experimental analysis and theoretical analysis is performed. An ex- act model of IMS architecture is replicated using open source software tools and proprietary network components. The goal of this implementation is not to design a content delivery platform. The motivation behind this implemen- tation is to test the usability of our protocol in real time. Thanks to numerous innovation in open source community, plenty of options are available to em- ulate IMS. Out of which, Asterisk SIP server is the most stable framework. Asterisk makes it simple to create and deploy a wide range of telephony ap- plications and services, including IP PBXs and VoIP gateways. To initiate registration requests, SIP compatible softphone client can be used. In or- der to secure SIP requests, we implement IPSec tunnels using OpenSwan. We make use of Cisco switches to provide isolation between different Local Area Networks (LAN). We use Wireshark to study call setup and tear down delays. 6 1.3 Organization of Thesis The rest of the thesis is organized as follows. In Chapter 2, we present background on IMS and traditional authentication mechanisms, authentication protocols for heterogeneous 3G-WLAN and LTE-Heterogeneous networks. In Chapter 3, we present our proposed IMS authentication protocol, and extend it to LTE access net- work. In Chapter 4, we discuss some of the important threats and security analysis, and formal validation of the security protocol. We present performance evaluations in Chapter 5, implement the protocol using open source software in Chapter 6, and conclude the thesis in Chapter 7. 7 Chapter 2 IMS Authentication in Heterogeneous Networks 2.1 Introduction This chapter describes three network architectures mentioned in Chapter 1. The IMS architecture is detailed in Section 2.2. 3GPP-WLAN heterogeneous network and the two authentication mechanisms used to access 3G-WLAN network are discussed briefly in Section 2.3. Traditional IMS authentication procedure is ex- plained in Section 2.4. IMS access over LTE-femtocell Heterogeneous architecture is elaborated in Section 2.5 and the motivation behind this research is explained in Section 2.6. 2.2 IMS Architecture The IP Multimedia Subsystem (IMS), as shown in Figure 2.1 is a standard that defines a generic architecture for offering Voice over IP (VoIP) and multimedia services[13]. This way, operators can take advantage of a powerful multi-vendor service creation industry, avoiding sticking to a single vendor to obtain new ser- vices. IMS provides integrated services to its customers, and a platform for appli- cation providers to host their content on its servers. The IMS does not mandate any particular business model. Instead, it lets oper- 8 Figure 2.1: IMS architecture over 3G-WLAN ators charge as they think more appropriate. The IMS provides information about the service being invoked by the user, and with this information the operator de- cides whether to use differentiated rate for the service, apply traditional time-based charging, apply QoS-based, or perform any new type of charging. 2.2.1 IMS Core Network The IMS core network [16] [17]consists of the following elements. They are 1. Home Subscriber Server (HSS) HSS is a data base server that contains the information about the end users. It contains all the user related information or user profiles including location base information, security profiles, user base services information i.e. what services a user is entitled to[14].HSS controls the user call and session using their profile information stored in its database such as user location infor- mation is used for mobility management and security information is used for user authorization. Similarly user privilege profiles are used to allow or deny user for a specific service it requests. There can be more than one HSS in 9 a single IMS network. If the number of users is quite huge to be handled by a single server, there can be multiple HSS servers. HSS communicates with serving call session control function S-CSCF using Diameter protocol defined by 3GPP[15]. 2. Subscriber Location Function (SLF) SLF is a database containing information about HSS locations and the user addresses whose profile information is stored in any given HSS. SLF keeps track of the HSS servers and the user profiles. SLF maps the user address with the HSS server in the network. 3. Application Server (AS) Application Servers provide application services including IP telephony, mul- timedia applications, voice call and video conferencing applications. SIP is the primary communication protocol. There can be a variety of application servers in IMS network dedicated for different services. 4. Proxy Call Session Control Function (P-CSCF) P-CSCF is the gateway between User Equipment UE and IM network. P- CSCF is a SIP enabled proxy server and all user requests, signalling and control information passes through it. During the IMS registration process P-CSCF address information and its allocation to user is taken care of. P- CSCF and UE must negotiate security parameters (shared Authentication and Key Agreement AKA) and security associations (SA). P-CSCF includes a policy decision function (PDF) which is responsible for implementing QoS on the media plane. 5. Serving Call Session Control Function (S-CSCF) S-CSCF is the most important element of IMS core. Most of its functions are related to registration, session and application services. Registration requests from end users are received by the S-CSCF and authenticated by contacting the HSS for user security and authentication parameters. The reference point between S-CSCF and HSS is denoted by Cx and Diameter protocol is applied 10 on this interface. During the connection with HSS it also downloads the user profiles to determine the services applications. It maintains Charging Data Records CDR for user billing purpose. CDR includes the service usage details, applications invoked, traffic details etc. This helps the operator charge the user according to the agreed tariff. 6. Interrogating Call Session Control Function (I-CSCF ) I-CSCF acts as the point of contact for user connections and sessions regard- less of whether a user belong to the same network or a roaming user from another network. The address of I-CSCF is stated in Domain Name System DNS and made visible to the SIP servers for next hop identification. During registration procedure of UE, I-CSCF assigns S-CSCF to the user. I-CSCF have the capability to supplement the security mechanism by the hiding the network topology details from external networks. 7. Signalling Gateway (SGW) Signalling Gateway is the gateway between circuit switch networks and packet switched networks, providing signalling conversion from circuit switched networks signalling to IP network signalling and vice versa. It provides the lower level protocols conversion services For instance, it converts Message Transfer Part (MTP) into Stream Control Transmission Protocol (SCTP). 8. Media Gateway (MGW)MGW connects the media plan of PSTN/PLMN to IMS media plan [6] and provides interworking between IMS and PLMN/P- STN. Mn is the reference point between Media Gateway Control Function MGCF and IMS-MGW. MGW is supported by H.248 protocol and is flexible in support of different media types. It can share physical resources and can be partitioned in virtual separate MGWs. It provides interceding services between IMS and CS domain when there is compatibility barrier between IMS and CS networks. 11 2.3 3G-WLAN Authentication Packet switched networks are compatible with IMS and can therefore be integrated with IMS through logical interfaces that implement SIP. For the mobile subscriber to gain lawful access to IMS services, the user first needs to get authenticated by the access network. The choice of the access network is prerogative of the mobile operator, because IMS services are independent of the underlying access network. However, to support rich applications offered by IMS, it is better to chose an access network that would support high bandwidths and low jitter. The speeds offered by todays network clearly do not support bandwidth intensive applications like video conferencing and cloud gaming. Hence for the first part of our thesis, we consider a heterogenous integration of 3G and WLAN, as shown in Figure 2.1. WLANs support higher data rates, limited coverage and low implementation and service cost compared to 3GPP. Clearly both technologies complement each other, and a network which combines both technologies will benefit both end users and the service provider. End users can enjoy high speed and cost effective ser- vices. The 3GPP service provider can offer new services to utilize the increased bandwidth brought by interworking WLANs. Innovative applications that require better QoS like video conferencing and real-time applications can be offered. With such coexistence, users can seamlessly HO from 3GPP to WLAN and vice versa without serious service disruption. 3GPP-WLAN interworking is introduced in Release 6 of 3GPP specifications [19]. There are 2 ways by which 3G-WLAN architecture could be implemented, tightly- coupled and loosely-coupled approaches [20], [19]. In the tightly-coupled approach, the WLAN is treated as another 3GPP access network directly connected to the 3GHN through the SGSN. The drawback is that WLAN and 3GPP networks must be owned by the same service provider and some 3GPP network components needs to be modified to support higher bit rate traffic delivered by WLAN[18]. In the loosely-coupled approach, WLANs are treated as a separate access network complementary to 3GPP access network while maintaining a direct connection to the Internet. In contrast to the tightly-coupled approach, data traffic in the loosely- coupled approach could access the Internet directly without passing through the 3GHN. This scheme is more desirable because 3GPP and WLANs belonging to 12 different operators can co-exist with minimum modifications, resulting in less com- plex and less expensive interworking system. However, this approach is challeng- ing because WLAN authentication is not controlled by the 3GPP network, hence WLAN authentication needs to be elevated to 3GPP authentication levels. In our model, we consider a tightly-coupled architecture where both 3G and WLAN ser- vices are controlled by a single service provider. 3G-WLAN architecture has the following benefits.: 1. Common billing and customer care. Subscribers receive a unified bill for 3GPP and non- 3GPP services. No interworking is required. 2. 3GPP system based access control and charging. In this scenario, Sub- scriber’s authentication, authorization and accounting are handled by the 3GPP network. This is to provide higher security measures when access- ing the Internet through a non-3GPP network. Users undergo 3GPP-based authentication challenges and key agreements to be able to directly access the Internet. Interaction between 3GPP and non-3GPP in this scenario is limited to the transportation of AAA traffic to authenticate users. 3. Access to the 3GPP Packet Switched (PS) based services. 3GPP subscriber accessing through the non-3GPP network can access the 3GPP PS based ser- vices, i.e., IP services, like Multimedia Message Services (MMS), IP Mul- timedia Subsystem (IMS) and the Internet. Clearly this is an extension to scenario 2 because users have the capability to access PS based services pro- vided by 3GHN in addition of being able to directly access the Internet. 4. Service continuity. This scenario guarantees the continuity of services when changing the access network from 3GPP based network to non-3GPP based network and vice versa. Change in access network may be noticeable by users and the service quality might not be maintained when moving to a new access network. 5. Seamless service continuity. This scenario improves on scenario 4 by seam- lessly changing the access network without users notice and with minimum HO delay and data loss. 13 6. Access to 3GPP Circuit Switched (CS) service. This scenario permits users the access to 3GPP CS services over the non-3GPP access network. The advantage is that WLAN authentication is handled by the 3GPP- AKA protocol. However, EAP-AKA is not efficient for subsequent re-authentications. In this thesis, we make use of an improved version of EAP-AKA, to authenticate the mobile entity. In EAP-AKA, MS and HAAA must generate MSK, EMSK and TEK keys. TEK is used to derive K-auth and K-encr keys responsible for preserving the in- tegrity and confidentiality of EAP messages during authentication. MSK is trans- ported to the AP to be used in generating a TSK, and EMSK is not used. In mod- EAP-AKA extending the key hierarchy by deriving additional keys from MSK and EMSK to enable fast local re-authentication and fast HHO pre-authentication [22]. MSK and EMSK are used in the new key hierarchy to generate WLAN domain- level and local-level keys specific to a WLAN domain. The resulting keys are later used to derive TSKs. MSK is the root key for ordinary local re-authentication op- erations while EMSK is the root key for HHO initiated pre-authentications. Two keys are derived from the MSK: Domain-level Re- authentication Key (DRK) and Local-level Re-authentication Key (LRK). The keys derived from EMSK are: HO root Key (HOK), Domain-level HO key (DHK) and Local-level HO key (LHK). In the extended key hierarchy, LRK is used to derive TSK in WLLR. Similarly, LHK is used to derive TSK in Intra/Inter-WLAN FP. LRK and LHK play the role of MSK in the standard EAP- AKA protocol. Consider the case where UE initially attaches to a WLAN. UE initiates the pro- cess by authenticating with the 3G Home Network (3GHN) [23], as illustrated in Figure 2.2. In addition to UE, this process involves the following: a WLAN Au- thentication Authorization and Accounting server (WAAA), a Home Authentica- tion Authorization and Accounting server (HAAA), an Access Point (AP) and EUs HSS. We make use of an improved version of EAP-AKA called mod-EAP-AKA, which distinctly minimizes re-authentication delays. In mod-EAP-AKA, WAAA locally re-authenticates stationary users on behalf of HAAA and HSS. The strat- egy of localizing authentications within the WLAN domain reduces authentication delays and minimizes dependence on critical servers in 3GHN. 14 Figure 2.2: mod-EAP-AKA Authentication The procedure is as follows: 1. HAAA generates the next local ID, IDWLAN, to be used by UE in the next pre-authentication, and a nonce (HN). HAAA indicates the permit- ted number of pre-authentications (nWR) UE can perform before falling back to mod-EAP-AKA authentication. WAAA and UE adjust the WLAN counter (WC), according to npre, where WC is the number of times pre- authentications has been performed and npre is the permitted number of pre-authentications. In addition, UE generates a nonce, UN. 2. New set of keys are generated. (a) A Root handover key, HOK, is derived from EMSK by HAAA and UE using a special pseudo-random function (PRF) similar to the one used in generating MSK in the standard EAP-AKA protocol: HOK = PRF(EMSK,EAP−AKAsessionID (2.1) |HAAA− ID|UEM,256) 15 where ”|” denotes concatenation and, EAP−AKAsessionID= (EAP|RAND|AUTN) (2.2) HAAA also generates Domain-level Root Key (DRK) upon receiving EAK request. DRK = PRF(MSK,HNi|WAAA− ID|MSM|”DRK”,256) (2.3) UEM is the UE address in the medium access control layer, HAAA ID is the identity of HAAA and AUTN is an authentication vector. (b) The domain-level handover key, DHK, is derived from HOK by HAAA and UE as follows DHK = PRF(HOK,HN|WAAAID|UEM,256) (2.4) where WAAA ID is the identity of WAAA. (c) The domain-level and local- level re-authentication keys, DRK and LRK. (d) A KWAAA−UE key, which is used to secure traffic between UE and WAAA. This key is only derived by UE and WAAA. The derivation is explained in detail in [22]. 3. The HAAA securely delivers DRK, DHK, npre and IDWLAN to WAAA. 4. WAAA securely delivers LRK to AP.LRK is the local-level re-authentication key derived from DRK. LRK = PRF(DRK|CWR|AP− ID|MSM|”LRK”,512) (2.5) 5. Encryption key (EK) and Integrity Key (IK) are derived to secure the traffic exchanged between the user and access-networks. They are also used to es- tablish secure tunnel prior to IMS authentication, which would be discussed in chapter 3. EKWA−MS|IKWA−MS = PRF(DRK ⊕ DLK (2.6) |WAAA− ID|MSM|”KWAMS”,512), where ⊕ is concatenation operator. 6. Temporary Local identity (TL-ID) is used by MS in subsequent re-authentication or Intra-WLAN protocol invocations, which we would discuss in the next 16 section. TL− IDi = HASH(DRK ⊕ DLK|MS− ID|CWR|CHHO) (2.7) 7. Derivation of HOK, DHK, DRK, LRK, and KWAAA−UE by UE. Additional security keys are derived as a result of performing mod-EAP-AKA to enable the WAAA to locally authenticate MSs without reverting to the 3GHN. The strategy of localizing authentications within the WLAN domain results in re- duced authentication delays and minimized dependence on critical servers in the 3GHN. To achieve fast re-authentication for stationary users, we use localized re-authentication protocol, known as, WLAN Local Re-authentication protocol (WLLR). A MS roams to a neighbour AP when experiencing poor signal-strength from the currently associated AP. The Target AP (TAP) might be in the same WLAN domain or belong to a different WLAN domain. Due to the inefficiency in EAP-AKA invocation during HHOs in 3GPP-WLAN and the inadaptability of fast authentication protocols during HHOs designed for autonomous WLANs, we make use of Intra-WLAN Fast Pre-authentication protocols. The protocols are designed to efficiently operate in the 3GPP-WLAN interworking architecture. It helps to minimize the dependency on HSS/HAAA, which results in improved performance without compromising security. UE may associate with a neighbouring AP when experiencing poor signal- strength from the currently associated AP in the same WLAN domain. Therefore, we make use of the Intra WLAN pre-Authentication protocol to secure access to the Target Access Point (TAP) and minimize delay [12]. In this process, UE authenti- cation is handled by WAAA instead of HSS and HAAA. The protocol proceeds as follows: 1. When UE recognizes the need for handover within the WLAN domain, it in- vokes the Intra-WLAN pre-authentication protocol and sends an EAP mes- sage to the currently associated AP, as shown in Figure 2.3. AP replies with an identity request message. 17 Figure 2.3: Intra WLAN Re-Authentication Protocol 2. UE responds to the request with IDWLAN, TWAAA ID and TAP ID 3. Receiving TWAAA ID and TAP ID indicates a handover pre-authentication request. WAAA classifies this request as Intra-WLAN if the received TWAAA ID matches its identity and the TAP ID matches the identity of one of the APs in the WLAN domain. WAAA then consults WC and prepares a challenge message that includes a fresh nonce, WN, and the next IDWLAN, and WC and MAC1Intra are calculated using KWAAA−UE: MAC1Intra= SHA−1(KWAAA−UE,WC| IDWLAN|WN) (2.8) , where SHA−1 is the Secure Hash Algorithm [24]. 4. On the UE’s side, the WC stored in the UE’s database is matched with the WC recently received. Then a new MAC1Intra is calculated and compared with the received MAC1Intra. If both checks are positive, then UE stores IDWLAN and replies with WC and MAC2Intra calculated as follows: MAC2Intra= SHA−1(KWAAA−UE,WC|WN) (2.9) 18 5. WAAA then derives a local-level handover key, LHK, from DHK as follows: LHK = PRF(DHK,WC|TAPID|UEM,512) (2.10) WAAA increments WC and sends an EAP success message to UE. Conse- quently, UE derives LHK and increments WC. WAAA and TAP exchange Notify-Request and Accept RADIUS AAA message to confirm handover operation. 2.4 IMS Authentication After the packet data protocol context activation explained in the previous section, if UE wants to use IMS services, UE will need to perform the IMS registration procedure, which is depicted in Figure 2.4 as explained below. 1. The UE sends a SIP Register message with impi [25], which passes through the UMTS Packet-Switched (PS) domain and P-CSCF before arriving at I- CSCF. 2. When I-CSCF receives the Register message, it sends a User Authorization Request (UAR) to HSS to ask for the available S-CSCFs that can serve UE. Then HSS gives a User Authorization Answer (UAA) to I-CSCF to inform about the available S-SCSCFs that can serve the forthcoming UE. 3. After I-CSCF identifies the address of S-CSCF, it then forwards the Register message to S-CSCF. 4. If S-CSCF does not have a valid authentication vector (AV) for UE, S-CSCF sends a Multimedia Authentication Request (MAR) over the Cx reference interface to HSS to request an AV array [26]. Otherwise, this step and step 6 are skipped. Note that an AV contains (i) a random number RAND, (ii) an expected response XRES, (iii) a cipher key CK, (iv) an integrity key IK, and (v) an authentication token AUTH. 5. S-CSCF stores AV and selects one array AV(i) from the vector. Then it sends a ”401 unauthorized message” notice to P-CSCF via I-CSCF. 19 Figure 2.4: Traditional IMS AKA Protocol 6. P-CSCF keeps CK(i) and IK(i) and then sends the 401 message to UE with impi, RAND(i) and AUTH(i). 7. UE authenticates the server by checking AUTH(i), computing RES(i), and then sending the Register message with impi and RES(i) to S-CSCF. 8. S-CSCF checks RES(i) with XRES(i) values; if they match, then UE is con- sidered as a legitimate user. S-CSCF sends a Server Assignment Request (SAR) to HSS to inform which S-CSCF will serve UE. HSS then sends a Server Assignment Answer (SAA) to S-CSCF. 9. S-CSCF sends a ”200-OK” message to UE. 2.5 LTE Heterogeneous Network In this section, we present Long Term Evolution network for 4G access, and unifi- cation of IMS services with the LTE core network. 20 Figure 2.5: LTE-femtocell Heterogeneous Network Emerging mobile broadband networks are being designed to support new value- added services and applications either enabled or optimized by the mobile opera- tor. With the massive traffic growth from smartphones and other mobile devices, the multimedia packet core network has become critical to providing a superior user experience and monetizing these new services and applications. In order to satisfy the burgeoning needs of applications, it is necessary to introduce the next generation of cellular network. A 4G system is expected to provide a com- prehensive and secure all-IP based mobile broadband solution to laptop computer wireless modems, smartphones, and other mobile devices. Facilities such as ultra- broadband Internet access, IP telephony, gaming services, and streamed multime- dia may be provided to users.In order to pass as a true 4G, any technology needs to achieve stationary speeds of 1Gbit/s and mobile speeds of 100Mbit/s. There are more technical specifications, but these two are enough to distinguish 4G from non-4G technologies. In order to support the burgeoning needs of customers, LTE core network alone may not be sufficient. In such cases, the operators could make user of a set of one or more femtocells and a set of core network elements to manage and support the use of those femtocells in accessing network services, as in Figure 2.5. A fem- 21 Figure 2.6: LTE Security Architecture tocell is a radio access network element that supports LTE services, operates in a limited geographic area in licensed spectrum, may operate over the public internet, and supports a limited number of simultaneous users in generally small environ- ments such as a home. The functionality of a femtocell is similar to a WLAN router. The Femtocell Access Point (FAP) helps to tunnel voice and multimedia content between UE and LTE core network. It is connected to the core network via broadband or air interface, with a capacity to hold few users in a residential area or business environment. LTE is implemented on Enhanced packet core. The transition to LTE/System Architecture Evolution (SAE) involves a fundamental shift to a ”flat” all-IP system architecture that impacts every part of the network, with the Evolved Packet Core (EPC) at its centre. SAE specifies an all-IP network architecture designed to sup- port end-to-end packet services. It comprises two tightly integrated components: the Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) - a.k.a. LTE RAN - and EPC. 22 2.5.1 Components of LTE The basic entities of Enhanced packed Core are shown in Figure 2.6. They are 1. eNodeB The only node in the Evolved Universal Terrestrial Radio Access (eUTRAN) is the eUTRAN Node-B (eNodeB). It is a radio base station that is in con- trol of all radio related functions in the fixed part of the system. Typically, the eNodeBs are distributed throughout the networks coverage area, each re- siding near the actual radio antennas. A noteworthy fact is that most of the typical protocols implemented in today’s Radio Network Controller (RNC) are moved to the eNodeB. The eNodeB is also responsible for header com- pression, ciphering and reliable delivery of packets. On the control plane, functions such as admission control and radio resource management are also incorporated into the eNodeB. 2. The Home Subscriber Server (HSS) The HSS is the master database for a given user. It is the entity containing the subscription-related information to support the network entities actually handling calls/sessions. A Home Network may contain one or several HSSs depending on the number of subscribers and size of the network. The HSS is considered a repository for IMS related services and supports User Iden- tification, Numbering and addressing information, Closed Subscriber Group (CSG) identification. The subset of the HSS functionality is required to sup- port roaming to legacy GSM/UMTS CS Domain networks. 3. Mobility Management Entity (MME) MME is the control plane entity within EPS. MME supports Non-Access-Stratum NAS signalling and secu- rity. It is responsible for authentication of users, bearer establishment, roam- ing and lawful interception of traffic. In a typical case, multiple applications may be running in a UE at any time, each one having different quality of ser- vice requirements. For example, a UE can be engaged in a VoIP call while at the same time browsing a web page or downloading an FTP file. VoIP has more stringent requirements for QoS in terms of delay and delay jitter than web browsing and FTP, while the latter requires a much lower packet loss 23 rate. In order to support multiple QoS requirements, it is necessary for the MME to establish multiple bearers. 4. PDN GW The PDN GW is the gateway which terminates the SGi interface towards the PDN. If a UE is accessing multiple PDNs, there may be more than one PDN GW for that UE . UE IP address are allocated by the PDN GW. In order to support LTE-Heterogeneous networks, we need to include the fol- lowing: 1. Home Node B (HeNB) HeNB is a base station located on the user premises and operates in the same radio interface as that of the operator. There are 2 ways in which HeNB could be deployed: - Closed Subscriber Group (CSG) - where only UEs belonging to a particular closed user group can access HeNB. - Open - where all the subscribers and roaming users are allowed to use HeNB. Both the approaches have merits and demerits. In Open mode, it is hard for the operator to maintain all the HeNBs and ensure physical security of the device. In CSG, it is hard to enforce periodic updates and maintenance upon the user, which is vital to ensure the security is not compromised. Hence, it is best advised to use a Hybrid approach, where the physical security, cost of ownership is borne by the customer while the operator ensures periodic upgrades and maintenance. When HeNBs are deployed in Hybrid or CSG mode, a unique CSG-ID is allotted for each HeNB. 2. Secure Gateway (SeGW) It is the door to the core network. All HeNBs must be authenticated by the SeGW before it could commence services. A SeGW may or may not use an AAA server to complete authentication procedure. Packet routing and 24 Figure 2.7: HeNB Authentication with LTE Secure Gateway forwarding functions is the responsibility of a SeGW. It also participates in awful Interception of traffic. 3. HeNB Management System(HeMS) HeMS or Femtocell Management System (FMS) is responsible for manage- ment of all the HeNBs. HeMS may either be located in the operators core network or on the public domain. Depending on its location, either radio interface or broadband access is used for communication with HeNB. HeMS is responsible for running periodic updates and monitoring the health of a HeNB. 2.5.2 LTE Heterogeneous Network Authentication Procedure The LTE-IMS authentication is a multi step process, during which both the user and HeNB are authenticated with the core network. 1. HeNB Authentication with LTE Secure Gateway HeNB is a SIP compatible node, capable supporting IMS access. It consists 25 of a globally unique manufacturer ID. The ID shall remain the same through- out its lifetime, irrespective of upgrades. The interface between HeNB and the core network is insecure, that is why it is essential to authenticate HeNB with a trusted gateway. • Upon gateway discovery, HeNB initiates an IKE v2 based authentica- ton by sending an IKE INIT Request to the secure gateway as shown in Figure 2.7. The request message consists of SAi, which is the list of algorithms that support IKE. KEi has the KeNB’s Diffie-Hellman value. IKE(IN IT−REQ) = PRF(SAi , KEi , Nonce ) • SeGW sends an INIT Response message, requesting a certificate from HeNB, certreq. It chooses the choice of the certificate vendor in SAri, completes Diffie-Hellman exchange with KEr. IKE(IN IT−RES) = PRF(SAr , KEr , Noncer , certreq ) • HeNB sends an IKE auth request message AUTH, which consists of its unique ID, IDi , the requested client certificate, authentication payload and traffic selectors TSi, TSr. It also requests the server certificate from SeGW. The entire payload is encapsulated for integrity protection. IKE(AUTH−REQ) = PRF(SAi , AUTH, IDi , TS i, TS r Noncei , cert, certreq ) • SeGW first verifies that the certificate in the cert payload has not been tampered and the IDi corresponds to the identity in the certificate. If the verification is successful, using the public key of the certificate, the SeGW generates the expected AUTH payload and compares it with the received AUTH payload. If they match, then the authentication of the HeNB is successful. Otherwise, the SeGW sends an IKEv2 Notifica- tion message indicating authentication failure. If the network policy requires femtocell subscription authorization, the SeGW contacts the AAA to verify that the HeNB identified by its ID is authorized to pro- vide service. AAA contacts HSS to derive authentication vectors and 26 Figure 2.8: LTE-AKA responds with the authorization result. IKE(AUTH−RESP) = PRF(SAr , AUTH, IDr , TS i, TS r Noncei , cert ) • HeNB verifies that the SeGW certificate in the CERT payload has not been modified and the identity IDr corresponds to identity in the server certificate. If the verification is successful, using the public key of the server certificate, the HeNB generates the expected AUTH payload and compares it with the received AUTH payload. If they match, then the SeGW (server) authentication is successful. • An IPsec SA pair is established between the FAP and the SeGW. Ad- ditional IPSec tunnels may be created, if required. 2. UE Authentication with LTE Core Network If HeNB operates in CSG or hybrid mode, HSS stores a record of list of all valid UEs in a particular CSG. The data can be retrieved by MME in order to verify CSG subscriptions and expiry time. 27 Figure 2.9: UE Authentication in LTE-Heterogeneous Network • The UE initiates the LTE NAS procedure by sending an attach message to the HeNB. The attach message is usually in the form of a NAS Re- quest message, which consists of UE’s IMSI. The process is shown in Figure 2.9. • Upon receiving the NAS request, HeNB attaches the CSG-ID and for- wards the request to HeNB gateway. If the UE identity has not been established before, the HeNB GW performs a registration procedure, before forwarding the NAS Request to the core network. • The MME verifies whether it holds subscription data for the UE. If there is no subscription data in MME then it sends an Update Request message to the HSS. • If the CSG ID is not valid, the MME shall send the corresponding NAS reject message to the UE. • For valid UEs, the MME would continue with the generic EPS-AKA, [27] to complete the authentication procedure as shown in Figure 2.8. 28 Figure 2.10: One-Pass LTE-IMS-AKA 3. Registration of UE with IMS IMS is seen as the native solution for delivering telephony and multimedia services over LTE. Furthermore, VoIMS (Voice Over IP Multimedia Sub- system) is expected to be widely deployed, ensuring coverage for LTE users whether at home or roaming. VoIMS is based on the LTE/IMS network that offers a flat all-IP network with full operational cost saving while al- lowing the mobile operators to offer new revenue generating applications and services. Since VoIMS has also been implemented within some UMTS networks, it will also provide an excellent ability to handover voice and data simultaneously because data and voice are handled over a single packet switched domain [28][29]. In order to use IMS to provide the services for the CS UE , the IMS HNB shall register the UE in IMS. HeNB assumes the role of a P-CSCF and SIP server for the UE. • The IMS HNB performs the HNB registration procedure to the HNB- GW, as shown in Figure. 2.11. 29 • When the UE attempts to access the HNB via an initial NAS mes- sage (e.g., LAU or RAU Request) and there is no context in the HNB allocated for that UE, the HNB performs the UE Registration to the HNB-GW according to [31]. • The IMS HNB requests IMS Access Authorization by providing nec- essary identifying information for the IMS HNB and UE, e.g., HNB Identity, IMSI, etc. to a RADIUS server associated with HSS. • The HSS grants the IMS access authorization to the UE after verifying one or more of the following criteria[30], as established by operator policy: – Access is granted to the user via this IMS based HNB subsystem. – The user has been authenticated by the CS Core Network. – The UE Attach has been performed through the HNB requesting the IMS Access Authorization. • In case the UE was already IMS registered via another IMS HNB, IMS will de-register the UE from the previous IMS HNB. • Completion of standard IMS registration procedures. Execution of IMS AKA is bypassed for this registration event. 2.6 Problems in Existing Authentication Mechanisms For the 3G-WLAN domain, the traditional IMS-AKA given in Figure 2.4, clearly demonstrates the intricate authentication procedure followed between the UE and the system servers. These transactions produce significant overhead, as mentioned before, thus supporting our claim for the need to create a simplified and secure authentication procedure that reduces authentication delay without compromising security. All security protocols for IMS layer, defined thus far would broadly fall under two categories. • Network Attachment Sub-System (NASS) Bundled IMS authentication • Password based Digest Authentication 30 2.6.1 NASS Bundled IMS Authentication NASS based models do not implement any authentication mechanism at all, to re- duce authentication delay. The IMS users are authenticated by underlying access network authentication and their identity and their IP address are sent to IMS net- work as the proof of authentication. Both solutions assume anti-spoofing mecha- nisms in access networks while forging of IP address would lead to forged identity in IMS network. The security level of IMS network corresponds to the security level of underlying access network. Similarly, in the LTE-Heterogeneous domain, there is over reliance on HeNb, as it plays the role of proxy in LTE and IMS layers. If the security of HeNB is compromised, an intruder could hack into LTE and IMS layers. Further, HeNB is not authenticated with the IMS layer. Authentication procedure specified in [30], is a throw back to the initial days of IMS, where security is compromised for faster access to IMS layer. IMS architecture is mainly based on SIP, and SIP runs primarily on UDP. Integrity and confidentiality of messages exchanged between nodes could be compromised. Hence, it is essential to safeguard communication between HeNB and UE. The existing one-pass authentication method specified in [8] is vulnerable to fake attack on IMS subscribers and temporary cheat attacks. It results in a situation where the UE and the P-CSCF do not have a cipher key (CK) and an integrity key (IK) to achieve condentiality and integrity protection support between the UE and the P-CSCF. This may lead to serious breach of security. For instance, the LTE-IMS AKA protocol described in [30], the radius server is designed to accept the IP address of the latest REGISTER request as the client’s IP address. Because the authentication is vulnerable to replay attack, and query floods, until the next REGISTER request is due, an adversary is able to re-register using the same challenge response with different IP address to redirect all the fea- tures to any other preferred destination. This effectively creates a denial of service and identify theft risk to the legitimate user. Also with the lack of two-way authen- tication, an adversary can hijack the session using man-in-the-middle attacks. 31 2.6.2 Password based Digest Authentication Digest access authentication is password based identification method that allows secure user identification using passwords. However, Digest authentication does not protect IMS signaling. Digest authentication uses Message-Digest algorithm 5 (MD5) cryptographic hashing algorithm together with nonce values to prevent cryptanalysis. It should be difficult to determine original secret input key value by knowing only algorithm output value. However attacker may try to test large set of inputs (dictionary or some other suitable list) with brute force attacks in order to find a matching output. If user password is too simple then attacker has a good chance to find it. Digest authentication does not rely on use of smart cards for tamper-proof storage of user password. It is up to user to remember the password and so if users are given a chance to set password they tend to produce simple ones that will be easy to remember. This gives brute-force attacks a higher chance for success. In order to prevent attacker to discover different parameters required for brute-force attack IMS signaling traffic must be protected. Digest authentication should be coupled with Transport Layer Security (TLS) / IPSec to provide security for IMS signaling traffic. 32 Chapter 3 Proposed IMS Authentication Protocol and Emulation 3.1 IMS Authentication in 3G-WLAN Networks In this section, we introduce the one - pass IMS authentication procedure as shown in Figure 3.1. The authentication mechanism explained in [16] involve IP address verification and SIP Digest authentication. While these procedures have their mer- its in terms of authentication delay, in particular environments, neither of them provide confidentiality or integrity protection. Bundling IMS-AKA with IPSec as- sociation would alleviate such threats. In order to establish IPSec tunnel with UE, it is necessary to have the necessary negotiation and authentication parameters at the gateway. In our model, these parameters are obtained from the earlier authen- tication mechanism with the access network. The UE is supplied with the required authentication vectors at the sim card. The proposed protocol offers high degree of security to the user and the net- work amidst threats. We make use of mod-EAP-AKA protocol explained in Chap- ter 2, for 3G-WLAN access network authentication. We propose a one-pass IMS- AKA protocol based on efficient reuse of keys generated during the access net- work authentication. We also eliminate redundant exchange of messages during IMS-AKA to reduce authentication delay. Assume that the UE has completed mod-EAP-AKA procedure. This protocol 33 Figure 3.1: Proposed IMS AKA Protocol is based on the assumption that all UE would request IMS services from the cellu- lar operator. Upon mod-EAP-AKA authentication occurring, a RAND, XRES and encryption keys are securely transported from HAAA to S-CSCF via HSS. This greatly reduces the time required to derive authentication vectors, when S-CSCF validates the IMS user for the first time. We make use of CK, IK derived from authentication with access-networks. The same parameters are used to establish an IPsec tunnel, after which an IP address is granted to the MS. As IMS authentication is tightly integrated with the access net- work authentication, it is not possible for a malicious user to initiate DoS attacks. Subsequent, authentications are solely based on impi verification. Ideally, this IMS registration expires in 600,000 seconds. However, in real time applications, the UE or the network initiates IMS re-registration quite often, depending on the changes in the underlying network. The protocol develops as follows: 1. Initially, when UE tries to secure first time access to IMS, it sends a SIP Reg- ister message with the impi parameter value to Packet Data Gateway (PDG), a sequence number (SN) and time stamp (TS), which notifies the network that it has completed EAP-AKA. This ensures IMS access to subscribers 34 only. 2. PDG can identify imsi of the UE from the impi . PDG forwards imsi and impi to P-CSCF. 3. I-CSCF identifies S-CSCF using the name address resolution mechanism and forwards the SIP register message to S-CSCF. 4. It is obvious that the (imsi, impi) pair would not present in S-CSCF. So it probes HSS with a Multimedia Auth Request, and receives the key value pair via Cx interface [32]. Further, S-CSCF encapsulates XRES stored during mod-EAP-AKA, in a 200 OK message and forwards it to the user. 5. The aforementioned step can be avoided during WLAN re-authentications. When UE moves from one AP to another in the same WLAN domain, Intra WLAN pre-authentication is invoked. If IMS re-authentication is required, then the S-CSCF compares the received imsi with the stored imsi, impi pair. If the imsi values match, it then sends a OK signal to the UE. 6. UE receives 200 OK message. P-CSCF stores encryption keys. 3.2 End to End Authentication Protocol for IMS Access over LTE-Heterogeneous Networks In this section, we extend our one pass IMS-AKA protocol to LTE-IMS heteroge- neous network. We make no changes to the HeNB or LTE architecture. HeNB is confined to the role of a SIP proxy. We reinforce security to UE and IMS by pass- ing messages through a secure tunnel. A typical LTE-Heterogeneous IMS AKA goes through the procedures specified in Figure 3.2. 3.2.1 HeNB Authentication with IMS Layer HeNB should be authenticated with the LTE core network as described in Chapter 2. Then, the HeNB should be authenticated with S-CSCF in IMS layer using, one of the following security mechanisms. • Trusted Node Authentication (TNA) 35 Figure 3.2: NAS Security Procedure • SIP Digest In our model, we make use of TNA to authenticate HeNB with S-CSCF. In TNA, access to IMS is granted based on a successful access level authentication performed by a trusted node in the network. As HeNB already has secured access to the core network, further authentications are not necessary. Hence the HeNB acts as a trusted node to the IMS domain and takes on the role of both the SIP User Agent and proxy from an IMS UE perspective. 3.2.2 UE Authentication with IMS Layer First, the UE should be authenticated with the LTE core network as described in Chapter 2. • As shown in Figure 3.3, HeNB takes the role of P-CSCF. When UE is au- thenticated by the MME, the integrity and confidentiality keys are securely transported to HeNB. • To initiate IMS-AKA, an IPSec tunnel is established between HeNB and UE. 36 Figure 3.3: UE Authentication with IMS Layer • UE generates a SIP digest request with IMPI and sends to HeNB. • HeNB identifies the appropriate I-CSCF and forwards the IMS initiation re- quest. • The rest of the protocol proceeds similar to the IMS AKA protocol men- tioned in the previous section. The protocol has been designed considering all the key security threats dis- cussed in Chapter 1. 37 Chapter 4 Security Analysis 4.1 Introduction In this section, we briefly analyze the security of our proposed protocol. Security protocols are sensitive and there is an urge to integrate formal validation in design and development phase. Hence, we provide a qualitative analysis based on rea- soning and a formal validation of protocol using software tools. We validate our proposed solution using automatic tools which use a formal specification language to input a protocol in a perceivable form and backend mathematical tools to detect flaws in the proposed protocol. 4.2 Qualitative Analysis 1. Fake IMS identity manifestations are eliminated as this method is based on impi value of the UE. The impi value is unique, and the impi− imsi pair is securely derived from HSS by S-CSCF, when the UE tries to authenticate for the first time. 2. Replay attacks are avoided when S-CSCF evaluates TS and SN. If TS is ac- ceptable, it checks whether SN is less than SNmax. SIP requests with greater SN values will be discarded. Further, PDG and S-CSCF would also know that UE has completed mod-EAP AKA, thereby preventing illegal access. 38 3. Better security for UE from malicious application providers as this method is based on authentication between S-CSCF and the UE. IMS services are not initiated before the user compares XRES and RES values. 4. This protocol guarantees confidentiality and integrity as no key is transmitted in the clear. Keys, nonces and counters are securely transmitted to protect against eavesdropping attacks. There is no key exchange between UE and AP when the UE authenticates with the access network. 5. All the keys generated in this protocol are fresh and discarded periodically. The concerns of using stale authentication keys during IMS-AKA are al- layed, as the previously generated keys in mod-EAP-AKA are used only for the first time, and discarded upon IMS authentication. 4.3 Formal Validation using Software Tools We evaluate the proposed security protocol in detail using Automated Vali- dation of Internet Security Protocols and Applications (AVISPA) tool [37], [36]. AVISPA package is a state-of-the-art tool for the automatic verification and analysis of Internet security protocols. AVISPA integrates automatic security analysis and verification back-end servers like On-the-Fly Model- Checker (OFMC), Constraint- Logic-based Attack Searcher (Cl-AtSe), and SAT-based Model-Checker (SATMC). Protocols under examination by AVISPA must be coded in the High Level Protocol Specifications Language (HLPSL) to be tested by the backend servers. HLPSL is an expressive, role-based formal language used to describe the details of the protocols in question. HLPSL codes are used to model the roles of UE, WAAA, S-CSCF, and other core network components, as well as the role of the environment and the security goals that has to be achieved. The following HLPSL code illustrates the role of a UE client in our one pass IMS-AKA protocol. 39 role client(C,S : agent, K : symmetric_key, Md5 : hash_func, Success, Failure : text, Access_accept,Access_reject : text, SND, RCV : channel(dy)) played_by C def= local State : nat, Impi_ID , Impi_Port : text, Chall_Message : text const k : protocol_id, sec_c_K : protocol_id init State := 0 transition s1. State = 0 /\ RCV(start) =|> State’:= 1 /\ Impi_ID’:=new() /\ Impi_Port’:=new() /\ SND(Impi_ID’.Impi_Port’.Md5(K)) /\ secret(K,sec_c_K,{C,S}) s2. State = 1 /\ RCV(Impi_ID.Access_accept) =|> State’:= 2 /\ SND(Impi_ID.Success) s3. State = 1 /\ RCV(Impi_ID.Access_reject) =|> State’:= 3 /\ SND(Impi_ID.Failure) s4. State = 1 /\ RCV(Impi_ID.Chall_Message’) =|> State’:= 4 /\ SND(Impi_ID.{Chall_Message’}_K) /\ witness(C,S,K,K) s5. State = 4 /\ RCV(Impi_ID.Access_accept) =|> State’:= 5 /\ SND(Impi_ID.Success) end role To permit testing the support of secured mutual authentication between the UE and S-CSCF, we make use of the unique IMPI id, RCV and SND state- ments. The statement SND(Impi_ID’.Impi_Port’.Md5(K)) 40 stated above,transmits the unique IMPI id, port number required for IMS ac- cess, encapsulated in an MD5 SIP register message. The rest of the codes illustrate the possible scenarios, that follows after SIP register message is sent. The statement (witness(C,K,K,K)) indicates the requirement that the WAAA should be authenticated by the UE. The S-CSCF plays a definitive role in IMS user authentication. Its key func- tions are explained below. role server(C,S : agent, K : symmetric_key, Md5 : hash_func, Success, Failure : text, Access_accept,Access_reject : text, SND, RCV : channel(dy)) played_by S def= local State : nat, Impi_ID , Impi_Port : text, Chall_Message : text const k : protocol_id, sec_s_K : protocol_id init State := 11 transition s1. State = 11 /\ RCV(Impi_ID’.Impi_Port’.Md5(K)) =|> State’:= 12 /\ SND(Impi_ID’.Access_accept) /\ secret(K,sec_s_K,{C,S}) s2. State = 12 /\ RCV(Impi_ID.Success) =|> State’:= 13 s3. State = 11 /\ RCV(Impi_ID’.Impi_Port’.Md5(K)) =|> State’:= 14 /\ SND(Impi_ID’.Access_reject) s4. State = 14 /\ RCV(Impi_ID.Failure) =|> State’:= 15 41 s5. State = 11 /\ RCV(Impi_ID’.Impi_Port’.Md5(K)) =|> State’:= 16 /\ Chall_Message’:=new() /\ SND(Impi_ID’.Chall_Message’) s6. State = 16 /\ RCV(Impi_ID.{Chall_Message}_K) =|> State’:= 17 /\ SND(Impi_ID.Access_accept) /\ request(S,C,K,K) s7. State = 17 /\ RCV(Impi_ID.Success) =|> State’:= 18 end role The following lines of code illustrates the environment in which the authen- tication procedure is carried out. role environment() def= const c1,s1 : agent, md5 : hash_func, succs, fails : text, acc_acp, acc_rej : text, kcsk , kisk, kcik : symmetric_key, k : protocol_id intruder_knowledge = {c1,s1,md5,kisk,kcik, succs, fails, acc_acp, acc_rej } composition session(c1,s1,kcsk,md5,succs,fails,acc_acp,acc_rej) /\ session(i, s1,kisk,md5,succs,fails,acc_acp,acc_rej) end role The support of secured mutual authentication in addition to the secrecy of keys in One pass IMS-AKA was tested using OFMC, Cl-AtSe, and four SAT solvers in SATMC. All tests returned positive results and confirmed the security of mu- tual authentication service and no authentication attacks were found. Results also 42 Figure 4.1: AVISPA Tool Summary for Improved One Pass IMS-AKA confirmed the secrecy of IMPI id and no vulnerabilities were discovered. A stand- alone graphical version of the AVISPA package was used in testing our protocols named Security Protocol Animator for AVISPA (SPAN)[38]. Figure 4.1 shows the AVISPA tool summary for Improved one-pass IMS authentication procedure. Fig- ure 4.2 demonstrate the messages returned by SPAN as a result of testing one pass IMS-AKA using SATMC and Figure 4.3 shows the message returned by SPAN as a result of testing the protocol by OFMC. Figure 4.4 shows the result of testing the protocol using OFMC. AVISPA Web Interface was used in SATMC testing because of problems running SATMC in the standalone versions Thus, our protocol introduces considerable improvement in performance, with- out compromising security. 43 Figure 4.2: Result of testing One Pass IMS-AKA with SATMC 44 Figure 4.3: Result of testing One Pass IMS-AKA with OFMC Figure 4.4: Result of testing One Pass IMS-AKA with CL-Atse 45 Chapter 5 Performance Analysis 5.1 Introduction The performance of proposed protocols is presented in this Chapter against the standardized IMS-AKA. Authentication delay is used as a performance metric for our evaluation. Authentication delay depends upon the delivery cost of an authenti- cation protocol. Studying the delivery cost produced by an authentication protocol is an important metric in evaluating its performance. Authentication delivery cost is the cumulative information exchanged between the nodes during an authentica- tion protocol. 5.2 Performance Evaluation of One-Pass IMS AKA Considering the delivery cost Di as an evaluation metric, we compare our protocol with original IMS-AKA protocol. We assume that the delivery cost between UE and S-CSCF is one unit and the delivery cost of one signalling message in the IMS layer ie between any two of I-CSCF, S-CSCF and HSS overCX interface is α units, where α <1. We make these assumptions because, the message from the UE takes at least 3 hops to reach S-CSCF. We should also take into account a substantial delay in the packet switched domain, and IP network overhead, whereas I-CSCF, S-CSCF and HSS are located in the same network. In existing IMS-AKA, if impi, imsi values are not present in S-CSCF, it inter- 46 acts with HSS to derive the vector pair. DI1 = 4+6α (5.1) If they are present in S-CSCF, then it reduces the message-exchange between HSS and S-CSCF to, DI2 = 4+4α (5.2) , where α is a value between 0 and 1. The AV contains n arrays, where n≥1; therefore one out of n IMS registrations executes Steps 4 and 5. Then the IMS registration cost is computed as follows DI = (DI1/n)+((n−1)∗DI2/n) = 4+((2n+1)∗2α/n) (5.3) In our proposed protocol as in Figure 4.1, If impi, imsi values are not present in S-CSCF, then: DP1 = 2+4α (5.4) If the vectors are present in S-CSCF, then DP2 = 2+2α (5.5) . Hence, the IMS registration cost is DP = 2+((n+1)∗2α/n) (5.6) The improvement factor SP is the improvement in IMS registration cost over the original protocol. It is obtained as follows, SP = (DI −DP)/DI = n(α+1)/(2n+α(1+2n)) (5.7) Plugging typical values for n and α shows an improvement of 50 percent over the traditional multi-pass IMS-AKA. Figure 5.1 plots the improvement achieved by 47 Figure 5.1: α vs Improvement Factor over IMS-AKA the proposed protocol over the original one for different values of n and α . Further, our protocol is better than the previously proposed one-pass IMS Au- thentications. We consider the improvement factor derived in Long et al [7]. SL = n/(2n+(2n+1)α) (5.8) SP/SL = (1+α) (5.9) Figure 5.2 plots the improvement achieved by the proposed protocol over the one proposed by Long et al, for different values of n and α . Thus, it can be observed that the proposed protocol achieves better performance in terms of delay, without compromising any security considerations. As a short recap, we revisit the authentication delay observed during emulation process. 48 Figure 5.2: Comparison of our protocol and Long et al’s protocol Authentication Protocol Authentication Delay in Seconds One-Pass IMS-AKA 2.4145 3GPP IMS-AKA 4.528 It should be noted that IPSec association delay is not included in our analysis. Comparing the numbers provided in the table, we can show that our protocol would reduce authentication delay by 47 percent. However, the improvement factor drops to 21 percent, if we included the time required to establish IPSec tunnel, prior to IMS-AKA. Hence, we could corroborate the results obtained using mathematical analysis with experimental analysis. Thus, our protocol achieves significant improvement in performance by reduc- ing the message exchange between HAAA and WAAA during re-authentications. Our proposed IMS protocol is much faster than the existing schemes. Storing es- sential vectors and response message further reduces delay and promotes efficient key re-use. Mathematical analysis shows a 50 percent improvement over the multi pass AKA for IMS access. The generation of additional keys during mod-EAP AKA procedure may re- 49 quire better processing capabilities at the end nodes. This is a compromise we need to make in order to reduce authentication delays. Faster authentication times translate to better quality of service. The proposed protocol also achieves better results during re-registrations. The number of times the UE handles message processing is directly related to battery drain. Since, the number of message passing between the UE and IMS is limited, it does not impose a drain in energy levels. We have tried to limit the number of times the UE is involved in message processing. 50 Chapter 6 Protocol Emulation and Analysis 6.1 Introduction The goal of this implementation is to test the usability of our protocol with the ex- isting infrastructure. This section provides a brief description of the technologies used to implement the emulator and UEs. Abstraction of key IMS components including P-CSCF, S-CSCF and I-CSCF using linux network tools was essential to validate our protocol [33]. The whole platform is deployed using three virtual machines which are built on top of Windows 2008 R2 server using VMWare virtu- alization tool. The server runs on Intel Core i7 processor at 3.05 Ghz and has 8GB of RAM. It consists of multiple Network Interface Cards to support multiple local area networks (LAN). The network topology, designed for IPv4 protocol, is given in Figure 6.1. • The entire network topology operates in two virtual lans (VLAN), namely VLAN 20 and VLAN 30. In order to provide suitable isolation between the two VLANs, we make use of a Cisco Catalyst 2950 24 switch. One to one correspondence exists between VLANs and the subnets. VLANs are config- ured to map directly to an IP subnet, which gives the appearance of involving Layer 3 (the network layer) in the context of VLANs. VLAN 20 operates in subnet, while VLAN 30 operates in • A Windows Vista virtual machine takes the role of a UE in our model. Our 51 Figure 6.1: Network Topology for Protocol Implementation network model is designed to support any popular SIP based softphone appli- cation. In this case, we have chosen Ekiga (formerly known as GNOMEMeet- ing). It is interoperable with many other standard compliant softwares, hard- wares and service providers as it uses both the major telephony standards (SIP and H.323). It also runs a variation of a Virtual Private Network (VPN) client software[34]. The windows user primarily operates in VLAN 20 network. • The gateway is a virtual machine which runs on CentOS 5.0 operating system. It is analogous to P-CSCF in an IMS architecture. It acts as the link between the user and the service layer. The gateway is designed to operate in two VLANs, namely VLAN 20 and VLAN 30. It can support Internet Security Association and Key Management Protocol (ISAKMP) protocol to support IPSec. For the user to initiate IMS-AKA, it is necessary to establish a secure tunnel between user and the gateway. It also supports secure transport of SIP messages to the service layer. The gateway configuration can be tweaked to limit the influx of SIP register requests from the user. This acts as a defence mechanism against DoS attacks. The gateway operates in both VLAN 20 and 52 VLAN 30 networks. • DNS Server assumes the role of an I-CSCF. Upon receiving the query from the gateway, DNS server would it query its database to identify the location of the server. The DNS server is implemented using a CentOS 5.0 linux virtual machine. The DNS server primarily operates in VLAN 30 network. • The server is a Ubuntu-Linux virtual machine, that runs Asterisk [35]. It is analogous to S-CSCF in an IMS architecture. Asterisk is an open source software which can be used to develop communication services. Asterisk is considered for this emulation, because it is simple to implement. Numer- ous features can be provided by altering its configuration file suitably. Open source means that the developer can change source codes so the applications can be added easily by the user. Asterisk can be considered as a complete Private Branch Exchange (PBX ) or Software complete PBX and provide all PBX features. The advantage of Asterisk is that it can run on multiple oper- ating systems and Asterisk is compatible with Simple Network Management Protocol (SNMP) for monitoring the alerts. For the server to support our pro- tocol, it is necessary to alter configuration files to include user details. The protocol operates on User Datagram Protocol (UDP) port 5060. In order to debug connections, we make use of SIP Python script. The Asterisk server primarily operates in VLAN 30 network, and it is assigned a domain name of • All the nodes in the topology run a version of Wireshark for packet capture and analysis. IPSec Tunnel between Gateway and User IPSec VPN tunnelling is typically performed at Layer 3, or lower, of the OSI net- work model. To enable access, we establish encrypted network connectivity be- tween a user and the internal network. VPNs use encryption and other security mechanisms to ensure that only authorized users can access the network. VPNs also ensure that data transmitted between computers cannot be intercepted by unau- thorized users. In general, the data is encoded so that it cannot be understood, and the data has to be decrypted before it can be used. 53 Figure 6.2: IPSec VPN message exchange The gateway has to be configured to set-up VPN tunnels with the user. There are plenty of open source VPN servers that run on Linux.We have used Open Swan for this implementation. As the first step, we need to define the Phase-1 negotiation parameters. In our model, we choose Digital Encryption Standard (DES), a 64-bit block algorithm that uses a 56-bit key and 3DES, in which plain text is encrypted three times by three keys for packet encryption. The encrypted data is then encap- sulated using SHA-1 algorithm to check the authenticity of messages during phase 1 negotiations. We chose Diffie-Hellman 5 group configuration for generating the session keys. For authentication purposes, we used Pre-shared key (PSK) for sim- plicity. The IKE Phase -1 operates in main mode, which has three sets of 2-way message exchanges between the user and gateway. Upon successful completion of IKE Phase 1, IKE phase 2 begins. IKE phase 2 operates in quick mode. It negotiates a shared IPSec policy, derives shared secret keying material used for the IPSec security algorithms, and establishes IPSec Secu- rity Associations (SA). Quick mode exchanges nonces that provide replay protec- 54 Figure 6.3: IKE as Captured by Wireshark tion. The nonces are used to generate new shared secret key material and prevent replay attacks from generating phony SAs. The tunnel association and key ex- change procedure has been captured and validated using Wireshark. The details are given in Figure 6.2. A graph plotting the data transfer in bytes/tick against time is given in Figure 6.4. The detailed key exchange is provided in the Appendix section. After IKE phase two is complete and quick mode has established IPSec SAs, 55 Figure 6.4: A plot of packet transferred against time during ISAKMP information is exchanged by an IPSec tunnel. Packets are encrypted and decrypted using the encryption specified in the IPSec SA. IPSec VPN association is indis- pensable in IMS-AKA because most of the SIP servers do not support TCP. VPN is the only solution to provide required level of security. On successful IKE association, the gateway assigns a dynamic IP address in VLAN 30 for the windows user. The IP address is valid as long as the association is valid. Authentication Procedure This subsection describes in detail how SIP messages are passed over the IMS network when establishing, participating in, and leaving an IMS network. A SIP registration request can be generated in Ekiga as shown in Figure 6.5. • All SIP requests are routed through the gateway. SIP runs primarily on UDP- 5060, hence it is securely transported through IPSec tunnel. • The gateway checks the destination of the SIP registrar. In this case, it is 56 Figure 6.5: SIP Registration - An Example • The gateway queries the DNS-server, which runs on a CentOS 5.0 linux server, to get the address of the SIP registrar. • The DNS Server returns the query with a valid IP address, or sends recursive queries to other DNS servers to get the IP address. In this case, the DNS server returns the IP address of to the gateway. • The gateway forwards the SIP register request to the Asterisk server. • The server compares the user-identification, password, and subscription de- tails. The user receives an OK message upon successful registration. • The entire authentication process is monitored using Wireshark packet ana- lyzer. A list of request methods generated during a typical call is given in Figure 6.14. The implementation is studied for three scenarios, 1) SIP registration with in- valid account details 2) SIP registration with a valid user account and 3) SIP un- register. SIP Registration with Invalid Account Whenever a user tries to access IMS layer without a valid account, the registration requests are rejected by the authenticating server. In our implementation, the user 57 Figure 6.6: SIP Register with Invalid User details generates a SIP request message encapsulated in MD5 digest message and forwards it to the gateway. The Asterisk server duly responds by sending a 404 Not found message. The process is depicted in Figures 6.6 and 6.7. SIP Registration with valid Account In this scenario, Ekiga client generates a SIP digest message with the following details. The Asterisk server validates the user details and responds with a 200 OK message. In this case, user is not authorized to use any of the subscription services. Any subscription requests or option updates would be duly responded with a 401 Not subscribed message. The process is shown in Figure 6.8 and 6.9. Method: REGISTER Request-URI: CSeq: 4 REGISTER Via: SIP/2.0/UDP/ User-Agest:Ekiga/3.2.7 58 Figure 6.7: A Plot of Message Exchange during SIP Registration with Invalid User details From: <> Call-ID:d530d861-b4ea-1810 To: <> Contact: <SIP:5005@> Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, SUBSCRIBE, REFER, PING Expires: 3600 SIP Unregistration The unregister SIP requests are responded with a 200 OK message. The process follows similar procedure compared to SIP registration, in order to prevent mali- cious users from sending Unregister messages. The process is shown in Figure 6.10 and 6.11. 59 Figure 6.8: SIP Register Process Figure 6.9: A Plot of Message Exchange during SIP Registration 60 Figure 6.10: SIP Unregister Process Figure 6.11: A Plot of Message Exchange during SIP Unregistration 61 Figure 6.12: 3GPP Specified registration Process Comparison with two-pass IMS-AKA 3GPP specified IMS-AKA process was explained in detail in Section 2.3. Upon receiving the Register message, S-CSCF sends a 401 notification to the UE, re- questing additional information. The additional information is usually sent in the form of an authentication challenge, along with a sequence number. IMS user com- putes the challenge response, generates a new Register message and forwards it to the S-CSCF. We have tried to model this process using our network topology. In our proposed protocol, we have eliminated all redundant exchange of information between the user and authentication server. Figure 6.12 and 6.13 illustrate the 3GPP specified IMS-AKA. The request methods, which is the typical number of packets generated during a call registration, generated in our protocol is shown in Figure 6.14. The call setup and tear down times can be calculated based on the packets captured using Wireshark. For our protocol, the call setup merely requires 8.2005 Seconds. This is the time taken to establish IPSec tunnel and SIP Registration. IPSec tunnel 62 Figure 6.13: A Plot of Message Exchange during 3GPP Specified SIP Regis- tration establishment requires 5.786 Seconds, and SIP registration takes 2.4145 Seconds. In contrast to our protocol, the two-pass IMS-AKA requires 4.528 Seconds, after IPSec tunnel establishment. Despite propagation delays and processing delays, the user would enjoy remarkable reduction in authentication delay, if deployed in mobile networks. Detailed performance evaluation and analysis is presented in Chapter 5. 63 Figure 6.14: List of request methods during call setup and teardown 64 Chapter 7 Conclusion 7.1 Summary In this thesis, we have identified the security challenges of IMS implementation over Heterogeneous networks. A re-authentication protocol based on key exchange procedure was discussed. We capitalized on the execution of mod-EAP-AKA and Trusted Node Authentication to shorten the execution of IMS-AKA and eventu- ally speed up re-authentications. The analysis shows an improvement in speed of 50 percent compared to traditional IMS-AKA and significant improvement over other proposed protocols, in terms of security and performance. Security issues identified in [30] and Lin et al [8] were eliminated. In the next part of our thesis, we introduced all packet core of LTE heteroge- neous networks. The problems associated with call set up and tear down due to the lack of circuit switched core network was discussed. A readymade solution for call setup using IMS was discussed. However, IMS access over LTE suffers the same disadvantages as in 3G-WLAN access networks. Thankfully, IMS being access independent, we were able to extend the same solution over LTE-Heterogeneous networks to shorten authentication times at the same level of security. We introduced a network topology using a collection of open source linux soft- ware, proprietary network components and virtualization tools to emulate our se- curity protocol. The software was calibrated to suit our security protocol. Interplay between various virtual machines, resulted in the establishment of a SIP call. Typ- 65 ical call setup and tear down sessions were carefully studied using Wireshark. Thus, we hope to address some of the key issues in IP Multimedia Subsystem, without introducing any serious changes to the existing architecture. 7.2 Future Work The protocols presented in Chapter 3 are effective when the user registers with the IMS for the first time. However, subsequent re-registrations are necessary when the access network changes or if the user is mobile. This is similar to registration procedure and invariably leads to additional delay. The proposed protocol could be expanded to reduce re-authentication delays to avoid unnecessary message ex- change with the user. Another way to reduce authentication delay is to design a protocol that could localize IMS authentications to HeNB. IMS could also play a big role in network unification. In addition to LTE, 4G services are also offered by WiMax. Both LTE and WiMax are IP based, and are designed to carry packets rather than voice. WiMax is a mature technology and it is capable of delivering broadband access to customers in a wireless medium. WiMax can also support Voice, in addition to IPTV and broadband access. IMS can not only support voice, but also unify WiMax with LTE networks. Hence, IMS could play a huge role to bring these complementing technologies together. It may be necessary to introduce additional changes in the protocol and architecture of IMS, depending on how the two networks are coupled. One way of extending our protocol is to make use of smart femtocells with dual-mode support, that is interoperable with WiMax and LTE, for IMS access. 66 Bibliography [1] UMTS Forum (2001), Ranking of top 3G services, UMTS Forum Tech. Rep. → pages 1 [2] 3GPP.TS.22.934 (2002), Group Services and System Aspects; Feasibility study on 3GPP system to Wireless Local Area Network interworking. → pages 2 [3] Bellman, B. (January 2007), Exploring IMS security mechanisms, Business Communications Review. → pages 4 [4] Hunter, M.T., Clark, R. J., and Park, F. S., ”Security issues with the IP Multi- media Subsystem (IMS), ACM Workshop on Middleware for next-generation converged networks and applications, Article 7, November 2007. → pages 4 [5] Velasco, V. (November 2000), Introduction to IP Spoofing, SANS Institute. → pages 5 [6] Crespi, N., Lavaud, S., WLAN Access to 3G Multimedia Services, Informa- tion and Communication Technologies (ICT), Bangkok, November 2004. → pages 5 [7] Long, X., and Joshi, J., Enhanced One-Pass IP Multimedia Subsystem Au- thentication Protocol for UMTS, Communications (ICC), 2010. → pages 5, 48 [8] Lin, Y., Chang, M., et al, One-pass GPRS and IMS authentication procedure for UMTS, IEEE Journal on Selected Areas in Communications, 2005. → pages 5, 31, 65 67 [9] Ntantogian, C., Xenakis, C. and Stavrakakis, I., Efficient authentication for users autonomy in Next Generation All-IP networks, BIMNICS, 2007. → pages 5 [10] Ntantogian, C., Xenakis, C., One-Pass EAP-AKA Authentication in 3G- WLAN Integrated Networks, Wireless Personal Communications, March 2009 → pages 5 [11] Huang, C. and Li, J., Efficient and Provably Secure IP Multimedia Sub- system Authentication for UMTS, The Computer Journal, November 2007, → pages 5 [12] Al Shidhani, A. and Leung, V.C.M., Pre-authentication schemes for UMTS- WLAN interworking, Eurasip J. Wirel.Commun.Netw., 2009. → pages 5, 17 [13] 3GPP.TS.23.002 (2010), Technical Specification Group Services and System Aspects; Network architecture. → pages 8 [14] 3GPP.TS.22.813 (2010), Study of Use Cases and Requirements for Enhanced Voice Codecs for the Evolved Packet System (EPS). → pages 9 [15] 3GPP.TS.22.228 (2009), Technical Specification Group Services and System Aspects; Service Requirement for Internet Protocol multimedia core network subsystem. → pages 10 [16] 3GPP.TS.33.203 (2009), 3G Security;Access security for IP-based services. → pages 9, 33 [17] 3GPP.TR.23.870 (2009), SR VCC Support for IMS Emergency Calls. → pages 9 [18] Olabisi, F., and Chan, H., AAA and Mobility Management in UMTS-WLAN interworking, Proc. 12th International Conference on Telecommunications, ICT 2005 → pages 12 68 [19] Buddhikot, G., Chandranmenon, S., Han, Y., et al, Integration of 802.11 and third-generation wireless data networks, Proc. IEEE INFOCOM 2003, vol.1, p. 503-512, San Francisco, USA, 2003. → pages 12 [20] Fitzek, F., Munari, M., Pastesini,V. et al, Security and authentication concepts for UMTS/WLAN convergence, Proc. IEEE 58th Vehicular Technology Con- ference, VTC 2003, vol.4, pp. 2343-2347, Florida, USA, 2003 → pages 12 [23] 3GPP.TS.33.102 (2009), Technical Specification Group Services and System Aspects; 3G Security;Release 9. → pages 14 [22] Al Shidhani, A. and Leung, V.C.M., Local fast re-authentication protocol for 3G-WLAN interworking architecture, Wireless Telecommunications Sympo- sium, 2007 → pages 14, 16 [23] 3GPP.TS.33.102 (2009), Technical Specification Group Services and System Aspects; 3G Security;Release 9, 3rd Generation Partnership Project.→ pages 14 [24] Wang, X., Yin, Y., and Yu, H., Finding Collisions in the Full SHA-1, Springerlink, 2005 → pages 18 [25] 3GPP.TS.33.210 (2009), 3G Security;Network Domain Security;Ip network layer security → pages 19 [26] 3GPP.TS.29.229 (2008),Technical Specification Group Core Network and Terminals; Cx and Dx interfaces based on the Diameter protocol; Release 8 → pages 19 [27] Forsberg, D., LTE Key Management Analysis with Session Keys Context, Computer Communications, 10-2010 → pages 28 [28] Oredope, A., Pham, V., et al, Deploying IP Multimedia Subsystem (IMS) Services in Future Mobile Networks, Communications (NCC), 2011 National Conference on, January, 2011 → pages 29 69 [29] 3GPP.TS.24.228 (2005), Technical Specification Group Core Network and Terminals;Signalling flows for the IP multimedia call control based on Ses- sion Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 → pages 29 [30] 3GPP.TR.23.832 (2010), IP Multimedia Subsystem (IMS) aspects of archi- tecture for Home Node B (HNB) → pages 30, 31, 65 [31] 3GPP.TS.25.467 (2010), UTRAN architecture for 3G Home Node B→ pages 30 [32] 3GPP.TS.29.228 (2009) Technical Specification Group Core Network and Terminals; IP Multimedia (IM) Subsystem Cx and Dx interfaces;Release 8 → pages 35 [33] Buono, A., Loreto, S., et al, A distributed IMS enabled conferencing architec- ture on top of a standard centralized conferencing framework [IP Multimedia Systems (IMS) Infrastructure and Services], March, 2007 → pages 51 [34] → pages 52 [35] → pages 53 [36] Armando, A., Compagna, L., An Optimized Intruder Model for SAT-based Model-Checking of Security Protocols, Workshop on Automated Reasoning for Security Protocol Analysis, ARSPA 2004 → pages 39 [37] AVISPA-Automated Validation of Internet Security Protocols,, 2002 → pages 39 [38] Armando, A., Basin, D., et al, The AVISPA tool for the Automatic Validation of Internet Security Protocols and Applications, Computer Aided Verifica- tion, LNCS 3576, Springer Verlag. 2005 → pages 43 70


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items