Content for TS 33.141 Word version: 17.0.0

C.1 General C.2 Authentication of the subscriber C.3 Authentication of the Presence Server C.4 Management of public user identities C.5 Authentication failures C.6 Set-up of Security parameters C.7 Error cases

C (Normative) Requirements specific to 3GPP2 Access |R8| p. 13

C.1 General p. 13

The present Annex describes how the normative text in the main body of this specification differs for 3GPP2 Access.

TLS with pre-shared keys as specified in [22] is referenced in this Annex. For this deployment of TLS the same TLS profiling shall apply as given for PSK TLS in clause 5.4.1 of TS 33.222.

C.2 Authentication of the subscriber p. 13

The text in clause 6.1.1 is replaced by the following text.

The authentication of the subscriber shall take place in the Presence server.

Subscriber authentication may be performed by the operator using proprietary or non-3G standardized methods. GBA defined in [21] may also be used. The UE may contact the Presence Server for further instructions on authentication procedures, see initiation of bootstrapping in 3GPP2 S.S0109 [21].

In case GBA is used for authentication, the authentication of the subscriber shall be based on the Generic Bootstrapping Architecture as defined in [21]. Generic Bootstrapping Architecture enables the use of different authentication methods to be used for the authentication of the subscriber by using shared secrets.

The authentication of the subscriber with GBA shall conform to Generic Bootstrapping Architecture, [21], for access to network application functions using HTTPS, using TLS with pre-shared keys as specified in [22].

C.3 Authentication of the Presence Server p. 13

The text in clause 6.1.2 is replaced by the following text.

Authentication of the Presence Server shall be performed using TLS with pre-shared keys as specified in [22].

C.4 Management of public user identities p. 13

The text in clause 6.1.3 is replaced by the following text.

The presence server, acting as a NAF in the sense of GBA, 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 [21]. 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 shall then verify that the preferred identity inserted in the HTTP request by the UE is one of the IMPUs provided by the BSF.

C.5 Authentication failures p. 13

The text in clause 6.1.4 is replaced by the following text.

The handling of authentication failures when using TLS with pre-shared keys shall be according to [22].

C.6 Set-up of Security parameters p. 14

The text in clause 7.1 is replaced by the following text.

Security parameters shall be set-up using TLS with pre-shared keys as specified in [22].

C.7 Error cases p. 14

The text in clause 7.2 is replaced by the following text.

Error cases when using TLS with pre-shared keys shall be handled as specified in [22]. In addition, the 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.

D (Normative) GPRS-IMS-Bundled Authentication for Ut interface security |R9| p. 15

A solution similar to GIBA for Gm interface, specified in TS 33.203 , may be used to protect HTTP services based on the secure IP address binding information stored in the HSS as an alternative to the mechanism specified in the main body of this specification. To achieve this, the Sh interface described in TS 29.328 and TS 29.329 shall be used by the Application Server (AS) to fetch secure IP address binding information from the HSS.

Authentication can also be performed by an Authentication Proxy (AP) used to separate the authentication procedure from the application logic. Provisioning of information to the AP is outside the scope of the present document.

The GGSN/PGW shall provide the user's IP address (or the prefix in the case of IPv6 stateless autoconfiguration) and IMSI to the HSS when a PDP/EPS Bearer context is activated. The HSS stores the currently assigned IP address (or prefix) so that it can be looked up using the user's IMPI and/or IMPU(s). The precise way of the handling of these identities in the HSS is outside the scope of standardization. The GGSN/PGW informs the HSS when the PDP/EPS Bearer context is deactivated/modified so that the stored IP address (or prefix) can be updated in the HSS.

When the AS/AP receives a HTTP request, it checks that the IP address (or prefix) in the HTTP request matches the IP address (or prefix) that was stored in the HSS. The UE must indicate its user identity in the HTTP requests so that the AS/AP has a reliable identity to use when querying the HSS.

This approach requires the APN to support GIBA, and that all active PDP/EPS Bearer contexts, for a single UE, associated with that APN use the same IP address (or the prefix in the case of IPv6 stateless autoconfiguration) at any given time. This approach also requires the GGSN/PGW to be in the home network and that the GGSN/PGW does not allow a UE to successfully transmit an IP packet with a source IP address (or prefix) that is different to the one assigned during PDP/EPS Bearer context activation.

Since the security of this approach relies on the security of the PS bearer, a dependency is created between the HTTP service and the PS bearer, which does not exist with the mechanism specified in the main body of this specification. This means that the solution described in this section does not provide as high a degree of access network independency as the solution in the main body of this specification. In particular, the solution does not currently support scenarios where HTTP services are offered over WLAN.

The following steps describe the procedure:

The UE sends the HTTP GET request to the AS. The "X-3GPP-Intended-Identity" header, as defined in TS 24.109, shall be used by the UE to indicate the user identity. The user is identified by the IMPU that is derived from the IMSI of the subscription according to the rules in TS 23.003.
The AS/AP decides to authenticate the UE based on the secure IP address binding information from the HSS. This decision might be based on the fact that GBA is not available. The AS/AP checks whether secure IP address binding information is available at the AS/AP; if yes, it proceeds with step 7, if not then it proceeds with step 3.
The AS/AP queries the HSS using User-Data-Request (UDR) over the Sh interface, and the IMPU is used for User-Identity.
The HSS responds with User-Data-Answer (UDA) including the secure binding information. If a securely bound IP address is not available in the HSS, then any incoming HTTP requests at the AS/AP shall be rejected.
The AS/AP stores the secure binding information.
The AS/AP uses the subscriber/notify feature on the Sh interface to ensure that it is informed about any changes in the secure IP address binding information in the HSS. If the AS/AP is notified by the HSS about such a change, it updates the secure IP address binding information stored in the AS/AP accordingly.
The AS/AP shall check that the IP address (or prefix) from the UE in HTTP requests matches the IP address (or prefix) provided by the HSS, otherwise the HTTP request shall be rejected.

The mechanism does not preclude that the HTTP service may run inside a server-authenticated TLS tunnel established between the UE and the AS/AP. However, support of TLS in the UE and in the AS/AP is not mandated in the present document.

The details for the interface between the AS/AP and HSS are described in TS 29.328 and TS 29.329 .