TS 33.326
Security Assurance Specification (SCAS) for the
Network Slice-Specific Authentication and Authorization Function (NSSAAF) network product class
V17.0.0 (Wzip)
2021/09 11 p.
- Rapporteur:
- Mrs. Rong, Wu HUAWEI TECHNOLOGIES Co. Ltd.
Content for TS 33.326 Word version: 17.0.0
1 Scope Word‑p. 6
The present document contains requirements and test cases that are specific to the NSSAAF network product class. It refers to the Catalogue of General Security Assurance Requirements and formulates specific adaptions of the requirements and test cases, as well as specifying requirements and test cases unique to the NSSAAF network product class.
2 References
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: "Security architecture and procedures for 5G system".
[3]
TS 33.117: (Release 16) "Catalogue of general security assurance requirements".
[4]
TR 33.926: "Security Assurance Specification (SCAS) threats and critical assets in 3GPP network product classes".
3 Definitions of terms, symbols and abbreviations
3.1 Terms
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.
3.2 Symbols
Void
3.3 Abbreviations Word‑p. 7
4 NSSAAF-specific security requirements and related test cases
4.1 Introduction
NSSAAF specific security requirements include both requirements derived from NSSAAF security functional requirements as well as security requirements derived from threats specific to eNB as described in TR 33.926. Generic security requirements and test cases common to other network product classes have been captured in TS 33.117 and are not repeated in the present document.
4.2 NSSAAF-specific security functional requirements and related test cases
4.2.1 Routes the S-NSSAI to the right place
Requirement Name:
Routes the S-NSSAI to the right place
Requirement Reference:
Requirement Description:
"If the AAA-P is present (e.g. because the AAA-S belongs to a third party and the operator deploys a proxy towards third parties), the NSSAAF forwards the EAP ID Response message to the AAA-P, otherwise the NSSAAF forwards the message directly to the AAA-S. NSSAAF routes to the AAA-S based on the S-NSSAI." as specified in TS 33.501, clause 6.13.
Threat Reference:
TBD
Test Name:
TC_NSSAAF_CORRECT_ROUTING
Purpose:
Verify that the NSSAAF forwards the NSSAA request to the right receiving end.
Pre-Conditions:
- Test environment with AMF, AAA-S and AAA-P, which may be simulated. The NSAAF under test is connected with AMF, AAA-S and AAA-P.
- A document describes the logic how the NSSAAF selects an AAA-S or AAA-P based on S-NSSAI.
- Preconfigure the NSSAAF under test with two routing entries, each for a NSSAI. One of the slice is a part of MNO and the AAA-S can be directly found by the NSSAAF, while the other slice serves 3rd party and the AAA-P will be used for NSSAA procedure.
- The AMF sends Nssaaf_NSSAA_Authenticate Req to the NSSAAF including one of the S-NSSAI.
- The NSSAAF sends AAA message to an AAA-P.
- Repeat step 1 and 2 with the other S-NSSAI, and the NSSAAF sends AAA message to an AAA-S.
The NSSAAF forwards the NSSAA request to the correct AAA-S or AAA-P on the S-NSSAI.
Expected format of evidence:
Save the logs and the communication flow in a .pcap file.
4.2.2 AAA-S authorization in re-authentication and revocation scenarios Word‑p. 8
Requirement Name:
AAA-S authorization in re-authentication and revocation scenarios
Requirement Reference:
Requirement Description:
"The NSSAAF checks whether the AAA-S is authorized to request the re-authentication and re-authorization by checking the local configuration of AAA-S address per S-NSSAI. If success, TtThe NSSAAF requests UDM for the AMF serving the UE using the Nudm_UECM_Get (GPSI, AMF Registration) service operation. The UDM provides the NSSAAF with the AMF ID of the AMF serving the UE." as specified in TS 33.501, clause 6.13.
Threat Reference:
TBD
Test Name:
TC_NSSAAF_AAAS_AUTHORIZATION_REAUTH_REVOCATION
Purpose:
Verify that the AAA-S is authorized to send the re-authentication or revocation.
Pre-Conditions:
- Test environment with AAA-S and AAA-P, which may be simulated. The NSAAF under test is connected with AAA-S and AAA-P.
- A document describes the mapping between S-NSSAI and AAA-S server.
- The AAA-S sends Re-authentication or revocation message to the NSSAAF including the S-NSSAI and the GPSI.
- The NSSAAF checks whether the AAA-S can be matched against with the S-NSSAI based on the mapping table.
The NSSAAF rejects the re-authentication or revocation or pass the re-authentication or revocation.
Expected format of evidence:
Save the logs and the communication flow in a .pcap file.
4.2.3 Technical baseline
4.2.3.1 Introduction
The present clause provides baseline technical requirements.
4.2.3.2 Protecting data and information
4.2.3.2.1 Protecting data and information - general
There are no NSSAAF 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. 9
There are no NSSAAF additions to clause 4.2.3.2.2 of TS 33.117.
4.2.3.2.3 Protecting data and information in storage
There are no NSSAAF additions to clause 4.2.3.2.3 of TS 33.117.
4.2.3.2.4 Protecting data and information in transfer
There are no NSSAAF additions to clause 4.2.3.2.4 of TS 33.117.
4.2.3.2.5 Logging access to personal data
There are no NSSAAF additions to clause 4.2.3.2.5 of TS 33.117.
4.2.3.3 Protecting availability and integrity
There are no NSSAAF additions to clause 4.2.3.3 of TS 33.117.
4.2.3.4 Authentication and authorization
4.2.3.4.1 Authentication attributes
There are no NSSAAF additions to clause 4.2.3.4.1 of TS 33.117.
4.2.3.5 Protecting sessions
There are no NSSAAF additions to clause 4.2.3.5 of TS 33.117.
4.2.3.6 Logging
There are no NSSAAF additions to clause 4.2.3.6 of TS 33.117.
4.2.4 Operating systems
There are no NSSAAF additions to clause 4.2.4 of TS 33.117.
4.2.5 Web servers
There are no NSSAAF additions to clause 4.2.5 of TS 33.117.
4.2.6 Network devices
4.2.6.1 Protection of data and information
There are no NSSAAF additions to clause 4.2.6 of TS 33.117.
4.2.6.2 Protecting availability and integrity
4.2.6.2.1 Packet filtering
There are no NSSAAF additions to clause 4.2.6.2.1 of TS 33.117.
4.2.6.2.2 Interface robustness requirements
There are no NSSAAF additions to clause 4.2.6.2.2 of TS 33.117.
4.2.6.2.3 GTP-C Filtering Word‑p. 10
The requirement and testcase in clause 4.2.6.2.3 of TS 33.117 is not applicable to eNB network product.
4.2.6.2.4 GTP-U Filtering
There are no NSSAAF additions to clause 4.2.6.2.4 of TS 33.117.
4.3 NSSAAF-specific adaptations of hardening requirements and related test cases
4.3.1 Introduction
The present clause contains eNodeB-specific adaptations of hardening requirements and related test cases.
4.3.2 Technical Baseline
There are no NSSAAF additions to clause 4.3.2 of TS 33.117.
4.3.3 Operating Systems
There are no NSSAAF additions to clause 4.3.3 of TS 33.117.
4.3.4 Web Servers
There are no NSSAAF additions to clause 4.3.4 of TS 33.117.
4.3.5 Network Devices
There are no NSSAAF additions to clause 4.3.5 of TS 33.117.
4.4 NSSAAF-specific adaptations of basic vulnerability testing requirements and related test cases
There are no NSSAAF additions to clause 4.4 of TS 33.117.
$ Change history Word‑p. 11
