Authentication between the subscriber and the network shall be performed as specified in clause 6.1.
An IM-subscriber will have its subscriber profile located in the HSS in the Home Network. The subscriber profile will contain information on the subscriber that may not be revealed to an external partner, cf. TS 23.228. At registration an S-CSCF is assigned to the subscriber by the I-CSCF. The subscriber profile will be downloaded to the S-CSCF over the Cx-reference point from the HSS (Cx-Pull). When a subscriber requests access to the IP Multimedia Core Network Subsystem this S-CSCF will check, by matching the request with the subscriber profile, if the subscriber is allowed to continue with the request or not i.e. Home Control (Authorization of IM-services).
All SIP-signalling will take place over the PS-domain in the user plane i.e. IP Multimedia Core Network Subsystem is essentially an overlay to the PS-domain. Hence the Visited Network will have control of all the subscribers in the PS-domain i.e. Visited Control (Authorization of bearer resources) since the Visited Network provides the subscriber with a transport service and its associated QoS.
For IM-services a new security association is required between the UE and the IMS before access is granted to IM-services.
The mechanism for mutual authentication in UMTS/LTE is called UMTS/EPS AKA. They are challenge response protocols and the AuC/HSS in the Home Stratum derives the challenge. A Quintet containing the challenge is sent from the Home Stratum to the Serving Network. The Quintet contains the expected response XRES and also a message authentication code MAC. The Serving Network compares the response from the UE with the XRES and if they match the UE has been authenticated. The UE calculates an expected MAC, XMAC, and compares this with the received MAC and if they match the UE has authenticated the Serving Network.
The AKA-protocol is a secure protocol developed for UMTS and the same concept/principles is reused for the IP Multimedia Core Network Subsystem, where it is called IMS AKA.
The Home Network authenticates the subscriber at anytime via the registration or re-registration procedures.
Initial registration shall always be authenticated. It is the policy of the operator that decides when to trigger a re-authentication by the S-CSCF. Hence a re-registration might not need to be authenticated.
A SIP REGISTER message, which has not been integrity protected at the first hop, shall be considered as initial registration.
The S-CSCF shall also be able to initiate an authenticated re-registration of a user at any time, independent of previous registrations.
Possibility for IMS specific confidentiality protection shall be provided to SIP signalling messages between the UE and the P-CSCF. Operators shall take care that the deployed confidentiality protection solution and roaming agreements fulfils the confidentiality requirements presented in the local privacy legislation. The following mechanisms are provided at SIP layer:
The UE shall always offer encryption algorithms for P-CSCF to be used for the session, as specified in clause 7.
The P-CSCF shall decide whether the IMS specific encryption mechanism is used. If used, the UE and the P-CSCF shall agree on security associations, which include the encryption key that shall be used for the confidentiality protection. The mechanism is based on IMS AKA and specified in clause 6.1.
Confidentiality between CSCFs, and between CSCFs and the HSS shall rely on mechanisms specified by Network Domain Security in TS 33.210.
Integrity protection shall be applied between the UE and the P-CSCF for protecting the SIP signalling, as specified in clause 6.3. The following mechanisms are provided.
The UE and the P-CSCF shall negotiate the integrity algorithm that shall be used for the session, as specified in clause 7.
The UE and the P-CSCF shall agree on security associations, which include the integrity keys that shall be used for the integrity protection. The mechanism is based on IMS AKA and specified in clause 6.1.
The UE and the P-CSCF shall both verify that the data received originates from a node, which has the agreed integrity key. This verification is also used to detect if the data has been tampered with.
Replay attacks and reflection attacks shall be mitigated.
Integrity protection between CSCFs and between CSCFs and the HSS shall rely on mechanisms specified by Network Domain Security in TS 33.210.
The operational details of an operator's network are sensitive business information that operators are reluctant to share with their competitors. While there may be situations (partnerships or other business relations) where the sharing of such information is appropriate, the possibility should exist for an operator to determine whether or not the internals of its network need to be hidden.
It shall be possible to hide the network topology from other operators, which includes the hiding of the number of S-CSCFs, the capabilities of the S-CSCFs and the capability of the network.
The I-CSCF/IBCF shall have the capability to encrypt the addresses of all the entities of the operator network in SIP Via, Record-Route, Route and Path headers and then decrypt the addresses when handling the response to a request. The P-CSCF may receive routing information that is encrypted but the P-CSCF will not have the key to decrypt this information.
The mechanism shall support the scenario that different I-CSCFs/IBCF s in the HN may encrypt and decrypt the addresses of all the entities of the operator network.
Privacy may in many instances be equivalent with confidentiality i.e. to hide the information (using encryption and encryption keys) from all entities except those who are authorized to understand the information. The SIP Privacy Extensions for IMS Networks do not provide such confidentiality. The purpose of the mechanism is rather to give an IMS subscriber the possibility to withhold certain identity information of the subscriber as specified in RFC 3323 and RFC 3325.
When a Rel-6 IMS is interworking with a non-IMS network, the CSCF in the IMS network shall decide the trust relation with the other end. The other end is trusted when the security mechanism for the interworking (see clause 6.5) is applied as well as the availability of an inter-working agreement. If the interworking non IMS network is not trusted, the privacy information shall be removed from the traffic towards to this non-IMS network. When receiving SIP signalling, the CSCF shall also verify if any privacy information is already contained. If the interworking non-IMS network is not trusted, the information shall be removed by the CSCF, and retained otherwise.
Because absence of the security mechanism for the interworking (see clause 6.5) indicates an untrusted non IMS network, separate CSCFs are usually needed to interface with IMS and non-IMS networks. The CSCF interfacing with IMS networks implicitly trusts all IMS networks reachable via the SEG that establishes security according to TS 33.210. A Rel-5 CSCF always assumes this trust relationship and network configuration. For a Rel-6 CSCF, this implicit trust setting shall be a configuration option, that an operator can set according to his network and interface configuration.