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
rchitnis@mail.smu.edu, tchen@engr.smu.edu
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:alice@company.com.” Alternatively, a sip-uri may have the form
of a fully qualified domain name such as “sip:bob@127.55.3.12” which specifies the host
IP address explicitly. Another possible form is a “tel-uri” resembling a telephone number
such as “sip:+1-212-555-1234@company.com.”
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 Service
identity 1 profile 1

Private
identity 1

IMS subscription Public

identity 2

Private Service
identity 2 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: P-
CSCF (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
HSS
S

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 (5) Authentication Home
assignment data network

(4) Register
I-CSCF S-CSCF
(6) 401 Unauthorized
(2) Register (7) 401 Unauthorized

P-CSCF
Visited
(8) 401 Unauthorized network
(1) Register

Alice

Figure 3. Challenge part of registration process

5
 HSS
(11) S-CSCF (13) User profile
assignment

(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:alice@company.com”), 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 P-
CSCF forwards the REGISTER request to the I-CSCF in Alice’s home network. The I-
CSCF 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 I-
CSCF 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 S-
CSCF. 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-the-
middle 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 Home
(6) Public identity,
assignment stored IP address network

(5) Register
I-CSCF S-CSCF
(7) 200 OK
(3) Register (8) 200 OK

P-CSCF
Visited
(9) 200 OK network
(2) Register

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 I-
CSCF 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] M. Poikselka, G. Mayer, H. Khartabil, A. Niemi, The IMS: IP Multimedia Concepts

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

10