IMS is a standard that defines a generic architecture for offering Voice over IP (VoIP) and multimedia services
[16]. This way, operators can take advantage of a powerful multi-vendor service creation industry, avoiding sticking to a single operator to obtain new services. IMS provides integrated services to its customers, and a platform for application providers to host their content on its servers.
The IMS does not mandate any particular business model. Instead, it lets operators charge as they think more appropriate. The IMS provides information about the service being invoked by the user, and with this information the operator decides whether to use differentiated rate for the service, apply traditional time-based charging, apply QoS-based, or perform any new type of charging
[17].
The IMS core network, predominantly consists of the Call Session Control Function (CSCF) and the Home Subscriber Server (HSS). The CSCF node facilitates session setup and teardown using SIP. HSS plays the role of a location server in IMS and also serves as a single point of service for IMS subscribers and their services
[18]. The Subscriber Location Function (SLF) is needed to map user addresses when multiple HSSs are used. CSCF is divided into three logical entities: Proxy CSCF (P-CSCF), Interrogating CSCF (I-CSCF), and Serving CSCF (S-CSCF). P-CSCF is responsible for routing incoming SIP messages to the IMS registrar server and for facilitating policy control. I-CSCF acts as an inbound SIP proxy server in the IMS. S-CSCF is the heart of the IMS core network. It facilitates the routing path for mobile originated or terminated session requests and is the most processing intensive node of the IMS core network. Finally, the Application Server (AS) is a standardized element in the IMS model, which hosts and executes services, and interfaces with S-CSCF using SIP.
The fact that IMS is an access network independent technology results in additional security concerns. There needs to be additional security measures that guarantee precise functioning of IMS regardless of what the access network offers. Hence, the 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 authenticated by the LTE core network can impersonate another user to gain illegal access to IMS services
[4, 5]. 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 Long Term Evolution- Authentication and Key Agreement ( LTE-AKA ) followed by IMS-AKA with IMS layer. The traditional IMS-AKA is shown in Figure
1. However, the operations in IMS-AKA are almost the same as that in LTE-AKA. It is inefficient that almost all involved steps in the multi-pass authentication are duplicated. This results in discernible delays and battery power drain during UE authentication, especially when UE needs to be re-authenticated multiple 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 authentication procedure.
LTE Heterogeneous Network
In this section, we present Long Term Evolution network for 4G access as shown in Figure
2, and unification of IMS services with the LTE core network. A true 4G 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. A femtocell 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 environments 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 EPC. 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 support 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.
Components of LTE
The basic entities of Enhanced packed Core are shown in Figure
2. 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 control of all radio related functions in the fixed part of the system. Typically, the eNodeBs are distributed throughout the networks coverage area, each residing near the actual radio antennas. 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. Mobility Management Entity (MME) is the control plane entity within EPC. MME supports Non-Access-Stratum NAS signalling and security. It is responsible for authentication of users, bearer establishment, roaming and lawful interception of traffic. The Packet Data Network Gateway (PDN GW) is responsible for handling packet transport within the LTE. In order to support LTE-Heterogeneous networks, we need to include the following:
Home Node B (HeNB) is a base station located on the user premises and operates in the same radio interface as that of the operator
[19]. The HeNB system can be deployed either in Closed Subscriber Group (CSG) mode or Open mode. In CSG mode, only certain subscribers can access the HeNB, whereas in Open mode any subscriber in the vicinity has access to HeNB. Secure Gateway (SeGW) 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 Authentication Authorization and Accounting (AAA) server to complete authentication procedure. Femtocell Management System (FMS) is responsible for management of all the HeNBs. 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.
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.
-
HeNB Authentication with LTE Secure Gateway Upon gateway discovery, HeNB initiates an Internet Key Exchange (IKE) v2 based authentication by sending an IKE INIT Request to the secure gateway as shown in Figure
3. The request message consists of SA
i
, which is the list of algorithms that support IKE. KE
i
denotes the HeNB’s Diffie-Hellman value.
(1)
SeGW sends an INIT Response message, requesting a certificate from HeNB, certreq. It chooses the choice of the certificate vendor in SAr
i
, completes Diffie-Hellman exchange with KE
r
.
(2)
HeNB sends an IKE auth request message AUTH, which consists of its unique ID, IDi , the requested client certificate, authentication payload and traffic selectors TS
i
, TS
r
. It also requests the server certificate from SeGW. The entire payload is encapsulated for integrity protection.
(3)
SeGW first verifies that the certificate in the cert payload has not been tampered and the ID
i
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 Notification 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 provide service. AAA contacts HSS to derive authentication vectors and responds with the authorization result.
(4)
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. Additional IPSec tunnels may be created, if required.
-
UE Authentication with LTE Core Network If HeNB operates in CSG 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.
-
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 Request message, which consists of UE’s International Mobile Subscriber Identity (IMSI). The process is shown in Figure
4.
-
Upon receiving the NAS request, HeNB attaches the CSG-ID and forwards 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 LTE-AKA, to complete the authentication procedure as shown in Figure
5.
-
Registration of UE with IMS HeNB assumes the role of a P-CSCF and SIP server for the UE
[20].
-
The IMS HeNB performs the HeNB registration procedure to the HeNB-GW.
-
When the UE attempts to access the HeNB via an initial NAS message and there is no context in the HeNB allocated for that UE, the HeNB performs the UE Registration to the HeNB-GW.
-
The IMS HeNB requests IMS Access Authorization by providing necessary identifying information for the IMS HeNB and UE, e.g., HeNB 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, as established by operator policy. Hence, all IMS authentications are localized to HeNB node.
-
In case the UE was already IMS registered via another IMS HeNB, IMS will de-register the UE from the previous IMS HeNB.event.
Problems in Existing Authentication Mechanisms
The traditional IMS-AKA given in Figure
1, 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.
NASS Bundled IMS Authentication
NASS based models do not implement any authentication mechanism at all, to reduce authentication delay. The IMS users are authenticated by underlying access network authentication and their identity and their IP address are sent to IMS network as the proof of authentication. Both solutions assume anti-spoofing mechanisms 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. This authentication procedure 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 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 conentiality 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 the existing protocols, 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 features 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 authentication, an adversary can hijack the session using man-in-the-middle attacks.
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.