X.4 Assignment of IMS identities to WebRTC IMS Client from pool of IMS subscriptions held by WWSF

33.2033G Security3GPPAccess security for IP-based servicesTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

X.4.0 General

The present clause X.4 deals with the security aspects of the registration scenario described in TS 23.228 [3] that is entitled "WIC registration of individual Public User Identity from a pool of Public User Identities".

X.4.1 General requirements

The following security requirements apply to the present registration scenario:

– REQ 3.0: For the interfaces W2 (WIC to eP-CSCF), and W4, if present, (WWSF to WAF), mutual authentication is required. For the W1interface, mutual authentication is required, except for the case of anonymous user. In the case of anonymous user, one way authentication (WIC needs to authenticate WWSF) is required.

– REQ 3.1: The WAF shall provide authorization information to the eP-CSCF (possibly via the WIC) that allows the IMS core to ascertain that the WIC in possession of this authorization information is authorized to access IMS using the associated public and private IMS identities presented during registration or retrieved from the WAF through undefined means.

– REQ 3.2: An IMS service provider shall ensure that the private IMS identity provided in the authorization information from REQ 3.2 belongs to an IMS subscription in the pool of IMS subscriptions uniquely assigned to the WWSF.

– REQ 3.3: The eP-CSCF shall verify that the WIC establishing the signalling connection with the eP-CSCF comes from a trusted domain.

X.4.2 Solution 3.1

X.4.2.1 General

In the present registration scenario it is assumed that the ”WWSF is provided with a pool of subscriptions, each containing a single unique IMPU/IMPI pair, to IMS and can assign individual Public and Private User Identities from this pool.” (quoted from TS 23.228). This assignment is temporary and the same IMPU (and IMPI) may be re-assigned to a different user at a later time once they are free and available for re‑use.

In an extension to this registration scenario, the IMS operator may also provide the WWSF with an unbounded number of IMPUs associated with IMPIs to be allocated to WIC users.

The user’s web identity may be authenticated by the WWSF or the WAF. (Whether it is the WWSF or the WAF depends on the deployment.), but the WWSF may decide not to authenticate the user. Unauthenticated users are anonymous to the WWSF and WAF, but may still be authorized for IMS service.

NOTE 1: The difference to the registration scenario addressed in clause X.3 is that, in the present registration scenario, the IMS subscriber is the WWSF, not the user. There is no linkage between the user’s web identity that may be authenticated by the WWSF or the WAF and the assigned IMS identities.

NOTE 2: Considerations on Lawful Interception, e.g. when the user is anonymous to the third party, are outside the scope of the present document.

X.4.2.2 Requirements

All requirements for solution 3.1 are covered in clause X.4.1.

X.4.2.3 Procedures

The procedure provided in this clause is split into a normative part and non-normative part: the description for the interfaces between eP-CSCF, I-/S-CSCF and HSS is normative while the description for the interfaces W1, W2 and W4 is only by way of example.

NOTE 3: This split into a normative part and a non-normative part is due to 3GPP’s decision not to standardise the interfaces W1, W2 and W4 in the present release.

For the non-normative part, the procedure allows for various realisations that are out of scope of 3GPP for the present release. All realisations have in common that the WAF issues authorization tokens that are provided to the WIC via the WWSF. The WIC presents this authorization token to the eP-CSCF during the IMS registration. The validation of the authorization token by the eP-CSCF is specific to the particular realisation. The authorization token allows the eP-CSCF to retrieve the IMS subscriber identity, the WAF and WWSF identities, validity period, and possible other authorization parameters.

The procedure in the present clause covers two cases of locating the authorization entity (WAF):

– The WAF is located in the IMS provider domain;

– The WAF is located in a third party domain.

NOTE 4: WWSF and WAF realisations can be physically co-located or physically separate; in the latter case, WWSF and WAF can reside in the same or in different domains.

An example signalling flow for the present registration scenario is shown in Figure X.3.3-1. In this figure, by way of example SIP over secure WebSocket is used between the WebRTC IMS Client and the eP-CSCF. Other protocols (e.g. HTTP RESTful or JSON over WebSocket) can also be used.

All steps in the procedure below apply to both cases of WAF location unless stated otherwise. For the example of OAuth 2.0 the WAF needs to be located in the IMS provider domain.

For the normative part, the procedure applies Trusted Node Authentication (TNA) specified for IMS in Annex U of the present specification. The trusted node is the eP-CSCF residing in the operator network, according to the present specification .

The signalling between the trusted node and the rest of the IMS core is unchanged from the signalling flow in Annex U of the present specification with the following exception: if the WAF is located in a third party domain then the REGISTER message may be enhanced with additional parameters (WAF and WWSF identity, if available), whose inclusion is conditional, to satisfy the requirements REQ 3.2 from clause X.4.1 of the present specification.

Figure X.4.2.3-1: WebRTC IMS Client access to IMS using Trusted Node Authentication (example flow)

The details of the signalling flows are as follows:

Each step x in the signalling flow has a part x.1 providing general text applying to all realisations, irrespective of whether the WAF is located in the IMS provider domain or in a third party domain. This part x.1 is followed by text explaining how it would work for a realisation using the example of OAuth. For the example of OAuth, the WAF needs to be located in the IMS provider domain.

In addition, some of the steps contain a second step x.2 that applies only when the WAF is located in a third party domain.

0. WWSF obtains authorization token

0.1 General:

The WWSF requests an authorization token from the WAF. The WWSF or the WAF authenticates the user via “web credentials”, i.e. credentials as commonly used for access to web based services, for example a username and password. The WWSF can choose not to authenticate the user if the user is to remain anonymous.

Example of OAuth 2.0:

When using the example of OAuth 2.0 then the following authorization flows defined by OAuth 2.0 is used.

– Client Credentials flow: The WAF authenticates only the WWSF and the authorization is performed without user involvement. As part of the authorization, the WAF verifies that the WWSF has the necessary permissions to access the IMS account indicated in the request. It is assumed that the WWSF has authenticated the user prior to sending the token request unless it is a case of anonymous access granted by the WWSF.

In the example of OAuth 2.0 the authorization token is an access token and IMPI and IMPU are associated with the access token.

Using the terminology of OAuth 2.0, the IMS subscriber corresponds to the resource owner, the WWSF corresponds to the client, the WAF corresponds to the authorization server, and the IMS network corresponds to the resource server. Note that, in this scenario, the WWSF is the IMS subscriber, so resource owner and client co-incide. Note further that the WWSF and the WAF may also co-incide.

NOTE 5: Void.

1. Web page download from WWSF

1.1 General:

An example realisation of this step is as follows:

– From within a WebRTC-enabled browser, the user accesses a URI to the WWSF to initiate an HTTPS connection to the WWSF. The TLS connection provides one-way authentication of the server based on the server certificate. The browser downloads and initializes the WIC from the WWSF. The WWSF forwards the authorization token to the WIC for inclusion in IMS registration procedure (step 3 below).

Example of OAuth 2.0: Identical to 1.1.

2. Establishment of secure Web socket connection between WIC and eP-CSCF

2.1 General:

An example realisation of this step is as follows:

The WIC opens a WSS (secure Web Socket) connection to the eP-CSCF. The TLS connection provides one-way authentication of the server based on the server certificate. The eP-CSCF verifies in this step that the WIC establishing the signalling connection comes from a trusted domain.

NOTE 6: The protection mechanism works under the assumption that the browser is not under the attacker’s control.

Example of OAuth 2.0: Identical to 2.1.

3. REGISTER request (WebRTC IMS Client to Trusted Node)

3.1 General:

An example realisation of this step is as follows:

The WebRTC IMS Client sends a REGISTER request. The REGISTER request includes an authorization token, which the WebRTC IMS Client has previously obtained.

Example of OAuth 2.0:

In addition to 3.1, the Authorization header in the REGISTER request includes the OAuth 2.0 access token obtained in step 1. The access token is of the so called "bearer" token type; see RFC 6750 [67].

NOTE 7: OAuth bearer tokens can be used with signalling protocols that supports the Authorization header defined in RFC 7616 [76], for example SIP and HTTP.

4. Validation of security token at eP-CSCF

4.1 General:

An example realisation of this step is as follows:

The eP-CSCF extracts the authorization token and validates it in some unspecified manner ensuring that only an authorized source can have generated the authorization token. The authorization token is associated with a specific resource owner (i.e. the IMS subscriber) and client (i.e. the WWSF) and has a certain lifetime and scope. This authorization information can either be encoded into the token itself and verified through a signature or MAC (so called self-contained token), or retrieved as part of the validation response if the validation is performed against the WAF.

If the authorization token is valid the eP-CSCF obtains the associated authorization information, including the IMPI and IMPU assigned to the user by the WWSF, the WAF and WWSF identity (if available), and the authorization token scope. The eP-CSCF verifies that the scope includes the value "webrtc-ims-client-access-to-ims".

NOTE 7a: In the present 3GPP release the token format and verification procedure is left out of scope.
It is assumed that the eP-CSCF can check the validity of the token and obtain the subscriber IMPI and IMPU(s), the WWSF identity, lifetime, and scope parameters.

NOTE 8: Under certain assumptions, the eP-CSCF can also verify that the IMPI, if it exists at all in the IMS, belongs to an IMS subscription in the pool of IMS subscriptions assigned to the WWSF.Such an assumption would be e.g. that the IMPIs from the pool of IMS subscriptions assigned to the WWSF have a special form, and the IMS provider does not assign IMPIs of this form to any other WWSF. However, the IMPU would not have to follow the same special format as the IMPI.

If the validation fails in some respect, the eP-CSCF declines the register request, closes the web socket and aborts the procedure.

NOTE 9: The value "webrtc-ims-client-access-to-ims" is just a placeholder. The final syntax will be defined in the stage 3 specification.

Example of OAuth 2.0: Identical to 4.1.

From the beginning of step 5 until the end of step 7, the text in the present subclause X.4.2.3 is normative.

5. REGISTER request (eP-CSCF to S-CSCF)

5.1 General:

The eP-CSCF proceeds if the previous step has provided it with IMPI, IMPU(s) of the user requesting registration, an assurance that the user is authorised to use this IMPI and IMPU, and an identity of the WWSF and WAF. Then, the eP-CSCF generates a TNA Authorization header and forwards the request to the S-CSCF (via the I-CSCF). The format of the TNA Authorization header is specified in TS 24.292, Clause 6.2 [15], and contains, among others, the IMPI assigned to the user, an integrity-protected directive set to auth-done, and an empty response directive.

Example of OAuth 2.0: Identical to 5.1.

5.2 Case of WAF located in third party domain:

In this case, in addition to step 5.1, if the eP-CSCF cannot not verify in step 4 that the IMPI, if it exists at all, belongs to an IMS subscription in the pool of IMS subscriptions assigned to the WWSF then the eP-CSCF includes the identity of the WAF and WWSF (if available).

6. Cx: S-CSCF Registration Notification

6.1 General:

Based on the presence of the "integrity-protected" directive set to indicate that authentication has already been performed, the S-CSCF knows that the user’s authorization has already been validated by the Trusted Node. The S-CSCF informs the HSS that the user has been registered. Upon being requested by the S-CSCF, the HSS will also include the user profile in the response sent to the S-CSCF. For detailed message flows see TS 29.228 [16].

Example of OAuth 2.0: Identical to 6.1.

6.2 Case of WAF located in third party domain:

In this case, in addition to step 6.1, the HSS further includes a list, if available, of WWSF identities allowed for assigning this IMS subscription. If the S-CSCF received a WWSF identity from the eP-CSCF, the S-CSCF checks whether it is contained in this list. The S-CSCF further checks whether the identities of the WWSF and WAF,received from the eP-CSCF, if any,are not barred. If the performed checks are positive, or no checks need to be performed, the S-CSCF proceeds with the next step; otherwise, it rejects the registration.

NOTE 10: The S-CSCF can obtain information about barred authorization entities from the HSS or via OAM. Barring may be useful in isolating the effects of security breaches in third party domains.

7. 200 (OK) response (S-CSCF to eP-CSCF)

7.1 General:

The S-CSCF sends a 200 (OK) response to the eP-CSCF (via I-CSCF) indicating that registration was successful.

When TLS is used between WIC and eP-CSCF, then, similar to the registration procedure for SIP Digest with TLS, the eP-CSCF associates the IMPI and all successfully registered IMPUs with the TLS Session ID when the 200 (OK) is received.

Example of OAuth 2.0: Identical to 7.1.

8. 200 (OK) response (eP-CSCF to WebRTC IMS Client)

8.1 General:

An example realisation of this step is as follows:

The eP-CSCF forwards the 200 (OK) response to the WebRTC IMS Client indicating that Registration was successful.

Example of OAuth 2.0: Identical to 8.1.