Content for  TS 33.501  Word version:  18.4.0

NF Service based discovery and registration shall support confidentiality, integrity, and replay protection. NRF shall be able to ensure that NF Discovery and registration requests are authorized. NF Service based discovery and registration shall be able to hide the topology of the available / supported NF's in one administrative/trust domain from entities in different trust/administrative domains (e.g. between NFs in the visited and the home networks.) NF Service Request and Response procedure shall support mutual authentication between NF Service Consumer and NF Service Producer. Each NF shall validate all incoming messages. Messages that are not valid according to the protocol specification and network state shall be either rejected or discarded by the NF.

The Network Repository Function (NRF) receives NF Discovery Request from an NF instance, provides the information of the discovered NF instances to the NF instance, and maintains NF profiles. The NRF receives from NF Service Consumers or SCPs access token requests for service consumption and provides authorization tokens. The NRF shall act as authorization server.The following NRF service-based architecture security requirements shall apply:

• NRF and NFs that are requesting service shall be mutually authenticated.
• NRF may provide authentication and authorization to NFs for establishing secure communication between each other.

The Network Exposure Function (NEF) supports external exposure of capabilities of Network Functions to Application Functions, which interact with the relevant Network Functions via the NEF. The interface between the NEF and the Application Function shall fulfil the following requirements:

• Integrity protection, replay protection and confidentiality protection for communication between the NEF and Application Function shall be supported.
• Mutual authentication between the NEF and Application Function shall be supported.
• Internal 5G Core information such as DNN, S-NSSAI etc., shall not be sent outside the 3GPP operator domain.
• SUPI shall not be sent outside the 3GPP operator domain by NEF.

The NEF shall be able to determine whether the Application Function is authorized to interact with the relevant Network Functions..

The SCP has interfaces with Network Functions (NF) and peer SCPs within the PLMN (or SNPN). The interface between the SCP and the NFs and between the two SCPs shall fulfil the following requirements:

• Mutual authentication shall be performed between the SCP and NFs, and between the two SCPs within the PLMN (or SNPN).
• All communication between the SCP and NFs and between SCPs shall be confidentiality, integrity and replay protected.

If SCP endpoints are co-located with the NFs, the above two requirements may be satisfied by colocation. The SCP shall provide confidentiality, integrity and replay protection for its internal communication over SCP internal network interfaces. If the signalling message (service/subscription request or notification message) from the sending NF does not include the PLMN ID or SNPN ID in the 3gpp-Sbi-Originating-Network-Id header and the sending SCP can determine the PLMN ID or SNPN ID value to be included in the 3gpp-Sbi-Originating-Network-Id header, the sending SCP should include it.

The present subclause contains requirements common to subclauses 5.9.2 and 5.9.3. A solution for e2e core network interconnection security shall satisfy the following requirements:

• The solution shall support application layer mechanisms for addition, deletion and modification of message elements by intermediate nodes except for specific message elements described in the present document.
• The solution shall provide confidentiality and/or integrity end-to-end between source and destination network for specific message elements identified in the present document. For this requirement to be fulfilled, the SEPP - cf clause 6.2.17 of TS 23.501 shall be present at the edge of the source and destination networks dedicated to handling e2e Core Network Interconnection Security. The confidentiality and/or integrity for the message elements is provided between two SEPPs of the source and destination PLMN-.
• The destination network shall be able to determine the authenticity of the source network that sent the specific message elements protected according to the preceding bullet. For this requirement to be fulfilled, it shall suffice that a SEPP in the destination network that is dedicated to handling e2e Core Network Interconnection Security can determine the authenticity of the source network.
• The solution should have minimal impact and additions to 3GPP-defined network elements.
• The solution should be using standard security protocols.
• The solution shall cover interfaces used for roaming purposes.
• The solution should take into account considerations on performance and overhead.
• The solution shall cover prevention of replay attacks.
• The solution shall cover algorithm negotiation and prevention of bidding down attacks.
• The solution should take into account operational aspects of key management.

The SEPP shall act as a non-transparent proxy node:

• The SEPP shall protect application layer control plane messages between two NFs belonging to different PLMNs or SNPNs that use the N32 interface to communicate with each other.
• The SEPP shall perform mutual authentication and negotiation of cipher suites with the SEPP in the roaming network.
• The SEPP shall handle key management aspects that involve setting up the required cryptographic keys needed for securing messages on the N32 interface between two SEPPs.
• The SEPP shall perform topology hiding by limiting the internal topology information visible to external parties.
• As a reverse proxy the SEPP shall provide a single point of access and control to internal NFs.

The receiving SEPP shall be able to verify whether the sending SEPP is authorized to use the PLMN ID or SNPN ID in the received N32 message. The SEPP to SEPP communication may go via up to two Roaming Intermediaries. The changes made by Roaming Intermediaries to messages originated by a SEPP, based on the originating PLMNs policy, shall be identifiable by the receiving SEPP. The SEPP shall be able to clearly differentiate between certificates used for authentication of peer SEPPs and certificates used for authentication of Roaming Intermediaries performing message modifications. The SEPP shall support multiple trust anchors. The SEPP shall discard malformed N32 signaling messages. The sending SEPP shall reject messages received from the NF (directly or via SCP) with JSON including "encBlockIndex" (regardless of the encoding used for that JSON request). The receiving SEPP shall reject any message in which a Roaming Intermediary has inserted or relocated references to encBlockIndex. The SEPP shall implement rate-limiting functionalities to defend itself and subsequent NFs against excessive CP signaling. This includes SEPP-to-SEPP signaling messages. The SEPP shall implement anti-spoofing mechanisms that enable cross-layer validation of source and destination address and identifiers (e.g. FQDNs or PLMN IDs). The SEPP shall be able to use one or more PLMN IDs (or SNPN IDs). In the situation that a PLMN (or SNPN) is using more than one PLMN ID (or SNPN ID), this PLMN's SEPP (or SNPN's SEPP) may use the same N32-connection for all of the networks PLMN IDs (or SNPN IDs), with each of the PLMN's (or SNPN's) remote partners. If different PLMNs (or SNPNs) are represented by the PLMN IDs (or SNPN IDs) supported by a SEPP, the SEPP shall use separate N32-connections for each pair of home and visited PLMN (or SNPN). Error messages may be originated from either PLMN SEPPs or Roaming Hubs to adjacent Roaming Hubs or adjacent PLMN SEPPs, in an identifiable way. If allowed by the PLMN policy, the SEPP shall be able to send error messages on the N32 interface to a roaming hub. Specific error messages relevant to Roaming Hubs shall be supported (such as 'an IE is encrypted while it was expected to be available in the clear', 'an IE is not encrypted while its availability in the clear is not required', 'the N32 connection cannot be setup due to contractual reasons', 'the N32 connection cannot be setup due to a connectivity issue' and 'the message was not delivered due to contractual reasons'). Sending SEPP behavior for the 3gpp-Sbi-Originating-Network-Id header specified in TS 29.500:

• If the sending NF or the SCP has inserted the 3gpp-Sbi-Originating-Network-Id header in the signaling message (service/subscription request or notification message), the sending SEPP shall compare the PLMN ID or SNPN ID in the 3gpp-Sbi-Originating-Network-Id header in the received signaling message with the PLMN ID(s) or SNPN ID(s) that the sending SEPP represents by its certificate.
  • If the PLMN ID or SNPN ID does not match with any of the PLMN IDs that the sending SEPP represents, the sending SEPP shall discard the received signaling message.
  • If the PLMN ID or SNPN ID matches with any of the PLMN IDs that the sending SEPP represents, the sending SEPP shall forward the signaling message to the receiving SEPP.
• If the sending NF and the SCP have not included the 3gpp-Sbi-Originating-Network-Id header in the signalling message, the sending SEPP shall include the 3gpp-Sbi-Originating-Network-Id header and send the updated signaling message to the receiving SEPP.
  • If the sending SEPP only represents one PLMN ID or SNPN ID, the sending SEPP shall insert the 3gpp-Sbi-Originating-Network-Id header with this ID.
  • If the sending SEPP represents multiple PLMN IDs or SNPN IDs, it is up to configuration and deployment to determine which PLMN ID or SNPN ID value should be included in the header.

Receiving SEPP behavior for the 3gpp-Sbi-Originating-Network-Id header:

• The receiving SEPP shall check whether the 3gpp-Sbi-Originating-Network-Id header included in the signalling message belongs to the sending SEPP's own PLMN or SNPN. It does this by verifying that the asserted PLMN ID in the 3gpp-Sbi-Originating-Network-Id header matches one of the sending SEPP's own PLMN ID(s) or SNPN ID(s) either in the N32-f context, the sending SEPP's certificate, or a locally configured list of PLMN IDs or SNPN-IDs that the sending SEPP represents.
  • If the 3gpp-Sbi-Originating-Network-Id header does not match with any of the PLMN IDs or SNPN IDs belonging to the peer sending SEPP, the receving SEPP shall discard the received signaling message.
  • If the 3gpp-Sbi-Originating-Network-Id header matches with any PLMN ID of the PLMN or SNPN IDs belonging to the peer sending SEPP, the header is successfully verified, and the receiving SEPP shall forward the received signaling message to the target NF.

A PLMN SEPP that makes use of Roaming Intermediaries shall be able to handle error messages generated by Roaming Intermediaries, delivered over the N32 connection. The following error messages relevant to Roaming Hub shall be supported,

• 'an IE is encrypted while it was expected to be available in the clear',
• 'an IE is not encrypted while its availability in the clear is not required',
• 'the N32 connection cannot be setup due to contractual reasons',
• 'the N32 connection cannot be setup due to a connectivity issue', and
• 'the message was not delivered due to contractual reasons'.

The mechanism used by the SEPP for setting up N32-c via a chain of Roaming Intermediaries shall contain sufficient information such that the target PLMN and the Roaming Intermediaries can determine the identities of the initiating PLMN and the target PLMN. Note: The Roaming Intermediary can reject the N32-c connection if no roaming relation exists. In this case, the expected error is "the N32 connection cannot be setup due to contractual reasons". Additionally, it shall be possible for the Roaming Hubs to generate application layer control plane messages in order to reject traffic. Application layer control plane messages may be generated by the Roaming Hubs in order to reject registration attempts (refer to clause 4.2.2.2 of TS 23.502), to terminate sessions (see clause 4.3.4.3 of TS 23.502) and/or deregister the UE (refer to clause 4.2.2.3.3 of TS 23.502) and shall be sent using the corresponding NF Service operation to the NF, when relevant decisions are enforced by the Roaming Hub. In this case, such messages are transparent to the SEPP and the SEPP shall act on them as any other message on the N32-f interface not making use of Roaming Intermediaries. How the SEPP authorizes such messages is left to implementation.

Integrity protection shall be applied to all attributes transferred over the N32-f interface. Confidentiality protection shall be applied to all attributes specified in SEPP's Data-type Encryption Policy (clause 13.2.3.2). The following attributes shall be confidentiality protected when being sent over the N32-f interface, irrespective of the Data-type Encryption Policy:

• Authentication Vectors.
• Cryptographic material.
• Location data, e.g. Cell ID and Physical Cell ID.
• Content of SMS in case of SMS over SBI over N32.
• Authorization token.

The following attributes should additionally be confidentiality protected when being sent over the N32-f interface:

• SUPI.

The IPUPS shall only forward GTP-U packets that contain an F-TEID that belongs to an active PDU session and discard all others. The IPUPS shall discard malformed GTP-U messages.

The NF that sends a signalling message (service/subscription request or notification message) shall include its PLMN ID or SNPN ID in the 3gpp-Sbi-Originating-Network-Id header. If an NF supports multiple PLMN IDs or SNPN IDs, the sending NF shall include the PLMN ID or SNPN ID in the 3gpp-Sbi-Originating-Network-Id header on behalf of which the message is sent. The handling of the PLMN ID or SNPN ID in the 3gpp-Sbi-Originating-Network-Id header at the receiving NF is up to configuration and deployment.