Tech-invite  3GPPspace  IETF RFCs  SIP
Quick  21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x
Top   in Index   Prev   Next

TS 33.514
Security Assurance Specification (SCAS)
for the UDM Network Product Class

3GPP‑Page   ETSI‑search   CONTENT↓
V17.0.0 (PDF)  2021/06  16 p.
V16.4.0  2020/12  14 p.
Rapporteur:
Mr. Yoshizawa, Taka
NEC Europe Ltd

Content for  TS 33.514  Word version:  17.0.0

Here   Top
1 Scope  2 References  3 Definitions of terms, symbols and abbreviations  4 UDM-specific security requirements and related test cases  4.1 Introduction  4.2 Security functional requirements on the UDM derived from 3GPP specifications and related test cases  4.3 UDM-specific adaptations of hardening requirements and related test cases  4.4 UDM-specific adaptations of basic vulnerability testing requirements and related test cases  $ Change history 

 

1  Scope  Word‑p. 6

The present document contains requirements and test cases that are specific to the UDM network product class. It refers to the Catalogue of General Security Assurance Requirements and formulates specific adaptions of the requirements and test cases. It also specifies the requirements and test cases unique to the UDM network product class.

2  References  Word‑p. 6

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
TS 33.501: (Release 15): "Security architecture and procedures for 5G system".
[3]
TS 33.117: "Catalogue of general security assurance requirements".
[4]
TR 33.926: "Security Assurance Specification (SCAS) threats and critical assets in 3GPP network product classes".
[5]
TS 23.501: "System Architecture for the 5G System (5GS)".
[6]
TS 23.003: "Numbering, addressing and identification".
Up

3  Definitions of terms, symbols and abbreviations  Word‑p. 6

3.1  Terms  Word‑p. 6

For the purposes of the present document, the terms given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
Subscription Identifier:
Defined in TS 23.501 and in TS 23.003.
Subscription Concealed Identifier:
Defined in TS 33.501.
Subscription Identifier De-concealing Function:
Defined in TS 33.501.

3.2  Symbols  Word‑p. 6

Void.

3.3  Abbreviations  Word‑p. 7

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
5GS
5G System
AMF
Access and Mobility Management Function
AKA
Authentication and Key Agreement
ARPF
Authentication credential Repository and Processing Function
AUSF
Authentication Server Function
EAP
Extensible Authentication Protocol
SIDF
Subscription Identifier De-concealing Function
SUCI
Subscription Concealed Identifier
SUPI
Subscription Permanent Identifier
UDM
Unified Data Management
UDR
Unified Data Repository
Up

4  UDM-specific security requirements and related test cases  Word‑p. 7

4.1  Introduction  Word‑p. 7

UDM specific security requirements include both requirements derived from UDM specific security functional requirements in relevant specifications as well as security requirements introduced in the present document derived from the threats specific to UDM as described in TR 33.926.

4.2  Security functional requirements on the UDM derived from 3GPP specifications and related test cases  Word‑p. 7

4.2.0  General  Word‑p. 7

The general approach in TS 33.117, clause 4.2.2.1 and all the requirements and test cases in TS 33.117, clause 4.2.2.2 related to SBA/SBI aspect apply to the UDM network product class.

4.2.1  User Privacy Procedure  Word‑p. 7

4.2.1.1  De-concealment of SUPI from the SUCI based on the protection scheme used to generate the SUCI.  Word‑p. 7

Requirement Name:
De-concealment of SUPI from the SUCI based on the protection scheme used to generate the SUCI.
Requirement Reference:
TS 33.501, clause 5.8.2.
Requirement Description:
"The SIDF shall resolve the SUPI from the SUCI based on the protection scheme used to generate the SUCI." as specified in TS 33.501, clause 5.8.2.
Threat References:
TR 33.926, clause E.2.2.1, Incorrect SUCI de-concealment.
TEST CASE:
Test Name:
TC_DE-CONCEAL_SUPI_from_SUCI_UDM
Purpose:
Verify that the SIDF De-conceals the SUPI from the SUCI based on the protection scheme used to generate the SUCI.
Procedure and execution steps:
Pre-Condition:
  • 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.
Execution Steps:
Test case:
Tester shall capture the entire authentication procedure between UE and AMF over N1, N12 and N13 interface using any network analyser.
  1. Tester shall filter the Nudm_Authentication_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_Authentication_Get Response message.
Expected Results:
SIDF resolves the SUPI from the SUCI based on the protection scheme used to generate the SUCI.
Expected format of evidence:
Evidence suitable for the interface, e.g., evidence can be presented in the form of screenshot/screen-capture.
Up

4.2.2  Authentication and key agreement procedure  Word‑p. 8

4.2.2.1  Synchronization failure handling  Word‑p. 8

Requirement Name:
Synchronization failure handling
Requirement Reference:
TS 33.501, clause 6.1.3.3.2.
Requirement Description:
"When the UDM/ARPF receives an Nudm_UEAuthentication_Get Request message with a "synchronisation failure indication" it acts as described in TS 33.102, 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, clause 6.1.3.3.2.
Threat References:
TR 33.926, clause E.2.2.2, Synchronization failure.
Test Case:
Purpose:
Verify that synchronization failure is recovered correctly in the home network.
Pre-Conditions:
Test environment with an AUSF. The AUSF or AMF may be simulated.
Execution Steps
  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.
Expected Results:
The UDM sends an Nudm_UEAuthentication_Get Response message with a new authentication vector to the AUSF.
Up

4.2.2.2  Storing of authentication status of UE by UDM.  Word‑p. 9

Requirement Name:
Storing of authentication status of UE by UDM.
Requirement Reference:
TS 33.501, clause 6.1.4.1a
Requirement Description:
"The UDM shall store the authentication status of the UE (SUPI, authentication result, timestamp, and the serving network name) after authentication" as specified in TS 33.501, clause 6.1.4.1a.
Threat References:
TR 33.926, clause E.2.2.3, Failure to store of authentication status.
TEST CASE:
Test Name:
TC_AUTH_STATUS_STORE_UDM
Purpose:
Verify that the UDM under test stores the authentication status of UE, which is identical to the UE authentication information sent to/from the AUSF and the AMF.
Procedure and execution steps:
Pre-Condition:
  • 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.
Execution Steps:
  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_Authentication_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_Authentication_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_Authentication_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.
Expected Results:
The storing of authentication status (SUPI, authentication result, timestamp, and the serving network name) of UE at the UDM is verified.
Expected format of evidence:
Evidence suitable for the interface, e.g., evidence can be presented in the form of screenshot/screen-capture.
Up

4.2.3  Technical Baseline  Word‑p. 10

4.2.3.1  Introduction  Word‑p. 10

The present clause provides baseline technical requirements.

4.2.3.2  Protecting data and information  Word‑p. 10

4.2.3.2.1  Protecting data and information - general  Word‑p. 10
There are no UDM-specific additions to clause 4.2.3.2.1 of TS 33.117.
4.2.3.2.2  Protecting data and information - unauthorized viewing  Word‑p. 10
There are no UDM-specific additions to clause 4.2.3.2.2 of TS 33.117.
4.2.3.2.3  Protecting data and information in storage  Word‑p. 10
There are no UDM-specific additions to clause 4.2.3.2.3 of TS 33.117.
4.2.3.2.4  Protecting data and information in transfer  Word‑p. 10
There are no UDM-specific additions to clause 4.2.3.2.4 of TS 33.117.
4.2.3.2.5  Logging access to personal data  Word‑p. 10
There are no UDM-specific additions to clause 4.2.3.2.5 of TS 33.117.

4.2.3.3  Protecting availability and integrity  Word‑p. 10

There are no UDM-specific additions to clause 4.2.3.3 of TS 33.117.

4.2.3.4  Authentication and authorization  Word‑p. 10

There are no UDM-specific additions to clause 4.2.3.4 of TS 33.117.

4.2.3.5  Protecting sessions  Word‑p. 10

There are no UDM-specific additions to clause 4.2.3.5 of TS 33.117.

4.2.3.6  Logging  Word‑p. 11

There are no UDM-specific additions to clause 4.2.3.6 of TS 33.117.

4.2.4  Operating Systems  Word‑p. 11

There are no UDM-specific additions to clause 4.2.4 of TS 33.117.

4.2.5  Web Servers  Word‑p. 11

There are no UDM-specific additions to clause 4.2.5 of TS 33.117.

4.2.6  Network Devices  Word‑p. 11

There are no UDM-specific additions to clause 4.2.6 of TS 33.117.

4.2.7  User plane security procedures  Word‑p. 11

4.2.7.1  UP Security enforcement configuration for TSC service  Word‑p. 11

Requirement Name:
UP security enforcement configuration
Requirement Reference:
TS 33.501, clause L.3, TS 23.501, clause 5.10.3.
Requirement Description:
"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, 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."
as specified in TS 23.501, clause 5.10.3.
Threat References:
TR 33.926.
Test Case:
Purpose:
Verify that UP security enforcement information is set to "required" for dedicated TSC service.
Pre-Conditions:
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.
Execution Steps
  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.
Expected Results:
The confidentiality and integrity protection requirements of the UP security enforcement information are set to "required".
Expected format of evidence:
Save the logs and the communication flow in a .pcap file.
Up

4.2.8  User plane security procedures  Word‑p. 12

4.2.8.1  UP security policy configuration for 5G LAN service  Word‑p. 12

Requirement Name:
UP security enforcement configuration
Requirement Reference:
TS 33.501, clause K.3, TS 23.501, clause 5.10.3.
Requirement Description:
"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, 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."
as specified in TS 23.501, clause 5.10.3.
Threat References:
TR 33.926.
Test Case:
Purpose:
Verify that UP security policy is set to the same for all the 5G LAN UEs.
Pre-Conditions:
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.
Execution Steps
  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.
Expected Results:
The confidentiality and integrity protection requirements of the UP security policy1 and UP security policy2 are the same.
Expected format of evidence:
Save the logs and the communication flow in a .pcap file.
Up

4.3  UDM-specific adaptations of hardening requirements and related test cases  Word‑p. 13

4.3.1  Introduction  Word‑p. 13

The present clause contains UDM-specific adaptations of hardening requirements and related test cases.

4.3.2  Technical baseline  Word‑p. 13

There are no UDM-specific additions to clause 4.3.2 of TS 33.117.

4.3.3  Operating systems  Word‑p. 13

There are no UDM-specific additions to clause 4.3.3 of TS 33.117.

4.3.4  Web servers  Word‑p. 13

There are no UDM-specific additions to clause 4.3.4 of TS 33.117.

4.3.5  Network devices  Word‑p. 13

There are no UDM-specific additions to clause 4.3.5 of TS 33.117.

4.3.6  Network functions in service-based architecture  Word‑p. 13

There are no UDM-specific additions to clause 4.3.6 in TS 33.117.

4.4  UDM-specific adaptations of basic vulnerability testing requirements and related test cases  Word‑p. 14

There are no UDM-specific additions to clause 4.4 of TS 33.117.

$  Change history  Word‑p. 15

Up   Top