Section: Annex X (normative): Security aspects of enablers for Network Automation (eNA) for the 5G system (5GS) X.1 General
Content: 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[ Architecture enhancements for 5G System (5GS) to support network data analytics services ]  [105]. X.2 Authorization of NF Service Consumers for data access via DCCF The detailed procedure for NF Service Consumer to receive data from Service Producers via DCCF is depicted in Figure X.2-1: Figure X.2-1: NF Service Consumer Authorization to receive data from NF Service Producers via DCCF 1-3. 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. 4. 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. NOTE 0: The procedure of NF Service Consumer (e.g. NWDAF) requesting the services provided by NF Service Producer via DCCF is defined in Clause 6.2.6.3 of TS 23.288[ Architecture enhancements for 5G System (5GS) to support network data analytics services ]  [105]. 5. 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. 6. The DCCF determines the NF Service Producer(s) from where the data is to be collected (as specified in Clause 6.2.6.3.2 in TS 23.288[ Architecture enhancements for 5G System (5GS) to support network data analytics services ] [105]). NOTE 1: If the NF Service Consumer sends the NF Service Producer information (i.e. NF Service Producer type and Instance ID) along with the service request in Step 4, then DCCF does not determine the NF Service Producer, but requests an access token from the NRF using the NF Service Producer details sent by the NF Service Consumer (as described in Step 7). 7. 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). NOTE 1a: Void 8. 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 13.3.1.2. NOTE 2: A Rel-16 NRF only authenticates and authorizes the DCCF, i.e., after the NRF receives Nnrf_AccessToken_Get request, the NRF validates whether the intermediate NF Service Consumer (e.g., DCCF) is authorized to receive the requested service from the NF Service Producer. The NRF from Rel-16 or earlier does not validate whether the source NF Service Consumer (e.g., NWDAF) is authorized to receive the requested service. NOTE 3: Void 9. The NRF after successful verification then generates and provides an access token to the DCCF as described in the clause 13.4.1.1.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. NOTE 4: 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. 10. The DCCF requests service from the NF Service Producer. The request also contains the content of the CCA_NWDAF, so that the NF Service Producer(s) authenticates the NF Service Consumer (e.g. NWDAF) , i.e.,the NF Service Producer shall check the subject claim of CCA_NWDAF with the access token claim conveying the source NF Instance ID, when this claim is present in the access token. Editor's note: The additional information about the NF Service Consumer (source NF, e.g., NWDAF) conveyed in the CCCCCA_NWDAF, and the way to be conveyed (e.g., in a new header) is to be specified in stage 3 (TS 29.510[ 5G System; Network function repository services; Stage 3 ] ). 11. 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. NOTE 5: Rel-16 NF Service Producer only authenticates and authorizes the DCCF. 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). NOTE 6: In the case a new NF Service Consumer comes at a later stage to request the data, which is already being collected by DCCF, steps 1-10 apply. When the request is received by the NF Service Producer (i.e. the data producer), it authenticates the NF Service Consumer and verifies the access token provided along with the service request and sends to DCCF the access token verification response. DCCF based upon the response received, either updates the subscription info to include the new NF Service Consumer as well and sends the data to both the consumers (as specified in Clause 6.2.6.3.2 in TS 23.288[ Architecture enhancements for 5G System (5GS) to support network data analytics services ]  [105]), or in the case of access token verification failure, the DCCF rejects the request received by the NF Service Consumer. NOTE 7: Void X.3 Authorization of NF Service Consumers for data access via DCCF when notification sent via MFAF 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: Figure X.3-1: Service Consumer Authorization to receive data from Service Producers via MFAF Steps 1-9 are same as Steps 1 – 9 of Annex X.2. 10-11. The DCCF sends an access token request to the NRF to request service from MFAF. NRF after verifying sends access_token_dccf to DCCF to consume the services of MFAF. 12. DCCF shall then send the Nmfaf_3daDataManagement_Configure request to MFAF (as specified in the Clause 6.2.6.3.2 in TS 23.288[ Architecture enhancements for 5G System (5GS) to support network data analytics services ] [105]) along with the access_token_dccf. Steps 13 – 14 are same as Steps 10 – 11 of Annex X.2 15. The NF Service Producer(s) shall provide requested data to the MFAF. 16. The MFAF forwards the received data to the data consumer(s). NOTE 1: In the case a new data consumer comes at a later stage to request the data, which is already being collected by DCCF, steps 1-9 and 13 apply. When the request is received by the NF Service Producer (i.e. the data producer), it authenticates the NF Service Consumer and verifies the access token provided along with the service request and sends to DCCF the access token verification response. DCCF based upon the response received, either updates the subscription info at the MFAF to include the new data consumer as well and MFAF sends the data to both the consumers (as specified in Clause 6.2.6.3.2 in TS 23.288[ Architecture enhancements for 5G System (5GS) to support network data analytics services ]  [105]), or in the case of access token verification failure, the DCCF rejects the request received by the data consumer and does not update the subscription at the MFAF. NOTE 2: Void X.4 Security protection of data via messaging framework 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. X.5 Protection of data transferred between AF and NWDAF As specified in TS 23.288[ Architecture enhancements for 5G System (5GS) to support network data analytics services ] [105], 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. X.6 Protection of UE data in transit between NFs 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.