Methods, systems, and computer-readable media for mitigating spoofing attacks on a secure edge protection proxy (SEPP) inter-public land mobile network (inter-PLMN) forwarding interface

Abstract

A method for mitigating a spoofing attack on an inter-PLMN forwarding interface of a SEPP includes obtaining, by a responding SEPP, a first SEPP identifier and / or a first PLMN identifier from at least one message received over an inter-PLMN control interface. The method further includes storing the first SEPP identifier and / or the first PLMN identifier in an identity cross-verification database. The method further includes obtaining a second SEPP identifier and / or a second PLMN identifier from at least one message received over an inter-PLMN forwarding interface, performing a lookup in the identity cross-verification database using a lookup key comprising at least one of the second SEPP identifier and the second PLMN identifier, determining that a record corresponding to the lookup key is not present in the identity cross-verification database, and in response, preventing the at least one message received over the inter-PLMN forwarding interface from entering a PLMN protected by the responding SEPP.

Description

[0001] CLAIM OF PRIORITY

[0002] This application claims the priority benefit of U.S. Patent Application Serial No. 17 / 129,441, filed December 21, 2020, U.S. Patent Application Serial No. 17 / 095,420, filed November 11, 2020, Indian Provisional Patent Application Serial No. 202041047779, filed November 2, 2020, and Indian Provisional Patent Application Serial No. 202041041754, filed September 25, 2020, the disclosures of which are incorporated herein by reference in their entirety. TECHNICAL FIELD

[0003] The subject matter described herein relates to enhancing security in 5G communication networks. More specifically, the subject matter described herein relates to methods, systems, and computer readable media for mitigating impersonation attacks on a SEPP inter-PLMN forwarding interface. BACKGROUND

[0004] In a 5G telecommunications network, a network node that provides a service is referred to as a producer network function (NF). A network node that consumes a service is referred to as a consumer NF. A network function can be both a producer NF and a consumer NF, depending on whether it is consuming or providing a service.

[0005] A given producer NF can have many service endpoints, where a service endpoint is a contact point for one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of an Internet Protocol (IP) address and a port number, or a fully qualified domain name that resolves to an IP address and a port number on the network node hosting the producer NF. An NF instance is an instance of a producer NF that provides a service. A given producer NF can include more than one NF instance. It should also be noted that multiple NF instances can share the same service endpoint.

[0006] A producer NF registers with a network function repository function (NRF). The NRF maintains service profiles of available NF instances that identify the services supported by each NF instance. A consumer NF can subscribe to receive information about producer NF instances that have registered with the NRF.

[0007] In addition to a consumer NF, another type of network node that can subscribe to receive information about NF service instances is a service communication proxy (SCP). The SCP subscribes with the NRF and obtains reachability and service profile information about producer NF service instances. A consumer NF connects to the SCP and the SCP load balances traffic among producer NF service instances that provide the required service, or routes the traffic directly to the destination producer NF instance.

[0008] In addition to SCPs, other examples of intermediary proxy nodes or groups of network nodes that route traffic between producer and consumer NFs include Security Edge Protection Proxies (SEPPs), service gateways, and nodes in a 5G service mesh. SEPPs are network nodes used to protect control plane traffic exchanged between different 5G Public Land Mobile Networks (PLMNs). As such, SEPPs perform message filtering, policing, and topology hiding on all Application Programming Interface (API) messages.

[0009] One vulnerability in the current 5G network architecture occurs on the N32 interface, which is the interface between SEPPs. As indicated above, SEPPs act as security screening nodes for Public Land Mobile Networks (PLMNs). The N32 control or N32-c interface is used to exchange control messages with a remote SEPP. Initiation of communications on the N32-c interface involves a Transport Layer Security (TLS) handshake procedure in order to establish a TLS connection for exchanging N32 control messages. After exchanging N32-c messages, a second TLS handshake occurs in order to establish a second TLS connection for the N32 forwarding or N32-f interface. The only verification that occurs on the N32-f interface is that the TLS certificate is valid and issued by a trusted certificate authority. Thus, a hacker SEPP can impersonate the identity of a real SEPP and engage in unauthorized service communications with a SEPP-protected PLMN on the forwarding interface. There is also no verification of the PLMN in the service messages received over the inter-PLMN forwarding interface.

[0010] In view of these and other difficulties, there is a need for methods, systems, and computer-readable media for mitigating impersonation attacks on the SEPP inter-PLMN forwarding interface. SUMMARY

[0011] A method for mitigating a spoofing attack on a security edge protection proxy (SEPP) public land mobile network inter (PLMN inter) forwarding interface includes obtaining, by a responding SEPP, at least one of a first SEPP identifier and a first PLMN identifier from at least one message received over a PLMN inter control interface. The method further includes storing the at least one of the first SEPP identifier and the first PLMN identifier in a SEPP PLMN inter forwarding interface identity cross-verification database. The method further includes obtaining, by the responding SEPP, at least one of a second SEPP identifier and a second PLMN identifier from at least one message received over a PLMN inter forwarding interface. The method further includes performing a lookup in the SEPP PLMN inter forwarding interface identity cross-verification database using a lookup key comprising the at least one of the second SEPP identifier and the second PLMN identifier. The method further includes determining that a record corresponding to the lookup key is not present in the SEPP PLMN inter forwarding interface identity cross-verification database, and in response, preventing the at least one message received over the PLMN inter forwarding interface from entering a PLMN protected by the responding SEPP.

[0012] According to another aspect of the subject matter described herein, the PLMN inter control interface comprises an N32-c interface and the PLMN inter forwarding interface comprises an N32-f interface.

[0013] According to another aspect of the subject matter described herein, obtaining the at least one of the first SEPP identifier and the first PLMN identifier from the at least one message received over the PLMN inter control interface comprises obtaining the first SEPP identifier from a first certificate included in a first transport layer security (TLS) certificate message received over the PLMN inter control interface during a TLS handshake to establish a first TLS connection for the N32-c interface.

[0014] According to another aspect of the subject matter described herein, the first certificate comprises a first X.509 certificate.

[0015] According to another aspect of the subject matter described herein, obtaining the first SEPP identifier comprises extracting the first SEPP identifier from a subject alternative name extension of the first X.509 certificate.

[0016] According to another aspect of the subject matter described herein, obtaining the at least one of the second SEPP identifier and the second PLMN identifier from the at least one message received over the PLMN inter forwarding interface comprises obtaining the second SEPP identifier from a second certificate included in a second TLS certificate message received during a TLS handshake to establish a second TLS connection for the N32-f interface.

[0017] According to another aspect of the subject matter described herein, the second certificate comprises a second X.509 certificate.

[0018] According to another aspect of the subject matter described herein, obtaining the second SEPP identifier includes extracting the second SEPP identifier from a subject alternative name extension of the second X.509 certificate.

[0019] According to another aspect of the subject matter described herein, obtaining the first SEPP identifier and the first PLMN identifier from the at least one message received over the inter-PLMN control interface includes obtaining the first SEPP identifier from a first TLS certificate message received during a TLS handshake for setting up a first TLS connection for the inter-PLMN control interface and obtaining the first PLMN identifier from an N32-c security capabilities exchange message received over the first TLS connection, and obtaining the second SEPP identifier and the second PLMN identifier from the at least one associated message received over the inter-PLMN forwarding interface includes obtaining the second SEPP identifier from a second TLS certificate message received during a TLS handshake for setting up a second TLS connection for the inter-PLMN forwarding interface and obtaining the second PLMN identifier from a 5G service message received over the second TLS connection.

[0020] According to another aspect of the subject matter described herein, the lookup key includes a tuple including the second SEPP identifier and the second PLMN identifier.

[0021] According to another aspect of the subject matter described herein, a system for mitigating spoofing attacks on a security edge protection proxy (SEPP) inter-public land mobile network (inter-PLMN) forwarding interface is provided. The system includes a security edge protection proxy (SEPP) including at least one processor and a memory. The system also includes a SEPP inter-PLMN forwarding interface identity cross-verification database residing in the memory. The system also includes an inter-PLMN forwarding interface identity spoofing mitigation module implemented by the at least one processor and configured to: obtain a first SEPP identifier and a first PLMN identifier from at least one message received over an inter-PLMN control interface; store at least one of the first SEPP identifier and the first PLMN identifier in the SEPP inter-PLMN forwarding interface identity cross-verification database; obtain at least one of a second SEPP identifier and a second PLMN identifier from at least one message received over an inter-PLMN forwarding interface; perform a lookup in the SEPP inter-PLMN forwarding interface identity cross-verification database using a lookup key including at least one of the second SEPP identifier and the second PLMN identifier; determine that a record corresponding to the lookup key does not exist in the SEPP inter-PLMN forwarding interface identity cross-verification database, and in response, prevent the at least one message received over the inter-PLMN forwarding interface from entering a PLMN protected by the SEPP.

[0022] According to another aspect of the subject matter described herein, the inter-PLMN forwarding interface identity impersonation mitigation module is configured to extract the first SEPP identifier from a subject alternative name extension of the first X.509 certificate.

[0023] According to another aspect of the subject matter described herein, the second certificate comprises a second X.509 certificate, and the inter-PLMN forwarding interface identity impersonation mitigation module is configured to obtain the second identifier by extracting the second identifier from a subject alternative name extension of the X.509 certificate.

[0024] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer, cause the computer to perform steps is provided. The steps include obtaining, by a responding security edge protection proxy (SEPP), at least one of a first SEPP identifier and a first PLMN identifier from at least one message received over an inter-public land mobile network (inter-PLMN) control interface. The steps also include storing the at least one of the first SEPP identifier and the first PLMN identifier in a SEPP inter-PLMN forwarding interface identity cross-verification database. The steps also include obtaining, by the responding SEPP, at least one of a second SEPP identifier and a second PLMN identifier from at least one message received over an inter-PLMN forwarding interface. The steps also include performing a lookup in the SEPP inter-PLMN forwarding interface identity cross-verification database using a lookup key comprising the at least one of the second SEPP identifier and the second PLMN identifier. The steps also include determining that a record corresponding to the lookup key is not present in the SEPP inter-PLMN forwarding interface identity cross-verification database, and in response, preventing the at least one message received over the inter-PLMN forwarding interface from entering a PLMN protected by the responding SEPP.

[0025] The subject matter described herein can be implemented in hardware, software, firmware, or any combination thereof. As used herein the term "functionality" "node" or "module" refers to hardware that is used to implement the described feature, which can also include software and / or firmware components. In one exemplary implementation, the subject matter described herein can be implemented using a computer readable medium having stored thereon computer executable instructions that, as a result of being executed by the processor of a computer, cause the computer to perform the steps. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory computer readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein can reside on a single device or computing platform or can be distributed across multiple devices or computing platforms. BRIEF DESCRIPTION OF DRAWINGS

[0026] The subject matter described herein will now be explained with reference to the drawing, wherein:

[0027] Figure 1 is a network diagram illustrating an exemplary 5G network architecture;

[0028] Figure 2 is a network diagram illustrating two SEPPs and an interface between the SEPPs;

[0029] Figure 3 is a message flow diagram illustrating exemplary messages exchanged between a client and a server in a TLS handshake;

[0030] Figure 4 is a network diagram illustrating a hacker impersonating a SEPP;

[0031] Figure 5 is a message flow diagram illustrating exemplary messages exchanged between SEPPs when an attacker SEPP successfully impersonates a legitimate SEPP on the N32-f interface;

[0032] Figure 6 is a message flow diagram illustrating screening of SEPP identities presented on the N32-f interface;

[0033] Figure 7 is a block diagram illustrating an exemplary architecture of a SEPP for mitigating impersonation attacks on the SEPP inter-PLMN forwarding interface; and

[0034] Figure 8 is a flow diagram illustrating an exemplary method for mitigating impersonation attacks on the SEPP inter-PLMN forwarding interface. DETAILED DESCRIPTION

[0035] The subject matter described herein relates to methods, systems, and computer readable media for mitigating 5G roaming impersonation attacks on the inter-PLMN forwarding interface of a SEPP. Figure 1 is a block diagram illustrating an exemplary 5G system network architecture. Figure 1 The architecture in FIG. 1 includes an NRF 100 and an SCP 101, which can be located in the same home public land mobile network (HPLMN). As described above, the NRF 100 can maintain profiles of available producer NF service instances and their supported services, and allow consumer NFs or SCPs to subscribe and be notified of registration of new / updated producer NF service instances. The SCP 101 can also support service discovery and selection of producer NF instances. The SCP 101 can perform load balancing for connections between consumer and producer NFs. In addition, using the methods described herein, the SCP 101 can perform selection and routing based on preferred NF locations.

[0036] The NRF 100 is a repository of service profiles for NFs or producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP must obtain an NF or service profile or producer NF instance from the NRF 100. An NF or service profile is a JavaScript Object Notation (JSON) data structure defined in Third Generation Partnership Project (3GPP) Technical Specification (TS) 29.510. An NF or service profile defines at least one of a fully qualified domain name (FQDN), an Internet Protocol (IP) version 4 (IPv4) address, or an IP version 6 (IPv6) address. In Figure 1 In general, any of the nodes (except the NRF 100) can be a consumer NF or a producer NF, depending on whether they are requesting services or providing services. In the illustrated example, the nodes include a Policy Control Function (PCF) 102 that performs policy-related operations in the network, a Unified Data Management (UDM) function 104 that manages user data, and an Application Function (AF) 106 that provides application services. Figure 1 The nodes illustrated in include a Session Management Function (SMF) 108 that manages sessions between an Access and Mobility Management Function (AMF) 110 and the PCF 102. The AMF 110 performs mobility management operations similar to those performed by a Mobility Management Entity (MME) in a 4G network. An Authentication Server Function (AUSF) 112 performs authentication services for user equipment (UE) such as a UE 114 that seeks to access the network.

[0037] A Network Slice Selection Function (NSSF) 116 provides network slice services for devices that seek to access particular network capabilities and characteristics associated with a network slice. A Network Exposure Function (NEF) 118 provides an application programming interface (API) for application functions that seek to obtain information about Internet of Things (IoT) devices and other UEs attached to the network. The NEF 118 performs similar functions to a Service Capability Exposure Function (SCEF) in a 4G network.

[0038] A Radio Access Network (RAN) 120 connects the user equipment (UE) 114 to the network via a wireless link. The radio access network 120 can be accessed using a g-Node B (gNB) (not shown in Figure 1 A User Plane Function (UPF) 122 can support various proxy functions for user plane services. One example of such a proxy function is a multi-path transmission control protocol (MPTCP) proxy function. The UPF 122 can also support a performance measurement function that can be used by the UE 114 to obtain network performance measurements. Figure 1 Also illustrated in is a Data Network (DN) 124 through which the UE accesses data network services, such as Internet services.

[0039] The SEPP 126 filters incoming traffic from another PLMN and performs topology hiding for traffic leaving the home PLMN. The SEPP 126 can communicate with SEPPs in external PLMNs that manage security for the external PLMNs. Thus, traffic between NFs in different PLMNs can pass through two SEPP functions, one for the local PLMN and one for the external PLMN.

[0040] As noted above, one problem with the existing 5G architecture is that there is no verification of the SEPP identity or PLMN identity presented on the inter-PLMN forwarding interface of the SEPP. Without verification of the SEPP identity or PLMN on the inter-PLMN forwarding interface, a malicious SEPP can attempt to spoof the identity of another SEPP or PLMN identity and initiate security attacks, including denial of service attacks, using service traffic transported over the forwarding interface. The responding SEPP does not verify that the SEPP or PLMN identity presented on the inter-PLMN forwarding interface is from a legitimate initiating SEPP and / or PLMN. As used herein, the term “initiating SEPP” refers to the SEPP that requests a TLS connection on the inter-PLMN control interface and the inter-PLMN forwarding interface. The term “responding SEPP” refers to the SEPP that receives the request for a TLS connection on the inter-PLMN control interface and the inter-PLMN forwarding interface. The subject matter described herein addresses this and other difficulties by cross-verifying the identity of the SEPP presented on the inter-PLMN forwarding interface with the identity of the SEPP presented on the inter-PLMN control interface.

[0041] In the 3GPP network architecture, the SEPP is the proxy for inter-PLMN control messages. According to 3GPP TS 33.501, the SEPP provides message protection, mutual authentication, key management, topology hiding, access control, malformed N32 signaling drop messages, rate limiting, and anti-spoofing. The subject matter described herein includes implementing anti-spoofing for communications on the N32-f interface.

[0042] Figure 2 Figure illustrates the SEPP and interfaces between SEPPs. Referring to Figure 2 , the SEPP 126A and the SEPP 126B communicate over the N32 interface. The N32 interface includes two different interfaces, the N32-c interface and the N32-f interface. The N32-c interface is a control plane interface between SEPPs that is used to perform an initial handshake and negotiate parameters to be applied during N32 message forwarding. The N32-f interface is a forwarding interface between SEPPs that is used to forward communications between NF service consumers and NF service producers after applying application level security protection.

[0043] In addition to the N32 interface,Figure 2 PRINS interfaces are also illustrated. PRINS interfaces are used to forward messages between SEPPs 126A and 126B via one or more IP exchange (IPX) providers 200 and 202. However, the subject matter described herein is interested in the N32-c and N32-f TLS connections.

[0044] For secure communications, separate TLS connections are established on the N32-c and N32-f interfaces. Figure 3 An exemplary message exchange between a client and a server in a TLS handshake for establishing a TLS connection is illustrated. In Figure 3 The client sends a ClientHello message to the server. The server then sends ServerHello, Certificate, ServerKeyExchange, CertificateRequest, and ServerHelloDone messages to the client. In response to these messages, the client sends a Certificate message, a ClientKeyExchange message, a CertificateVerify message, and a Finished message to the server. The Certificate message from the client to the server is used by the responding SEPP (acting as a server to establish the TLS connection) to obtain an X.509 certificate. The sender's identity is extracted from the X.509 certificate for the TLS handshake used to establish the TLS connection for N32-c communications. In one example, the sender's identity can be used to cross-verify the sender's N32-f identity. As noted above, the TLS handshake protocol is defined in Internet Engineering Task Force (IETF) Request for Comments (RFC) 5246 and includes the exchange of certificate messages by both ends of a TLS connection. The structure of the TLS handshake messages defined in IETF RFC 5246, including the certificate messages, is shown below:

[0045]

[0046]

[0047] As shown in the TLS handshake message structure, one of the defined handshake message types is the certificate message, which contains the certificate of the client or server, depending on whether the sender is acting as a client or server. In establishing secure TLS communications over the N32-c interface, bidirectional TLS or m-TLS is used, in which both ends of the TLS connection receive and validate the X.509 certificate of the other end. IETF RFC 5246 indicates that the certificate type must be X.509v3 unless explicitly negotiated otherwise. The examples described herein use X.509v3 certificates as an example, but the subject matter described herein is not limited to validating the sender's N32-f identity using only the sender's identity extracted from an X.509v3 certificate. The X.509v3 certificate format is defined in IETF RFC 3280. According to IETF RFC 3280, one extension or parameter that can be included in an X.509v3 certificate is the subject alternative name extension. The subject alternative name extension is defined as follows:

[0048] The subject alternative name extension allows additional identities to be bound to the subject of the certificate.

[0049] The defined options include Internet electronic mail addresses, DNS names, IP addresses, and uniform resource identifiers (URIs). Other options exist, including fully locally defined. Multiple instances of each type of name can be included. Whenever such identities are bound into a certificate, the subject alternative name (or issuer alternative name) extension must be used; however, DNS names can be represented in the "subject" field using the domainComponent attribute, as described in RFC 4514.

[0050]

[0051]

[0052]

[0053]

[0054]

[0055] Section 4.1.2.4

[0056] Because the "subject alternative name" is considered to be explicitly bound to the public key, all parts of the "subject alternative name" must be verified by the CA.

[0057] ​​​​​​​As indicated above, the subject alternative name extension of an X.509 v3 certificate can contain a DNS name, an IP address, or a URI that identifies the subject of the certificate and is verified by the certificate authority. Because the subject alternative name is verified by the certificate authority, the subject alternative name is difficult to counterfeit. However, merely ensuring that the sender has a valid X.509 certificate does not verify the sender’s identity at the N32-f application level. To perform such cross-verification, the responding SEPP 126B can extract the sender’s identity from the certificate message used to establish the TLS connection for N32-c communications, extract the sender’s identity from the certificate message used to establish the TLS connection for N32-f communications, and compare the identities. If the identities match, the responding SEPP 126B can perform a further verification step of comparing the identity extracted from either certificate message to a database of configured peer SEPP identities. If either verification fails, the responding SEPP blocks the inter-PLMN communication associated with the TLS connection for N32-f communications.

[0058] Figure 4 An exemplary attack scenario that can occur when there is no cross-verification of the identities used on the N32-c and N32-f interfaces is illustrated. In Figure 4 , the initiating SEPP 126A located in PLMN 1 can establish a TLS connection with the responding SEPP 126B on the N32-c interface. The hacker SEPP 300 located in PLMN 3 can establish a TLS connection for N32-f communications with the SEPP 126B. Because there is no cross-verification of the identities used in the TLS connection for N32-f communications and the TLS connection for N32-c communications, the hacker SEPP 300 and hacker NF 302 located in PLMN 3 can send attack traffic to the responding SEPP 126B and the producer NF 304 located in PLMN 2. In one example, such attack traffic can be used to implement a denial of service attack to prevent the consumer NF 306 located in PLMN 1 from obtaining service from the producer NF 304.

[0059] Figure 5 An attack scenario for N32-f communications is illustrated in more detail. In Figure 5 , a TLS connection is established for N32-c communications between the initiating SEPP 126A and the responding SEPP 126B.

[0060] After the TLS connection is established for N32-c communications, the initiating SEPP 126A and the responding SEPP 126B exchange N32-c security capabilities messages over the TLS connection.

[0061] Once the N32-c connection is established, the initiating SEPP 126A and the responding SEPP 126B perform a second TLS handshake for N32-f communication. Once the second TLS connection is established, the initiating SEPP 126A and the responding SEPP 126B can exchange 5G service request and response messages between consumer and producer NFs in their respective PLMNs.

[0062] Because there is no cross-verification of the N32-f TLS identity with the N32-c TLS identity, a hacker SEPP 300 can initiate a TLS handshake with the responding SEPP 126B. The responding SEPP 126B checks to see if the certificate was issued by a valid certificate authority. However, there is no cross-verification with the identity obtained on the other interface. Thus, the hacker SEPP 300 can establish a TLS connection for N32-f communication and send a 5G request message to a producer NF in a network protected by the responding SEPP 126B that is masquerading as the initiating SEPP 126A, which can cause denial of service or other problems for services in the PLMN protected by the responding SEPP 126B.

[0063] To prevent this type of attack, the responding SEPP 126B can store the identity of the initiating SEPP received on the N32-c interface and use that identity to cross-verify the identity of the initiating SEPP in the TLS connection for N32-f communication. Figure 6 Figure illustrates cross-verification that can be performed by a responding SEPP. Reference is made to Figure 6 In line 1, the initiating SEPP 126A and the responding SEPP 126B exchange TLS messages to establish a TLS connection for N32-c communication. In lines 2 and 3, the initiating SEPP 126A and the responding SEPP 126B exchange N32-c, security capabilities exchange messages.

[0064] After line 2, the responding SEPP 126B can cross-verify the identity of the initiating SEPP 126A extracted from the X-509 certificate used for the first TLS connection and the PLMN of the initiating SEPP 128C from the N32-c security capabilities exchange message from line 2 in the SEPP PLMN-to-PLMN interworking interface identity cross-verification database 600. The responding SEPP 126B can use the identities stored in the SEPP PLMN-to-PLMN interworking interface identity cross-verification database 600 to validate the N32-f identity presented by the initiating SEPP.

[0065] Since the SEPP 126B is a responding SEPP for the N32-c security capability negotiation transaction, the responding SEPP 126B can extract the N32-c identity from the senderID attribute of the N32-cSecNegotiateReqData information element of the HTTP POST message from the initiating SEPP 126A. Tables 1 and 2 below correspond to Table 6.1.5.2.2.1 of 3GPP TS 29.573, which illustrates the attributes that can be included in the SecNegotiateReqData information element as part of the N32-c security capability negotiation.

[0066] Table 1: Definition of SecNegotiateReqData type

[0067]

[0068] As can be seen from Table 1, the sender attribute is a mandatory parameter of the SecNegotiateReqData information element and contains the FQDN of the sending SEPP. The PLMN of the SEPP can be obtained from the FQDN of the sending SEPP. For example, if the FQDN of the sending SEPP is sepp1.5gc.mnc123.mcc456.3gppnetwork.org, then the PLMN portion of the FQDN is 5gc.mnc123.mcc456.3gppnetwork.org. As will be described in detail below, the PLMN of the sender is included in 5G Core (5GC) or service messages exchanged over the N32-f interface and can be used to verify subsequent 5GC messages even if the TLS identities used for N32-c and N32-f communications match. This additional check prevents a misbehaving SEPP that was identified as trusted in the first check from sending a false PLMN identity in subsequent messages exchanged over the forwarding interface. In line 4, the initiating SEPP 126A initiates a TLS handshake with the responding SEPP 126B for N32-f communications. The responding SEPP 126B can extract the identity of the initiating SEPP 126A from the X.509 certificate used for the second TLS handshake. The responding SEPP 126B can perform a lookup in the SEPP PLMN inter- forwarding interface identity cross-verification database 600 to determine whether the identity of the SEPP 126A that initiated the N32-c communications matches the identity presented on the N32-f interface. In this example, the identities match. Thus, in lines 5 and 6, the initiating SEPP 126A sends a 5G service request message to the responding SEPP 126B and the responding SEPP 126B sends a 5G service response message to the initiating SEPP 126A.

[0069] In line 7, the hacker SEPP 300 sends a message to the responding SEPP 126B to initiate a TLS connection for N32-f communication with the responding SEPP 126B. The responding SEPP 126B extracts the identity presented by the hacker SEPP 300 for the TLS connection from the X.509 certificate of the certificate message in the TLS handshake procedure. The responding SEPP 126B performs a lookup in the database 600 and does not find the identity presented by the hacker SEPP 300 to exist in the database 600. Because the identity presented by the hacker SEPP 300 does not exist in the database 600, the cross-verification fails and the responding SEPP 300 blocks the 5G service request message from the hacker PLMN in line 8. In another example, the responding SEPP 126B can receive the 5G service request message in line 8, extract the PLMN identity from the 5G service request message, and perform a lookup in the database 600 using a lookup key that includes both the N32-c TLS SEPP identity and the N32-c PLMN identity. If the record corresponding to the lookup key does not exist in the database 600, then the responding SEPP 126B can prevent inter-PLMN traffic received over the TLS connection for the N32-f interface from entering the PLMN.

[0070] Figure 7 is a block diagram illustrating an exemplary architecture for a responding SEPP 126B. The SEPP 126B includes at least one processor 700 and a memory 702. The SEPP 126B also includes an inter-PLMN forwarding interface impersonation mitigation module 704 that performs the steps described herein for cross- verifying the TLS identity presented by a SEPP on the N32-c interface with the identity presented by a real or hacker SEPP on the N32-f interface. The inter-PLMN forwarding interface impersonation mitigation module 704 can also cross-verify the PLMN presented by a SEPP on the N32-c interface with the PLMN presented by a SEPP on the N32-f interface. The SEPP 126B also includes a SEPP inter-PLMN forwarding interface identity cross-verification database 600 that is dynamically populated by the inter-PLMN forwarding interface impersonation mitigation module 704 with the identities of SEPPs obtained on the N32-c interface and / or PLMNs. The SEPP 126B can use the SEPP identities and / or PLMN identities stored in the SEPP forwarding interface identity cross-verification database 600 to cross-verify the TLS level SEPP identities and / or service level PLMN identities presented on the N32-f interface.

[0071] The SEPP 126B can also include a peer SEPP database 706 configured with identities of peer SEPPs that are allowed for inter-PLMN communication. The inter-PLMN forwarding interface impersonation mitigation module 704 can be implemented by the processor 700 and can also perform cross-checking of the N32-f identity presented by the remote node against the peer SEPP identities stored in the database 706. If the identity of the remote node presented in the certificate exchanged during TLS connection setup for the N32-f interface is not present in the database 706, or if the cross-checking between the N32-c and N32-f identities fails, then the inter-PLMN forwarding interface impersonation mitigation module 704 can block inter-PLMN communication with the remote node. If both identity cross-checks pass, then the inter-PLMN forwarding interface impersonation mitigation module 704 can allow inter-PLMN communication with the remote node.

[0072] Figure 8 is a flowchart illustrating an exemplary method for mitigating 5G talk attacks. Referring to Figure 8 In step 800, the responding SEPP obtains at least one of a first SEPP identifier and a first PLMN identifier from at least one message received over an inter-PLMN control interface. For example, the responding SEPP 126B can extract the identity of the sending node from the alternative ID field of the X.509 certificate in a TLS message received from a sending node seeking to establish N32-c communication with the responding SEPP. The TLS message can be a certificate message exchanged with the remote node as part of a TLS handshake procedure for establishing a TLS connection with the remote node. The sending node can be an initiating SEPP associated with another PLMN.

[0073] In step 800, the responding SEPP can also (optionally) obtain the first PLMN identifier from at least one message received over the inter-PLMN control interface. For example, the SEPP 126B can extract the first PLMN identifier from the sender attribute of the SecNegotiateReqData information element transmitted during N32-c security capabilities negotiation on the first TLS connection and store the PLMN identifier in a database.

[0074] In step 802, the responding SEPP stores the at least one of the first SEPP identifier and the first PLMN identifier in a SEPP inter-PLMN forwarding interface identity cross-verification database. For example, the SEPP 126A can store the first SEPP identifier, the first PLMN identifier, or both (depending on the level of security screening required by the network operator) in the database 600. Table 2 shown below illustrates the state of the database after being populated with SEPP identifiers and PLMN identifiers received over the inter-PLMN control interface.

[0075]

[0076]

[0077] Table 2: N32-c TLS identity and PLMN identity In Table 2, the first column includes the SEPP identity extracted from the N32-c TLS certificate message, and the second column includes the PLMN identity extracted from the N32-c security capabilities exchange message. It should be noted that in Table 2, the PLMN obtained from the N32-c security capabilities exchange message is the same as the PLMN extracted from the X.509 certificate in the TLS message. Therefore, in this case, it is optional to store the PLMN extracted from the N32-c security capabilities exchange message. If the PLMN from the N32-c security capabilities exchange message does not match the PLMN obtained from the N32-c TLS connection, then inter-PLMN communication from the sender of the N32-c message can be blocked.

[0078] In step 804, the responding SEPP obtains at least one of a second SEPP identifier and a second PLMN identifier from at least one message received by the responding SEPP from the inter-PLMN forwarding interface. For example, the responding SEPP can obtain the second SEPP identifier from a TLS certificate message received during a TLS handshake that establishes a TLS connection for the N32-f interface and / or obtain the second PLMN identifier from a 5GC service message received over the TLS connection for the forwarding interface.

[0079] In step 806, the responding SEPP performs a lookup in the SEPP inter-PLMN forwarding interface identity cross-verification database using a lookup key that includes at least one of the second TLS SEPP identifier and the second PLMN identifier. For example, the responding SEPP can perform a lookup in database 600 using a lookup key that includes the second TLS SEPP identifier, the second PLMN identifier, or a tuple that includes the N32-f TLS SEPP identifier and the N32-f PLMN identifier.

[0080] In step 808, the responding SEPP determines whether a matching record exists in the SEPP inter-PLMN forwarding interface identity cross-verification database. If no matching record exists, this indicates an attack, and control proceeds to step 810, where the responding SEPP prevents at least one message received over the inter-PLMN forwarding interface from entering the PLMN protected by the responding SEPP. For example, if the SEPP and / or PLMN identity cross-verification fails, the responding SEPP can block the one or more initial messages for which verification failed, as well as subsequent messages received over the TLS connection established for the N32-f interface. The TLS connection established for the N32-f interface can also be blocked if verification is performed based only on cross-verification of the N32-f TLS SEPP identity with the N32-c TLS SEPP identity, and prior to completion of the establishment of the TLS connection for the N32-f interface.

[0081] In step 808, if it is determined that a matching identifier exists in the SEPP inter-PLMN forwarding interface identity cross-verification database, control proceeds to step 812, where the responding SEPP performs a lookup of the second SEPP identifier in a peer SEPP database. The network operator can provision the peer SEPP database with the identities of SEPPs that are allowed to communicate with a given SEPP in the operator's network. Such SEPPs are referred to herein as peer SEPPs, as they can be associated with the peer network operator's PLMN.

[0082] In step 814, if the second SEPP identifier exists in the peer SEPP database, control proceeds to step 816, where the SEPP allows messages received over the inter-PLMN forwarding interface to enter the PLMN protected by the SEPP.

[0083] The inter-PLMN forwarding interface identity cross-verification can be used in conjunction with the identity verification described in co-assigned co-pending Indian provisional patent application number: 202041041754 (hereinafter “the ‘754 application”), filed September 25, 2020; the disclosure of which is incorporated herein by reference in its entirety. The identity verification described in the ‘754 application includes extracting the identity of the sending node from the TLS certificate message received for establishing the TLS connection for N32-c communications. This is the same identity described herein that is used for cross-verification with the identity extracted from the TLS connection for N32-f communications. In the ‘754 application, the TLS identity for N32-c communications is used to verify the identity extracted from the N32-c Security Capabilities Exchange message. For example, the responding SEPP can extract the N32-c identity from the senderID attribute of the N32-c SecNegotiateReqData information element of the HTTP POST message from the remote node. If the N32-c identity matches the TLS identity of the TLS connection for N32-c communications, then this verification check passes. If the N32-c identity does not match the TLS identity of the TLS connection for N32-c communications, then the verification check fails.

[0084] Because the N32-c communications should occur before the TLS connection for N32-f communications is established, the verification check performed in the ‘754 application can be performed before the verification check described herein. If the verification check described in the ‘754 application fails, then the N32-c and N-32-f communications with the node having the identity shown in the sender information element of the N32-c SecNegotiateReqData message should be blocked.

[0085] If the verification check described in the ‘754 application passes and the verification check described in this application fails, then the N32-f communications associated with the second TLS connection (from the hacker) will be blocked, but the N32-c communications will be allowed (because they can be from a legitimate SEPP).

[0086] If the verification check described in the ‘754 application and the verification check described herein fail, then the N32-c and N32-f communications using the identity presented in the N32 SecNegotiateReqData message or the second TLS connection (for N32-f communications) should be blocked.

[0087] The subject matter described herein improves network security between SEPPs and PLMNs by performing cross-verification of SEPP identities and PLMN identities exchanged between SEPPs on different interfaces. By comparing N32-c and N32-f SEPP and / or PLMN identities, the SEPPs described herein reduce the likelihood of a successful spoofing attack on the N32-f interface, which is the interface that carries service traffic between PLMNs. Reducing the likelihood of a spoofing attack on the forwarding interface used for inter-PLMN service traffic is beneficial because this interface carries the majority of traffic exchanged between PLMNs. Furthermore, implementing anti-spoofing mitigation on the SEPP for inter-PLMN forwarding traffic is beneficial because the SEPP is the point of ingress for the PLMNs. Stopping attack traffic at the point of ingress for the PLMNs minimizes the impact of attack traffic on services provided by the PLMNs.

[0088] The disclosure of each of the following references is hereby incorporated by reference in its entirety.

[0089] REFERENCES

[0090] 1. IETF RFC 5246; The Transport Layer Security (TLS) Protocol, Version 1.2; August 2008.

[0091] 2. IETF RFC 3280; Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002.

[0092] 3. 3GPP TS 29.573; 3 rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Public Land Mobile Network (PLMN) Interconnection; Stage 3 (Release 16) V16.3.0 (2020-07).

[0093] 4. 3GPP TS 33.501; 3 rd3GPP TS 33.501 ; 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System; (Release 16), V16.3.0 (2020-07).

[0094] 5.3GPP TS 29.510; 3 rd 3GPP TS 28.541 ; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 16), V16.4.0 (2020-07).

[0095] It will be understood that various details of the presently disclosed subject matter can change without departing from the scope of the presently disclosed subject matter. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.

Claims

1. A method for mitigating a spoofing attack on a security edge protection proxy (SEPP) public land mobile network inter (PLMN inter) forwarding interface, the method comprising: obtaining, by a responding SEPP, at least one of a first SEPP identifier and a first PLMN identifier from at least one message received over a PLMN inter control interface, wherein obtaining the first SEPP identifier and the first PLMN identifier from the at least one message received over the PLMN inter control interface comprises obtaining the first SEPP identifier from a first transport layer security (TLS) certificate message received during a TLS handshake to set up a TLS connection for the PLMN inter control interface and obtaining the first PLMN identifier from an N32-c security capabilities exchange message received over the TLS connection for the PLMN inter control interface; storing the at least one of the first SEPP identifier and the first PLMN identifier in a SEPP PLMN inter forwarding interface identity cross-verification database; obtaining, by the responding SEPP, at least one of a second SEPP identifier and a second PLMN identifier from at least one message received over a PLMN inter forwarding interface, wherein obtaining the second SEPP identifier and the second PLMN identifier from the at least one associated message received over the PLMN inter forwarding interface comprises obtaining the second SEPP identifier from a second TLS certificate message received during a TLS handshake to set up a TLS connection for the PLMN inter forwarding interface and obtaining the second PLMN identifier from a 5G service message received over the TLS connection for the PLMN inter forwarding interface; performing a lookup in the SEPP PLMN inter forwarding interface identity cross-verification database using a lookup key comprising the at least one of the second SEPP identifier and the second PLMN identifier; and determining that a record corresponding to the lookup key is not present in the SEPP PLMN inter forwarding interface identity cross-verification database and, in response, preventing the at least one message received over the PLMN inter forwarding interface from entering a PLMN protected by the responding SEPP, wherein the PLMN inter control interface comprises an N32-c interface and the PLMN inter forwarding interface comprises an N32-f interface.

2. The method of claim 1, wherein obtaining at least one of a first SEPP identifier and a first PLMN identifier from the at least one message received over the inter-PLMN control interface comprises: obtaining the first SEPP identifier from a first certificate contained in a first TLS certificate message received over the PLMN inter control interface during a TLS handshake to set up a TLS connection for the N32-c interface.

3. The method of claim 2, wherein the first certificate comprises a first X.509 certificate.

4. The method of claim 3, wherein obtaining a first SEPP identifier comprises: extracting the first SEPP identifier from a subject alternative name extension of the first X.509 certificate.

5. The method of any of the preceding claims, wherein obtaining at least one of the second SEPP identifier and the second PLMN identifier from at least one message received over the inter-PLMN forwarding interface comprises: obtaining the second SEPP identifier from a second certificate contained in a second TLS certificate message received during a TLS handshake to set up a TLS connection for the N32-f interface.

6. The method of claim 5, wherein the second certificate comprises a second X.509 certificate.

7. The method of claim 6, wherein obtaining a second SEPP identifier comprises: extracting the second SEPP identifier from a subject alternative name extension of the second X.509 certificate.

8. The method of any of claims 1 to 4, wherein the lookup key comprises a tuple comprising the second SEPP identifier and the second PLMN identifier.

9. A system for mitigating impersonation attacks on a security edge protection proxy (SEPP) public land mobile network inter (PLMN inter) forwarding interface, the system comprising: a SEPP comprising at least one processor and a memory; a SEPP PLMN inter forwarding interface identity cross-verification database residing in the memory; and a PLMN inter forwarding interface identity impersonation mitigation module implemented by the at least one processor and configured to: obtain at least one of a first SEPP identifier and a first PLMN identifier from at least one message received over a PLMN inter control interface, wherein obtaining the first SEPP identifier and the first PLMN identifier from the at least one message received over the PLMN inter control interface comprises obtaining the first SEPP identifier from a first transport layer security (TLS) certificate message received during a TLS handshake to set up a TLS connection for the PLMN inter control interface and obtaining the first PLMN identifier from an N32-c security capabilities exchange message received over the TLS connection for the PLMN inter control interface; store the at least one of the first SEPP identifier and the first PLMN identifier in the SEPP PLMN inter forwarding interface identity cross-verification database; obtain at least one of a second SEPP identifier and a second PLMN identifier from at least one message received over a PLMN inter forwarding interface, wherein obtaining the second SEPP identifier and the second PLMN identifier from the at least one associated message received over the PLMN inter forwarding interface comprises obtaining the second SEPP identifier from a second TLS certificate message received during a TLS handshake to set up a TLS connection for the PLMN inter forwarding interface and obtaining the second PLMN identifier from a 5G service message received over the TLS connection for the PLMN inter forwarding interface; perform a lookup in the SEPP PLMN inter forwarding interface identity cross-verification database using a lookup key comprising the at least one of the second SEPP identifier and the second PLMN identifier; and determine that a record corresponding to the lookup key is not present in the SEPP PLMN inter forwarding interface identity cross-verification database and, in response, prevent the at least one message received over the PLMN inter forwarding interface from entering a PLMN protected by the SEPP, wherein the PLMN inter control interface comprises an N32-c interface and the PLMN inter forwarding interface comprises an N32-f interface.

10. The system of claim 9, wherein obtaining the at least one of the first SEPP identifier and the first PLMN identifier comprises obtaining the first SEPP identifier from a first certificate included in a first TLS certificate message received during a TLS handshake to set up a TLS connection for the N32-c interface. ​ 11. The system of claim 10, wherein the first certificate comprises a first X.509 certificate.

12. The system of claim 11, wherein the inter-PLMN forwarding interface identity impersonation mitigation module is configured to extract the first SEPP identifier from a subject alternative name extension of the first X.509 certificate.

13. The system of any of claims 9 to 11, wherein obtaining at least one of the second SEPP identifier and the second PLMN identifier from at least one message received over the inter-PLMN forwarding interface comprises: receive a second certificate included in a second TLS certificate message received during a TLS handshake for setting up a TLS connection for the N32-f interface.

14. The system of claim 13, wherein the second certificate comprises a second X.509 certificate, and the inter-PLMN forwarding interface identity impersonation mitigation module is configured to obtain the second identifier by extracting the second identifier from a subject alternative name extension of the X.509 certificate.

15. The system of any of claims 9 to 12, wherein the lookup key comprises a tuple including the second SEPP identifier and the second PLMN identifier.

16. A non-transitory computer-readable medium having stored thereon executable instructions that, when executed by a processor of a computer, perform steps comprising: obtaining, by a responding security edge protection proxy (SEPP), at least one of a first SEPP identifier and a first PLMN identifier from at least one message received over an inter-public land mobile network (inter-PLMN) control interface, wherein obtaining the first SEPP identifier and the first PLMN identifier from the at least one message received over the inter-PLMN control interface comprises obtaining the first SEPP identifier from a first transport layer security (TLS) certificate message received during a TLS handshake for setting up a TLS connection for the inter-PLMN control interface and obtaining the first PLMN identifier from an N32-c security capabilities exchange message received over the TLS connection for the inter-PLMN control interface; storing the at least one of the first SEPP identifier and the first PLMN identifier in a SEPP inter-PLMN forwarding interface identity cross-verification database; obtaining, by the responding SEPP, at least one of a second SEPP identifier and a second PLMN identifier from at least one message received over an inter-PLMN forwarding interface, wherein obtaining the second SEPP identifier and the second PLMN identifier from the at least one associated message received over the inter-PLMN forwarding interface comprises obtaining the second SEPP identifier from a second TLS certificate message received during a TLS handshake for setting up a TLS connection for the inter-PLMN forwarding interface and obtaining the second PLMN identifier from a 5G service message received over the TLS connection for the inter-PLMN forwarding interface; performing a lookup in the SEPP inter-PLMN forwarding interface identity cross-verification database using a lookup key comprising the at least one of the second SEPP identifier and the second PLMN identifier; and determining that a record corresponding to the lookup key does not exist in the SEPP inter-PLMN forwarding interface identity cross-verification database, and in response, preventing the at least one message received over the inter-PLMN forwarding interface from entering a PLMN protected by the responding SEPP, wherein the inter-PLMN control interface comprises a N32-c interface and the inter-PLMN forwarding interface comprises a N32-f interface.

Images