Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x
Top   in Index   Prev   Next

TS 33.519
5G Security Assurance Specification (SCAS) –
NF Repository Function (NRF)

V17.0.0 (PDF)  2022/03  14 p.
V16.2.0 (PDF)  2020/12  14 p.
Rapporteur:
Mr. PENG, Jin
ZTE Corporation

Content for  TS 33.519  Word version:  17.0.0

Here   Top

 

1  ScopeWord‑p. 6

The present document contains requirements and test cases that are specific to the NEF network product class. It refers to the Catalogue of General Security Assurance Requirements and formulates specific adaptions of the requirements and test cases given there, as well as specifying requirements and test cases unique to the NEF network product class.

2  ReferencesWord‑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]
TS 21.905: "Vocabulary for 3GPP Specifications".
[2]
TS 33.501: "Security architecture and procedures for 5G system" (Release 15).
[3]
TS 23.501: "System Architecture for the 5G System".
[4]
TS 33.122: "Security aspects of Common API Framework (CAPIF) for 3GPP northbound APIs".
[5]
TR 33.926: "Security Assurance Specification (SCAS) threats and critical assets in 3GPP network product classes".
[6]
TS 33.117: "Catalogue of general security assurance requirements".
Up

3  Definitions of terms, symbols and abbreviationsWord‑p. 6

3.1  TermsWord‑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  SymbolsWord‑p. 6

Void.

3.3  AbbreviationsWord‑p. 6

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.
CAPIF
Common API Framework for 3GPP northbound APIs
NEF
Network Exposure Function

4  NEF-specific security requirements and related test casesWord‑p. 7

4.1  IntroductionWord‑p. 7

NEF specific security requirements include both requirements derived from NEF-specific security functional requirements as well as security requirements derived from threats specific to NEF 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  NEF-specific security functional adaptations of requirements and related test casesWord‑p. 7

4.2.0  IntroductionWord‑p. 7

The present clause describes the security functional requirements and the corresponding test cases for NEF network product class. The proposed security requirements are classified in two groups:
  • Security functional requirements derived from TS 33.501 and detailed in clause 4.2.2.
  • General security functional requirements which include requirements not already addressed in TS 33.501 but whose support is also important to ensure that NEF conforms to a common security baseline detailed in clause 4.2.3.
Up

4.2.1Void

4.2.2  Security functional requirements on the NEF deriving from 3GPP specifications and related test casesWord‑p. 7

4.2.2.0  GeneralWord‑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 NEF network product class.

4.2.2.1  Security functional requirements on the NEF deriving from 3GPP specifications - TS 33.501 [2]Word‑p. 7

4.2.2.1.1  Authentication on application functionWord‑p. 7
Requirement Name:
Authentication on application function
Requirement Reference:
Requirement Description:
"Mutual authentication between the NEF and Application Function shall be supported" as specified in TS 33.501, clause 5.9.2.3. "For authentication between NEF and an Application Function that resides outside the 3GPP operator domain, mutual authentication based on client and server certificates shall be performed between the NEF and AF using TLS" and "Certificate based authentication shall follow the profiles given in TS 33.210, clause 6.2. " as specified in TS 33.501, clause 12.2.
Threat References:
TR 33.926, clause I.2.2.1, No authentication on application function
Test Case:
Test Name:
TC_CP_AUTH_AF_NEF
Purpose:
To verify that the NEF can authenticate application function and establish TLS connection towards the application server with certificate based authentication, and may authenticate application function and establish TLS connection towards the application server with pre-shared key based authentication.
Pre-Condition:
  • The NEF network product shall be connected in emulated/real network environments.
  • In order to establish TLS connections to the NEF network product, the application function shall offer a feature that is supported by the NEF network product, including protocol version and combination of cryptographic algorithms.
  • The application function and the NEF network product shall support certificate based authentication, and may support pre-shared key based authentication.
  • If the NEF network product does not support CAPIF as specified in clause 6.2.5.1 in TS 23.501, the certificates or the pre-shared key shall be provisioned in the NEF network product.
  • If the NEF network product supports CAPIF, the certificates or the pre-shared key shall be provisioned in the CAPIF core function, the CAPIF core function shall be able to select appropriate authentication method as defined in the sub-clause 6.5.2 in TS 33.122.
Execution Steps:
  1. If certificate based authentication is used, provision correct certificate on the application function, if pre-shared key based authentication is used, provision same pre-shared key on the application function.
  2. The application function shall initiate establishment of TLS connection towards the NEF network product, and check whether a TLS connection is established successfully.
  3. If certificate based authentication is used, provision incorrect certificate on the application function, if pre-shared key based authentication is used, provision different pre-shared key on the application function.
  4. The application function shall initiate establishment of TLS connection towards the NEF network product, and check whether no new TLS connection is established.
Expected Results:
Only one TLS connection is established at step 2.
Expected format of evidence:
Evidence suitable for the interface, e.g., Screenshot containing the operational results.
Up
4.2.2.1.2  Authorization on northbound APIsWord‑p. 8
Requirement Name:
Authorization on application function
Requirement Reference:
Requirement Description:
"The NEF shall authorize the requests from Application Function using OAuth-based authorization mechanism, the specific authorization mechanisms shall follow the provisions given in RFC 6749 [43]" as specified in TS 33.501, clause 12.4.
Threat References:
TR 33.926, clause I.2.2.2, No authorization on northbound APIs
Test Case:
Test Name: TC_CP_AUTHOR_AF_NEF
Purpose: To verify that the NEF can authorize application function.
Pre-Condition:
  • The NEF network product shall be connected in emulated/real network environments.
  • The application function and the NEF network product shall support OAuth-based authorization mechanism.
  • An authorization server (e.g. NRF, or CAPIF core function) that supports OAuth2 protocol to authorize NEF northbound APIs using the "Client Credentials" authorization grant has been deployed.
  • The TLS connection between the NEF network product and the application function has been established.
  • The authorization server is configured to grant the application function to access a northbound API of the NEF network product, called NEF northbound API A.
Execution Steps:
Test 1: without token:
  1. The application function invokes Obtain_Authorization service towards the authorization server to get a token from the authorization server for accessing the NEF northbound API A.
  2. The application function invokes NEF northbound API A.
  3. The tester triggers the application function to invoke another northbound API of the NEF network product, called NEF northbound API B, without token.
Test 2: With incorrect token:
  1. The application function invokes Obtain_Authorization service towards the authorization server to get a token from the authorization server for accessing the NEF northbound API A.
  2. The application function invokes NEF northbound API A.
  3. The tester triggers the application function to invoke the NEF northbound API B with a fake token.
Expected Results:
The invoking of NEF northbound API A succeeds, while the invoking of NEF northbound API B fails.
Expected format of evidence:
Evidence suitable for the interface, e.g., Screenshot containing the operational results.
Up

4.2.3  Technical BaselineWord‑p. 9

4.2.3.1  IntroductionWord‑p. 9

The present clause provides baseline technical requirements.

4.2.3.2  Protecting data and informationWord‑p. 9

4.2.3.2.1  Protecting data and information - generalWord‑p. 9
There are no NEF-specific additions to clause 4.2.3.2.1 of TS 33.117.
4.2.3.2.2  Protecting data and information - unauthorized viewingWord‑p. 9
There are no NEF-specific additions to clause 4.2.3.2.2 of TS 33.117.
4.2.3.2.3  Protecting data and information in storageWord‑p. 9
There are no NEF-specific additions to clause 4.2.3.2.3 of TS 33.117.
4.2.3.2.4  Protecting data and information in transferWord‑p. 9
There are no NEF-specific additions to clause 4.2.3.2.4 of TS 33.117.
4.2.3.2.5  Logging access to personal dataWord‑p. 10
There are no NEF-specific additions to clause 4.2.3.2.5 of TS 33.117.

4.2.3.3  Protecting availability and integrityWord‑p. 10

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

4.2.3.4  Authentication and authorizationWord‑p. 10

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

4.2.3.5  Protecting sessionsWord‑p. 10

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

4.2.3.6  LoggingWord‑p. 10

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

4.2.4  Operating SystemsWord‑p. 10

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

4.2.5  Web ServersWord‑p. 10

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

4.2.6  Network DevicesWord‑p. 10

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

4.2.7Void

4.3  NEF-specific adaptations of hardening requirements and related test casesWord‑p. 10

4.3.1  IntroductionWord‑p. 10

The requirements proposed hereafter (with the relative test cases) aim to securing NEF by reducing its surface of vulnerability. In particular, the identified requirements aim to ensure that all the default configurations of NEF (including operating system software, firmware and applications) are appropriately set.

4.3.2  Technical baselineWord‑p. 10

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

4.3.3  Operating systemsWord‑p. 10

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

4.3.4  Web serversWord‑p. 11

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

4.3.5  Network devicesWord‑p. 11

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

4.3.6  Network functions in service-based architectureWord‑p. 11

There are no NEF-specific additions to clause 4.3.6 of TS 33.117.

4.4  NEF-specific adaptations of basic vulnerability testing requirements and related test casesWord‑p. 11

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

$  Change HistoryWord‑p. 12


Up   Top