Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TR 33.926  Word version:  17.6.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   A…   B…   C…   D…   E…   F…   G…   H…   I…   J…   K…   L…   M…   O…   P… 
G Aspects specific to the network product class SEPP  G.1 Network product class description for the SEPP  G.2 Assets and threats specific to the SEPP  G.2.1 Critical assets  G.2.2 Threats related to cryptographic material in the SEPP  G.2.3 Threats related to error handling in the SEPP  G.2.4 Threats related to sensitive information exposure  G.2.5 Threats related to TLS protection between NF and SEPP 
...

 

G  Aspects specific to the network product class SEPP |R16|  p. 47

G.1  Network product class description for the SEPP  p. 47

G.1.1  Introduction  p. 47

This annex captures the aspects specific to network product class SEPP.

G.1.2  Minimum set of functions defining the SEPP network product class  p. 47

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 SEPP network product class, it is necessary to define the common set of 3GPP-defined functionalities that is constitutive for a SEPP. As part of the SEPP network product, it is expected that the SEPP contains SEPP application, a set of running processes (typically more than one) executing the software package for the SEPP functions and OAM functions that is specific to the SEPP network product model. Functionalities specific to the SEPP network product introduce additional threats and/or critical assets as described below. Related security requirements and test cases have been captured in TS 33.517.
Up

G.2  Assets and threats specific to the SEPP  p. 47

G.2.1  Critical assets  p. 47

In addition to the critical assets of a GNP described in clause 5.2 of the present document, the critical assets specific to the SEPP to be protected are:
  • SEPP Application;
  • Service Messages to be sent/received over N32.
  • SEPP security capability (i.e. N32 protection mechanisms): Mechanism 1 (N32 Application Layer Security), Mechanism 2 (TLS), etc.
  • Application layer security data: e.g. N32-f peer information, N32-f security context, cryptographic material of peer SEPPs, cryptographic material of IPX providers, etc.
  • Protection policies: e.g. data-type encryption policy and modification policy for outgoing and incoming messages, as described in clause 13.2.3.5 of TS 33.501.
  • Internal topology information;
  • The interfaces of SEPP to be protected and which are within SECAM scope:
    • N32 (N32-c, N32-f).
    • Interfaces between SEPP and NFs.
    • Console interface, for local access: local interface on SEPP.
    • OAM interface, for remote access: interface between SEPP and OAM system.
  • SEPP Software: binary code or executable code
Up

G.2.2  Threats related to cryptographic material in the SEPP  p. 48

G.2.2.1  Misusing cryptographic material of peer SEPPs and IPX providers  p. 48

  • Threat name: Misusing cryptographic material of peer SEPPs and IPX providers
  • Threat Category: Denial of Service, Spoofing identity, Tampering of Data, Information Disclosure
  • Threat Description: There are following threats if cryptographic material of peer SEPPs and cryptographic material of IPX providers are not clearly differentiated and misused:
    • The SEPP using the wrong cryptographic material will lead to the failure of N32-c TLS connection establishment with the peer SEPP; or lead to rejecting genuine N32-f JSON patches from an authentic intermediate IPX provider. This can result in service interruption as well as waste of system resources.
    • The SEPP will wrongly accept forged N32-f JSON patches signed by a peer SEPP, which maliciously impersonates an intermediate IPX provider. This can result in service data tampering as well as waste of system resources.
    • The SEPP will wrongly establish N32-c TLS connection with an intermediate IPX entity, which maliciously impersonates a peer SEPP. This can result in information disclosure as well as waste of system resources.
  • Threatened Asset: SEPP Application, N32-c, N32-f, Application layer security data, Sufficient Processing Capacity
Up

G.2.2.2  Misusing cryptographic material beyond connection-specific scope  p. 48

  • Threat name: Misusing cryptographic material beyond connection-specific scope
  • Threat Category: Denial of Service, Tampering of Data, Information Disclosure
  • Threat Description: There are following threats if the SEPP authenticates N32-f message modifications using the cryptographic material from an IPX provider which was not exchanged as part of the IPX security information list via the related N32-c connection:
    • The SEPP using the wrong cryptographic material will lead to failed authentication of N32-f message modifications signed by the authentic IPX provider, who is a part of the related N32-c connection. This can result in service interruption as well as waste of system resources.
    • The SEPP will wrongly accept N32-f JSON patches signed by an IPX provider, who is a part of a different N32-c connection. This can result in service data tampering as well as waste of system resources.
  • Threatened Asset: SEPP Application, N32-c, N32-f, Sufficient Processing Capacity
Up

G.2.3  Threats related to error handling in the SEPP  p. 48

G.2.3.1  Incorrect handling for PLMN ID mismatch  p. 48

  • Threat name: Incorrect handling for PLMN ID mismatch
  • Threat Category: Denial of Service, Information Disclosure, Spoofing Identity
  • Threat Description: there are following threats if the SEPP does not make correct handling when detecting that the PLMN-ID contained in the incoming N32-f message does not match the PLMN-ID in the related N32-f context:
    • Without receiving error signalling message from the SEPP which detected the mismatch, the peer SEPP is not aware of such error and will continue to send the messages with errors. This can result in waste of system resources.
    • If the SEPP sends an error signalling message without indicating the error cause and the corresponding N32-f message ID, the peer SEPP is not able to identify what error occurs and what is the source message on which the error occurs. Hence the peer SEPP is not able to take actions accordingly. This can result in service interruption as well as waste of system resources.
    • The serving PLMN ID appended in the subject claim of the access token sent by a NF service consumer in the serving PLMN will not be checked by the NF service producer in the home PLMN. If the SEPP in the HPLMN detected the mismatch of serving PLMN ID in the access token but still forwards the NF Service Request to the NF service producer, the serving PLMN ID mismatch will not be detected by the NF service producer and the request will be wrongly accepted if all the other checks on the access token get passed. This can result in unauthorized service access by NF service consumer as well as waste of system resources.
  • Threatened Asset: Application layer security data, Sufficient Processing Capacity
Up

G.2.3.2  Incorrect handling for protection policies mismatch  p. 49

  • Threat name: Incorrect handling for protection policies mismatch
  • Threat Category: Information Disclosure. Tampering of Data, Denial of Service
  • Threat Description: For the following threats if the SEPP cannot detect the mismatch between the policies received on N32-c connection from a specific roaming partner and the policies manually configured on it for this specific roaming partner and IPX provider:
    • The policies received on N32-c connection from a peer SEPP could be tampered by an attacker, which is however not detected. Or the policies manually configured on the SEPP could be misconfigured, which is however not detected.
      1. If Data-type encryption policies are tampered or misconfigured, the IEs on N32-f which shall be encrypted may be disclosed due to policy tampering. This can result in information disclosure.
      2. If Modification policies are tampered or misconfigured, the IEs on N32-f which cannot be modified/added/removed by IPX provider may be tampered. This can result in tampering of data.
    • As the data-type encryption policies in the two partner SEPPs are not equal, a consistent ciphering of IEs on N32-f cannot be enforced.
  • Threatened Asset: Protection policies, SEPP Application, Sufficient Processing Capacity
Up

G.2.4  Threats related to sensitive information exposure  p. 49

G.2.4.1  Weak JWS algorithm  p. 49

  • Threat name: Use of weak JWS algorithm.
  • Threat Category: Information Disclosure.
  • Threat Description: There are multiple standard signature algorithms defined for JWS, among which some algorithms may be considered weaker than the others. If an IPX entity is misconfigured, a weak cryptographic algorithm can be used to sign the modifiedDataToIntegrityProtect JSON object, which is more prone to attacks. If the SEPP does not follow the restriction on the signature algorithm for JWS operation as required (using only ES256), it can be exposed to the threat described in clause 5.3.6.3. This can result in sensitive information exposure.
  • Threatened Asset: SEPP Application.
Up

G.2.4.2  Exposure of confidential IEs in N32-f message  p. 50

  • Threat name: Exposure of confidential IEs in N32-f message.
  • Threat Category: Information Disclosure.
  • Threat Description: the following behaviours may lead to exposure of confidential IEs in N32-message, which can result in information disclosure:
    • if the SEPP does not correctly replace the cleartext representations of information elements requiring encryption with the value "encBlockIdx", there is the threat that the sensitive information in original N32-f messages may be exposed to IPX providers in the path or any other parties eavesdropping on the connection between roaming partners.
    • if the SEPP does not correctly apply the basic validation rule and verify that an intermediate IPX has not inserted an IE requiring encryption at a different location in a JSON object, there is the threat that a misbehaving or compromised intermediate IPX can copy the encrypted IE into a cleartext IE in a request. Then the receiving SEPP decrypts the encrypted IE and puts its value into the cleartext IE field, resulting in the confidential IEs in N32-f message being exposed in the clear.
  • Threatened Asset: SEPP Application, Service Messages to be sent/received over N32.
Up

G.2.5  Threats related to TLS protection between NF and SEPP |R17|  p. 50

G.2.5.1  Inter-PLMN routing using the incorrect reference  p. 50

  • Threat name: Inter-PLMN routing using the incorrect reference
  • Threat Category: Denial of Service, Information Disclosure
  • Threat Description: TLS protection between the SEPP and NFs within a PLMN may rely on using telescopic FQDN or 3gpp-Sbi-Target-apiRoot header. When telescopic FQDN is used between the NF and the SEPP, the NF shall use a telescopic FQDN in the Request URI of the HTTP Request to convey the target apiRoot to the SEPP. When 3gpp-Sbi-Target-apiRoot header is used between the NF and the SEPP, the NF shall use the 3gpp-Sbi-Target-apiRoot HTTP header in the HTTP Request to convey the target apiRoot to the SEPP. However, there may be the case that a potentially malicious or misbehaving NF would include both the 3gpp-Sbi-Target-apiRoot header and a request URI containing a telescopic FQDN when communicating with the SEPP. In this case, the SEPP is given two references for routing the NF request across PLMN. According to clause 13.1.1.1 of TS 33.501, when communication between the NF and the SEPP that generated the telescopic FQDN is based on using 3gpp-Sbi-Target-apiRoot header, the NF needs to use the telescopic FQDN in the 3gpp-Sbi-Target-apiRoot header of the HTTP Request. That means whenever the telescopic FQDN is available on the NF, it shall be used to convey the target apiRoot to the SEPP. If a malicious or misbehaving NF includes a 3gpp-Sbi-Target-apiRoot header containing an element different than the telescopic FQDN contained in the Request URI and the SEPP ignores the telescopic FQDN but uses the 3gpp-Sbi-Target-apiRoot header to route the request, the NF request will not be correctly routed. This can result in Denial of Service and Information Disclosure.
  • Threatened Asset: SEPP Application, Service Messages to be sent/received over N32.
Up

G.2.5.2  Tampering of Target API Root  p. 50

  • Threat name: Tampering of target API root
  • Threat Category: Denial of Service, Information Disclosure
  • Threat Description: TLS protection between the SEPP and NFs within a PLMN may rely on using telescopic FQDN or 3gpp-Sbi-Target-apiRoot header. Security mechanism negotiated between the SEPPs can be TLS security or PRINS security, and PRINS security shall be used if there are IPX entities on the path between the SEPPs. When PRINS security is used between the SEPPs and 3gpp-Sbi-Target-apiRoot header is used between the NF and the SEPP, the HTTP Request from the NF received by the SEPP will include the 3gpp-Sbi-Target-apiRoot header, which is set to the apiRoot of the target NF. If the sending SEPP forwards the 3gpp-Sbi-Target-apiRoot header together with the HTTP Request on the N32-f interface, there are potentially two threats:
    • Even if both negotiating SEPPs support the 3gpp-Sbi-Target-apiRoot custom HTTP header, the IPX entities on the path between the SEPPs may possibly not support this custom HTTP header, which will lead to failed message transmission. This can result in Denial of Service.
    • Even if all the IPX entities on the path between the SEPPs support the 3gpp-Sbi-Target-apiRoot custom HTTP header, the apiRoot of the target NF in the 3gpp-Sbi-Target-apiRoot header could be potentially modified by a malicious IPX entity, which will lead to the message delivery to the incorrect target. This can result in Information Disclosure and Denial of Service.
  • Threatened Asset: SEPP Application, Service Messages to be sent/received over N32.
Up

Up   Top   ToC