5G Core Network Security

Acronyms

NDS - Network Domain Security
NF - Network Function
NRF - Network Repository Function
NEF - Network Exposure Function
SBA - Service Based Architecture
NDS/IP - Network Domain Security for IP based protocols
IPX - IP eXchange Service
PLMN - Public Land Mobile Network: A telecommunications network providing mobile cellular services.
SEPP - Security Edge Protection Proxy
DNN - Data Network Name
S-NSSAI Single Network Slice Selection Assistance Information
SUPI - Subscription Permanent Identifier
JWE - JSON Web Encryption
JWS - JSON Web Signatures
FQDNs - Fully Quantified Domain Name
SEGs - Security Gateways
N32 - Reference point between SEPP in the visited network and the SEPP in the home network
IKE - Internet Key Exchange

Signalling

In telecommunication, signaling is the use of signals for controlling communications. This may constitute an information exchange concerning the establishment and control of a telecommunication circuit and the management of the network.

A telecommunication circuit is any line, conductor, or other conduit by which information is transmitted.

Planes

Control Plane

Control Plane makes decisions about where traffic is sent.

Control plane packets are destined to or locally originated by the router itself.

The control plane functions include the system configuration, management, and exchange of routing table information.

The route controller exchanges the topology information with other routers and constructs a routing table based on a routing protocol, for example, RIP, OSPF or BGP.

Control plane packets are processed by the router to update the routing table information.

It is the Signalling of the network.

Since the control functions are NOT performed on each arriving individual packet, they do NOT have a strict speed constraint and are less time-critical.

Data Plane

Also known as Forwarding Plane.

Forwards traffic to the next hop along the path to the selected destination network according to control plane logic.

Data plane packets go through the router
The routers/switches use what the control plane built to dispose of incoming and outgoing frames and packets

Example 1

The protocol or application itself doesn’t really determine whether the traffic is control, management, or data plane, but more importantly how the router processes it. Consider a 3 router topology with routers R1, R2 and R3. Lets say a Telnet session is established from R1 to R3. On both of these routers the packets need to be handled by the control/management plane. However from R2′s perspective this is just data plane traffic that is transiting between its links.

Example 2

• Control Plane => Learning what we will do

  Our planning stage, which includes learning which paths the buses will take, is similar to the control plane in the network. We haven’t picked up people yet, nor have we dropped them off, but we do know the paths and stops due to our plan. The control plane is primarily about the learning of routes.

• Data Plane => Actually moving the packets based on what we learned.

  The data plane is the actual movement of the customers data packets over the transit path we learned in the control plane stage.

Security domains

Security domains and interfaces

The network domain of an NDS/IP-network shall be logically and physically divided into security domains. These control plane security domains may closely correspond to the core network of a single operator and shall be separated by means of security gateways.

Security Gateways (SEGs)

Security Gateways (SEGs) are entities on the borders of the IP security domains and will be used for securing native IP based protocols. The SEGs are defined to handle communication over the Za-interface, which is located between SEGs from different IP security domains.
All NDS/IP traffic shall pass through a SEG before entering or leaving the security domain. Each security domain can have one or more SEGs. Each SEG will be defined to handle NDS/IP traffic in or out of the security domain towards a well-defined (easy to see or understand) set of reachable IP security domains.

The number of SEGs in a security domain will depend on the need to differentiate between the externally reachable destinations, the need to balance the traffic load and to avoid single points of failure. The security gateways shall be responsible for enforcing security policies for the interworking between networks. The security may include filtering policies and firewall functionality NOT required in this specification.

SEGs are responsible for security sensitive operations and shall be physically secured. They shall offer capabilities for secure storage of long-term keys used for IKE authentication.

Trust boundaries

It is assumed for the set of requirements in this sub-clause that mobile network operators subdivide their networks into trust zones. Subnetworks of different operators are assumed to lie in different trust zones.

Messages that traverse (move across) trust boundaries shall follow the requirements in next clause of the present article, if not protected end to end by NDS/IP (Network Domain Security for IP based protocols) as specified in TS 33.210.

The scope of network domain control plane security is to cover the control signaling on selected interfaces between network elements of NDS/IP networks. NDS/IP serves as a central repository for cryptographic profiles for security above IP layer.

Requirements on SBA (service-based architecture)

Security Requirements for service registration, discovery and authorization

• 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 (the arrangement in which the nodes of a LAN are connected to each other) of the available/supported NF's in one administrative/trust domain from entities in different trust/administrative domains (e.g. between NFs in visited and the home networks.)

• NF Service Request and Response procedure shall support mutual authentication between NF consumer and NF 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.

NRF security requirements

The Network Repository Function (NRF)

1. receives NF Discovery Request from an NF instance
2. provides the information of the discovered NF instances to the NF instance
3. maintains NF profiles.

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

NEF security requirements

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 (Data Network Name), S-NSSAI (Single Network Slice Selection Assistance Information) etc., shall NOT be sent outside the 3GPP operator domain.

• SUPI (Subscription Permanent Identifier) 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.

Requirements for e2e (end to end) core network interconnection security

General

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 article.

  NOTE: Typical example for such a case is IPX (IP eXchange Service) providers modifying messages for routing purposes.

• The solution shall provide confidentiality and/or integrity end-to-end between source and destination network for specific message elements identified in the present article.

  For this requirement to be fulfilled, the Security Edge Protection Proxy (SEPP) – cf 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 (item).

  For this requirement to be fulfilled, it shall suffice (be sufficient) 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 should take into account operational aspects of key management.

• The solution shall cover algorithm negotiation and prevention of bidding down attacks.

Bidding down attacks

bidding down attacks aim at coercing participants in Mobile IPv6 route optimization to forgo (give up) the stronger methods for the default return routability.

Alice wants to engage Bob in an exchange, and Mallory wishes to affect the result of the exchange such that they end up using the weak method by which Alice can NOT provide cryptographical assurances to Bob about some of its properties, including its address..

Application layer security on the N32 interface

General

N32 - Reference point between SEPP in the visited network and the SEPP in the home network

The internetwork interconnect allows secure communication between service-consuming and a service-producing NFs in different PLMNs. Security is enabled by the Security Edge Protection Proxies (SEPP) of both networks, henceforth (starting now) called cSEPP and pSEPP respectively. The SEPPs enforce protection policies regarding application layer security thereby (by means of it) ensuring integrity and confidentiality protection for those elements to be protected.

It is assumed that there are interconnect providers between cSEPP and pSEPP. The interconnect provider the cSEPP's operator has a business relationship with is called cIPX, while the interconnect provider the pSEPP's operator has a business relationship with is called pIPX. There could be further interconnect providers in between cIPX and pIPX, but they are assumed to be transparent and simply forward the communication.

The SEPPs use JSON Web Encryption (JWE, specified in RFC 7516 [59]) for protecting messages on the N32 interface, and the IPX providers use JSON Web Signatures (JWS, specified in RFC 7515 [45]) for signing their modifications needed for their mediation services.

Illustration

For illustration, consider the case where a service-consuming NF sends a message to a service-producing NF. This communication is across PLMN operators over the N32 interface, as shown in figure below.

1. The cSEPP receives the message and applies symmetric key based application layer protection, as defined in clause 13.2 of the present document.

2. The resulting JWE object is forwarded to intermediaries. The pIPX and cIPX can offer services that require modifications of the messages transported over the interconnect (N32) interface.

3. These modifications are appended to the message as digitally signed JWS objects which contain the desired changes.

4. The pSEPP, which receives the message from pIPX, validates the JWE object, extracts the original message sent by the NF, validates the signature in the JWS object and applies patches corresponding to the modifications by intermediaries. The pSEPP then forwards the message to the destination NF.

The N32 interface consists of:

• N32-c connection, for management of the N32 interface, and
• N32-f connection, for sending of JWE and JWS protected messages between the SEPPs.
  The application layer security protocol for the N32 interface described in clause 13.2 of the present document is called PRINS.

Overview of PRINS

Requirements for Security Edge Protection Proxy (SEPP)

• 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 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 (get something by effort) 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 in the received N32 message.

• The SEPP shall be able to clearly differentiate between

  1. certificates used for authentication of peer SEPPs and
  2. certificates used for authentication of intermediates performing message modifications.

  NOTE: Such a differentiation could be done e.g. by implementing separate certificate storages.

• The SEPP shall discard malformed N32 signaling messages.

• The SEPP shall implement rate-limiting functionalities to defend itself and subsequent NFs against excessive CP (control plane) 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 (Fully Quantified Domain Name) or PLMN IDs).

  NOTE: An example for such an anti-spoofing mechanism is the following:

The message will be discarded if

1. There is a mismatch between different layers of the message or
2. The destination address does not belong to the SEPP’s own PLMN

Protection of attributes

• Integrity protection shall be applied to all attributes transferred over the N32 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 interface, irrespective of (regardless of / in spite of) the Data-type Encryption Policy:

• Authentication Vectors

• Cryptographic material

• Location data, e.g. Cell ID and Physical Cell ID

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

• SUPI