S.2 Application of clause 4

33.2033G Security3GPPAccess security for IP-based servicesTS

In 3GPP2 networks, the IMS is essentially an overlay to the PDS and has a low dependency on the PDS. PDS can be deployed without the multimedia session capability. The IMS Security Framework is shown in Figure S.1.

For the purposes of this Annex, the UE is not mandated to contain a UICC. The security data at the UE for access using IMS AKA are stored according to the requirements in clause S.4. It shall be possible for the IMS authentication keys and functions to be logically independent to the keys and functions used for PDS authentication. However, this does not preclude common authentication keys and functions from being used for IMS and PDS authentication.

The IMS Security Framework also addresses the security of interfaces between the IMS and external network domains, for example, Multimedia IP-Networks as shown in Figure S.1. This is important since the service capability subsystem of the IMS includes application servers that reside on untrusted third-party networks, and which can access network functionality.

Figure S.1: The IMS security architecture

There are seven different security associations and different needs for security protection for IMS (including SIP AS nodes) and they are numbered 1 through 7 in Figure S.1.

1. Provides mutual authentication between the UE and the S-CSCF. The HSS delegates the performance of subscriber authentication to the S-CSCF. The long-term key in the UE and the HSS is associated with the user private identity (IMPI). The UE will have one (network internal) user private identity (IMPI) and at least one external user public identity (IMPU).

The security associations 2 through 5 are as defined in clause 4 except that requirements in clause S.5 of this specification shall apply for security protection.

6. Provides security between a SIP-capable node residing in an external IP network, and the HSS. This security association is covered in clause S.5 of this specification The SIP-capable node is a SIP Application Server and may also reside within the HN. However, this security association is only applicable when the SIP AS resides in an external IP network. If the SIP AS resides in the Home Network, then the security association 3 applies.

7. Provides security between SIP-capable nodes located in different networks. It differs from security association 4 in that the SIP-capable node here is the SIP Application Server. Using SIP, this type of application server may communicate with network entities to offer service control and content, access functionality provided in the operator’s network, and manage bearers. This security association is covered in clause S.5 of this specification. It is only applicable when the SIP AS resides in an external IP network. If the SIP AS resides in the Home Network, then security association 5 applies.

Not all security mechanisms in this specification provide all of the above. There may exist other interfaces and reference points in IMS, which have not been addressed above. Those interfaces and reference points reside within the IMS, either within the same security domain or between different security domains. Clause S.5 of this specification is intended to address security issues for all such interfaces. The present document assumes that the IP-CAN supports secure communications via standard IETF protocols RFC 4301 [53].

The confidentiality and integrity protection for SIP-signaling is provided in a hop-by-hop fashion. The first hop i.e. between the UE and the P-CSCF is specified in clause S.3. The other hops, inter-domain and intra-domain are specified in clause S.5 of this specification.