TS 33.326
Security Assurance Specification (SCAS) for the
Network Slice-Specific Authentication and Authorization Function (NSSAAF) network product class
V18.0.0 (PDF)
2023/06 … p.
V17.0.0
2021/09 11 p.
- Rapporteur:
- Mrs. Rong, Wu
HUAWEI TECHNOLOGIES Co. Ltd.
Content for TS 33.326 Word version: 17.0.0
1 Scope 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 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: "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 p. 6
3.1 Terms 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.
3.2 Symbols p. 6
Void
3.3 Abbreviations p. 7
4 NSSAAF-specific security requirements and related test cases p. 7
4.1 Introduction p. 7
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 p. 7
4.2.1 Routes the S-NSSAI to the right place p. 7
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 clause 6.13 of TS 33.501.
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 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 clause 6.13 of TS 33.501.
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 p. 8
4.2.3.1 Introduction p. 8
The present clause provides baseline technical requirements.
4.2.3.2 Protecting data and information p. 8
4.2.3.2.1 Protecting data and information - general p. 8
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 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 p. 9
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 p. 9
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 p. 9
There are no NSSAAF additions to clause 4.2.3.2.5 of TS 33.117.
4.2.3.3 Protecting availability and integrity p. 9
There are no NSSAAF additions to clause 4.2.3.3 of TS 33.117.
4.2.3.4 Authentication and authorization p. 9
4.2.3.4.1 Authentication attributes p. 9
There are no NSSAAF additions to clause 4.2.3.4.1 of TS 33.117.
4.2.3.5 Protecting sessions p. 9
There are no NSSAAF additions to clause 4.2.3.5 of TS 33.117.
4.2.3.6 Logging p. 9
There are no NSSAAF additions to clause 4.2.3.6 of TS 33.117.
4.2.4 Operating systems p. 9
There are no NSSAAF additions to clause 4.2.4 of TS 33.117.
4.2.5 Web servers p. 9
There are no NSSAAF additions to clause 4.2.5 of TS 33.117.
4.2.6 Network devices p. 9
4.2.6.1 Protection of data and information p. 9
There are no NSSAAF additions to clause 4.2.6 of TS 33.117.
4.2.6.2 Protecting availability and integrity p. 9
4.2.6.2.1 Packet filtering p. 9
There are no NSSAAF additions to clause 4.2.6.2.1 of TS 33.117.
4.2.6.2.2 Interface robustness requirements p. 9
There are no NSSAAF additions to clause 4.2.6.2.2 of TS 33.117.
4.2.6.2.3 GTP-C Filtering 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 p. 10
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 p. 10
4.3.1 Introduction p. 10
The present clause contains eNodeB-specific adaptations of hardening requirements and related test cases.
4.3.2 Technical Baseline p. 10
There are no NSSAAF additions to clause 4.3.2 of TS 33.117.
4.3.3 Operating Systems p. 10
There are no NSSAAF additions to clause 4.3.3 of TS 33.117.
4.3.4 Web Servers p. 10
There are no NSSAAF additions to clause 4.3.4 of TS 33.117.
4.3.5 Network Devices p. 10
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 p. 10
There are no NSSAAF additions to clause 4.4 of TS 33.117.
$ Change history p. 11
