Content for TR 33.926 Word version: 17.6.0
P Aspects specific to the network product class NSSAAF
P.1 Threat to select AAA-P and AAA-S
Q Aspects specific to the network product class SCP
Q.1 Network product class description for the SCP
Q.2 Assets and Threats specific to SCP
$ Change history
P Aspects specific to the network product class NSSAAF |R17| p. 79
P.1 Threat to select AAA-P and AAA-S p. 79
- Threat name: AAA-P and AAA-S wrong selection
- Threat Category: Denial of service.
- Threat Description: AAA-S in NSSAA procedure may be hosted by the HPLMN or third party which has a business relationship. When AAA-S belongs to a third party, the AAA-P in the HPLMN may be involved. Different S-NSSAI may go to different AAA-S. If the NSSAAF does not have the ability to select the right receiver, the authentication will always fail.
- Threatened Asset: GNP Application.
Q (Normative) Aspects specific to the network product class SCP |R17| p. 80
Q.1 Network product class description for the SCP p. 80
Q.1.1 Introduction p. 80
This Annex covers the aspects specific to the SCP network product class.
Q.1.2 Minimum set of functions defining the SCP network product class p. 80
According to TR 33.916, a network product class is a class of products that all implement a common set of 3GPP-defined functionalities. Therefore, in order to define the SCP network product class, it is necessary to define the common set of 3GPP-defined functionalities that is constitutive for a SCP. As part of the SCP network product, it is expected that the SCP contains SCP application, a set of running processes (typically more than one) executing the software package for the SCP functions and OAM functions that is specific to the SCP network product model. Functionalities specific to the SCP network product introduce additional threats and/or critical assets as described below. Related security requirements and test cases have been captured in TS 33.522.
Q.2 Assets and Threats specific to SCP p. 80
Q.2.1 Threats related to tokens handled by the SCP p. 80
Q.2.1.1 Token forwarded to a wrong pNF instance p. 80
- Threat name: Token forwarded to a wrong pNF instance
- Threat Category: Denial of Service, Information Disclosure, Spoofing Identity, Elevation of Privilege
-
Threat Description: According to clauses 13.4.1.3 of TS 33.501, the SCP is able to obtain the access token and/or client credentials assertion from the consumer NF, which are/is forwarded to the producer NF for authorization and/or authentication. If the SCP failed to select the correct target pNF instance due to e.g. mis-implementation or misconfiguration or weak internal interface protection, which results in the token being forwarded to the wrong pNF instance, there are the following threats:
- The pNF instance receiving the access token will not be able to verify the access token, hence leading to authorization failure for indirect communication. Consequently, the access token, as a piece of sensitive information of the cNF, is exposed to a NF instance which is not meant to have it. This can result in denial of service, information disclosure, as well as waste of system resources. In worse case, if the NF instance receiving the access token wants to access the service granted in the token but not granted to the NF, it may impersonate the cNF to invoke the service of the target pNF using the received access token. This can result in spoofed identity and elevation of privilege.
- The pNF instance receiving the client credentials assertion will not be able to verify the assertion, hence leading to failure of authenticating the cNF. Consequently, the credentials assertion, as a piece of sensitive information of the cNF, is exposed to a NF instance which is not meant to have it. This can result in denial of service, information disclosure, as well as waste of system resources. In worse case, if the NF instance receiving the assertion wants to access the service granted in the token but not granted to the NF, it may impersonate the cNF using the assertion for authentication with the target pNF, so as to facilitate the service access to the target pNF with the exposed access token. This can result in spoofed identity and elevation of privilege.
- Threatened Asset: SCP Application, Access Tokens, Client Credentials Assertions, Service Messages forwarded/routed between NFs/NF services, Sufficient Processing Capacity
Q.2.1.2 Swapped token forwarded to the target pNF p. 81
- Threat name: Swapped token forwarded to the target pNF
- Threat Category: Denial of Service, Information Disclosure, Spoofing Identity, Elevation of Privilege
-
Threat Description: When NFs and NF services communicate indirectly via the SCP, the SCP may receive multiple access tokens, which could come from multiple cNFs requesting services or from a single cNF requesting access to various services or network slices provided by the target pNFs. Particularly for indirect communication with delegated discovery, the SCP is delegated to request access tokens from the NRF for service requests from cNFs and then include the correct access token in each of the service requests from cNFs. If the SCP mixes-up the received multiple access tokens and includes the wrong access token in a service request, due to mis-implementation or misconfiguration, there are the following threats:
- During indirect communication with delegated discovery, if the SCP mistakenly includes an access token of the requesting cNF destined for a pNF different from the target pNF (i.e. audience mismatch), the target pNF will fail to verify the access token, hence leading to authorization failure for indirect communication. Consequently, the access token, as a piece of sensitive information of the cNF, is exposed to a NF instance which is not meant to have it. This can result in denial of service as well as waste of system resources. In worse case, if the target NF wants to access the service granted in the token but not granted to the NF, it may impersonate the cNF to invoke the service of another pNF using the received access token. This can result in spoofed identity and elevation of privilege.
- During indirect communication with delegated discovery, if the SCP mistakenly includes the access token of a cNF different from the requesting cNF (i.e. subject mismatch) or includes an access token of the requesting cNF for a service/slice different from the requested service/slice (i.e. scope mismatch), the target pNF will fail to verify the access token, hence leading to authorization failure for indirect communication. This can result in denial of service as well as waste of system resources.
- During indirect communication with delegated discovery, if the SCP includes the correct access token but mistakenly includes a client credentials assertion of another cNF, the target pNF will fail to verify the assertion, hence leading to authentication failure for indirect communication. This can result in denial of service as well as waste of system resources.
- Threatened Asset: SCP Application, Service Messages forwarded/routed between NFs/NF services, Sufficient Processing Capacity
$ Change history p. 82
