Content for TS 33.501 Word version: 17.4.2

1… 4… 5… 6… 6.1.3… 6.1.4 6.2… 6.2.2… 6.3… 6.5… 6.7… 6.8… 6.9… 6.10… 6.12… 6.14 6.15 6.16 7… 7A… 7A.2.3… 7B… 8… 9… 10… 11… 13… 13.2.2… 13.2.4 13.3… 13.4… 14… 15… A… B… C… D… G… I… J… K… O… P… S… U… X… Y…

U.1 Introduction U.2 Procedure V.1 General V.2 Requirements V.3 User consent check V.4 User consent revocation W.1 General W.2 Security requirements W.3 Security mechanisms for xMB-C/MB2-C and xMB-U/MB2-U interface W.4 Security mechanisms for MBS traffic transmission W.5 Security protection for interworking between 5MBS and eMBMS
...

U Primary authentication using EAP-TTLS in SNPNs |R17| Word‑p. 263

U.1 Introduction Word‑p. 263

In SNPN, when a credential holder is located outside of the 5GC of the SNPN, EAP-TTLS can be used to authenticate the UE. EAP-TTLS consists of two phases of authentication. In the first phase, a TLS tunnel is established between the UE and the EAP-TTLS server on AUSF. In the second phase, a legacy authentication protocol can be run between the UE and the credential holder (namely AAA) through the established TLS tunnel.

After the successful completion of EAP-TTLS, the AUSF and the UE derive the KAUSF from the EMSK.

UE is provisioned with a trust anchor to enable verification of the EAP-TTLS server certificate. The provisioning of trust anchor on the UE is outside the scope of this document.

U.2 Procedure Word‑p. 263

Reproduction of 3GPP TS 33.501, Fig. U.2-1: Primary authentication using EAP-TTLS and AAA

Figure U.2-1: Primary authentication using EAP-TTLS and AAA

Step 0.

The UE is configured with the trust anchor needed to authenticate the certificate of the EAP-TTLS server running on the AUSF. Further, the UE is configured with the credentials required to authenticate with the AAA server.

Steps 1-17 are same as the steps 1-17 in clause B.2.1.1 in Annex B, except in the following steps:

Step 1.

The SUPI in the NAI format, i.e., username@realm, is used.

Step 5.

EAP-TTLS is selected by the UDM as the authentication method.

Step 6-17.

EAP-TTLS phase 1 is executed between the AUSF and the UE. EAP-Type is set to EAP-TTLS and the authentication of the UE using TLS client certificate is skipped. Since TLS client certificate is not used in EAP-TTLS, the UE need not be configured with UE certificate.

Step 18-27.

After EAP-TTLS phase 1 is successfully completed, the UE runs EAP-TTLS phase 2 authentication with the AAA as specified in RFC 5281 via NSSAAF. The phase 2 authentication method used is outside the scope of the present document but MS-CHAPv2 is depicted here as an example to show that the Nnssaaf_AIW_Authentication service offered by NSSAAF carries AVPs if the phase 2 authentication method is non-EAP.NOTE: As referenced in Section 14.1.11 of RFC 5281, allowing the use of phase 2 (inner) authentication method outside of tunnelled protocol leads to Man-in-the-Middle (MitM) vulnerability. Thus, it is assumed that the UE does not allow the use of phase 2 authentication method outside of TLS tunnel (i.e., the UE does not respond to requests for phase 2 authentication outside of the TLS tunnel). In environments where the use of phase 2 authentication outside of the tunnelled protocol cannot be prevented, EAP-TTLS implementations need to address this vulnerability by using EAP channel binding or cryptographic binding described in RFC 6678.

Step 28-31.

After EAP-TTLS phase 2 authentication is successfully completed, the rest of the procedures are same as steps 18-21 described in clause B.2.1.1, except that the EAP-Type is set to EAP-TTLS in the EAP Response message from the UE to the AUSF.

V (Normative) User consent requirements and mechanisms |R17| Word‑p. 265

V.1 General Word‑p. 265

V.1.1 Scope Word‑p. 265

User consent can be required for 3GPP features depending on local regulations. Therefore, this Annex describes the generic security requirements and procedures to support user consent enforcement in 3GPP services. While the use cases can differ, the Annex focuses on the common and generic aspects related to the storage, checking and revocation of the user consent.

The user consent related requirements and mechanism in the present document are applicable only when it is required by regional regulations or operator's local policy, not otherwise.

The term data processing in this Annex is used to convey the same meaning as in [101].

V.1.2 Relationship between end-users and subscriber Word‑p. 265

It is assumed that the user consent is obtained from the end-users. The end-user(s) is the subscriber itself or authorize the subscriber to provide consent on behalf of the end-users. Alternatively, the end-users are authorized by the subscriber to provide the consent. That means user consent is always tied to the subscription information. How authorization is provided between the subscriber and the end-users is out-of-scope of this specification.

V.2 Requirements Word‑p. 265

The UDM shall support the following services related to the user consent.

Retrieval of user consent parameters.
Notification of user consent parameters change.

The user consent parameters shall be stored in the UDM/UDR as subscription data.

The user consent parameters shall be bound to a SUPI/GPSI.

The user consent parameters shall be bound to the purpose of data processing.

The user consent parameters shall include whether the user consent is granted or not.

The user consent parameters shall be effective only after the point in time that user consent was given, and they shall be effective until they are revoked.

The user consent parameters shall be effective until revoked. It means that there is no expiry/validity timer for the user consent parameters.

V.3 User consent check Word‑p. 265

Any NF that is deemed an enforcement point for user consent shall support to retrieve the user consent parameters from the UDM.

Any NF that is deemed an enforcement point for user consent shall not accept any services or requests for data processing unless user consent is granted.

NFs obtaining or checking the user consent parameters shall consider the user consent parameters as effective until revoked when obtaining or checking the user consent parameters.

V.4 User consent revocation Word‑p. 266

Any NF that is deemed an enforcement point for user consent shall support subscription to the user consent parameter change notification provided by the UDM.

Following a notification event, any NF that is deemed an enforcement point for user consent shall no longer accept any service request for data processing subject to a revoked user consent.

Following a notification event, any NF that is deemed an enforcement point for user consent may notify other NFs to halt the processing of the data subject to the revoked user consent.

Upon notification of consent revocation, NFs (possessing the data pertaining to the revoked consent) shall halt processing and collection of the data.

Upon notification of consent revocation, the data may have to be deleted, or quarantined, or temporarily retained.

W (Normative) Security for multicast/broadcast service for 3GPP service |R17| Word‑p. 267

W.1 General Word‑p. 267

This clause describes the security requirements, procedures and handling for 5G Multicast/Broadcast Service (MBS).The general features for 5G MBS are described in TS 23.247.

NOTE: Security for Multicast-broadcast service for roaming is not supported.

W.2 Security requirements Word‑p. 267

W.2.1 Requirements of MBSF Word‑p. 267

The security requirements on the NEF described in clause 5.9.2.3 of present document also apply to MBSF.

W.2.2 Requirements of MBSTF Word‑p. 267

The security requirements on the NEF described in clause 5.9.2.3 of present document also apply to MBSTF.

W.3 Security mechanisms for xMB-C/MB2-C and xMB-U/MB2-U interface Word‑p. 267

The security aspects defined in clause 12 in present document is applicable for both MBSF and MBSTF. TLS based solution are reused to protect the interface xMB-C/MB2-C and xMB-U/MB2-U between AF and 5GC in MBS.

W.4 Security mechanisms for MBS traffic transmission Word‑p. 267

W.4.1 Key derivation, management and distribution Word‑p. 267

W.4.1.1 General Word‑p. 267

For security protection of MBS traffic, control-plane procedure and user-plane procedure are optionally supported in service layer. The multicast security policy between UE and RAN shall be not needed to avoid redundant protection.

W.4.1.2 Control-plane procedure Word‑p. 267

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 MSK ID and MTK ID are determined as specified in Clause 6.3.2.1 and clause 6.3.3.1 of TS 33.246.

The MBSF generates the MSK and its key ID for a MBS session and distributes the MSK to the MB-SMF and MBSTF. The MBSF shall 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.

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 after protecting it using the MSK as specified in TS 33.246. The MBSTF shall also provide the new MTK to the MBSF.

In the multicast session join and session establishment procedure, the SMF interacts with the MB-SMF to retrieve the multicast session security context. The SMF shall provide the multicast session security context to the UE if the UE is authorized to use the required multicast service. The UE uses the received MTK 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 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 and the corresponding key ID are delivered to the UEs that has joined the multicast session. The MBSF shall also send the new MSK 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 MBSFT. The key update request message shall include the MBS session ID. If the MBSFT has generated a new MTK, the MBSFT 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.

W.4.1.3 User-plane procedure Word‑p. 268

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.

W.4.2 Protection of the traffic transmission Word‑p. 268

The actual method of protection may vary depending on the type of data being transmitted, e.g. media streaming application or file download. Clause 6.6.2 and clause 6.6.3 of TS 33.246 apply to the protection of streaming data and protection of download data, respectively.

W.4.3 Authentication and authorization aspects for the multicast session Word‑p. 268

The support for the optional-to-use authentication and authorization procedure for a 5G multicast session is specified in this clause.

AKMA/GBA is supported for authentication and authorization in user-plane procedure for security protection of MBS traffic, as specified in clause W.4.1.2 of present document.

W.5 Security protection for interworking between 5MBS and eMBMS Word‑p. 269

Interworking between 5G MBS and eMBMS is supported at service layer. The procedures for inter system mobility with interworking at service layer is specified in clause 7.4 in TS 23.247.

The joint BM-SC+MBSF/MBSTF functionality provides the security protection for MBS traffic. During inter-system mobility, when the target system is EPS, the security protection specified in TS 33.246 applies. The security protection specified in present document applies to the case when the target system is 5GS.