U.2 Use case and detailed description

33.2033G Security3GPPAccess security for IP-based servicesTS

The main use case for TNA is to provide access to the IMS network for legacy or IMS enabled equipment when connected via a CS access domain as defined for ICS (see TS 23.292 [50]).

TNA relies on the following assumptions:

– The trusted node can be in either the home or visited network

– The trusted node provides sufficient means for authentication in the CS access domain

– The trusted node provides interworking between the IMS domain and the CS access domain

The authentication flow is depicted below in Figure U.1.

Figure U.1 Trusted Node performs registraton on behalf of the UE

The details of the signalling flows are as follows:

1. CS attach (UE A to Trusted Node)

As a result of some stimulus, UE A performs CS attachment toward the CS network

2. Authentication and Update Location (MSC/VLR to HLR/HSS)

The CS network performs standard CS location update, authentication and obtains subscriber data.

3. CS attach accept (MSC to UE A)

The CS attach request is accepted by the network, an accept message is sent to the UE.

4. REGISTER request (Trusted Node to I-CSCF)

The Trusted Node sends a SIP REGISTER to the I-CSCF with a private and temporary public user identity derived from the subscriber’s IMSI as well as an Instance ID. The REGISTER also contains information indicating the capabilities and characteristics of the Trusted Node as a SIP User Agent Client. The Trusted Node inserts an "integrity-protected" flag set to indicate that authentication has already been performed. The I-CSCF verifies that the incoming REGISTER originates from a trusted node (according to TS 33.210 [5]).

5. Cx: User registration status query procedure

The I-CSCF makes a request for information related to the Subscriber registration status by sending the private user identity, public user identity and visited domain name to the HSS as specified in see TS 29.228 [39]. The HSS returns the S-CSCF required capabilities and the I-CSCF uses this information to select a suitable S-CSCF.

6. REGISTER request (I-CSCF to S-CSCF)

I-CSCF forwards the REGISTER request to the selected S-CSCF.

7. Cx: S-CSCF Registration Notification

Based on the presence of the "integrity-protected" flag set to indicate that authentication has already been performed, the S-CSCF knows that the subscriber has already been authenticated by the Trusted Node. The S-CSCF informs the HSS that the user has been registered. Upon being requested by the S-CSCF, the HSS will also include the user profile in the response sent to the S-CSCF. For detailed message flows see TS 29.228 [39].

8. 200 (OK) response (S-CSCF to I-CSCF)

The S-CSCF sends a 200 (OK) response to the I-CSCF indicating that Registration was successful.

9. 200 (OK) response (I-CSCF to Trusted Node)

The I-CSCF forwards the 200 (OK) response to the MSC Server enhanced for ICS indicating that Registration was successful.

Annex V (informative):
NAT deployment considerations for GIBA

In the current IMS architecture, it is assumed that no NAT is present between the GGSN and the P-CSCF in GIBA (or that it is kept transparent to the UE). If a NAT device is between the GGSN and P-CSCF, problems may arise if it is not deployed properly. Although there is no IP address theft, when signaling messages traverse the NAT device, the source IP address may be translated. When P-CSCF compares the source IP address in the IP header with the one in the SIP header, it will find that these two IP address are not equal, and will attach the source IP address in the IP header to the “received” parameter of the Via header in the SIP header. When the request message is forwarded to the S-CSCF, the S-CSCF shall compare the IP address in the “received” parameter with the one stored in HSS. These two IP addresses may not be equal, and the registration will fail. This implies that GIBA will not be able to distinguish between address translation caused by NAT and IP address theft.

There are two deployment options that can be used to mitigate this problem.

A) If a NAT is deployed between GGSN and P-CSCF, it shall be controlled by the Operators and kept transparent to the UE. The P-CSCF can retrieve the address mapping information from the NAT device, and add the correct address information in the SIP message. The precise way of getting the address mapping information from the NAT is outside the scope of this specification.

NOTE 1: A common practice among NAT devices is to implement such address mapping information query interface based on a standardized protocol like SNMP.

B) A second alternative to solve the NAT problem is to ensure that the NAT function is provided in the P-CSCF (see also TS 23.228 [3]). The P-CSCF may have two interfaces. The internal interface has a private IP address and communicates with the private address space where the UE resides. The external interface has a public IP address and communicates with the public address space where the IMS core devices reside. This will then also ensure that the correct IP address is provided in the SIP message towards the S-CSCF.

NOTE 2: In practical deployment, a P-CSCF may have more than one internal interface to extend the capability to hold multiple private networks.

NOTE 3: The two solutions here only define the NAT traversal of the GPRS-IMS bundled authentication signaling. Media flow NAT traversal in above cases can be correspondingly solved using the mechanism defined in 3GPP TS 23.228 Annex G [3].

Annex W (normative):
Tunnelling of IMS Services over Restrictive Access Networks