IMS security

IMS (IP Multimedia Subsystem) is a set of specifications to offer multimedia services through IP protocol. This makes it possible to incorporate all kinds of services, such as voice, multimedia and data, on an accessible platform through any Internet connection (fixed or mobile).

IMS's origin

Initially defined by 3G.IP (a set of companies belonging the telecommunications sector), it was 3GPP (3rd Generation Partnership Project) who definitively adopted the definition of IMS as a part of the standardization 3G system in networks UMTS (Universal Mobile Telecommunications System), specified in Release 5 and 6.

Architecture

It can be divided into three layers:

Application

Where there are AS (Application Servers), the MRF (Media Resource Function) and a HSS (Home Subscriber Server).

Control

Formed by different subsystems among which is IMS core.

Other important devices in this layer are the CSCF (Call State Control Function), which includes three subsystems: P-CSCF (Proxy CSCF), S-CSCF (Serving CSCF) and I-CSCF (Interrogating CSCF). These subsystems are the responsible, basically, of: processing and routing the signaling; to control the resources of the transport subsystem, to register and authenticate users; provisioning IMS services by diverting signaling application servers in question and to generate billing records.

The MRF (Media Resources Function) provides functions related to media, such as the manipulation of the media and the reproduction of tones and announcements. Each MRF divides into a MRFC (Media Resources Function Controller) and a MRFP (Media Resources Function Processor). The MRFC is a signaling plane node that interprets the information coming from an AS and S-CSCF to control the MRFP. The MRFP is a node of the plane of the media, is used to mix the source or process media streams.

Transport

Composed by the UE (User Equipment), the access network, the NASS (Network Attachment Subsystem) and the RACS (Resource Admission Control Subsystem). The transport of network is performed using either IPv6 or IPv4, allowing QoS's implementation, integrated security, autoconfiguration…

Security

Having seen a little of what is IMS and the devices that act, we enter IMS specifications relating to security.

From the point of view of the standardization, only exists a mechanism of authentication and access control, specified in the TS 33.203 of 3GPP (Access Security for IP-Based Services) and commonly called AKA (Authentication and Key Agreement). However, there are many other mechanisms for authentication and access control, defined to meet the needs of inherited terminals and to enable faster deployment. The most common are:

The existing variety of authentication mechanisms used in networks, causes problems related with the interoperability, the existence of networks with different security levels, the most adapted method selection during the client registration, etc. In this respect, 3GPP has developed the recommendation TR 33.803 to guide in selecting the most appropriate authentication method.

AKA (Authentication and Key Agreement)

The security in IMS is based on a secret key of long duration shared between the ISIM and the AUC (Authentication Center) of the local network.

The AKA used to establish both the encryption keys (3DES or AES-CBC) and the integrity keys (HMAC-MD5 or HMAC-SHA-1).

  1. ISIM ↔ HSS: Required for the mutual authentication. Both the HSS and the ISIM have stored a secret key and private identification (IMPI) associated with that key.
  2. UA ↔ P-CSCF: Ensures a secure link between the UE and network.
  3. I/S-CSCF ↔ HSS: Establishes a security association for information transfer between the I/S-CSCF and the HSS.
  4. P-CSCF ↔ I/S-CSCF: This security association applies only when the P-CSCF is not in the Home Network.
  5. I-CSCF ↔ S-CSCF: Provides security between SIP nodes within a network.

Registration process

Before a user can get access to IP Multimedia services, it must register at least one IMPU (IP Multimedia Public Identity), such as a telephone number. Then the IMS network must authenticate the IMPI (IP Multimedia Private Identity) at application. The registration process is initiated by the IMS terminal sending a SIP REGISTER message to the P-CSCF directed his IMPI and IMPU. This message reaches the P-CSCF, and it forwards the message to the I-CSCF. The I-CSCF sends a DIAMETER message authentication request of the user who sent the REGISTER message, DIAMETER UAR to HSS, who responds with another message DIAMETER UAA and parallel to I-CSCF informs the direction of the S-CSCF assigned to the user. Then the I- CSCF forwards the registration message to the S-CSCF, which in turn sends the message DIAMETER MAR including IMPI, which is used by the HSS to calculate the Authentication Vector (AV) and generates the quintuple < RAND, AUTN, XRES, CK, IK > and returns the S-CSCF to fivefold through DIAMETER MAA message. This message is an indication that the network is requesting that the terminal uses its security algorithms in order to authenticate. Then the S-CSCF sends the SIP 401 Unauthorized message accompanied by four of the five parameters making up the AV to I-CSCF, which forwards the message to the P-CSCF. Again, the P-CSCF forwards the message to the UE but leaving him only two parameters, the RAND and AUTN. Since the terminal has the same secret key that has a corresponding HSS, the user can calculate the AUTN. If this matches the one received from the network, the network is considered legitimate. The UE also calculates its response RES which is sent to another SIP REGISTER message with IMPI and ARPU. This message reaches the P-CSCF which forwards the I-CSCF. After the I-CSCF sends a DIAMETER UAR to HSS who responds with the address of S-CSCF through a DIAMETER UAA message. Then the I-CSCF forwards the registration message with the RES to S-CSCF. The latter sends the message DIAMETER SAR to the HSS who replies with DIAMETER SAA. If the RES parameter sent by the user is equal to XRES had calculated the HSS during the first registration attempt, then the HSS authenticates the user by means of the message DIAMETER SAA. Finally the S-CSCF sends a SIP 200 OK message to P-CSCF, which forwards it to the user. Security processes are always executed by the Home Network, even if the user is roaming.

Support confidentiality of SIP messages between the UE and the P-CSCF through the use of IPsec is provided.

IMS Access Security for SIP

According to 3GPP specifications, user authentication must be based on Digest AKA, somewhat analogous to the UMTS (Universal Mobile Telecommunications System) access authentication but for SIP. The 3GPP specification TS 33.203 exposed to signalling between the user agent and the P-CSCF should be based on IPsec ESP (Encapsulating Security Payload) in transport mode. However, the use of IPSec in this mode was not suitable for use in fixed networks. The problem lay in the intersection IPsec NAT (Network Address Translation), so TISPAN (Telecommunications and Internet Convergence Services and Protocols for Advanced Networks) mode selected UDP (User Datagram Protocol) encapsulation of IPsec.

GAA (Generic Authentication Architecture)

All security mechanisms we've seen are used in access networks and IMS domains. However, it is possible to extend the above authentication mechanisms at the application or service using what is known as GAA.

The GAA is the authentication architecture that makes it possible to extend the existing authentication mechanisms in IMS application layer/service.

GAA employs two authentication mechanisms. One is based on the possession of a shared secret between the communicating entities (GBA-Generic Bootstrapping Architecture) derived from the keys used in the AKA authentication, and the other based on asymmetric cryptography (public and private key) and digital certificates or PKI (SSC - Support for Subscriber Certificates).

Authentication using a shared secret

Of the two types of implementation, the most used is based on shared secrets. The great advantage of GAA/GBA is that it allows the creation of security associations between the user agent and the various applications. These partnerships consist primarily to share a key (the shared secret), which allows subsequent user agent authentication against the application, and, if necessary, other security features such as the guarantee of confidentiality and integrity of information (through encryption and digital signature), non-repudiation (digital signature), etc. The problem with these mechanisms is the way to agree on this shared secret. As I mentioned earlier, the secret is derived from the authentication keys used in AKA.

A new network element called BSF (Bootstrapping Server Function) is introduced. This BSF has an interface with the HSS. The UE runs AKA with the HSS via the BSF. An application server called NAF (Network Application Function) can retrieve this session key from the BSF, with the subscriber profile information. Thus, NAF server applications and UE share a secret key that can then be used for security application, in particular to authenticate the UE and the NAF in the beginning of the application session (possibly for the integrity and/or protection of confidentiality). The communication between the UE and the BSF as well as between and among NAF and BSF and HSS, are independent of the application.

Asymmetric cryptography based authentication and certificates

An alternative to the use of shared secrets for authentication is the use of asymmetric cryptography. This means that the entity that wants to be authenticated must have a key pair (public and private) and validating a digital certificate key pair. Once in possession of the key and the certificate, the UE can use them to produce digital signatures. The main disadvantage of this type of authentication is that you need a PKI and asymmetric key operations require more computational effort.

If a customer wishes to use asymmetric encryption technology, you need a digital certificate issued by a CA (Certification Authority). The certificate binds a public key to the identity of their respective owners. If a mobile subscriber wants to have and use a pair of keys (private and public), the certificate must be pre-installed or the subscriber must have the means to generate or obtain a key pair and, likewise, to dynamically obtain one digital certificate. To obtain a digital certificate dynamically a UE should send an application for a site certificate to PKI, and PKI portal must authenticate the certificate request. The key pair and digital certificate can also be used for the integrity and protection, but these are not part of the scope of the GAA.

Liberty Alliance and SSO (Single Sign On)

The Liberty Alliance is a group of companies dedicated to creating specifications related to authentication, privacy and identity management applications users online. One of the concepts handled is the SSO (Single Sign On), in which a user needs to authenticate only once to access various applications or services.

The 3GPP has introduced a recommendation for the combination of GAA/GBA and SSO and authentication mechanisms defined by Liberty Alliance and SAML v2.0. Thus, it is possible to benefit from strong authentication based on AKA, the mechanisms defined by Liberty Alliance and SAML v2.0 SSO to provide. However, the biggest disadvantage of GAA / GBA is designed for user agents that have some kind of support card. OMA specified authentication solutions, for example based on HTTP Digest with user credentials, for terminals that do not have an ISIM card.

Attacks

Network snoop

Breaking confidentiality. Without the protection with SSL/TLS or IPSec, it will be easy for an attacker to capture the SIP signalling and RTP (Real-time Transport Protocol) traffic using tools like Wireshark. Another attack against confidentiality can be realized by using scan tools to gather sensitive and valuable information about IMS components, operating systems and network topology.

Session hijacking

Directed integrity of session. The attacker can insert malicious packets in a session and can even replace some of the traffic. For example, the attacker can send SIP Re-Invite to modify the parameters of the session.

DoS (Denial of Service)

Attack against availability. The attacker sends a large number of datagrams in a short period of time, causing degradation of performance or completely stopping services. Examples include TCP SYN floods, UDP floods...

P- CSCF Discovery

Concerns integrity and availability. The P-CSCF is the entry point to the UE. DHCP (Dynamic Host Control Protocol) and DNS (Domain Name System) are commonly used to discover the P-CSCF. An attacker can break the process of P-CSCF discovery cache poisoning DNS for a domain name or IP false is returned to the UE. The result is that the UE cannot be registered to the network or is registered to a fake server.

Service Abuse

Impact availability and integrity of IMS. Authorized users can use the services more than expected or gain access to services that are not allowed for them.

Toll Fraud

Attack on the accounting. An attacker can forge a UE and send a Bye request to CSCF. The CSCF will think that the session is end, and stop accounting at this time the UE don’t release the media streams. This means that the UE continues exchanging flows without being counted. This threat calls media theft, and use the weakness of lack of effective control of media streams.

Permission Acquisition

Attack authentication. An attacker can obtain the password authentication due to a crack or other methods. Basically, a UE does not have a SIM card used, as mentioned above, HTTP Digest. This method is based on a username and password, which usually is not high security level. HTTP Digest lists several attacks, such as brute force or a replay attack.

Mitigated

To mitigate these attacks on the IMS network that must be met:

See also

References

This article is issued from Wikipedia - version of the 11/17/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.