TR 33.926 [ 4], clause 5.3.6.7, Personal Identification Information Violation

Data masking on integration analysis about personal data

TBA.

NWDAF can collect data from UE, NF, OAM, etc. used for analytics. Personal data of the UE's user are involved also. When NWDAF uses such personal data in analytics with other information together, such data correlation operation could bind more personal information with the user's identity. Thus, privacy sensitive information about that specific user could be revealed to the person who is allowed to operate data correlation for analytics but not allowed to know the privacy information as the result of data correlation. Therefore, applicable measures (e.g. data masking) shall be applied to mitigate such privacy violation risk.

Verify that no privacy information of operators' users is revealed to the party who is not allowed to have.

The vendor shall provide the documentation describing how to create an account for accessing the analytics results.

Privacy information list (should be specified based on local policy, regulation and others).

1. Review the documentation provided by the vendor describing how to create the account for accessing the analytics results provided by the NWDAF.

2. The tester creates the account, and retrieves the analytics results from the NWDAF using the account.

TR 33.926 [ 4], clause 5.3.6.7, Personal Identification Information Violation

Data masking on integration analysis about personal data

1. Tester triggers behaviour so that the 'data producer' is required to handle privacy information (e.g. for AMF trigger registration request at UE).

2. The tester sends an Nnwdaf_AnalyticsInfo_Request request message from the 'analytics consumer' to NWDAF according to TS 29.552 [6], clause 5.2.3.1. The request message shall be crafted to capture information from step 1.

3. The tester retrieves the Nnwdaf_AnalyticsInfo_Request response message from the NWDAF.

TR 33.926 [4], threats related to "Privilege Escalation" and "Unauthorized Service Access".

Fine-grained authorization for analytics services

In accordance with TS 33.501 [7], clauses X.8, X.9, and X.12.

The NF Service Producer authenticates the NF Service Consumer and verifies the access token and ensures that the Analytics ID is included in the access token.

To verify that the NWDAF, when acting as an NF service producer, can perform fine-grained authorization control based on the Analytics ID claim in an access token within procedures such as Nnwdaf_RoamingAnalytics_Subscribe/Request. The test ensures that a service consumer is only able to access the specific analytics type(s) it is authorized for.

NOTE: This test case applies only when the access token includes Analytics ID.

• The NWDAF under test is configured to support at least two distinct analytics services, Analytics ID 1 and Analytics ID 2.

• The tester has the capability to generate valid OAuth 2.0 access tokens. Two valid OAuth 2.0 access tokens are pre-configured and prepared for testing:

• Token_A: Contains Analytics ID 1 in its claims.

• Token_B: Contains Analytics ID 2 in its claims.

• The vendor's product documentation describes the NWDAF's authorization policies and the APIs for the analytics services.

• The NWDAF under test has already authenticated the NF service consumer (simulated by the tester).

1. The tester sends an Nnwdaf_RoamingAnalytics_Subscribe/Request message to the NWDAF for Analytics ID 1, including Token_A in the request. The tester observes and records the NWDAF's response.

2. The tester sends an Nnwdaf_RoamingAnalytics_Subscribe/Request message to the NWDAF for Analytics ID 2, including Token_A in the request. The tester observes and records the NWDAF's response.

3. The tester repeats step 1, but uses Token_B for the request to Analytics ID 1.

4. The tester repeats step 2, but uses Token_B for the request to Analytics ID 2.

1. The request in Step 1 (authorized Analytics ID) is processed successfully by the NWDAF (subject to other normal conditions being met).

2. The request in Step 2 (unauthorized Analytics ID) is rejected by the NWDAF with an appropriate error (e.g., 403 Forbidden with OAuth 2.0 error insufficient_scope).

3. The request in Step 3 (unauthorized Analytics ID for Token_B) is rejected by the NWDAF with an appropriate error.

4. The request in Step 4 (authorized Analytics ID for Token_B) is processed successfully by the NWDAF.

Logs, network traces (e.g., .pcap files), or screenshots of the relevant interface messages. The evidence must clearly show:

1. The Nnwdaf_RoamingAnalytics_Subscribe/Request request messages, including the target Analytics ID and the access token used (Token A or Token B).

2. The corresponding success or error response (including status code and error details) from the NWDAF.

TR 33.926 [4], threats related to "Unauthorized Access to Critical Assets" and "Model Poisoning".

Analytics ID-level access control for ML model assets in MTLF provisioning

In accordance with TS 33.501 [7], clauses X.9 and X.10.

The NWDAF containing the MTLF verifies that the Analytics ID contained within the access token's scope matches the Analytics ID associated with the requested ML model asset.

To verify that the NWDAF, when acting as an MTLF (NF service producer), can perform fine-grained authorization control based on the Analytics ID claim in an access token within the Nnwdaf_MLModelProvision_Subscribe procedure. The test ensures that a service consumer is only able to access the specific ML model asset(s) it is authorized for.

NOTE: This test case applies only when the access token includes Analytics ID.

• The vendor's product documentation describes the ML model provisioning procedure and the associated authorization mechanism for the Nnwdaf_MLModelProvision_Subscribe service operation.

• A test environment with at least one NWDAF containing an MTLF and one NWDAF containing an AnLF (or an equivalent simulation provided by the vendor) shall be available.

• The MTLF under test is configured with at least two distinct ML model assets, identifiable by different Analytics IDs (e.g., Analytics ID 1 and Analytics ID 2).

• The tester has the capability to generate valid OAuth 2.0 access tokens. Two valid OAuth 2.0 access tokens are pre-configured and prepared for testing:

• Token_A: Contains Analytics ID 1 in its claims.

• Token_B: Contains Analytics ID 2 in its claims.

1. The tester sends an Nnwdaf_MLModelProvision_Subscribe request to the MTLF for the ML model corresponding to Analytics ID 1, including Token A in the request. The tester observes and records the MTLF's response.

2. The tester sends an Nnwdaf_MLModelProvision_Subscribe request to the MTLF for the ML model corresponding to Analytics ID 2, including Token A in the request. The tester observes and records the MTLF's response.

3. The tester repeats step 1, but uses Token_B for the request to Analytics ID 1.

4. The tester repeats step 2, but uses Token_B for the request to Analytics ID 2.

1. The request in Step 1 (authorized Analytics ID for Token A) is accepted by the MTLF, and ML model information for Analytics ID 1 is returned normally.

2. The request in Step 2 (unauthorized Analytics ID for Token A) is rejected by the MTLF with an appropriate error (e.g., 403 Forbidden with OAuth 2.0 error insufficient_scope).

3. The request in Step 3 (unauthorized Analytics ID for Token B) is rejected by the MTLF with an appropriate error.

4. The request in Step 4 (authorized Analytics ID for Token B) is accepted by the MTLF, and ML model information for Analytics ID 2 is returned normally.

Logs, network traces (e.g., .pcap files), or screenshots of the relevant interface messages. The evidence must clearly show:

1. The Nnwdaf_MLModelProvision_Subscribe request messages, including the target Analytics ID and the access token used (Token A or Token B).

2. The corresponding success or error response (including status code and error details) from the MTLF for each of the four execution steps.

TS 33.926 [4], [clause X.Y]{.mark}.

Finding the right NF instance are serving the UE

TS 23.288 [2], clause 6.2.2.1.

To retrieve data related to a specific UE, the NWDAF shall first determine which NF instances are serving this UE as stated in table 4.2.2.1-2 unless the NWDAF has already obtained this information due to recent operations related to this UE.

Table 4.2.2.1-2: NF Services consumed by NWDAF to determine which NF instances are serving a UE

----------------------------------------------------------------------------------------------------------------------------------------------- Type of NF instance (serving the UE) to determine NF to be contacted by NWDAF Service Reference in TS 23.502 [3] ------------------------------------------------------- --------------------------------- ------------------ ---------------------------------- UDM NRF Nnrf_NFDiscovery 5.2.7.3

AMF UDM Nudm_UECM 5.2.3.2

SMF UDM Nudm_UECM 5.2.3.2

BSF NRF Nnrf_NFDiscovery 5.2.7.3

PCF BSF Nbsf_Management 5.2.13.2

NEF NRF Nnrf_NFDiscovery 5.2.7.3 -----------------------------------------------------------------------------------------------------------------------------------------------

"as specified in TS 23.288 [2], clause 6.2.2.1.

Verify that the NWDAF always find a recent NF from operations related to the UE.

Editor's Note: Purpose of test to be clarified.

Test environment with UE, source AMF, and target AMF and UDM. UE, source AMF, target AMF and UDM may be simulated.

The UE is registrated on the source AMF and the UDM, and the NWDAF subscribes analytics A which needs to collect the UE's information on the source AMF.