10 Security Procedures

26.2373GPPIP Multimedia Subsystem (IMS) based Packet Switch Streaming (PSS) and Multimedia Broadcast/Multicast Service (MBMS) User ServiceProtocolsRelease 17TS

10.1 General

Different security procedures apply for IMS, MBMS and PSS.

IMS level authentication and access security is performed during IMS registration in accordance to [7].

PSS-Only: PSS defines an optional confidentiality protection of individual RTP payloads used in a streaming session. If PSS confidentiality protection as defined in 3GPP TS 26.234 [8], Annex K. is used, then the terminal initiates the GAA/GBA Bootstrapping procedure 3GPP TS 33.220 [26] after a successful IMS registration and Service discovery.

MBMS-only and combined PSS/MBMS service offerings: MBMS security is based on GAA/GBA [26]. The GAA/GBA Bootstrapping procedure is initiated by the UE after a successful IMS registration and Service discovery. It is necessary before any service description retrieval and session initiation.

GBA (see 3GPP TS 33.220 [26]) is used to generate a master key Ks from which NAF specific keys (e.g. Ks_NAF for ME based key management) can be derived when needed. It is also used to authenticate the user for signaling that is not performed via the IMS core network (e.g. HTTP based service description retrieval).

GBA is also used to generate and provision the NAF keys (e.g. Ks_NAF for ME based key management) – which is the Long Term Key that is used in content encryption/decryption procedures – and the B-TID – which is the corresponding bootstrapping transaction identifier.

Figure 21: GBA/GAA Bootstrapping procedure

Figure 21 illustrates the GBA/GAA bootstrapping procedure. The following steps are performed. See [26] for details:

– The UE sends a request to the BSF with its IMPI as User ID. The UE discovers the address of the BSF as specified in [26].

– The BSF then acquires one Authentication Vector from the HSS and may acquire the User’s GUSS (GBA User Security Settings) and forwards the RAND and AUTN to the UE in the HTTP 401 message.

– The UE checks AUTN to verify that the challenge is from an authorised network.

– The UE sends another HTTP request, containing the Digest AKA response (calculated using RES), to the BSF.

– The BSF authenticates the UE by verifying the Digest AKA response. The BSF shall send a 200 OK message, including a B-TID, to the UE to indicate the success of the authentication.

If UICC based MBMS key management is required, then USIM shall be used. Otherwise either USIM or ISIM may be used.

NOTE: The reason for this is that UICC based MBMS key management is currently specified only for USIM.

10.2 Secure Service Description Retrieval

The Service Description retrieval procedure allows the UE to acquire the necessary information to select and initiate PSS and/or MBMS sessions using IMS procedures. See clause 7 for more details on this procedure.

Figure 22: Service Description retrieval with authentication

Figure 22 describes the Service Description retrieval procedure with authentication.

The UE requesting a service description towards the SSF (acting as a GBA Network Application Function (NAF)) shall include the B-TID corresponding to the Ks established during the bootstrapping procedure. When the SSF receives the service description request, it shall trigger an authentication request towards the BSF to acquire the NAF keys ( e.g. Ks_NAF for ME based key management) of the user if the SSF does not already have the NAF keys available. The SSF shall trigger HTTP digest authentication procedure towards the UE in accordance with 3GPP TS 33.222 [20].

The SSF shall use TLS to encrypt the Service Description during retrieval.

10.3 PSS Authentication and Content encryption

Void (TBD).

10.4 MBMS Security procedures

The IMS based MBMS user service security procedures shall fulfil the key management procedures defined in TS 33.246 [5], including MSKprocedures in clause 6.3.2 of TS 33.246 [5], and MTK procedures in clause 6.3.3 of TS 33.246 [5]. The MSK procedure further includes MBMS user service registration procedure, deregistration procedure, MSK request procedure and MSK delivery procedure.

Clause 10.4.1 describes MBMS security procedures where HTTP is used as described in TS 33.246 [5], and BMSC.UPF acts as NAF to interact with BSF and derives security keys.

Clause 10.4.2 describes MBMS security procedures where SIP is used and SCF act as a NAF to interact with BSF and derives security keys.

The procedures according to clause 10.4.1 and clause 10.4.2, respectively, are alternatives for MBMS security procedures. They are equal in terms of security provision. The UE shall support both alternatives for MBMS security procedures. The UE is informed about the supported MBMS security procedure by retrieval of the service attachment information from the SDF as defined in Annex H.

10.4.1 HTTP based MBMS security procedure

Clause 10.4.1 describes MSK procedures, and clause 10.4.2 describes MTK procedures.

10.4.1.1 MSK procedures

The IMS based MBMS user service registration procedure, deregistation procedure, MSK request procedure and MSK delivery procedure are defined in clause 10.4.1 to 10.4.4 respectively.

10.4.1.1.1 IMS based MBMS user service key registration procedure

Figure 23: Security procedures for IMS based MSMS user service

10.4.1.1.1.1 Procedures at the UE

When the user indicates to view an MBMS user service, the UE shall send a SIP INVITE message to SCF via IM CN Subsystem, The SIP INVITE message shall include MBMS Service ID to indicate which service the user intends to watch, as defined in clause 8.3.3.2, and a P- Preferred –Identity header with the value set to the desired user public identity.

After receiving a SIP 200 OK message, the UE shall perform MSK registration procedure as defined in clause 6.3.2.1a of TS 33.246[5]. The HTTP POST message initiated by the UE and addressed to BMSC.UPF shall conform to TS 33.246[5], and include an HTTP X-3GPP- Intended -Identity header as defined in TS 24.109 [22] with the value set to the user’s public identity.

10.4.1.1.1.2 Procedures at the IM CN Subsystem

The IM CN Subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6].

10.4.1.1.1.3 Procedures at the SCF

Upon receipt of a SIP INVITE request, the SCF shall perform service authorization procedure as defined in clause 8.3.3.4.

After successfully service authorization, the SCF shall send an Authorization Notification HTTP POST message to BMSC.UPF. The HTTP POST message shall be populated as follows:

– the HTTP version shall be 1.1 which is specified in RFC2616 [34];

– the base of the Request-URI shall contain the full BM-SC key management URI (e.g. http://bmsc.home1.net:1234);

– the Request-URI shall contain an URI parameter "requesttype" that shall be set to "authorize", i.e. Request-URI takes the form of "/keymanagement?requesttype= authorize";

– the HTTP X-3GPP-Asserted-Identity header shall be the IMPU of the user retrieved from the SIP INVITE message.

– the HTTP header Content-Type shall be the MIME type of the payload, i.e. "application/mbms-authorize+xml".

– the HTTP payload shall contain request including the authorized MBMS Service ID ServiceId carried in the SIP INVITE message;

After receiving an authorization acknowledgement, the SCF shall send a SIP 200 OK message to the UE as defined in clause 8.3.3.4.

10.4.1.1.1.4 Procedures at the BM-SC.UPF

Upon receiving an Authorization Notification message from SCF, the BMSC.UPF shall store the received message, and respond an Authorization Acknowledgment HTTP 200 OK message.

Upon receiving MSK registration message from a UE, the BMSC.UPF shall act as a NAF and perform GBA usage procedure with BSF to get GBA keys to derive MUK. The MUK is used for BM-SC.UPF to protect the transfer of MSK.

The BMSC.UPF shall authorize the UE according to the stored information. The BMSC.UPF shall send MSKs to the UE corresponding to the service IDs in the received message via MIKEY, as defined in clause 6.3.2.1a of TS 33.246[5].

10.4.1.1.2 IMS based MBMS user service key deregistration procedure

The IMS based MBMS user service MSK request procedure conforms to clasue 6.3.2.1B of TS 33.246[5]. Additionaly, The HTTP POST message initiated by the UE and addressed to BMSC.UPF shall include an HTTP X-3GPP- Intended -Identity header as defined in TS 24.109 [22] with the value set to the user’s public identity.

10.4.1.1.3 IMS based MBMS user service MSK request procedure

The IMS based MBMS user service MSK request procedure conforms to clasue 6.3.2.2 of TS 33.246[5]. Additionaly, The HTTP POST message initiated by the UE and addressed to BMSC.UPF shall include an HTTP X-3GPP- Intended -Identity header as defined in TS 24.109 [22] with the value set to the user’s public identity.

10.4.1.1.4 IMS based MBMS user service MSK delivery procedure

The IMS based MBMS user service MSK delivery procedure conforms to clause 6.3.2.3 of TS 33.246[5].

10.4.1.2 MTK procedure

The IMS based MBMS user service MTK procedure conforms to clause 6.3.3 of TS 33.246[5].

10.4.2 SIP based MBMS security procedures

10.4.2.0 General

Clause 10.4.2 describes an alternative to clause 10.4.1 for MBMS security procedures, where the NAF for the MBMS User Services is implemented in the SCF and interacts with the BSF. The procedures apply for both ME and UICC based key management.

The MBMS Security specification 3GPP TS 33.246 [5] defines a set of security procedures. The following list describes how these procedures are applied in the context of IMS based MBMS user services when using SIP based MBMS security procedures.

– "MBMS User Service Registration procedure".

– In the context of SIP based MBMS security procedure, this procedure is applied as specified in clause 10.4.2.1 in the present document.

– "MBMS User Service Deregistration procedure".

– In the context of SIP based MBMS security procedure, this procedure is applied as specified in clause 10.4.2.1A in the present document.

– "Basic MSK request procedure".

– In the context of SIP based MBMS security procedure, this procedure is applied as specified in clause 10.4.2.2 in the present document.

– "Missed key update procedure".

– This procedure is equivalent to Basic MSK request procedure.

– "BM-SC solicited pull procedure".

– In the context of SIP based MBMS security procedure, this procedure is applied as specified in clause 10.4.2.4 in the present document.

– "MSK delivery procedure"

– In the context of SIP based MBMS security procedure, this procedure is applied as defined TS 33.246 [5] with exception that SCF FQDN is sent instead of BM-SC FQDN.

– "MTK update procedure"

– In the context of SIP based MBMS user services this procedure is applied as defined TS 33.246 [5].

10.4.2.1 SIP based MBMS User Service Registration

This procedure is used to register a UE with one or more MBMS User Services.

It is assumed that the UE has received the service description (cf. clause 10.2). The service description includes, e.g. the service protection description. The service protection description is similar as defined in 3GPP TS 33.246 [5] with the following exception: the FQDN of the BM-SC is not included in the service protection description. Instead, the service protection description for the service shall include an FQDN belonging to the SCF as the SCF acts as a NAF.

NOTE 1: This is to ensure consistent NAF key derivation in the UE and in the BSF as the SCF acts as a NAF and as the FQDN of the NAF is used as input in NAF key derivation.

In case more than one BM-SCs are connected to the SCF, the SCF shall locally associate a different one of its FQDNs to each connected BM-SC. As there is one NAF FQDN indicated in the service protection description for each service, the SCF (NAF) will know from the userServiceId indicated by the UE which NAF FQDN to be used for NAF key derivation.

NOTE 2: This will ensure that each connected BM-SC will get different NAF key, and consequently will get different MUK. GBA TS 33.220 [26] allows the NAF to be known in DNS under several FQDNs if it is ensured that the correct NAF FQDN is used in NAF key derivation.

It is also assumed that the UE has been registered and authenticated to IMS and the SIP procedures are protected according to 3GPP TS 33.203 [31], and that the UE has run GBA bootstrapping with the BSF as defined in 3GPP TS 33.220 [26]. It is also assumed that the network interfaces are protected with Network Domain Security (NDS/IP) as defined in 3GPP TS 33.210 [32].

Figure 24: SIP based MBMS User Service Registration

The procedure is as follows (cf. figure 24 which is simplified as it does not show all parameters):

– The UE sends a SIP INVITE to the SCF via the IM CN subsystem. The INVITE indicates SCF in the Request-URI and the message includes the identities of the requested MBMS user services (userServiceIds) for which the UE wants to register and the bootstrapping transaction identifier (B-TID) in the body of the SIP INVITE. The XML schema for the list of MBMS user service IDs is defined in TS 26.346 [11] and the XML schema for the B-TID is defined in annex I.1.

– The SCF receives the IP address of the UE and the asserted identitie(s) of the UE from the headers of the SIP INVITE message. The SCF performs a check based on stored subscription information whether the UE is authorized to access the requested MBMS user services. If yes, the procedure continues. If not, the procedure is terminated.

– If there is no B-TID stored for the UE or if the received B-TID is different than the one stored for the UE, the SCF runs GBA usage procedure with the BSF over Zn to fetch the NAF keys corresponding to the UE as defined in 3GPP TS 33.220 [26]. The NAF-Id which the SCF uses over Zn is constructed from the NAF FQDN indicated in the service protection description for this service and Ua security protocol identifier specified in 3GPP TS 33.220 [26]. As there is one NAF FQDN indicated in the service protection description for each service, the SCF will know from the userServiceId indicated by the UE which FQDN to be used as NAF FQDN. Upon receiving the NAF keys from the BSF, the SCF derives MBMS User Key (MUK) as defined in TS 33.246 [5].
If the received B-TID is not valid or if the SCF desires the UE to make a new GBA bootstrapping, the SCF shall response to the UE with an appropriate error message. The error message will trigger the UE to run new GBA bootstrapping.

– The SCF sends a HTTP POST message to the BM-SC. The SCF populates the HTTP POST as follows:

– the HTTP version shall be 1.1 which is specified in RFC 2616 [34];

– the base of the Request-URI shall contain the full BM-SC key management URI (e.g. http://bmsc.home1.net:1234);

– the Request-URI shall contain an URI parameter "requesttype" that shall be set to "sip-based-register", i.e. Request-URI takes the form of "/keymanagement?requesttype= sip-based-register ";

– the SCF may add additional URI parameters to the Request-URI;

– X-3GPP-Asserted-Identity header which includes the identitie(s) of the UE;

– the HTTP header Content-Type shall be the MIME type of the payloads;

– the HTTP payload shall contain an XML document including a list of one or more userServiceIds of MBMS User Services to which the UE wants to register, IP address of the UE, MBMS user key (MUK), lifetime of MUK, NAF FQDN and B-TID. NAF FQDN and B-TID are included as they are further included in the MIKEY MSK messages from the BM-SC to the UE to identify the used MUK (i.e. NAF key). The XML schema for the list of MBMS user service IDs is defined in TS 26.346 [11] and the XML schema for carrying IP address, MUK, MUK lifetime, NAF FQDN and BTID is defined in annex x.2.

– the SCF may add additional HTTP headers to the HTTP POST request.

– Upon receiving the HTTP POST message, the BM-SC checks that the HTTP POST is valid, and extracts the request for further processing. As the HTTP POST message came from SCF with asserted identitie(s), the BM-SC does not need to authenticate the UE as the UE has been authenticated by the IMS. Also, the HTTP POST message also implicitly indicates to the BM-SC that the SCF has authorized the UE to register to the indicated MBMS User Service(s).

The BM-SC stores the received information and returns HTTP 200 OK to the SCF. The BM-SC shall populate HTTP response as follows:

– the HTTP status code in the HTTP status line shall be 200;

– the HTTP header Content-Type shall be the MIME type of the payload, i.e. "application/mbms-register-response+xml ";

– the HTTP payload shall contain an XML document including a list including one status code for each MBMS User Service. The XML schema of the payload is the same that is used for MBMS Registration in 3GPP TS 33.246 [5] and it is specified in 3GPP TS 26.346 [11].

– Upon receiving the HTTP 200 OK., the SCF then includes the XML body from the HTTP 200 OK message into a SIP 200 OK message and sends the SIP 200 OK message to the UE via the IM CN subsystem.

– Upon receiving the 200 OK the UE derives NAF keys corresponding to the NAF-Id. The NAF-Id is constructed from the NAF FQDN indicated in the service description and Ua security protocol identifier specified in 3GPP TS 33.220 [26]. The UE derives MBMS User Key (MUK) from the NAF key as defined in 3GPP TS 33.246 [5].

BM-SC can now start sending MIKEY MSK messages (protected with MUK) to the UE as defined in 3GPP TS 33.246 [5]. In MIKEY MSK messages the BM-SC shall include the NAF FQDN and B-TID received from the SCF as they are used to­ identify the used MUK (i.e. NAF keys).

10.4.2.1a SIP based MBMS User Service De-registration

This procedure is used to de-register a UE from one or more MBMS User Services.

The same assumptions apply as in SIP based MBMS User Service Registration in clause 10.4.2.1.

Figure 24a: SIP based MBMS User Service De-registration

The procedure is as follows (cf. figure 24a which is simplified as it does not show all parameters):

– UE sends a SIP re-INVITE to the SCF via the IM CN subsystem. The re-INVITE indicates SCF in the Request-URI and the message includes the identities of the requested MBMS user services (userServiceIds) from which the UE wants to de-register and the bootstrapping transaction identifier (B-TID) in the body of the SIP INVITE.. The XML schema for the list of MBMS user service IDs is defined in TS 26.346 [11] and the XML schema for the B-TID is defined in annex x.1.

– The SCF receives the asserted identitie(s) of the UE from the headers of the SIP re-INVITE message.

– If there is no B-TID stored for the UE or if the received B-TID is different than the one stored for the UE, the SCF runs GBA usage procedure with the BSF over Zn to fetch the NAF keys corresponding to the UE as defined in 3GPP TS 33.220 [26]. The NAF-Id which the SCF uses over Zn constructed from the NAF FQDN indicated in the service protection description for this service and Ua security protocol identifier specified in 3GPP TS 33.220 [26]. Upon receiving the NAF key from the BSF, the SCF derives MBMS User Key (MUK) as defined in 3GPP TS 33.246 [5].
If the received B-TID is not valid or if the SCF desires the UE to make a new GBA bootstrapping, the SCF shall response to the UE with an appropriate error message. The error message will trigger the UE to run new GBA bootstrapping.

– The SCF sends a HTTP POST message to the BM-SC. The SCF populates the HTTP POST as follows:

– the HTTP version shall be 1.1 which is specified in RFC 2616 [34];

– the base of the Request-URI shall contain the full BM-SC key management URI (e.g. http://bmsc.home1.net:1234);

– the Request-URI shall contain an URI parameter "requesttype" that shall be set to "sip-based-deregister", i.e. Request-URI takes the form of "keymanagement?requesttype= sip-based-deregister";

– the SCF may add additional URI parameters to the Request-URI;

– X-3GPP-Asserted-Identity header which includes the identities of the UE;

– the HTTP header Content-Type shall be the MIME type of the payloads;

– the HTTP payload shall contain the request an XML document including a list of one or more userServiceIds of MBMS User Services from which the UE wants to deregister. If new NAF keys were created in the previous step, then the SCF shall also include MBMS user key (MUK), lifetime of MUK, NAF FQDN and B-TID. E.g. the BM-SC may send an MSK message to invalidate the MSKs in the UE as defined in 3GPP TS 33.246 [5]. The XML schema for the list of MBMS user service IDs is defined in 3GPP TS 26.346 [11] and the XML schema for carrying MUK, MUK lifetime, NAF FQDN and BTID is defined in annex x.2;

– the SCF may add additional HTTP headers to the HTTP POST request.

– The BM-SC receives the HTTP POST message. The BM-SC checks that the HTTP POST is valid, and extracts the request for further processing. As the HTTP POST message came from SCF with asserted identities, the BM-SC does not need to authenticate the UE as the UE has been authenticated by the IMS.

The BM-SC returns HTTP 200 OK to the SCF. The BM-SC shall populate HTTP response as follows:

– the HTTP status code in the HTTP status line shall be 200;

– the HTTP header Content-Type shall be the MIME type of the payload, i.e. "application/mbms-register-response+xml". XML document is the same that is used for MBMS De-registration in 3GPP TS 33.246 [5] and it is specified in 3GPP TS 26.346 [11];

– the HTTP payload shall contain a list including one status code for each MBMS User Service.

– Upon receiving the HTTP 200 OK, the SCF then includes the XML body from the HTTP 200 OK message into a SIP 200 OK message and sends the SIP 200 OK message to the UE via the IM CN subsystem.

10.4.2.2 SIP based Basic MSK Request

This procedure is used to by the UE to request one or more MSKs.

Figure 25: SIP based MBMS MSK request

The same assumptions apply as in IMS based MBMS User Service Registration in clause 10.4.2.1.

The procedure is as follows (cf. figure 25 which is simplified as it does not show all parameters):

– UE sends a SIP re-INVITE to the SCF via the IM CN subsystem. The re-INVITE indicates SCF in the Request-URI and the message includes a list of one or more Key Domain ID – MSK ID pair(s) of the MSKs that the UE wants to receive and the bootstrapping transaction identifier (B-TID) in the body of the SIP INVITE. The XML schema for the list of MBMS user service IDs is defined in TS 26.346 [11] and the XML schema for the B-TID is defined in annex x.1.

– The SCF receives the asserted identitie(s) of the UE from the headers of the SIP re-INVITE message. The SCF performs a check based on stored subscription information whether the UE is authorized to receive the specified MSK(s). If yes, the procedure continues. If not, the procedure is terminated.

– If there is no B-TID stored for the UE or if the received B-TID is different than the one stored for the UE, the SCF runs GBA usage procedure with the BSF over Zn to fetch the NAF keys corresponding to the UE as defined in 3GPP TS 33.220 [26]. The NAF-Id which the SCF uses over Zn is constructed from the NAF FQDN indicated in the service protection description for this service and Ua security protocol identifier specified in 3GPP TS 33.220 [26]. Upon receiving the NAF keys from the BSF, the SCF derives MUK from the NAF key as defined in 3GPP TS 33.246 [5].
If the received B-TID is not valid or if the SCF desires the UE to make a new GBA bootstrapping, the SCF shall response to the UE with an appropriate error message. The error message will trigger the UE to run new GBA bootstrapping.

– The SCF sends a HTTP POST message to the BM-SC. The SCF populates the HTTP POST as follows:

– the HTTP version shall be 1.1 which is specified in RFC 2616 [34];

– the base of the Request-URI shall contain the full BM-SC key management URI (e.g. http://bmsc.home1.net:1234);

– the Request-URI shall contain an URI parameter "requesttype" that shall be set to "sip-based-msk-request", i.e. Request-URI takes the form of "/keymanagement?requesttype= sip-based-msk-request";

– the SCF may add additional URI parameters to the Request-URI;

– X-3GPP-Asserted-Identity header which includes the identities of the UE;

– the HTTP header Content-Type shall be the MIME type of the payloads;

– the HTTP payload shall contain a list of one or more Key Domain ID – MSK ID pair(s) of the MSKs that the UE wants to receive. If new NAF keys were created in the previous step, then the SCF shall also include MBMS user key (MUK), lifetime of MUK, NAF FQDN and B-TID. NAF FQDN and B-TID are included as they may be further included in the MIKEY MSK messages from the BM-SC to the UE, The XML schema for the list of Key Domain ID – MSK ID pair(s) is defined in 3GPP TS 26.346 [11] and the XML schema for carrying IP address, MUK, MUK lifetime, NAF FQDN and BTID is defined in annex x.2.

– the UE may add additional HTTP headers to the HTTP POST request.

– The BM-SC receives the HTTP POST message. The BM-SC checks that the HTTP POST is valid, and extracts the request for further processing. As the HTTP POST message came from SCF with asserted identities, the BM-SC does not need to authenticate the UE as the UE has been authenticated by the IMS. Also, the HTTP POST message also implicitly indicates to the BM-SC that the SCF has authorized the UE to receive the specified MSK(s).

The BM-SC stores the received information and returns HTTP 200 OK to the SCF. The BM-SC shall populate HTTP response as follows:

– the HTTP status code in the HTTP status line shall be 200;

– the HTTP header Content-Type shall be the MIME type of the payload, i.e. "application/mbms-msk-response+xml";

– the HTTP payload shall contain a list including one status code for each MSK. The XML schema of the payload is the same that is used for MBMS MSK request in 3GPP TS 33.246 [5] and it is specified in 3GPP TS 26.346 [11].

– The SCF receives the HTTP 200 OK. The SCF then includes the XML body from the HTTP 200 OK message into a SIP 200 OK message and sends the SIP 200 OK message to the UE via the IM CN subsystem.

10.4.2.3 Updating MUK

The GBA session (i.e. key Ks derived NAF specific keys, e.g. MUK) has a limited lifetime. The GBA session may expire during service consumption. In this case the UE shall run GBA bootstrapping again to create a new Ks. The UE shall then re-register to the services with the SIP based MBMS registration procedure defined in clause 10.4.2.1 with re-INVITE and the new B-TID. This will create a new MUK in the UE and network.

10.4.2.4 SIP based BM-SC solicited pull

According to 3GPP TS 33.246 BM-SC solicited pull procedure is triggered by the BM-SC by sending an MSK message with a specific MSK-ID value. This will trigger the UE to perform MSK request. IMS based MBMS uses the BM-SC solicited pull procedure as defined in TS 33.246 to trigger the UE to perform SIP based basic MSK request procedure which is specified in clause 10.4.2.2.