TR 33.926 [4], clause E.2.2.1, Incorrect SUCI de-concealment.

De-concealment of SUPI from the SUCI based on the protection scheme used to generate the SUCI.

TS 33.501 [2], clause 5.8.2.

The SIDF resolves the SUPI from the SUCI based on the protection scheme used to generate the SUCI as specified in TS 33.501 [2], clause 5.8.2.

Verify that the SIDF De-conceals the SUPI from the SUCI based on the protection scheme used to generate the SUCI.

• UDM network product is connected in simulated/real network environment including an AUSF and AMF.

• Tester shall have access to the subscription data stored in UDR.

• Tester shall record the SUPI from the UE.

• Tester shall provision subscription data in the UDR and for the UE with the following protection schemes (see TS 33.501 [2], clause Annex C):

• Null-scheme (mandatory to support).

• Profile A (mandatory to support).

• Profile B (mandatory to support).

• any other implemented protection scheme as stated in the vendor documentation.

Tester shall capture the procedure between UDM and AUSF over N13 interface, AMF and AUSF over N12 interface using any network analyser.

For every implemented protection scheme the tester repeats the following steps:

1. Tester shall filter the Nudm_UEAuthentication_Get Response message sent from UDM to AUSF over N13 interface containing the SUPI.

2. Tester shall compare the SUPI gotten from UE and the SUPI retrieved from Nudm_UEAuthentication_Get Response message.

NOTE: The tester may filter the Nausf_UEAutentication_Authenticate Response message sent from the UDM/AUSF to the AMF over N12 interface containing the SUPI, if the UDM and AUSF network products are collocated without an open N13 interface.

SIDF resolves the SUPI from the SUCI based on the protection scheme used to generate the SUCI.

Evidence suitable for the interface, e.g., evidence can be presented in the form of screenshot/screen-capture.

TR 33.926 [4], clause E.2.2.1, Incorrect SUCI de-concealment.

De-concealment of SUPI from the SUCI based on the protection scheme used to generate the SUCI.

TS 33.501 [2], clause 5.8.2.

The SIDF resolves the SUPI from the SUCI based on the protection scheme used to generate the SUCI as specified in TS 33.501 [2], clause 5.8.2.

Verify that the SIDF De-conceals the SUPI from the SUCI based on the protection scheme used to generate the SUCI.

• UDM network product is connected in simulated/real network environment including an AUSF and AMF.

• Tester shall have access to the subscription data stored in UDR.

• Tester shall record the SUPI from the UE.

Tester shall provision subscription data in the UDR and for the UE with the following protection schemes (see TS 33.501 [2], clause Annex C):

Null-scheme (mandatory to support).

Profile A (mandatory to support).

Profile B (mandatory to support).

any other implemented protection scheme as stated in the vendor documentation.

1. Tester shall filter the Nudm_UEAuthentication_Get Response message sent from UDM to AUSF over N13 interface containing the SUPI.

2. Tester shall compare the SUPI gotten from UE and the SUPI retrieved from Nudm_UEAuthentication_Get Response message.

NOTE: The tester may filter the Nausf_UEAutentication_Authenticate Response message sent from the UDM/AUSF to the AMF over N12 interface containing the SUPI, if the UDM and AUSF network products are collocated without an open N13 interface.

SIDF resolves the SUPI from the SUCI based on the protection scheme used to generate the SUCI.

Evidence suitable for the interface, e.g., evidence can be presented in the form of screenshot/screen-capture.

TR 33.926 [4], clause E.2.2.6, Invalid public key.

Rejection of SUCIs using an ECIES protection scheme with an invalid public key.

TS 33.501 [2], clause C.3.3 with reference to SECG SEC 1 [8] clause 2.3.4.

Output: An elliptic curve point P, or "invalid" as specified [8], clause 2.3.4.

Verify that the SIDF rejects the SUCI if it uses an ECIES protection scheme and contains an invalid point as the UE's public key for Profile B.

• The tester has access to the public information of the SUCI profile (e.g., profile type, public key ...) of the UDM/SIDF under test.

• The tester has configured the UDM to use Profile B.

• The tester has access to a SUPI of provisioned subscriber.

1. The tester selects an invalid point (> > NOTE 1) and uses the point as a public key to encrypt the SUPI based on the encryption defined in Annex C of 33.501 [2] and SECG SEC 1 [8] (> > NOTE 2).

2. The tester sends the SUCI to the Nudm_UEAuthentication_Get service of the UDM/ SIDF under test.

NOTE 1: An example invalid point for Profile B (of order 47) is: 0x049af0190d4e237.462c94.447052.770f6d34.866f1dbbe29a0ee889.18835d6a97.457a67.0323716ef2c8a37.3793be64b54cec40eb86ab19.057c95baf8cfe.

NOTE 2: An example SUCI encrypted with the invalid point (above) for the MCC\|MNC (27.012) and MSIN (00.002086) for Profile B (Annex C of 33.501 [2]) is: suci-0-274.012-0-2-2-049af0190d4e237.462c94.447052.770f6d34.866f1dbbe29a0ee889.18835d6a97.457a67.0323716ef2c8a37.3793be64b54cec40eb86ab19.057c95baf8cfe8cf9a09.9454b74e31.331018b.

The UDM/SIDF rejects the SUCI, and the UDM sends a Nudm_UEAuthentication_Get Response message with an HTTP status code "403 Forbidden" and may include additional error information in the response body (in "ProblemDetails" element) as specified in TS 29.503 [9], clause 5.4.2.2.2, 2b.

NOTE 3: Values for "ProblemDetails" may be AUTHENTICATION_REJECTED or INVALID_SCHEME_OUTPUT as specified in TS 29.503 [9], clause 6.3.3.2.4.2.2-2.

Evidence suitable for the interface, e.g., evidence can be presented in the form of packet trace (e.g., pcap file).

TR 33.926 [4], clause E.2.2.6, Invalid public key.

Rejection of SUCIs using an ECIES protection scheme with an invalid public key.

TS 33.501 [2], clause C.3.3 with reference to SECG SEC 1 [8] clause 2.3.4.

Output: An elliptic curve point P, or "invalid" as specified [8], clause 2.3.4.

Verify that the SIDF rejects the SUCI if it uses an ECIES protection scheme and contains an invalid point as the UE's public key for Profile B.

• The tester has access to the public information of the SUCI profile (e.g., profile type, public key ...) of theUDM/SIDF under test.

• The tester has configured the UDM to use Profile B.

• The tester has access to a SUPI of provisioned subscriber

1. The tester selects an invalid point (> > NOTE 1) and uses the point as a public key to encrypt the SUPI based on the encryption defined in Annex C of 33.501 [2] and SECG SEC 1 [8] (> > NOTE 2).

2. The tester sends the SUCI to the Nudm_UEAuthentication_Get service of the UDM/ SIDF under test.

NOTE 1: An example invalid point for Profile B (of order 47) is: 0x049af0190d4e237.462c94.447052.770f6d34.866f1dbbe29a0ee889.18835d6a97.457a67.0323716ef2c8a37.3793be64b54cec40eb86ab19.057c95baf8cfe.

NOTE 2: An example SUCI encrypted with the invalid point (above) for the MCC\|MNC (27.012) and MSIN (00.002086) for Profile B (Annex C of 33.501 [2]) is: suci-0-274.012-0-2-2-049af0190d4e237.462c94.447052.770f6d34.866f1dbbe29a0ee889.18835d6a97.457a67.0323716ef2c8a37.3793be64b54cec40eb86ab19.057c95baf8cfe8cf9a09.9454b74e31.331018b.

The UDM/SIDF rejects the SUCI, and the UDM sends a Nudm_UEAuthentication_Get Response message with an HTTP status code "403 Forbidden" and may include additional error information in the response body (in "ProblemDetails" element) as specified in TS 29.503 [9], clause 5.4.2.2.2, 2b.

NOTE 3: Values for "ProblemDetails" may be AUTHENTICATION_REJECTED or INVALID_SCHEME_OUTPUT as specified in TS 29.503 [9], clause 6.3.3.2.4.2.2-2.

Evidence suitable for the interface, e.g., evidence can be presented in the form of packet trace (e.g., pcap file).

TR 33.926 [4], clause E.2.2.6, Invalid public key.

Rejection of SUCIs using an uncompressed point with Profile B.

TS 33.501 [2], clause C.3.4.0.

Profile B shall use point compression to save overhead as specified in TS 33.501 [2], clause C.3.4.0.

Verify that the SIDF rejects the SUCI if it uses the ECIES Profile B protection scheme and contains an uncompressed point as the UE's public key.

Tester shall have access to the HN's public key for SUCI decryption with Profile B.

1. The tester shall generate a SUCI for a registered SUPI with the protection scheme output for Profile B. Theephemeral public key of the UE should be in the uncompressed point format specified in SECG SEC 1 [8] clause 2.3.3. The remaining parts of the protection scheme output retain their format specified in SECG SEC 1 [8].

NOTE 1: The uncompressed point format shall have a size of 65 bytes, and the most significant byte shall be 0x04. The compressed point format shall have a size of 33 bytes, with 0x02 or 0x03 as the most significant byte. Test data in TS 33.501 [2], clause C.4.4.1.

1. The tester shall send the SUCI to the Nudm_UEAuthentication_Get service of the UDM/ SIDF under test.

The SIDF rejects the SUCI, and the UDM sends a Nudm_UEAuthentication_Get Response message with an HTTP status code "403 Forbidden" and may include additional error information in the response body (in "ProblemDetails" element) as specified in TS 29.503 [9], clause 5.4.2.2.2, 2b.

NOTE 2: Values for "ProblemDetails" may be AUTHENTICATION_REJECTED or INVALID_SCHEME_OUTPUT as specified in TS 29.503 [9], clause 6.3.3.2.4.2.2-2.

Evidence suitable for the interface, e.g., evidence can be presented in the form of packet trace (e.g., pcap file).

TR 33.926 [4], clause E.2.2.6, Invalid public key.

Rejection of SUCIs using an uncompressed point with Profile B.

TS 33.501 [2], clause C.3.4.0.

Profile B shall use point compression to save overhead as specified in TS 33.501 [2], clause C.3.4.0.

Verify that the SIDF rejects the SUCI if it uses the ECIES Profile B protection scheme and contains an uncompressed point as the UE's public key.

The tester shall generate a SUCI for a registered SUPI with the protection scheme output for Profile B. Theephemeral public key of the UE should be in the uncompressed point format specified in [x] clause 2.3.3. The remaining parts of the protection scheme output retain their format [x].

NOTE 1: The uncompressed point format shall have a size of 65 bytes, and the most significant byte shall be 0x04. The compressed point format shall have a size of 33 bytes, with 0x02 or 0x03 as the most significant byte. Test data in TS 33.501 [2], clause C.4.4.1.

1. The tester shall send the SUCI to the Nudm_UEAuthentication_Get service of the UDM/ SIDF under test.

The SIDF rejects the SUCI, and the UDM sends a Nudm_UEAuthentication_Get Response message with an HTTP status code "403 Forbidden" and may include additional error information in the response body (in "ProblemDetails" element) as specified in TS 29.503 [9], clause 5.4.2.2.2, 2b.

NOTE 2: Values for "ProblemDetails" may be AUTHENTICATION_REJECTED or INVALID_SCHEME_OUTPUT as specified in TS 29.503 [9], clause 6.3.3.2.4.2.2-2.

Evidence suitable for the interface, e.g., evidence can be presented in the form of packet trace (e.g., pcap file).

TR 33.926 [4], clause E.2.2.2, Synchronization failure.

Synchronization failure handling

TS 33.501 [2], clause 6.1.3.3.2.

When the UDM/ARPF receives an Nudm_UEAuthentication_Get Request message with a "synchronisation failure indication" it acts as described in TS 33.102 [7], clause 6.3.5 where ARPF is mapped to HE/AuC. The UDM/ARPF sends an Nudm_UEAuthentication_Get Response message with a new authentication vector for either EAP-AKA' or 5G-AKA depending on the authentication method applicable for the user to the AUSF as specified in TS 33.501 [2], clause 6.1.3.3.2.

Verify that synchronization failure is recovered correctly in the home network.

Test environment with an AUSF. The AUSF or AMF may be simulated.

1. The tester sends an Nudm_UEAuthentication_Get Request message to the UDM under test with a "synchronisation failure indication" and parameters RAND and AUTS.

2. The UDM/ARPF performs steps 1-5 as described in TS 33.102, clause 6.3.5, and sends the Nudm_UEAuthentication_Get Response message to the AUSF.

3. The tester checks whether the Nudm_UEAuthentication_Get Response message sent from the UDM under test contains a new authentication vector.

The UDM sends an Nudm_UEAuthentication_Get Response message with a new authentication vector to the AUSF.

NOTE: The expected results would be that the UDM/AUSF sends an Nausf_UEAuthentication_Authenticate Response message with EAP Request/AKA'-Challenge for EAP AKA', or 5G SE AV for 5G AKA to the AMF, if the UDM and AUSF network products are collocated without an open N13 interface.

Evidence suitable for the interface, e.g., Screenshot, packet capture or application log containing the operational results.

TR 33.926 [4], clause E.2.2.2, Synchronization failure.

Synchronization failure handling

TS 33.501 [2], clause 6.1.3.3.2.

When the UDM/ARPF receives an Nudm_UEAuthentication_Get Request message with a "synchronisation failure indication" it acts as described in TS 33.102 [7], clause 6.3.5 where ARPF is mapped to HE/AuC. The UDM/ARPF sends an Nudm_UEAuthentication_Get Response message with a new authentication vector for either EAP-AKA' or 5G-AKA depending on the authentication method applicable for the user to the AUSF as specified in TS 33.501 [2], clause 6.1.3.3.2.

Verify that synchronization failure is recovered correctly in the home network.

Test environment with an AUSF. The AUSF or AMF may be simulated.

1. The AUSF sends an Nudm_UEAuthentication_Get Request message to the UDM with a "synchronisation failure indication" and parameters RAND and AUTS.

2. The UDM/ARPF performs steps 1-5 as described in TS 33.102, clause 6.3.5.

The UDM sends an Nudm_UEAuthentication_Get Response message with a new authentication vector to the AUSF.

NOTE: The expected results would be that the UDM/AUSF sends an Nausf_UEAuthentication_Authenticate Response message with EAP Request/AKA'-Challenge for EAP AKA', or 5G SE AV for 5G AKA to the AMF, if the UDM and AUSF network products are collocated without an open N13 interface.

Evidence suitable for the interface, e.g., Screenshot, packet capture or application log containing the operational results.

TR 33.926 [4], clause E.2.2.3, Failure to store of authentication status.

Storing of authentication status of UE by UDM.

TS 33.501 [2], clause 6.1.4.1a

The UDM stores the authentication status of the UE (SUPI, authentication result, time stamp, and the serving network name) after authentication as specified in TS 33.501 [2], clause 6.1.4.1a.

Verify that the UDM under test stores the authentication status of UE.

• UDM network product is connected with an AUSF in simulated/real network environment.

• The tester shall have access to the UDM under test.

1. The tester shall send an Nudm_UEAuthentication_Get Request message to the UDM with the UE credentials and a selected serving network name.

2. The tester shall receive a successful Nudm_UEAuthentication_Get Response from the UDM.

3. The tester shall simulate the successful authentication by sending the Nudm_UEAuthentication_ResultConfirmation Request message with a selected timestamp to the UDM.

4. The tester shall receive a successful Nudm_UEAuthentication_ResultConfirmation Response message from the UDM.

5. The tester shall compare the serving network name stored in the UDM against the serving network name retrieved from the Nudm_UEAuthentication_Get Request message and the serving network name retrieved from the Nudm_UEAuthentication_ResultConfirmation Request message.

6. The tester shall compare the SUPI stored in the UDM (retrieved from the Nudm_UEAuthentication_ResultConfirmation Response message) against the SUPI retrieved from the Nudm_UEAuthentication_Get Response message.

7. The tester shall compare the timestamp stored in the UDM against the time of authentication procedure retrieved from the Nudm_UEAuthentication_ResultConfirmation Request message.

The storing of authentication status (SUPI, timestamp, and the serving network name) of UE at the UDM is verified.

Evidence suitable for the interface, e.g., evidence can be presented in the form of packet capture or screenshot/screen-capture.

NOTE: Void

TR 33.926 [4], clause E.2.2.3, Failure to store of authentication status.

Storing of authentication status of UE by UDM.

TS 33.501 [2], clause 6.1.4.1a

• UDM network product is connected with an AUSF in simulated/real network environment involving AMF, eNB.

• The tester shall have access to all the authentication specific data sent over N1 interface, N12 interface and N13 interface.

• The tester shall have access to the UDM under test.

1. The tester shall capture the entire authentication procedure and authentication confirmation procedure over N12 and N13 interface using any network analyser.

2. the tester shall filter the Nudm_UEAuthentication_Get Request message sent over the N13 interface to retrieve serving network name.

3. The ester shall filter the Nudm_UEAuthentication_Get Response message sent over N13 interface to find the SUPI.

4. The tester shall filter the Nausf_UEAuthentication_Authenticate Response message sent over N12 interface to retrieve the Authentication result (EAP success/failure for EAP-AKA' or Result for 5G AKA).

5. The tester shall filter the Nudm_UEAuthentication_ResultConfirmation Request message to retrieve the authentication result and time of authentication procedure sent from the AUSF to the UDM over N13 interface.

6. The tester shall compare the serving network name stored in the UDM against the serving network name retrieved from the Nudm_UEAuthentication_Get Request message and the serving network name retrieved from the Nudm_UEAuthentication_ResultConfirmation Request message.

7. The tester shall compare the authentication status stored in the UDM against the authentication result retrieved from N12 interface.

8. The tester shall compare the SUPI stored in the UDM against the SUPI retrieved from the Nudm_UEAuthentication_Get Response message and the SUPI retrieved from the Nudm_UEAuthentication_ResultConfirmation Request message.

9. The tester shall compare the timestamp stored in the UDM against the time of authentication procedure retrieved from the Nudm_UEAuthentication_ResultConfirmation Request message.

NOTE: this test case does not apply to the deployment scenario where the UDM and AUSF network products are collocated without an open N13 interface.

TR 33.926 [4].

NOTE: The test case below only applies to the UDMs which support the setting and providing of User Plane Security Policy for dedicated TSC service.

UP security enforcement configuration

TS 33.501 [2], clause L.3, TS 23.501 [5], clause 5.10.3.

"After the 5GS TSC-enabled UE is authenticated and data connection is set up, any data received from a TSC bridge or another 5GS TSC-enabled UE shall be transported between DS-TT (in the UE) and NW-TT (in the UPF) in a protected way using the mechanisms for UP security as described in clause 6.6.

The UP security enforcement information shall be set to "required" for data transferred from gNB to a 5GS TSC-enabled UE. This is also applicable to the gPTP messages sent in the user plane."

as specified in TS 33.501 [2], clause L.3.

"The SMF determines at PDU session establishment a User Plane Security Enforcement information for the user plane of a PDU session based on:

• subscribed User Plane Security Policy which is part of SM subscription information received from UDM; and

• User Plane Security Policy locally configured per (DNN, S-NSSAI) in the SMF that is used when the UDM does not provide User Plane Security Policy information.

• The maximum supported data rate per UE for integrity protection for the DRBs, provided by the UE in the Integrity protection maximum data rate IE during PDU Session Establishment. The UE supporting NR as primary RAT, i.e. NG-RAN access via Standalone NR, shall set the Integrity protection maximum data rate IE for Uplink and Downlink to full rate at PDU Session Establishment as defined in TS 24.501 [47]."

as specified in TS 23.501 [5], clause 5.10.3.

Verify that UP security enforcement information is set to "required" for dedicated TSC service.

Test environment with SMF. The SMF may be simulated.

A dedicated DNN/S-NSSAI combination is defined to identify the TSC service.

The security policy is configured in the UDM.

1. During the PDU session establishment procedure, the SMF sends a Nudm_SDM_Get Request message to the UDM under test with a dedicated DNN/S-NSSAI combination.

2. The UDM under test sends the Nudm_SDM_Get Response back to the SMF with UP security enforcement information.

3. The tester checks the UP security enforcement information contained in the Nudm_SDM_Get Response message.

The confidentiality and integrity protection requirements of the UP security enforcement information are set to "required".

Save the logs and the communication flow in a .pcap file.

TR 33.926 [4].

NOTE: The test case below only applies to the UDMs which support the setting and providing of User Plane Security Policy for dedicated TSC service.

UP security enforcement configuration

TS 33.501 [2], clause L.3, TS 23.501 [5], clause 5.10.3.

"After the 5GS TSC-enabled UE is authenticated and data connection is set up, any data received from a TSC bridge or another 5GS TSC-enabled UE shall be transported between DS-TT (in the UE) and NW-TT (in the UPF) in a protected way using the mechanisms for UP security as described in clause 6.6.

The UP security enforcement information shall be set to "required" for data transferred from gNB to a 5GS TSC-enabled UE. This is also applicable to the gPTP messages sent in the user plane."

as specified in TS 33.501 [2], clause L.3.

"The SMF determines at PDU session establishment a User Plane Security Enforcement information for the user plane of a PDU session based on:

• subscribed User Plane Security Policy which is part of SM subscription information received from UDM; and

• User Plane Security Policy locally configured per (DNN, S-NSSAI) in the SMF that is used when the UDM does not provide User Plane Security Policy information.

• The maximum supported data rate per UE for integrity protection for the DRBs, provided by the UE in the Integrity protection maximum data rate IE during PDU Session Establishment. The UE supporting NR as primary RAT, i.e. NG-RAN access via Standalone NR, shall set the Integrity protection maximum data rate IE for Uplink and Downlink to full rate at PDU Session Establishment as defined in TS 24.501 [47]."

as specified in TS 23.501 [5], clause 5.10.3.

Verify that UP security enforcement information is set to "required" for dedicated TSC service.

Test environment with SMF. The SMF may be simulated.

A dedicated DNN/S-NSSAI combination is defined to identify the TSC service.

The security policy is configured in the UDM.

1. During the PDU session establishment procedure, the SMF sends a Nudm_SDM_Get Request message to the UDM under test with a dedicated DNN/S-NSSAI combination.

2. The UDM under test sends the Nudm_SDM_Get Response back to the SMF with UP security enforcement information.

The tester checks the UP security enforcement information contained in the Nudm_SDM_Get Response message.

The confidentiality and integrity protection requirements of the UP security enforcement information are set to "required".

Save the logs and the communication flow in a .pcap file.

TR 33.926 [4].

NOTE 1: The test case below only applies to the UDMs which support the setting and providing of User Plane Security Policy for 5G LAN service.

UP security enforcement configuration

TS 33.501 [2], clause K.3, TS 23.501 [5], clause 5.10.3.

"To reduce incremental complexity added by security, all PDU sessions associated with a specific 5G LAN group should have the same UP security policy. When generating the policy enforcement information, and to avoid the redundant double protection, the SMF may consider information by a DN-AAA about DN protection mechanisms already applied."

as specified in TS 33.501 [2], clause K.3.

"The SMF determines at PDU session establishment a User Plane Security Enforcement information for the user plane of a PDU session based on:

• subscribed User Plane Security Policy which is part of SM subscription information received from UDM; and

• User Plane Security Policy locally configured per (DNN, S-NSSAI) in the SMF that is used when the UDM does not provide User Plane Security Policy information.

• The maximum supported data rate per UE for integrity protection for the DRBs, provided by the UE in the Integrity protection maximum data rate IE during PDU Session Establishment. The UE supporting NR as primary RAT, i.e. NG-RAN access via Standalone NR, shall set the Integrity protection maximum data rate IE for Uplink and Downlink to full rate at PDU Session Establishment as defined in TS 24.501 [47]."

as specified in TS 23.501 [5], clause 5.10.3.

Verify that UP security policy is set to the same for all the 5G LAN UEs.

Test environment with SMF. The SMF may be simulated.

A dedicated DNN/S-NSSAI combination is defined to identify the 5G LAN service.

The security policy of the 5G LAN service is configured in the UDM.

1. During the PDU session establishment procedure initiated by the UE1, the SMF1 sends a Nudm_SDM_Get Request message to the UDM under test with the dedicated DNN/S-NSSAI combination defined to identify the 5G LAN service, and SUPI1.

2. The UDM under test sends the Nudm_SDM_Get Response back to the SMF1 with UP security policy1.

3. During the PDU session establishment procedure initiated by the UE2, the SMF2 sends a Nudm_SDM_Get Request message to the UDM under test with the dedicated DNN/S-NSSAI combination, defined to identify the 5G LAN service and SUPI2.

4. The UDM under test sends the Nudm_SDM_Get Response back to the SMF2 with UP security policy2.

5. The tester compares the UP security policies contained in the Nudm_SDM_Get Response messages in step 2 and step 4.

NOTE 2: SMF1 and SMF2 could be the same network function.

The confidentiality and integrity protection requirements of the UP security policies received in step 2 and step 4 are the same.

Save the logs and the communication flow in a .pcap file.

TR 33.926 [4].

NOTE 1: The test case below only applies to the UDMs which support the setting and providing of User Plane Security Policy for 5G LAN service.

UP security enforcement configuration

TS 33.501 [2], clause K.3, TS 23.501 [5], clause 5.10.3.

"To reduce incremental complexity added by security, all PDU sessions associated with a specific 5G LAN group should have the same UP security policy. When generating the policy enforcement information, and to avoid the redundant double protection, the SMF may consider information by a DN-AAA about DN protection mechanisms already applied."

as specified in TS 33.501 [2], clause K.3.

"The SMF determines at PDU session establishment a User Plane Security Enforcement information for the user plane of a PDU session based on:

• subscribed User Plane Security Policy which is part of SM subscription information received from UDM; and

• User Plane Security Policy locally configured per (DNN, S-NSSAI) in the SMF that is used when the UDM does not provide User Plane Security Policy information.

• The maximum supported data rate per UE for integrity protection for the DRBs, provided by the UE in the Integrity protection maximum data rate IE during PDU Session Establishment. The UE supporting NR as primary RAT, i.e. NG-RAN access via Standalone NR, shall set the Integrity protection maximum data rate IE for Uplink and Downlink to full rate at PDU Session Establishment as defined in TS 24.501 [47]."

as specified in TS 23.501 [5], clause 5.10.3.

Verify that UP security policy is set to the same for all the 5G LAN UEs.

Test environment with SMF. The SMF may be simulated.

A dedicated DNN/S-NSSAI combination is defined to identify the 5G LAN service.

The security policy of the 5G LAN service is configured in the UDM.

1. During the PDU session establishment procedure initiated by the UE1, the SMF1 sends a Nudm_SDM_Get Request message to the UDM under test with a dedicated DNN/S-NSSAI combination, and SUPI1.

2. The UDM under test sends the Nudm_SDM_Get Response back to the SMF1 with UP security policy1.

3. During the PDU session establishment procedure initiated by the UE2, the SMF2 sends a Nudm_SDM_Get Request message to the UDM under test with a dedicated DNN/S-NSSAI combination, and SUPI2.

4. The UDM under test sends the Nudm_SDM_Get Response back to the SMF2 with UP security policy2.

5. The tester compares the UP security policies contained in the Nudm_SDM_Get Response messages in step 2 and step 4.

NOTE 2: SMF1 and SMF2 could be the same network function.

Save the logs and the communication flow in a .pcap file.