If the security protection of MBS traffic is required, confidentiality and integrity protection as specified in clause 5.3 of TS 33.246 apply. The control-plane procedure and user-plane procedure are optionally supported in service layer. The control-plane procedure is only applicable for multicast sessions, while the user-plane procedure is applicable for both multicast sessions and broadcast sessions. The user plane security between UE and RAN shall be deactivated when 5GC shared MBS traffic delivery method for MBS data transmission is used to avoid redundant protection.

The multicast session security context consists of the MBS session ID, MBS keys and the corresponding key ID. The MBS keys include MBS Service Key (MSK) and MBS Traffic Key (MTK). MBS traffic is protected with the MTK. The MSK is used to protect the MTK when the MTK is delivered to the UE. The identification for every MSK and MTK are determined as specified in Clause 6.3.2.1 and clause 6.3.3.1 of TS 33.246. The MBSF determines whether security protection to be applied or not for the MBS session based on locally configured policy or based on the information provided by the AF. If security protection to be applied, then the MBSF shall create the multicast session security context by generating the MSK and its key ID for a MBS session. Afterwards, the MBSF distributes the MSK with MBS session ID and its key ID to the MB-SMF and MBSTF. The MBSF shall also distribute them to MB-SMF either upon request by the MB-SMF (i.e., pull) or when a new MSK is generated (i.e., push). The MBSF may also include the MSK lifetime when it distributes the MSK to MBSTF. Upon receiving the MSK from the MBSF, the MBSTF generates the MTK and its key ID for the MBS traffic protection. A new MTK may be generated based on the MBS session security policy. When the MBSTF generates a new MTK, the MBSTF shall multicast the MTK and its key ID after protecting it using the MSK as specified in TS 33.246. The MBSTF shall also provide the new MTK and its key ID to the MBSF. During the MBS session creation for multicast communication as specified in clause 7.1.1 of TS 23.247, after receiving the description for an MBS session from the AF of content provider, the MBSF shall create the multicast session security context by generating an MSK and acquiring an MTK from the MBSTF. Afterwards, the MBSF distributes the muticast session security context to the MB-SMF via the Nmbsmf_MBSSession_Create Request message. In the multicast session join and session establishment procedure, the SMF interacts with the MB-SMF to obtain the multicast session security context. Absence of the multicast security context indicates that security protection is not applied for the MBS session. The SMF shall provide the multicast session security context to the UE if received from the MB-SMF and the UE is authorized to use the required multicast service. The UE shall use the MTK in the received multicast session security context, to process the protected MBS traffic until it receives a new MTK update over the user-plane. The MSK may be updated based on the request from MB-SMF or AS (e.g., due to the change of authorization information) or based on the local policy (e.g., key lifetime expiration). When the MSK is updated, the MBSF shall send the new MSK with MBS session ID and its key ID to the MB-SMF and then the MB-SMF shall trigger the session update as specified in clause 7.2.6 in TS 23.247. The MSK with MBS session ID and the corresponding key ID are delivered to the UEs that has joined the multicast session. The MBSF shall also send the new MSK with MBS session ID and its key ID to the MBSTF. The MBSTF may request a MSK to the MBSF when it does not have a valid MSK (e.g., due to the current MSK expiration). The MTK may be updated based on the change of the authorization information or based on the local policy (e.g. key lifetime expiration). In such cases, the MBSF or MB-SMF may trigger the MTK update to the MBSTF. The key update request message shall include the MBS session ID. If the MBSTF has generated a new MTK, the MBSTF shall provide the new MTK to the MBSF. To improve the efficiency of MTK update, the updated MTK is delivered from MBSTF to the UE using MIKEY over UDP as specified in clause 6.3.3.2 of TS 33.246. The MSK is used to protect the updated MTK. The UE shall not send an error message to the MBSTF as a result of receiving an MTK message.

The UE registers to the MBS service and receives the MBS traffic as specified in TS 33.246 with the following changes.

• MBSTF takes the role of the BM-SC in TS 33.246.
• The UE authenticates to the MBSTF based on the GBA as in MBMS security (see TS 33.246) or based on the AKMA (see TS 33.535). When the AKMA is used, the MRK is derived from the KAF as specified in Annex F of TS 33.246 by replacing the Ks_NAF for the GBA_ME run with KAF. Furthermore, when the AKMA is used, the MUK is set to KAF. When the authorization of MBS service to the UE is required, the user id (e.g. GPSI) provided to the MBSTF by the AAnF shall be used.
• The identifier(s) of MBS user service(s) in TS 26.502 is included in local configuration in MBSTF or in UDM as part of MBS subscription data for a UE, which identifies the user service(s) that the UE is allowed to join. After receiving the HTTP POST message(see clause 6.3.2 of TS 33.246) that] includes the identifier(s) of MBS user service(s), MBSTF shall authorize the UE based on local configuration if available. If no local configuration is available, the MBSTF should send verification request with user id (e.g. IMPI in GBA or GPSI in AKMA) and identifier(s) of MBS user service(s) to UDM via MBSF/NEF to acquire the authorization result. If the UE is authorized, the MBSTF registers the UE to the MBS user service(s).