T.8 Message Flows

33.2033G Security3GPPAccess security for IP-based servicesTS

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

T.8.1 Successful registration

Figure T.1 below describes the message flow for successful registration to the IMS that is specified by the early IMS security solution.

NOTE: The "received" parameter is only sent from P-CSCF to S-CSCF under the conditions given in RFC 3261 [6].

The procedure is as follows.

The UE starts by setting up a PDP context.

When a PDP context has been set up successfully, the UE sends a SIP REGISTER. The REGISTER message contains the IP address and the IMPU of the UE.

The GGSN checks that the IP address provided in the REGISTER message matches the IP address allocated to the UE when the PDP context was set up. When the IP address has been verified, the GGSN forwards the REGISTER message to the P-CSCF.

The P-CSCF checks the source IP address against the IP address in the Via header of the REGISTER message. If the source IP address differs from the IP address in the Via header, the P-CSCF adds the source IP address to a received parameter in the Via header. The P-CSCF then forwards the REGISTER to the I-CSCF in the home network.

NOTE: The source IP address differs from the IP address in the Via header only in case the UE is malicious or the UE is misbehaving for some reason.

The I-CSCF contacts the HSS to authorize the UE. The HSS responds that the UE is authorized, and the I-CSCF forwards the SIP REGISTER message to the S-CSCF chosen to serve the UE.

The S-CSCF sends a message to the HSS, informing that this S-CSCF is going to serve the UE, and the HSS responds which a message providing information that the S-CSCF needs for serving the UE.

The S-CSCF returns a SIP 200 OK to the UE, indicating that the registration is successfully completed.

Figure T.1: Message sequence for early IMS security showing a successful registration

T.8.2 Unsuccessful registration

Figure T.2 below gives an example message flow for the unsuccessful attempt of an attacker trying to spoof the IMS identity of a valid IMS user.

NOTE: Again, the "received" parameter is only present between P-CSCF to S-CSCF under the conditions given in RFC 3261 [6].

The procedure is as follows.

UE1 sets up a PDP context. UE2 already has an active PDP context.

After UE1 has set up the PDP context, UE2 attempts to REGISTER using the IP address allocated to UE2, but using the IMPU of UE1.

The GGSN checks that the IP address provided in the REGISTER message matches the IP address allocated to the UE2 when the PDP context was set up. When the IP address has been verified, the GGSN forwards the REGISTER message to the P-CSCF.

The S-CSCF contacts the HSS and indicates that GIBA is used to authenticate the UE. The HSS returns the stored IP address to the S-CSCF. The S-CSCF then checks the IP address returned by the HSS against the IP address obtained in the REGISTER message (if present, the received by parameter shall be used). Since the IP address stored by the HSS (the IP address of UE1) does not match the IP address in the REGISTER (IP address of UE2), the authentication fails. The S-CSCF returns a 403 Forbidden to the UE, indicating that the registration failed.

Figure T.2: Message sequence for early IMS security showing an unsuccessful identity theft

T.8.3 Successful registration for a selected interworking case

Figure T.3 below describes the message flow for successful registration to the IMS in the case that the UE supports both fully compliant IMS and GIBA security and the network supports GIBA security only. This case is denoted as case 3 in clause 6.2.6.

NOTE: The "received" parameter is only sent from P-CSCF to S-CSCF under the conditions given in RFC 3261 [6].

The procedure is as follows.

The UE starts by setting up a PDP context.

When a PDP context has been set up successfully, the UE sends a SIP REGISTER. As the UE supports fully compliant IMS security, the UE attempts to register using the procedures of fully compliant IMS security.

The P-CSCF does not support fully compliant IMS security, and returns an indication back to the UE that the network does not support fully compliant IMS security.

The UE sends a new REGISTER, this time according to the procedures of GIBA security. The REGISTER message contains the IP address and the IMPU of the UE.

The S-CSCF sends a message to the HSS, informing that this S-CSCF is going to serve the UE, and the HSS responds which a message providing information that the S-CSCF needs for serving the UE.

The S-CSCF returns a SIP 200 OK to the UE, indicating that the registration is successfully completed.

Figure T.3: Message sequence for GIBA security showing interworking case where UE supports both fully compliant IMS security and GIBA security and network supports GIBA security only

Annex U (normative):
Trusted Node Authentication (TNA)