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 and 3GPP TS23.288 .
NF Service Consumer shall send a request to the NRF to receive an access token to request services of DCCF, to be used for data collection request. NRF after verifying shall generate access token and sends it to the NF Service Consumer.
The NF Service Consumer initiates a NF service request to the DCCF which includes the access_token_nwdaf. The NF Service Consumer shall also generate a Client Credentials Assertion (CCA) token (CCA_NWDAF) as described in the clause 13.3.8 and include it in the request message in order to authenticate itself towards the NF Service Producers.
The DCCF sends a Nnrf_AccessToken_Get request to NRF including the information to identify the target NF (NF Service Producer), the source NF (NF Service Consumer e.g. NWDAF), the NF Instance ID of DCCF and the CCA_NWDAF provided by the NF Service Consumer.
The NRF shall check whether the DCCF and the NF Service Consumer (e.g. NWDAF) are allowed to access the service provided by the identified NF Service Producers , and the DCCF as the proxy is allowed to request the service from the identified NF Service Producers on behalf the NF Service Consumer. NRF authenticates both DCCF and NWDAF based on one of the SBA methods described in clause 184.108.40.206. DCCF may include an additional CCA for authentication.
The NRF after successful verification then generates and provides an access token to the DCCF as described in the clause 220.127.116.11.2, with NF Service Consumer Instance (subject), and an additional access token claim containing the identity of DCCF, in order to authorize both NF Service Consumer (e.g. NWDAF) and DCCF to consume the services of NF Service Producer.
The NF Service Producer(s) authenticate the NF Service Consumer and verify the access token as specified in the Clause 18.104.22.168.2 and ensures that the DCCF identity is included as an access token additional claim. If the DCCF identity is not included in the access token additional claims, e.g., NRF is Release 16 or prior, the NF Service Producer shall authorize the DCCF locally. After authentication and authorization is successful, the NF Service Producer(s) assure that the DCCF as the proxy is allowed to receive the response message on behalf the NF Service Consumer, and execute the service after successful verification. DCCF may include an additional CCA for authentication.
12. The NF Service Producer(s) shall provide requested data to the DCCF.
13. The DCCF forwards the received data to the NF Service Consumer(s).
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.