T.5 Restrictions imposed by GIBA

33.2033G Security3GPPAccess security for IP-based servicesTS

The mechanism assumes that only one contact IP address is associated with one IMPI. Furthermore, the mechanism supports the case that there may be several IMPUs associated with one IMPI.

In GIBA the IMS user authentication is performed by linking the IMS registration (based on an IMPI) to a PDP context (based on an authenticated IMSI). The mechanism here assumes that there is a one-to-one relationship between the IMSI for bearer access and the IMPI for IMS access.

For the purposes of the present document, an APN, which is used for IMS services, is called an IMS APN. An IMS APN may be also used for non-IMS services. The mechanism described in the present document further adds the requirement on the UE that it allows only one APN for accessing IMS for a PLMN and that all active PDP contexts, for a single UE, associated with that IMS APN use the same IP address at any given time.

The GIBA mechanism relies on the Via header remaining unchanged between the UE and the S-CSCF for requests and responses sent in the direction from the UE to the S-CSCF.

Due to the fact that the Authorization header is not included in REGISTER requests in GIBA, the I-CSCF is unable to use the presence or absence of the "integrity-protected" parameter to distinguish initial and non-initial REGISTER messages. Therefore the S-CSCF reselection procedure described in clause 5.3.1.3 of TS 24.229 [8] cannot be used.

GIBA requires the GGSN to be in the home network.

GIBA works with UEs that contain a SIM or a USIM, whereas full IMS security requires a USIM or ISIM. GIBA does not authenticate at the IMS level. Instead, it relies on bearer level security at the GPRS or UMTS PS level. Because there is no key agreement, IPsec security associations are not set up between UE and P-CSCF, as they are in the full IMS security solution.

The solution works by binding the IMS level transactions to the GPRS or UMTS PS domain security association established at a GPRS or UMTS PS domain level. In doing so, it creates a dependency between SIP and the PS bearer, which does not exist with the full IMS security solution. This means that the interim solution does not provide as high a degree of access network independency as the full solution. In particular, the solution does not currently support scenarios where IMS services are offered over WLAN. If support for WLAN access is required then the full solution must be used or GIBA must be extended to cover WLAN access.

GIBA derives the public user identity used in the REGISTER request from the IMSI. Consequently, the same derived public user identity cannot be simultaneously registered from multiple terminals, using only GIBA registration procedures. However, simultaneous registration of a public user identity from one terminal using GIBA, and from other terminals using fully compliant IMS security is not precluded.

Unlike in fully compliant IMS security, the private user identity is not included in the REGISTER requests when GIBA is used for registration, re-registration and mobile-initiated de-registration procedures. Subsequently, all REGISTER requests from the UE shall use the IMSI-derived IMPU as the public user identity even when the implicitly registered IMPUs are available at the UE. Otherwise, the I-CSCF would be unable to derive the private user identity that is needed to query the HSS in certain Cx messages.