Content for TS 33.141 Word version: 17.0.0

4.1 Overview of the security architecture 4.2 The Ut reference point 5.1 Secure Access to the Presence Server over the Ut reference point 6.1 Authentication and key agreement 6.2 Confidentiality protection 6.3 Integrity protection 7.1 Set-up of Security parameters 7.2 Error cases

4 Security architecture p. 7

4.1 Overview of the security architecture p. 7

An IMS operator using the CSCFs as Watcher Presence proxies and Presentity Presence proxies may offer the Presence services on top of the IMS network, see TS 22.141. The access security for IMS is specified in TS 33.203 ensuring that SIP signalling is integrity protected and that IMS subscribers are authenticated through the use of IMS AKA. The security termination point from the UE towards the network is in the P-CSCF utilising IPsec ESP.

A watcher may send a SIP SUBSCRIBE over IMS towards the network, to subscribe or to fetch presence information, i.e., the Presence Service supports SIP-based communications for publishing presence information. The presence information is provided by the Presence Server to the Watcher Application using SIP NOTIFY along the dialogue setup by SUBSCRIBE. This traffic is protected in a hop-by-hop fashion as specified in TS 33.210 with the access security provided in TS 33.203.

The Presence Server is responsible for managing presence information on behalf of the presence entity and it resides in the presentity's home network. Furthermore, the Presence Server provides a subscription authorization policy that is used to determine which watchers are allowed to subscribe to certain presence information. Prior to accepting the subscription requests from watchers, the presence server attempts to verify the identities of the watchers. Optionally, depending on the implementation, the Presence Server may authenticate an anonymous watcher depending on the Subscription Authorization Policy.

A Presence List Server is responsible of storing grouped lists of watched presentities and enables a Watcher Application to subscribe to the presence of multiple presentities using a single SIP SUBSCRIBE transaction. The Presence List Server also stores and enables management of filters in the presence list, see Figure 1.

Copy of original 3GPP image for 3GPP TS 33.141, Fig. 1: The Location of the Presence Server and the Presence List Server from an IMS point of view

Figure 1: The Location of the Presence Server and the Presence List Server from an IMS point of view
(⇒ copy of original 3GPP image)

4.2 The Ut reference point p. 7

A Presence User Agent shall be able to manage the data on the Presence Server and the Presence List Server over the Ut reference point, see TS 23.002, which is based on HTTP. This reference point is not covered in TS 33.203 and it is mainly this reference point for Presence use, which is covered in this specification.

An overview of the security architecture for Presence Ut reference point is depicted in Figure 2:

Copy of original 3GPP image for 3GPP TS 33.141, Fig. 2: An overview of the Security architecture for the Ut reference point including the support of an Authentication Proxy

Figure 2: An overview of the Security architecture for the Ut reference point including the support of an Authentication Proxy
(⇒ copy of original 3GPP image)

5 Security features p. 8

5.1 Secure Access to the Presence Server over the Ut reference point p. 8

5.1.1 Authentication of the subscriber and the presence server p. 8

A subscriber shall be authenticated before accessing user data in a server. The subscriber shall only be able to manipulate data that is associated with that particular subscriber. A subscriber shall authenticate the presence server.

Authentication between the subscriber and the presence server shall be performed as specified in clause 6.1.

5.1.2 Confidentiality protection p. 8

It shall be possible to apply confidentiality protection over the Ut reference point.

5.1.3 Integrity protection p. 8

The Ut reference point shall be integrity protected.

5.1.4 Authentication Proxy p. 8

The Authentication Proxy may reside between the UE and the Presence Server as depicted in figure 2. Its use is specified in TS 33.222.

The following requirements apply for the use of an Authentication Proxy in addition to those in TS 33.222:

Authentication Proxy may authenticate the UE using the means of Generic Bootstrapping Architecture, or it may use other means of authentication;
if the AP uses the GBA for authentication of the UE, then the procedures shall conform to TS 33.222.

Confidentiality and integrity protection may be provided for the interface between the AP and the AS, using the Zb interface of NDS/IP as specified in TS 33.222.

6 Security Mechanisms for the Ut reference point p. 9

The UE and the AP/Presence Server shall support the TLS version and profile as specified in clause 5.3 of TS 33.222.

6.1 Authentication and key agreement p. 9

6.1.1 Authentication of the subscriber p. 9

The authentication of the UE may take place in either the Authentication Proxy, see TS 33.222, or the Presence server.

Subscriber authentication can be also performed by the operator using proprietary or non-3G standardized methods. A UE may contact the Presence Server/AP for further instructions on authentication procedures, see initiation of bootstrapping in clause 4.5.1 of TS 33.220.

In case 3GPP authentication mechanisms are used, the authentication of the subscriber shall be based on the Generic Authentication Architecture as defined in TR 33.919. Generic Authentication Architecture enables the use of different authentication methods to be used for the authentication of the subscriber by using:

subscriber certificates; or
shared secrets.

For both cases, the authentication of the subscriber shall conform to the use of the Generic Authentication Architecture, TR 33.919, for access to network application functions using HTTPS, as specified in TS 33.222.

6.1.2 Authentication of the AP/Presence Server p. 9

Authentication of the AP/Presence Server shall be performed according to clause 5.3.1.3 of TS 33.222.

6.1.3 Management of public user identities p. 9

The presence server, acting as a NAF in the sense of TS 33.220, may obtain identities related to the subscriber over the Zn reference point, as part of the GBA user security setting for presence, according to the policies of the BSF, see clause 4.5.3 of TS 33.220. These identities may include the IMPI and several IMPUs. The UE shall send its preferred public user identity in each HTTP request. The Presence server (or AP) shall then verify that the preferred identity inserted in the HTTP request by the UE is one of the IMPUs, associated with the HTTP request, according to clause 6.5.2.4 of TS 33.222.

If the presence server sits behind an AP and the verification of the preferred identity, which was inserted by the UE in the HTTP request, was successful, then the AP shall verify the value of the preferred identity of the user in the HTTP request before forwarding it to the presence server. How the asserted user identity is carried in each HTTP request is specified in the relevant stage 3 specification.

If there is no preferred identity inserted in the HTTP request, the AP shall insert a default IMPU from the user profile in the HTTP request, before forwarding it to the Presence server. If the validation of the UE inserted preferred identity fails in the AP the HTTP request shall be dropped.

6.1.4 Authentication failures p. 9

The handling of authentication failures shall be according to clause 5.3.1.4 of TS 33.222.

6.2 Confidentiality protection p. 9

If confidentiality protection is provided over the Ut interface, then it shall be provided using TLS. The terminal shall in the negotiation phase include protection alternatives that include at least one alternative with encryption algorithm support. The terminal and the server shall be able to resume a previous session and to perform an abbreviated handshake.

6.3 Integrity protection p. 10

Integrity protection over the Ut reference point shall be provided using TLS. The terminal and the server shall be able to resume a previous session and to perform an abbreviated handshake.

7 Security parameters agreement p. 10

7.1 Set-up of Security parameters p. 10

Security parameters shall be set-up according to clause 5.3.1.5 of TS 33.222.

7.2 Error cases p. 10

Error cases shall be handled as specified in clause 5.3.1.6 of TS 33.222. In addition, the AP/Presence Server shall consider the following cases as a fatal error:

if none of the received ciphersuites include encryption and the policy of the operator stipulates that encryption is required;
if the policy of the operator stipulates that encryption is required and the common set of supported ciphersuites only include key material less than the number of bits required by the operator for confidentiality protection.