6 Registration and authentication

24.3713GPPProtocol specificationRelease 17Stage 3TSWeb Real-Time Communications (WebRTC) access to the IP Multimedia (IM) Core Network (CN) subsystem (IMS)

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

6.1 General

This clause specifies procedures that are related to registration of a WIC in the IM CN subsystem that are required for support of WebRTC.

There are the following IMS registration scenarios defined in 3GPP TS 23.228 [4] Annex U. 3GPP TS 33.203 [9] specifies the following authentication methods applying to different IMS registration scenarios separately.

a) Scenario 1: The WIC registration of individual public user identity using IMS authentication. There are two authentication methods specified in 3GPP TS 33.203 [9], corresponding to this scenario:

1) SIP Digest authentication scheme; and

2) use of IMS AKA authentication scheme.

b) scenario 2: The WIC registration of individual public user identity based on web authentication.

1) Web authentication scheme: The registration procedure between the eP-CSCF and the IM CN subsystem reuses the Trusted Node Authentication (TNA) procedure specified in 3GPP TS 33.203 [9]; or

c) scenario 3: The WIC registration of individual public user identity from a pool of public user identities.

1) Web authentication scheme: The registration procedure between the eP-CSCF and the IM CN subsystem reuses the Trusted Node Authentication (TNA) procedure specified in 3GPP TS 33.203 [9]. The registration procedure of scenario 3 is basically the same with scenario 2, with the difference that, in scenario 3 it is assumed that the WWSF is provided with a pool of public user identities and can assign public user identities within this pool.In all the registration scenarios, it is assumed that HTTP or HTTPS connection is used between the WIC and the WWSF, where HTTPS connection is recommended due to the security considerations.

The structure of clause 6 is divided by functional entity as the first level, and in each clause of a specific functional entity, all the authentication solutions are described in the sequence of registreation scenarios.

As the media plane security mechanisms for WebRTC, i.e. DTLS-SRTP for RTP based media and DTLS/SCTP for non-RTP based media, are mandatory to be supported in WIC and eP-CSCF, there is no need to indicate the media plane security mechanisms in the Security-Client header field of the REGISTER request and in the Security-Server header field of the 200 (OK) response to the REGISTER request.

The WIC and the eP-CSCF using Gm shall follow the registration procedures as described in 3GPP TS 24.229 [3] and the procedures as described in this document in addition. For the WIC and eP-CSCF using Gm, the appropriate signalling protocol is defined in 3GPP TS 24.229 [3] and this document.

For the WIC and eP-CSCF using non-Gm or non-SIP, the registration procedures and the signalling protocol are out of scope of this document.

6.2 WIC (WebRTC IMS Client)

6.2.1 WIC registration of individual Public User Identity using IMS authentication

6.2.1.1 General

When using SIP over Websockets as signalling protocol on the W2 interface:

1) when the WIC uses registration using SIP Digest it shall follow the procedures as described in clause 6.2.1.2; and

2) when the WIC uses registration using IMS-AKA it shall follow the procedures described in clause 6.2.1.3.

6.2.1.2 W2 using SIP Digest credentials

When using SIP over Websockets as signalling protocol on the W2 interface and using registration based on SIP Digest credentials, the WIC shall use the procedures for "SIP Digest without TLS" as specified in 3GPP TS 24.229 [3].

NOTE: The WIC uses the TLS connection that was established during the WebSocket connection setup.

6.2.1.3 W2 using IMS-AKA

When using SIP over Websockets as signalling protocol on the W2 interface and when IMS AKA is used for authenticating the WIC, the WIC shall use the IMS-AKA procedures defined in 3GPP TS 24.229 [3] with the following modifications:

1) HTTP Digest AKAv2 as defined in RFC 4169 [33] is used instead of HTTP Digest AKA defined in RFC 3310 [32]; and

2) IPSec security association set-up is not performed at the final stage of the authentication.

NOTE: The WIC uses the TLS connection that was established during the WebSocket connection setup to protect the IMS signalling between the WIC and the eP-CSCF.

On sending a REGISTER request as defined in 3GPP TS 24.229 [3] for IMS AKA, the WIC shall:

1) additionally populate the Authorization header field with the "algorithm" header field parameter set to "AKAv2-SHA-256" as defined in RFC 4169 [33]; and

2) not include the Security-Client header in the REGISTER request.

On receiving the 200 (OK) response to the REGISTER request the WIC shall not set the IPSec security association and associated lifetime.

6.2.2 WIC registration of individual public user identity based on web authentication

In this clause it is assumed that SIP over Websockets is used as the signalling protocol on the W2 interface and the user has a subscription with an individual IMPU, but uses a web identity and authentication scheme, e.g. OAuth 2.0, to authenticate with the WWSF or the WAF.

As specified in 3GPP TS 33.203 [9], after receiving the access token from WWSF, which is issued by WAF, the WIC shall:

– send a SIP REGISTER request to the eP-CSCF via the Websockets connection, which includes:

i) the Authorization header field with the Bearer scheme containing the access token as described in RFC 8898 [27]; and

ii) values for the To header field and the From header field decided by the UE implementation.

NOTE: The WIC can use the access token to form the values of the To header field and the From header field.

The WIC shall obtain a new access token from the WWSF/WAF before the access token expiry period to continue to get an access to IMS core network.

6.2.3 WIC registration of individual public user identity from a pool of public user identities

In this scenario it is assumed that the WWSF is provided with a pool of public user identities and can assign public user identities within this pool. The WIC procedure is as specified in clause 6.2.2, with the difference that the public user identity (and private user identity) is temporarily assigned to the user and there is no linkage between the user’s web identity that may be authenticated by an authentication service and the assigned IMS identities.

6.3 WWSF (WebRTC Web Server Function) and WAF (WebRTC Authorisation Function)

6.3.1 WIC registration of individual public user identity using web credentials

The WWSF pushes WebRTC JavaScript to theWIC, authenticates the WIC’s web credentials and forwards the authorization token to the WIC which is issued by WAF. Detailed web authentication procedures related to the WWSF in W1 and W4 interface are described in 3GPP TS 33.203 [9] and will not be specifed in this document.

6.3.2 WIC registration of individual public user identity from a pool of public user identities

The WWSF and the WAF procedure is the same as specified in clause 6.3.1, with the exception that in this scenario the WAF authenticates only the WWSF without user involvement, and the WWSF may choose not to authenticate the user if the user is to remain anonymous.

6.4 eP-CSCF (P-CSCF enhanced for WebRTC)

6.4.1 WIC registration of individual Public User Identity using IMS authentication

6.4.1.1 Determination of IMS authentication mechanism

When the eP-CSCF receives a REGISTER request using SIP over Websockets as signalling protocol on the W2 interface, the eP-CSCF determines which IMS authentication mechanism to use as described in annex P of 3GPP TS 33.203 [9].

6.4.1.2 W2 using SIP Digest credentials

When the eP-CSCF receives a REGISTER request for "SIP Digest with TLS" using SIP over Websockets as signalling protocol on the W2 interface, then the procedures as defined in 3GPP TS 24.229 [3] clause 5.2.2 apply. In addition the eP-CSCF shall:

1) if the REGISTER request was received on a pre-established TLS then:

a) if the REGISTER request does not map to an existing TLS association, and does not contain a challenge response, not include the "integrity-protected" header field parameter;

b) if the REGISTER request does not map to an existing TLS association, and does contain a challenge response, include an "integrity-protected" header field parameter with the value set to "tls-pending";

c) if the REGISTER request does map to an existing TLS association, include an "integrity-protected" header field parameter with the value set to "tls-protected";

d) if the "rport" header field parameter is included in the Via header field, set the value of the "rport" header field parameter in the Via header field to the source port of the received REGISTER request; and

e) insert the "received" header field parameter in the Via header field containing the source IP address that the request came from, as defined in RFC 3581 [26].

NOTE: As defined in RFC 3581 [26], the P-CSCF will insert a "received" header field parameter containing the source IP address that the request came from, even if it is identical to the value of the "sent-by" component.

When the eP-CSCF receives a 401 (Unauthorized) response to a REGISTER request, the eP-CSCF shall:

1) send the 401 (Unauthorized) response to the UE using the TLS session with which the associated REGISTER request was protected.

When the eP-CSCF receives a 200 (OK) response to a REGISTER request as defined, and the registration expiration interval value is different than zero, the eP-CSCF shall additionally:

– create an TLS association by storing and associating the UEs IP address and port of the TLS connection with the TLS Session ID, the private user identity and all the successfully registered public user identities related to that private user identity; and

– send the 200 (OK) response to the REGISTER request within the same TLS session to that in which the request was protected.

6.4.1.3 W2 using IMS-AKA

When the eP-CSCF receives a REGISTER request from the WIC for IMS-AKA over a TLS session set-up prior registration:

1) not including the Security Client header field; and

2) containing an Authorization header field with an "algorithm" header field parameter set to "AKAv2-SHA-256";

the eP-CSCF shall:

a) include the "integrity-protected" header field parameter with the value set to "tls-connected" in the Authorization header field;

b) if the "rport" header field parameter is included in the Via header field, then set the value of the "rport" header field parameter in the Via header field to the source port of the received REGISTER request; and

c) insert the "received" header field parameter in the Via header field containing the source IP address that the request came from, as defined in RFC 3581 [26]:

before forwarding the REGISTER request.

When the eP-CSCF receives a 401 (Unauthorized) response to a REGISTER request, the eP-CSCF shall:

1) send the 401 (Unauthorized) response to the UE using the TLS session with which the associated REGISTER request was protected.

When the eP-CSCF receives a 200 (OK) response to a REGISTER request, and the registration expiration interval value is different than zero, the eP-CSCF shall additionally:

– create an association by storing and associating the UEs IP address and port of the TLS connection with the TLS Session ID, the private user identity and all the successfully registered public user identities related to that private user identity; and

– protect the 200 (OK) response to the REGISTER request within the same TLS session to that in which the request was protected.

6.4.2 WIC registration of individual public user identity using web credentials

In this clause it is assumed that SIP over Websockets is used as the signalling protocol on the W2 interface. Upon receiving the SIP REGISTER request from the WIC, the eP-CSCF shall extract from the Authorization header field the access token and validate it as specified in 3GPP TS 33.203 [9] Annex X. If the access token is verified valid, the eP-CSCF obtains the associated authorization information, including the private user identity and public user identity of the associated user, the WAF and WWSF identities, and the authorization information scope.

The eP-CSCF inserts the obtained private user identity and public user identity in the SIP REGISTER request, where the Authorization header field in SIP REGISTER request, as specified in 3GPP TS 33.203 [9] Annex U, contains the private user identity, and the To and From header fields in the SIP REGISTER request contains the public user identity.

NOTE: The eP-CSCF will overwrite the To header field and From header field values received in the SIP REGISTER request from the WIC.

Then the eP-CSCF performs as the trusted node in TNA scheme specified in 3GPP TS 33.203 [9] Annex U. The eP-CSCF forwards the SIP REGISTER request to the S-CSCF as specified in 3GPP TS 24.229 [3], where the Authorization header in SIP REGISTER request, as specified in 3GPP TS 33.203 [9] Annex U, contains the user’s private user identity, an "integrity-protected" header field set to "auth-done ", and an empty "response" header field.

If the WAF, which authorizes the WIC to access the IMS core and issues the access token, is located in third party domain, the eP-CSCF shall also include the WAF identity in the REGISTER request, using a JSON Web Token (defined in RFC 7519 [35]) with a "3gpp-waf" JSON Web Token claim (defined in 3GPP TS 24.229 [3]) set to the value of the WAF identity. The eP-CSCF shall include the JSON Web Token in the REGISTER request as a MIME body with an "application/jwt" MIME value (defined in RFC 7519 [35]).

If the WWSF, which authorizes the WIC to access the IMS core and issues the access token, is located in third party domain, the eP-CSCF shall also include the WWSF identity in the REGISTER request, using a JSON Web Token with a "3gpp-wwsf" JSON Web Token claim (defined in 3GPP TS 24.229 [3]) set to the value of the WWSF identity. The eP-CSCF shall include the JSON Web Token in the REGISTER request as a MIME body with an "application/jwt" MIME value (defined in RFC 7519 [35]).

If the eP-CSCF includes a JSON Web Token in the REGISTER request, it shall include a JSON Web Token header "alg" property with a "none" value. In addition, the eP-CSCF shall not calculate and include a signature in the JSON Web Token, as described in RFC 7519 [35].

NOTE: If the eP-CSCF includes both the WAF identity and the WWSF identity in the REGISTER request then both identities are placed in the same JSON Web Token.

Upon receiving the SIP 200 (OK) response from the S-CSCF, the eP-CSCF forwards SIP 200 (OK) response to the WIC. When TLS is used between the WIC and the eP-CSCF, the eP-CSCF shall additionally create an association between the UE and the TLS connection as specified in 3GPP TS 24.229 [3] clause 5.2.2.4.

6.4.3 WIC registration of individual public user identity from a pool of public user identities

As specified in clause 6.4.2 with the following addition:

– An as option, upon receiving the SIP REGISTER request from the WIC, if the registration expiration interval (specified in 3GPP TS 24.229 [3]) contains a value higher than the lifetime of the authorization token, then in order to allow the WWSF to know when to re-assign a public user identity and private user identity to another user, the eP-CSCF may set a value for the registration expiration interval in the SIP REGISTER request equal to the lifetime of the authorization token. Other options may exist.