Q.2 Assertion of identities by the P-CSCF

33.2033G Security3GPPAccess security for IP-based servicesTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

Assertion of identities by the P-CSCF is currently described in TS 24.229 [8], clause 5.2.6.3. This clause is referenced in Annex N.2.1 of this specification. The underlying assumption of this clause is the use of IMS AKA with IPsec.

It is briefly recapped how identity assertion works for IMS AKA with IPsec as this helps to understand its use in Annex N: The P-CSCF stores the IP address and port together with the IMPI and the registered IMPUs in an “SA table” during a successful registration. The idea of identity assertion for non-registration message is that the P-CSCF securely knows from the source IP address and port, tied to the IPsec security association, which user sent the non-registration message. The P-CSCF therefore can assert to the S-CSCF that a certain IMPU is related to the sender of the non-registration message. The P-CSCF uses the P-Asserted-Identity header for this purpose. The S-CSCF has to rely on the P-CSCF for the verification of user identities as the security is provided by IPsec which terminates at the P-CSCF.

The relevant paragraphs from TS 24.229, clause 5.2.6.3, are:

“When the P-CSCF receives an initial request for a dialog or a request for a standalone transaction, and the request contains a P-Preferred-Identity header that matches one of the registered public user identities, the P-CSCF shall identify the initiator of the request by that public user identity.

When the P-CSCF receives an initial request for a dialog or a request for a standalone transaction, and the request contains a P-Preferred-Identity header that does not match one of the registered public user identities, or does not contain a P-Preferred-Identity header, the P-CSCF shall identify the initiator of the request by a default public user identity. If there is more than one default public user identity available, the P-CSCF shall randomly select one of them.

NOTE 1: The contents of the From header do not form any part of this decision process.”

It is clear that the S-CSCF needs to be certain about the user identities associated with a non-registration message, e.g. for charging purposes or for being able to convey the asserted identities to application servers (ASs). The concept of identity assertion may be applied to the three authentication mechanisms for non-registration messages, which may be used in conjunction with SIP Digest authentication for registrations, as follows:

TLS:

This case is very similar to the IPsec case as the P-CSCF knows the originator of a message from the TLS session (i.e. security association) with which the corresponding packet was protected. The procedures in TS 24.229, clause 5.2.6.3 apply without changes.

IP address check:

This case is also similar to the IPsec and TLS cases. The P-CSCF knows the originator of a message from the association of IP address and, if applicable, port with the user identities in the IP address check table which it established during registration. The procedures in TS 24.229, clause 5.2.6.3 apply in the P-CSCF without changes. A minor change of the local S-CSCF behaviour is required when the mechanism is used in conjunction with SIP Digest proxy-authentication, cf. next paragraph.

SIP Digest proxy-authentication:

This case is different from the previous cases in that proxy-authentication is transparent to the P-CSCF. The P-CSCF therefore cannot assert any identity to the S-CSCF. However, the S-CSCF has now secure knowledge of the user’s private identity. The P-CSCF-related procedures in TS 24.229, clause 5.2.6.3 therefore can remain the same only when they are used in conjunction with the IP address check. In order to cover a potential error condition of a mismatch in the S-CSCF between the identity asserted by the P-CSCF by means of IP address check and the identity verified by the S-CSCF by means of Digest proxy-authentication, the rule is added that the latter shall take precedence as Digest proxy-authentication is the stronger of the two mechanisms, cf. below.