This Annex provides security requirements and procedures for the Network Automation features. The feature for enablers for Network Automation by 5GS is described in 3GPP TS23.501[2] and 3GPP TS23.288 [105].

The detailed procedure for NF Service Consumer to receive data from Service Producers via DCCF is depicted in Figure X.2-1:

The detailed procedure for NF Service Consumer to receive data from Service Producers via DCCF when notification is sent via MFAF is depicted in Figure X.3-1:

Steps 1-9 are same as Steps 1 - 9 of Annex X.2. Steps 13 - 14 are same as Steps 10 - 11 of Annex X.2

The transfer of the data between the data source and data consumer via the messaging framework shall be confidentiality, integrity, and replay protected. Confidentiality protection, integrity protection, and replay-protection shall be supported on the new interfaces between 3GPP entities and MFAF by reusing the existing security mechanism defined for SBA in Clause 13.

As specified in TS 23.288, the NWDAF may interact with an AF to collect data from UE Application(s) as an input for analytics generation. The AF can be in the MNO domain or an AF external to MNO domain. To enhance the 5GS to support collection and utilisation of UE related data for providing the inputs to generate analytics information (to be consumed by other NFs), the communication between AF and NWDAF needs to be secured. The NWDAF interacts with the 5GC NFs and the AF using Service-based Interfaces. The existing 5G security mechanism can be reused for the transfer of UE data over the SBA interface between AF and NWDAF. When the AF is located in the operator's network, the NWDAF uses Service-Based Interface as depicted in clause 13 to communicate with the AF directly. When the AF is located outside the operator's network, the NEF is used to exchange the messages between the AF and the NWDAF. The security aspects of NEF is specified in clause 12.

According to clause 13.1.0, all network functions shall support mutually authenticated TLS and HTTPS. TLS shall be used for transport protection within a PLMN unless network security is provided by other means. Thus, communication between NFs is integrity, confidentiality and replay protected. NFs shall obtain an access token from NRF for requesting analytics from an analytics function or providing analytics data to the analytics function.

The user consent requirements for enablers of network automation shall comply with Annex V of the present document and TS 23.288. For scenarios where local regulations permit, for example vPLMN and hPLMN subject to the same regulatory requirements, the NWDAF shall be deemed to be the enforcement point and shall be subject to the requirement specified in Annex V.

The authorization for selecting participant NWDAF instances in the Federated Learning (FL) group uses token-based authorization as specified in clause 13.4.1, with the following additions. Figure X.9-1 depicts the authorization mechanism for NWDAF containing MTLF acting as FL Server to initiate the Federated Learning process on the NWDAF containing MTLF(s) acting as FL Client(s). The authorization is based upon the FL capability type (FL server or FL client) provided by the NWDAF containing MTLF acting as FL server during registration, and the Analytics ID and Interoperability Indicator per Analytics ID provided by the NWDAF containing MTLF acting as FL client during registration.

Authorization of the NWDAF containing MTLF acting as FL client is implicit, since it can join a Federated Learning group only when selected by the NWDAF containing MTLF acting as FL server.

The detailed procedure for secured and authorized AI/ML model sharing between different vendors is depicted in Figure X.10-1: