X.2 Authentication of WebRTC IMS Client with IMS subscription re-using existing IMS authentication mechanisms

33.2033G Security3GPPAccess security for IP-based servicesTS

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

X.2.0 General

The present clause X.2 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 using IMS authentication".

X.2.1 General requirements

The following security requirements apply to all solutions for the present registration scenario:

– REQ 1.0: For the reference interface W1 (WIC to WWSF), one way authentication (WIC needs to authenticate WWSF) is needed. For the interface W2 (WIC to eP-CSCF), mutual authentication is required.

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

When the WIC has access to the USIM/ISIM in the UE, IMS AKA scheme shall be used for authenticating WebRTC IMS Client, as defined in section X.2.3 of this document.

X.2.2 Solution 1.1: Use of SIP Digest credentials

X.2.2.1 General

In solution 1.1 it is assumed that the user has a subscription with an individual IMPU. The WebRTC IMS Client (WIC) is provided with the user’s SIP Digest credentials and uses SIP Digest to register with IMS. The eP-CSCF is assumed to relay the authentication information so that the message flows are unchanged. The use of SIP Digest in IMS is specified in Annex N of this document.

NOTE: The use of SIP Digest breaks the security requirement mandating IMS AKA to connect to IMS when using a 3GPP access network. See Annex N of this document.

It is recommended to maintain a clear separation between WICs and regular IMS UEs. A user accessing IMS from a WIC should be assigned a separate subscription in the HSS with a unique IMPI and SIP Digest password. In this way a compromised password will have an isolated impact and only affect the WIC.

The entities that have access to the IMPI and SIP Digest password, and thus needs to be trusted by the operator, are the user, the browser, the WWSF, and the IMS core network. (The WWSF is included here since it has the ability to inject rogue JavaScript code into the WIC). SIP Digest should therefore only be used when the WWSF is controlled by the operator or a 3rd party trusted by the operator.

X.2.2.2 Requirements

No requirements have been identified.

X.2.2.3 Procedures

Figure X.2.3-1 shows the registration flow. In this figure SIP over secure WebSocket is used between the WIC and the eP-CSCF. Other protocols (e.g. HTTP RESTful or JSON over WebSocket) can also be used as long as it is able to relay the digest challenge, challenge-response, and auth-info values.

Solution 1.1 requires that the IMPU and SIP Digest password are made available to the JavaScript in the WIC. The IMPI can be omitted from the initial SIP Register request, and if that is the case the S-CSCF will try to determine its value from the registering IMPU. This requires that IMPUs are not shared between IMS users (see Annex N).

NOTE 1: It is assumed that the credentials are entered by the user via the web GUI or retrieved from the WWSF over HTTPS. Note that the latter option requires that WWSF has authenticated the user previously.

NOTE 2: Unless the SIP Digest password or the intermediate hash value H(A1) (see RFC 7235 [83] and RFC 7616 [76]) is stored in the WIC, the password needs to be re-obtained each time a re-registration is performed. If the password is entered manually and if re-registrations occur often, this will result in a negative user experience. This can be avoided by storing the SIP Digest password or H(A1) in the WIC after the initial registration procedure. Ensuring the confidentiality of the SIP Digest password or H(A1) during storage is at the discretion of the implementation and is outside the scope of 3GPP. The use of MD5 in HTTP Digest is not recommended and only supported for interoperability.

NOTE 3: It is recommended that the user does not enter his SIP Digest credentials into the WIC, except possibly once before the initial registration.

Figure X.2.2.3-1: WebRTC IMS Client authentication using SIP Digest

The details of the signalling flows are as follows:

1) Web page download from WWSF

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.

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

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 3: The protection mechanism works under the assumption that the browser is not under the attacker’s control.

3-10) SIP Digest message flow

The SIP Digest messages exchanged between the WIC and eP-CSCF and between the eP-CSCF and the I/S-CSCF are as defined in Annex N of this document.

X.2.3 Solution 1.2: Use of IMS AKA

X.2.3.1 General

When the WIC has access to the USIM/ISIM in the UE, IMS AKA scheme is used for authenticating WebRTC IMS Client, as described figure X.2.3.3-1.

The IMS AKA procedure is performed as specified in section 6.1 with the usage of HTTP Digest AKAv2 as defined in RFC 4169 [65] (instead of HTTP Digest AKA defined in RFC 3310 [17]) and without security association set-up. The protection of IMS signalling between the WIC and the eP-CSCF is provided by the secure WebSocket connection.

The ME shall be able to apply access control policy to the WIC before granting the access to the UICC application in charge of the IMS AKA authentication for WebRTC.

NOTE: Precision on how the ME could apply access control policy to restrict access to UICC is at the discretion of the ME implementation and is left out of scope of the present 3GPP release.

It is optional to have in the UICC an ISIM application that would be dedicated to WebRTC usage in order to maintain a clear separation between WebRTC Client and regular IMS UEs. This ISIM application dedicated to WebRTC could have separate subscription in the HSS (with unique IMPI and key K). In this way an attack will have an isolated impact and only affect the WebRTC IMS Client.

X.2.3.2 Requirements

No requirements have been identified.

X.2.3.3 Procedures

Figure X.2.3.3-1 shows the registration flow:

Figure X.2.3.3-1: WebRTC client authentication using IMS AKA

Web page download from WWSF

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

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 1: The protection mechanism works under the assumption that the browser is not under the attacker’s control.

– IMS AKA Procedure (from Step 1 to Step 8)

The IMS AKA procedure is performed as specified in section 6.1 with differences as explained below.

HTTP Digest AKAv2 is used as defined in RFC 4169 [65] (instead of HTTP Digest AKA defined in RFC 3310 [17]) and no IPsec security association is set-up. The keys CK and IK shall not be forwarded by the S-CSCF to thee P-CSCF in SM4. Hence, any statements relating to the use of these keys in the eP-CSCF do not apply.

The WebRTC IMS Client forwards necessary IMS AKA information to the UICC application in charge of the IMS AKA authentication for WebRTC.

The ME applies access control policy to the WIC before granting the access to the UICC application in charge of the IMS AKA authentication for WebRTC.

This UICC application sends back the results of the AUTHENTICATE command executed to perform the IMS AKA authentication, as defined in section 8 of this document. After successful execution of the AUTHENTICATE command, the ME securely derives the HTTP Digest password as described in RFC 4169 [65] using algorithm name equal to "AKAv2-SHA-256" and associated pseudo-random function (PRF) as defined in RFC 4169 [65] The algorithm value equals to SHA-256 in RFC 3310[17]. The WebRTC IMS Client uses this HTTP Digest password to provide the authentication response in the SIP Register message. The WIC shall not have access to the keys CK and IK.

NOTE: The messages SM2, SM8, SM9 and SM11 mentioned in the following are defined in clause 6 of this specification.

The eP-CSCF shall forward the REGISTER request to the S-CSCF including the "integrity-protected" header field parameter with the value set to "tls-connected" in message SM2 if the REGISTER request was received over the TLS connection between the WIC and the eP-CSCF. The eP-CSCF sends message SM8 with a TLS integrity protection indicator indicating the logical value "authentication pending". When the eP-CSCF receives message SM11 (200 OK), it shall associate the UE’s IP address and port of the TLS connection with the TLS session ID, the IMPI and all the successfully registered IMPUs related to that IMPI. From this point onwards for WebRTC session, the eP-CSCF shall not accept any SIP signalling messages outside the TLS connection other than messages relating to emergency services in accordance to TS 24.229 [8] and TS 23.167 [31].

In the REGISTER message received by the S-CSCF, if the value of the "integrity-protected" flag is set to "tls-connected" and "algorithm" parameter in the Authorization header has the value "AKAv2-SHA-256", the S-CSCF concludes that the REGISTER request relates to IMS AKA with HTTP Digest AKAv2 over TLS session set-up prior to registration.

The S-CSCF shall derive the HTTP Digest password as described in RFC 4169 [65] using algorithm name equal to "AKAv2-SHA-256" and associated pseudo-random function (PRF) After message SM9, if the authentication of the UE is successful, the S-CSCF shall associate the registration with the local state "tls-protected". An S-CSCF shall accept a REGISTER message with a TLS integrity protection indicator indicating "authentication pending" only if it contains a verifiable Digest value computed over a valid challenge according to RFC 4169 [65].