In this section:
P-CSCF security is established during the Registration process. A security mechanism is chosen based on the Security-Client header information (currently ipsec-3gpp) which is used between UE and P-CSCF.
The following security mechanism options are available:
The Security Mechanism Criteria table below illustrates the SIP headers and parameter values corresponding to the security mechanisms employed through the P-CSCF. For example, when UE sends a Register request with following parameters, IPsec with AKA is employed:
Once the Registration process completes and the security associations are established between UE and the , all subsequent messages received from UE must occur over the secure channel if IPsec or TLS is enabled on the received socket. A flag stored in the RCB (Registration Control Block) indicates the Registration is secure. All subsequent messages not received on a secure socket that associate to a secure Registration (except for emergency calls and certain Register requests) are rejected with ‘488 Not Acceptable Here’ message.
The CLI syntax to configure a
sipSecurityProfile and assign it to a SIP trunk group is shown below:
% set profiles services sipSecurityProfile <profile_name> forceClientSecurityPref <disabled | enabled> rejectSecUnsupportedRequest <disabled | enabled> sbxSecMode <sbc-only | sbc-pcscf> sipSecurityMechanism <ipsec-3gpp / tls precedence <1-65535> % set addressContext <addressContext name> zone <zone name> sipTrunkGroup <TG_NAME> services sipSecurityProfile <profile name>
forceClientSecurityPref is enabled, while selecting the Security Mechanism to be applied, precedence is given to the order of occurrence of "mechanism-name" values in the "Security-Client" header.
rejectSecUnsupportedRequest is enabled, the incoming REGISTER is rejected when it does not contain "sec-agree" header value (in Require or Proxy-Require headers) or it does not contain any supported mechanism-name (ipsec-3gpp) in "Security-Client" header. Otherwise, processing continues using "Digest without TLS" security mechanism.
The security mechanism precedence value (range: 1-65535) specifies the precedence to assign a security mechanism. A lower value represents a higher precedence.
IMS AKA (Authentication and Key Agreement) authentication ensures all traffic between UE and P-CSCF during a session is sent on IPsec-protected channels.
The UE starts the AKA session registration process on an unprotected channel. During registration, the AKA mechanism establishes two IPsec protected channels between the UE and the P-CSCF.
Implementing IPsec AKA security involves configuring one or more IMS Security Profiles (maximum of 10), and then assigning the profiles to specific SIP trunk groups. Key features include:
Example CLI commands:
% set profiles services sipSecurityProfile S-PROFILE1 forceClientSecurityPref enabled rejectSecUnsupportedRequest enabled sipSecurityMechanism ipsec-3gpp precedence 1 % set addressContext default zone MYZONE sipTrunkGroup STG-1 services sipSecurityProfile S-PROFILE1
The as P-CSCF supports TLS over TCP as a transport towards IMS UE as per 3GPP TS 33.203. Whether to use IPsec or TLS towards the IMS UE is negotiated at the time of registration.
A typical call flow when using "tls" as the security mechanism is show below with a brief explanation following the table.
P-CSCF receives only the initial REGISTER on the unprotected connection when TLS is employed. The REGISTER with credentials and all the subsequent messages are received only on the protected connection. Otherwise, P-CSCF ignores the messages.
The acting as a P-CSCF applies the following procedures once it infers SIP Digest without TLS is employed. When it receives a REGISTER request from the UE, the P-CSCF applies the “integrity-protected” header field parameter according to the following criteria:
The following flow diagram provides a high-level view of the P-CSCF authentication procedure.
3GPP standards ensure that simple, yet adequately secure mechanisms are in place to protect against the most significant security threats that will exist in early IMS implementations. These mechanisms are described under the heading of “GPRS-IMS-Bundled-Authentication” (GIBA) in the standards. For security reasons, these provisions only apply to IMS procedures used over the 3GPP PS domain. That is, these procedures are NOT recommended to be used for IP access networks other than 3GPP access.
The GIBA security solution works by creating a secure binding in the HSS between the public/private user identity (SIP-level identity) and the IP address currently allocated to the user at the GPRS level (bearer/network level identity). Therefore, IMS level signaling, and especially the IMS identities claimed by a user, can be connected securely to the PS domain bearer level security context.
The GGSN terminates each user's PDP context and has assurance that the IMSI used within this PDP context is authenticated. The GGSN shall provide the user's IP address, IMSI and MSISDN to a RADIUS server in the HSS when a PDP context is activated towards the IMS system. The HSS has a binding between the IMSI and/or MSISDN and the IMPI and IMPU(s), and is therefore able to store the currently assigned IP address from the GGSN against the user's IMPI and/or IMPU(s). The GGSN informs the HSS when the PDP context is deactivated / modified so that the stored IP address can be updated in the HSS.
When S-CSCF receives a SIP registration request or any subsequent requests for a given IMPU (public user identity), it checks that the IP address in the SIP header (verified by the network) matches the IP address that was stored against that subscriber's IMPU in the HSS.
The GIBA mechanism relies on several assumptions and restrictions to provide the desired level of security. The two most notable assumptions are:
The acting as P-CSCF checks that the source IP address in the SIP header is the same as the source IP address in the IP header received from the UE (assumiing no NAT is present between the GGSN and the P-CSCF).
For an acting as P-CSCF to implement GIBA security, user must set accessClass parameter to "3GPP" for Trunk Groups facing the UE. The following behavior applies to this feature:
The CLI syntax to enable 3GPP security is shown below:
% set addressContext <address context name> zone <zone name> sipTrunkGroup <TG name> signaling accessClass <3GPP | none>
The supports the NULL algorithm for IP Multimedia Subsystem (IMS) Authentication and Key Agreement (AKA) registration request processing when it is offered by a UE. Previously, the could not force a UE to use the NULL encryption algorithm. The is enhanced with the SIP Security Profile parameter
encryptionPreference to either enforce the NULL encryption algorithm irrespective of what encryption algorithm is offered by the UE or enforce non-NULL encryption algorithm by rejecting the registration request if the UE offers a NULL encryption algorithm.
encryptionPreference options are: