Iec Final Paper Pdf

Protection Against Identity Threats in Early IP Multimedia Subsystem (IMS) Rohan Kiran Chitnis Thomas M. Chen Department of Electrical Engineering Southern Methodist University Dallas, Texas 75275 [email protected], [email protected] Tel: (214) 768-8541 Abstract – Early IMS has been recognized as an evolutionary step from existing networks to full IMS. Concern has been raised about the adequacy of incomplete security. This paper examines the concepts of identity and potential identity threats in early IMS. The early IMS authentication process designed to protect against the most likely identity threats is described. 1. Introduction In the very broad picture, mobile devices (cell phones, smartphones, wireless PDAs) and the Internet stand out as recent successes in the telecommunications field. There are now more than 2 billion mobile device users around the world, and demand continues to grow for faster 3G services. Mobile devices have clearly evolved from simple phones to multimedia computing devices similar in capabilities to traditional PCs. Multimedia mobile devices have a need beyond simply accessing the Internet; they need sophisticated real-time multimedia services built on common Internet protocols [1]. The initial idea of building an IMS (IP Multimedia Subsystem) architecture for delivering IP-based (Internet Protocol) multimedia to mobile users came from the 3G.IP (3rd Generation Internet Protocol Forum) industry forum. The initial IMS architecture was brought to 3GPP (3rd Generation Partnership Project) which was working on standards for the Universal Mobile Telecommunications System (UMTS). 3GPP Release 4 completed in 2001 included IP transport for the core network, and IMS was added in 3GPP Release 5 in 2002. Release 5 identified architectural entities, reference points, quality of service, AKA (authentication and key agreement) for security, and SIP (session initiation protocol) for signaling. In 2004, 3GPP Release 6 added interoperability with wireless local area networks, IP address-based authentication, confidentiality protection of SIP messages, and some enhancements to IMS such as PoC (push to talk over cellular). In 2006, 3GPP Release 7 added more support for fixed broadband networks. “Early IMS” was defined to allow an evolutionary path towards fully compliant IMS implementations. In particular, it was believed that a complete IMS security implementation would take considerable time to be realized [2,3]. One reason is that IMS uses IPv6 (version 6), which is far from ubiquitous. Early IMS can use IPv4 and aims to incorporate some security defenses against the most significant threats [4]. In this paper, we examine the shortcomings of security in early IMS. In particular, we discuss the concept of identities in IMS and possible threats to identities in early IMS.

1

A goal of early IMS is “strength of subscriber authentication comparable to the level of authentication provided for existing chargeable services in mobile networks” [4]. 2. IMS Identities Authentication is the problem of verifying the subscriber identity. How are subscribers identified in IMS? In the traditional telephone network, subscribers are identified simply by their assigned telephone number. Unfortunately, the concept of identity in IMS is complicated because subscribers have various identities associated with them [2]. Since all communications is IP, every communicating device has an IPv6 or IPv4 address (early IMS allows IPv4). In addition, 3GPP networks make use of these numbers: • IMSI (international mobile subscriber identity) • TMSI (temporary mobile subscriber identity) • IMEI (international mobile equipment identity) • MSISDN (mobile subscriber integrated services digital network number) The IMSI is a unique mobile number stored in the ISIM (IMS subscriber identification module) in the mobile device. The ISIM is an application residing in a secure UICC (universal integrated circuit card) card in the mobile device [5]. For protection of privacy, a TMSI is generated per geographic location and used for different sessions. Whereas the IMSI or TMSI are associated with users, the IMEI is a unique number bound to a particular device. The MSISDN is a phone number of a user (who might use multiple MSISDN numbers). IMS translates MSISDN numbers internally into SIP uniform resource identifiers (URIs), explained below. Furthermore, ISM subscribers have two additional identities, one private and the other public: • IMPI (IP multimedia private identity) • IMPU (IP multimedia public identity) The private identity is a unique identity assigned to the user by his/her home network operator. For compatibility, the private identity may be derived from a user’s IMSI. The private identity is associated with the user’s service profile. Authentication is mainly the problem of verifying a user’s private identity during a registration process. To prevent malicious tampering, a user’s private identity is stored in the user’s ISIM. As the term “private” implies, the private identity is used only for authentication but public identities are used for communications with other users. Public identities may be published to enable users to find each other. Public identities are SIP URIs resembling e-mail addresses [6]. The so-called “sip-uri” SIP address format is “sip:[email protected].” Alternatively, a sip-uri may have the form of a fully qualified domain name such as “sip:[email protected]” which specifies the host IP address explicitly. Another possible form is a “tel-uri” resembling a telephone number such as “sip:[email protected].” There may be multiple public identities associated with a private identity. These public identities are registered with the user’s home network operator but are not used for authentication. At least one but not necessarily all public identities are stored in the user’s ISIM.

2

A public identity may be shared by multiple mobile devices, each device using a different private identity, so that multiple people may be reached with the same public identity. In this case, a group of people share the same IMS subscription and service profile. Figure 1 shows that a private identity can have multiple public identities, and a public identity may be associated with multiple private identities.

Public identity 1

Service profile 1

Private identity 1 IMS subscription

Public identity 2 Private identity 2

Service profile 2 Public identity 3

Figure 1. Example of relationship between identities 3. IMS Registration and User Authentication As mentioned before, SIP is the signaling protocol in IMS for establishing, changing, and terminating multimedia sessions [6]. A session is established by processing and forwarding SIP INVITE messages through SIP servers or proxies, called CSCFs (call/session control functions) in IMS. IMS makes use of three types of SIP proxies: PCSCF (proxy CSCF), S-CSCF (serving CSCF), and I-CSCF (interrogating CSCF). They have different functions in the registration process and session establishment [2]. The P-CSCF is the first SIP proxy to receive and forward a signaling message from an IMS user, as shown in Figure 2. The IMS user may connect to the P-CSCF through the GGSN (gateway GPRS support node) responsible for routing IP packets (including SIP messages) between the user and IMS. The P-CSCF could be located in the visited network or home network, and might be implemented by a session border

3

controller. As the first point of contract from the IMS user, all signaling messages go through the P-CSCF. It is able to inspect and process all signaling messages.

IM S

HSS

I-CSCF

S-CSCF

P-CSCF

GGSN

User

Figure 2. Simplified architecture of IMS security

The I-CSCF is a SIP proxy that resides in the user’s home network and serves as the point of contact for calls going to that user’s home network. It queries the HSS (home subscriber server) for S-CSCFs, and chooses one and routes SIP requests to that S-CSCF. The S-CSCF is another SIP proxy residing in the user’s home network. It consults the HSS to look up information about a user and his/her service profile (authorized services). After determining which services are authorized, the S-CSCF forwards SIP signaling to the appropriate application servers. The S-CSCF maintains session state to support services.

4

3.1. Basic Registration Process A user Alice must register with IMS in order to use services. Alice’s private identity is used for authentication and associating her with the correct service profile. The registration process is based on challenge-response and carried out in two phases. The first phase shown in Figure 3 results in a challenge from the network sent to Alice. In the second phase shown in Figure 4, Alice returns a response to prove his/her identity.

HSS (3) S-CSCF assignment

(5) Authentication data

Home network

(4) Register

I-CSCF

S-CSCF (6) 401 Unauthorized

(2) Register

(7) 401 Unauthorized

P-CSCF (1) Register

(8) 401 Unauthorized

Alice

Figure 3. Challenge part of registration process

5

Visited network

HSS (11) S-CSCF assignment

(13) User profile (12) Register

I-CSCF

S-CSCF (14) 200 OK

(10) Register

(15) 200 OK

P-CSCF (9) Register

(16) 200 OK

Alice

Figure 4. Response part of registration process

Alice initiates the registration process by sending a SIP REGISTER request to the nearby P-CSCF. The request contains Alice’s public user identity (say “sip:[email protected]”), private identity, IP address, and a home domain name (address of the home I-CSCF). These information are all stored in Alice’s ISIM. The PCSCF forwards the REGISTER request to the I-CSCF in Alice’s home network. The ICSCF queries the HSS for an assigned S-CSCF. After getting the assignment, the I-CSCF forwards the REGISTER request to the designated S-CSCF. The S-CSCF creates a binding between Alice’s public identity and her IP address. The S-CSCF consults with the HSS for authentication data for the user and sends a challenge back to Alice in the form of a SIP 401 UNAUTHORIZED response (SIP responses have various status codes with different meanings). Alice must calculate the proper response to the challenge, which is returned in another SIP REGISTER request. The request is forwarded through the P-CSCF and ICSCF to the S-CSCF. The S-CSCF checks the response against the authentication data it had retrieved from the HSS. If the response is valid, the S-CSCF fetches Alice’s user profile from the HSS and acknowledges the successful registration with a SIP 200 OK response to Alice.

6

3.2. User Authentication The critical step in the registration process is obviously Alice’s response compared to the authentication data at the S-CSCF. What is the authentication data? Like all challenge-response protocols, the IMS registration process depends on a shared secret. In IMS, the secret is shared between Alice’s ISIM and the HSS. The shared secret allows Alice’s ISIM to calculate the proper response to any challenge issued by the HSS. As mentioned above, the S-CSCF actually handles the authentication of Alice. It does not fetch the secret from the HSS because the secret might be compromised if it is transmitted. Instead, the HSS provides this vector of data: • a random challenge, RAND • the expected response, XRES • the network authentication token, AUTN • the integrity key, IK • the ciphering key, CK. This vector of data enables the S-CSCF to validate the response from Alice without knowing the shared secret. When Alice sends the initial REGISTER request, the S-CSCF fetches the authentication data vector from the HSS and rejects the REGISTER request with a 401 UNAUTHORIZED response. The 401 response contains the RAND, AUTN, IK, and CK. The 401 response goes through the P-CSCF on the way to Alice. The P-CSCF takes out the IK and CK keys before forwarding the 401 response to Alice. Alice does receive the RAND and AUTN, which are processed by her ISIM. The ISIM uses its stored secret to verify that the AUTN corresponds to the number of her home network’s HSS. Next, the ISIM uses it stored secret and the RAND to calculate the proper response, RES. The RES is carried in the second REGISTER request that Alice sends to the SCSCF. The S-CSCF compares the RES from Alice with the XRES fetched from the HSS. If they match, then it proves that Alice’s ISIM has the same secret as the HSS. Hence, the S-CSCF will consider that Alice’s identity is authenticated and will proceed with Alice’s SIP registration. 4. Early IMS Security “Early IMS” refers to the industry’s recognition that existing networks will take significant time to evolve to an IMS architecture that is fully compliant with standards. For one thing, IMS requires IPv6 but early IMS may use IPv4. Early IMS is an evolutionary stage between existing networks and full IMS, where security mechanisms in particular may not be complete but should be adequate to ensure confidentiality (especially over the radio interface) and authentication of subscribers to access their authorized services [4]. Existing 3GPP access including GSM (Global System for Mobile) and GPRS (General Packet Radio Service) is specifically supported with early IMS security. Since 2G-only mobile devices might access early IMS, the interim security in early IMS may not depend on ISIM-based authentication, as described above. Early IMS security aims only to protect against the most likely and serious security threats, under these constraints:

7

• • • • •

low impact on existing mobile devices smooth migration towards full IMS security co-existence with full IMS security support for secure 3GPP access (GSM/GPRS) a single early IMS solution.

4.1. Identity Threats What are the most likely and serious identity threats? The presumed goal of identity theft is to masquerade as someone else in order to access and steal network services [4]. One can easily imagine different ways to perpetrate masquerade by an intruder Trudy: Scenario 1: intruder Trudy accesses the network with her own IP address and IMS identity, and sends a SIP INVITE request (to set up a connection) with her own IP address but a legitimate user Alice’s IMS identity. In this way, Trudy would be charged for IP connectivity but IMS service would be fraudulently charged to Alice. Scenario 2: intruder Trudy sends a SIP INVITE request with her own IMS identity but a legitimate user Alice’s IP address. In this way, Trudy would be charged for IMS service but Alice would be fraudulently charged for IP connectivity. This would have no impact on Alice if she is already paying a flat fee for unlimited IP connectivity. In addition, this fraud makes sense for Trudy only for IMS services with outgoing traffic because incoming packets will go to Alice instead of Trudy. Scenario 3: intruder Trudy sends a SIP INVITE request with a legitimate user Alice’s IMS identity and Alice’s IP address. In this way, Alice will be fraudulently charged for IP connectivity and IMS services. However, Trudy does not accomplish that much. Similar to scenario 2, this fraud makes sense for Trudy only for IMS services with outgoing traffic because incoming packets will go to Alice instead of Trudy. Naturally, a wide range of identity attacks are possible, for example, man-in-themiddle attacks, session hijacking, DNS (domain name system) attacks, or rogue SIP proxies. Early IMS does not attempt to protect against every potential threat and does not claim to provide adequate protection against sophisticated attacks. 4.2. Authentication Procedure Early IMS security is based on authentication of a user’s IP address at the GPRS level and the user’s IMS identity at the SIP level [4]. The basic registration procedure for Alice is shown in Figure 5. Alice uses an IMS public identity derived from her IMSI. Since early IMS assumes that devices may not have fully compliant ISIMs to store private identities, early IMS registration does not use private identities (unlike full IMS). Instead, a temporary public identity is derived from a user’s IMSI. In another difference from full IMS, registration is not challenge-response, i.e., dependent on a shared secret.

8

HSS (4) S-CSCF assignment

(6) Public identity, stored IP address

Home network

(5) Register

I-CSCF

S-CSCF (7) 200 OK

(3) Register

(8) 200 OK

P-CSCF (2) Register

Visited network

(9) 200 OK

GGSN (1) Register

(10) 200 OK

Alice

Figure 5. Early IMS registration process

For registration to work, the HSS must know the public identity associated with Alice’s subscription. Before the process is initiated, it is important for Alice to contact the HSS, going through the GGSN, to establish a binding between her MSISDN, IMSI, and IP address. The procedure for this initial contact is not shown in Figure 5. The registration process in Figure 5 assumes that the HSS has a binding between Alice’s MSISDN, IMSI, and IP address. Alice initiates registration by a SIP REGISTER request to the GGSN. The GGSN knows the proper binding between Alice’s public identity and her IP address, and will check for IP address spoofing in the REGISTER request. The REGISTER message is forwarded to the P-CSCF and then I-CSCF. The ICSCF passes the public identity to the HSS, which designates a S-CSCF. The REGISTER request is forwarded to the assigned S-CSCF, which queries the HSS with Alice’s public identity. The HSS checks the MSISDN or IMSI bound to that public identity to determine Alice’s IP address. After learning Alice’s IP address from the HSS, the S-CSCF compares the proper IP address to the IP address in the REGISTER request. If the IP addresses match, then Alice’s identity is authenticated, and a 200 OK response is returned back to her.

9

5. Conclusions Full IMS authentication depends on a challenge-response to prove a shared secret. In contrast, early IMS authentication is weaker. It depends only on demonstrating the proper binding between a user’s IP address and a derived temporary IMS public identity. This weak authentication method is adequate protection against simple masquerade attacks where the IP address or IMS identity is spoofed, but it is likely inadequate against more sophisticated attacks. 6. References [1] [2] [3] [4] [5] [6]

M. Poikselka, G. Mayer, H. Khartabil, A. Niemi, The IMS: IP Multimedia Concepts and Services, 2nd ed., John Wiley & Sons, West Sussex, 2006. 3GPP, “3G security; access security for IP-based services (Release 7),” TS 33.203 v7.6.0, June 2007. 3GPP, “3G security; security architecture,” TS 33.102 v7.1.0, Dec. 2006. 3GPP, “Security aspects of early IP Multimedia Subsystem (IMS),” TR 33.978 v7.0.0, June 2006. 3GPP, “Characteristics of the IP multimedia services identity module (ISIM) application,” TS 31.103 v7.2.1, June 2007. J. Rosenberg, et al., “SIP: session initiation protocol,” IETF RFC 3261, June 2002.

10