X.3 Authentication of WebRTC IMS Client with IMS subscription using web credentials

33.2033G Security3GPPAccess security for IP-based servicesTS

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

X.3.0 General

The present clause X.3 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 based on web authentication".

X.3.1 General requirements

The following security requirements apply to the present registration scenario:

– REQ 2.0: For the interface W1 (WIC to WWSF) mutual authentication is required, unless the user’s web identity is authenticated by the WAF, in which case only one-way authentication is required. For the interfaces W2 (WIC to eP-CSCF), and W4, if present, (WWSF to WAF), mutual authentication is required.

– REQ 2.1: An IMS service provider shall ensure that a third party authenticating a WebRTC IMS Client (WIC) and authorizing it to register with an IMS network using certain IMS identities has been granted the right to do so by the IMS subscriber owning these IMS identities. In case of a potential security breach affecting that third party, IMS subscribers that did not grant any right to that third party shall not be affected.

– REQ 2.2: An IMS service provider should be able to identify and mitigate security anomalies or security breaches at one third party entity authenticating or authorizing WebRTC IMS Clients , without affecting clients associated with other such third party entities.

– REQ 2.3: To prevent a third party from providing authorization information to a WebRTC IMS Client (WIC) without having been authorized by the IMS service provider to do so, an IMS service provider shall be able to identify the granting third party each time the IMS subscriber registers with the IMS network through the W2 interface. The identity of the third party shall be determined from the authorization information securely received by the IMS network over W2.

– REQ 2.4: An IMS service provider relying on a third party for authenticating or authorizing WebRTC IMS Clients (WIC), shall securely determine from the received authorization information the IMPI and IMPU of the authenticated WIC attempting to register with the IMS network.

NOTE: In a use-case where IMPI is associated with multiple IMPUs, IMPI to IMPU association check when
I-CSCF User Registration Query is processed by the HSS, is not enough. For example, a user who has authenticated to the WWSF as sip:bob-impu1@operator.com but changes "To" field in the W2 REGISTER message to sip:bob-impu2@operator.com, will not be detected by the IMS network. It is therefore necessary to determine IMPU and IMPI of the authenticated user from the received authorization information.

– REQ 2.5: It shall be ensured that a third party authenticating and authorizing a WebRTC IMS Clienthas enough information to guarantee that the user is entitled to use the IMS private identity IMPI determined from the user’s web identity authenticated by the third party.

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

X.3.2 Solution 2.1

X.3.2.1 General

In the present registration scenario it is assumed that the user has a subscription with an individual IMPU, but uses a web identity and authentication scheme to authenticate with the WWSF or the WAF. (Whether it is the WWSF or the WAF depends on the deployment).

X.3.2.2 Requirements

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

X.3.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 1: 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 2: 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.2.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 TS 23.228 [3]. 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 is enhanced with additional parameters (WAF and WWSF identity, if available), which are included to satisfy the requirements REQ 2.1 and REQ 2.2 from clause X.3.1 of the present specification.

Figure X.3.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 WAF or WWSF, depending on the authorization flow used, 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 user’s web identity is mapped to the corresponding IMS subscriber identity (i.e. IMPI and IMPU(s) ).

NOTE 3: It is assumed that the WWSF or WAF maintains the mapping between a user’s web identity and IMPI/IMPU. How this mapping is established (i.e. how REQ 2.5 is satisfied) is out-of-scope of this specification.

Example of OAuth 2.0:

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

– Authorization Code flow: The WAF authenticates both the user and the WWSF before it issues the access token. The WAF may also request the user to explicitly authorize the WWSF.

– 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.

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 4: 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 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 5: 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 6: 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 of the associated user, the WAF and WWSF identities(if available),, and the authorization token scope. The eP-CSCF verifies that the scope includes the value "webrtc-ims-client-access-to-ims"

NOTE 6a: 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.

If the token is not valid in some respect, the eP-CSCF declines the register request, closes the web socket and aborts the procedure.

NOTE 7: 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.3.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 user’s IMPI, 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 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 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 of WAF and WWSF identities (if available), outside the IMS provider’s domain allowed for this IMS subscription. If the S-CSCF received an identity of the authorization entity from the eP-CSCF then the S-CSCF checks whether this identity is contained in the list received from the HSS. The S-CSCF further checks whether the identity of the authorization entity received from the eP-CSCF, if any, is 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 8: 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.