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 includes it in the request message in order to authenticate itself towards the NF Service Producers.
The DCCF shall verify if the access_token_nwdaf is valid and executes the service. If the NRF does not support authorization of the source NF (e.g. NWDAF) for data access via the DCCF (e.g. if the NRF is Rel-16), the DCCF authorizes the data access of the NF Service Consumer.
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 nfInstanceId IE attribute in the access token request (Nnrf_AccessToken_Get) indicates the NF instance ID of the DCCF as intermediate NF Service Consumer, whereas the sourceNfInstanceId IE attribute indicates the source NF instance ID (NF Service Consumer e.g., NWDAF).
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 18.104.22.168.
The NRF after successful verification then generates and provides an access token to the DCCF as described in the clause 22.214.171.124.2, with NF Instance ID of the DCCF (subject), and an additional access token claim containing the identity ofthe source NF Service Consumer, in order to authorize both DCCF and NF Service Consumer (e.g.. NWDAF) to consume the services of NF Service Producer.
In the case the NRF is from Rel-16 or earlier, the NRF generates an OAuth2.0 access token with "subject" claim mapped to the intermediate NF Service Consumer, i.e., in this case DCCF, and no additional claim for the source NF Service Consumer (e.g., NWDAF) identity is added.
The NF Service Producer(s) authenticates the NF Service Consumer and ensures that the source NF Service Consumer identity is included as an access token additional claim. The NF Service Producer authenticates and authorizes the DCCF following clauses 13.3.2 and 13.4.1. After authentication and authorization is successful, the NF Service Producer(s) executes the service.
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 protection of data and analytics exchange in roaming case including authorization and anonymization of data/analytics:
Authorization at data and analytics level is enforced by the roaming entry NWDAF producer. The parameters used by NWDAF service consumer to request/subscribe to the services provided by NWDAF producer are defined in clause 6.1.5 of TS 23.288. Accordingly, the operator authorization policies can be configured locally in the NWDAF producer. Also, when the NWDAF in one PLMN requests an access token from the NRF in the peer PLMN, the access token request and the access token claims may contain the Analytics ID.
The roaming entry NWDAF producer is responsible to control the amount of exposed data/analytics and to abstract or hide internal network aspects in the exposed data/analytics. The corresponding mechanisms used to restrict the data/analytics and/or anonymization are subject to the implementation.
The roaming entry NWDAFp shall verify the service request, including verifying token and the visited PLMN ID and determine whether the requested analytics are allowed to be exposed to NWDAFc in PLMN1 by pre-configured policies.
The producer NRF has the NF profile of the NF Service Producer including the list of allowed Analytics ID(s) per PLMN. According to clause 5.2.1 of TS 29.510, the NF profile can be configured in the NRF by other means such as O&M.
The home network hNRF shall verify the access token get request as specified 13.4.1, and determine whether the requested analytics implied by the Analytics ID(s) can be obtained by the visited PLMN according to the allowed analytics ID(s) of the visited PLMN.
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.
The NWDAF containing MTLF acting as FL client registers to the NRF with its FL related information, including supported FL capability (FL client), Analytics ID(s) and Interoperability Indicator per Analytics ID as described in clause 5.2 of TS 23.288.
Step 1b. The NWDAF containing MTLF acting as FL server registers to the NRF with its FL capability (FL Server).
The NWDAF containing MTLF acting as FL server (NF Service Consumer) sends a discovery request to NRF and receives the available NWDAFs containing MTLF acting as FL client(s) (NF Service Producer) as a response, as specified in clause 6.2C.2.1 of TS 23.288.
The NWDAF containing MTLF acting as FL server (NF Service Consumer) sends an access token request to the NRF as specified in clause 13.4.1. The access token request may contain the Analytics ID for the requested Federated Learning process.
The NRF authorizes the NWDAF containing MTLF acting as FL server (NF Consumer) based upon the information received in Step 1b, and after verifying that the Server NWDAF's Vendor ID is included in the Interoperability Indicator for the requested Analytics ID provided in Step 1a. If the authorization succeeds, NRF generates the access token(s) as specified in clause 13.4.1. The access token claims may include the Analytics ID for the request Federated Learning process.
The NWDAF containing MTLF acting as FL server sends the service request to the NWDAF(s) containing MTLF acting as FL client with the access token received in Step 5a. along with the Analytics ID information for which the FL process is to be performed, as described in TS 23.288.
The NWDAF containing MTLF acting as FL client (NF Service Producer) verifies the received access token as specified in clause 13.4.1. In case of successful access token verification, the NWDAF containing MTLF acting as FL client sends a success response to the NWDAF containing MTLF acting as FL server, as described in TS 23.288.
NF Service producer i.e. NWDAF containing MTLF registers its NF profile in the NRF with ML Model Interoperability indicator per Analytics ID as described in clause 5.2 of TS 23.288. The ML Model Interoperability indicator is a list of NWDAF providers (vendors) that are allowed to retrieve ML models from this NWDAF containing MTLF.
The model is stored in encrypted format unless both the AI/ML model producer (NWDAF MTLF) and storage platform (ADRF) are part of the same system and belong to the same vendor and operator security domain.
Storage of the model in encrypted format can be required by the trust model established to store and share AI/ML models. The trust model between AI/ML NF producer (NWDAF MTLF), storage platform (ADRF) and NF consumer (e.g., AnLF) is to be determined during the implementation phase among operator and the providers of the different platforms (MTLF, AnLF, ADRF). How the model is encrypted is vendor specific. Key distribution is not specified in this document.
If NWDAF containing MTLF determines to store ML model in ADRF, NWDAF containing MTLF triggers the Nadrf_MLModelManagement_StorageRequest as described in TS 23.288, optionally including an allowed NFc list. The absence of allowed NFc list indicates that only the MTLF which stored the model is allowed to retrieve the model.
NF Service consumer e.g., NWDAF containing AnLF requests an access token from the NRF using the Nnrf_AccessToken_Get request operation. The token request message contains, besides the parameters described in clause 126.96.36.199.2, the Vendor ID of NWDAF containing AnLF and the Analytics ID.
NRF checks whether the NWDAF containing AnLF is authorized to access the requested service in NWDAF containing MTLF and verifies that the NF Consumer's Vendor ID is included in the NWADF containing MTLF 's interoperability indicator for the Analytics ID and grants the token (token1), based on the vendor ID provided by the NF consumer during registration.
The NWDAF containing MTLF authenticates the NF Service Consumer and verifies the access token as specified in the clause 188.8.131.52.2 and ensures that the Analytics ID is included in the access token. If verification is successful, NWDAF containing MTLF determines the ML model to be shared for the requested Analytics ID and stored the NF instance ID of NWDAF containing AnLF as part of allowed NF instance list for the ML model.
If the determined ML model is stored in ADRF, and if the NF Service Consumer is not yet in the allowed NFc list stored at the ADRF, the NWDAF containing MTLF triggers the update of Nadrf_MLModelManagement_StorageRequest at the ADRF, with NF ID of NWDAF containing MTLF and Model ID, adding the NF Service Consumer to the allowed NFc list. The ADRF verifies that the requesting NWDAF containing MTLF is same as the one that stored the model. Then, ADRF stores the allowed NF instance list for the ML model referenced by the Model ID.
NWDAF containing MTLF sends Nnwdaf_MLModelProvision Notify to the NF Service Consumer with Model ID, the address of the determined ML model, which can be either the one stored in NWDAF containing MTLF or in ADRF,or ADRF(set) ID. If the address of the determined ML model is provided, steps 8a to 10 are skipped.
If the ADRF(set) ID is provided, the following steps are applied:
NRF verifies that the NF Service consumer e.g., NWDAF containing AnLF is authorized to access the service provided by the ADRF. If verification is successful, NRF grants the token (token2), based on the information provided in ADRF's NF profile.
ADRF authenticates the NF Service Consumer and verifies the access token (token2) as specified in the clause 184.108.40.206.2. ADRF verifies also the NF Service Consumer's NF ID is included in the allowed NF instance list for the ML model and/or is same as the NF ID of the MTLF that stored the model. If verification is successful, ADRF sends Nadrf_MLModelManagement_Retrieval Response to the NF Service Consumer, which contains the address of the stored model in ADRF.