Method, system and computer-readable medium for performing message verification in a fifth generation (5G) communication network

Abstract

[0006] A method, system, and computer-readable medium for performing message validation in a fifth-generation (5G) communication network are disclosed. One method, performed in a first network node of a first network, includes obtaining authentication information for identifying a user equipment from at least one authentication and key agreement (AKA) procedure-related message associated with a user equipment communicating over a second network, storing the authentication information in a data store for validating subsequent messages, receiving a request message associated with the user equipment, determining that the request message is invalid using the authentication information, and performing an invalid message operation in response to determining that the request message is invalid.

Description

[Technical Field]

[0001] Priority claim This application claims the benefit of priority to U.S. Patent Application No. 17 / 123,038, filed December 15, 2020, the entire disclosure of which is incorporated herein by reference.

[0002] Technical Field The subject matter described herein relates to enhancing security in fifth-generation (5G) communication networks. More particularly, the subject matter described herein relates to methods, systems, and computer-readable media for performing message verification in 5G communication networks. [Background technology]

[0003] background In fifth-generation (5G) communication networks, a network node that provides a service is called a producer Network Function (NF). A network node that consumes a service is called 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.

[0004] A particular producer NF can have many service endpoints. 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 port number, or a fully qualified domain name that resolves to the IP address and port number of the network node hosting the producer NF. An NF instance is an instance of a producer NF that provides a service. A particular producer NF may contain multiple NF instances. Note that multiple NF instances can share the same service endpoint.

[0005] Producer NFs register 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. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF. In addition to consumer NFs, another type of network node that can subscribe to receive information about NF service instances is the Service Communication Proxy (SCP). An SCP subscribes to the NRF to obtain reachability and service profile information about producer NF service instances. Consumer NFs connect to the Service Communication Proxy, which load balances traffic among producer NF service instances that offer the required service or routes traffic directly to the destination producer NF instance.

[0006] In addition to SCPs, other examples of a set of intermediate proxy nodes or 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 for all application programming interface (API) messages. Summary of the Invention [Problem to be solved by the invention]

[0007] However, there is a need to improve the security measures of one or more NFs. [Means for solving the problem]

[0008] overview

[0003] A method, system, and computer-readable medium for performing message validation in a fifth-generation (5G) communication network are disclosed. One exemplary method for performing message validation in a 5G communication network includes, at a first network node of a first network, obtaining authentication information for identifying a user equipment from at least one authentication and key agreement (AKA) procedure-related message associated with the user equipment communicating via a second network, storing the authentication information in a data store for validating subsequent messages, receiving a request message associated with the user equipment, determining that the request message is invalid using the authentication information, and performing an invalid message operation in response to determining that the request message is invalid.

[0009] One exemplary system for performing message validation in a 5G communication network includes a first network node of a first network including at least one processor and a memory, configured to obtain authentication information for identifying a user equipment from at least one authentication and key agreement (AKA) procedure-related message associated with a user equipment communicating over a second network, store the authentication information in a data store for validating subsequent messages, receive a request message associated with the user equipment, determine using the authentication information that the request message is invalid, and perform an invalid message operation in response to determining that the request message is invalid.

[0010] One exemplary non-transitory computer-readable medium includes computer-executable instructions that, when embodied on the non-transitory computer-readable medium and executed by at least one processor of at least one computer, cause the at least one computer to perform the following steps: at a first network node of a first network, obtaining authentication information for identifying a user equipment from at least one authentication and key agreement (AKA) procedure-related message associated with a user equipment communicating over a second network, storing the authentication information in a data store for validating subsequent messages, receiving a request message associated with the user equipment, determining that the request message is invalid using the authentication information, and performing an invalid message operation in response to determining that the request message is invalid.

[0011] According to one aspect of the subject matter described herein, determining that the request message is invalid using the authentication information may include retrieving the authentication information from a data store using a user equipment identifier in the request message, and determining that the authentication information does not verify that the user equipment is roaming on the network from which the request message originated.

[0012] According to one aspect of the subject matter described in this specification, the request message to perform message validation may include a nudm-sdm service message, a nudm-uecm service message, an npcf-ue policy service message, an nsmf-pdu session service message, an nnrf-disc service message, or an nnrf-nfm service message.

[0013] According to one aspect of the subject matter described herein, the AKA procedure related messages may include messages including an AuthenticationInfo data type, a UEAuthenticationCtx data type, a ConfirmationData data type, or a ConfirmationDataResponse data type.

[0014] According to one aspect of the subject matter described herein, authentication information usable to identify a user equipment or a network may include a network identifier, a user equipment identifier, a network node identifier, a subscription persistent identifier (SUPI), a subscription hidden identifier (SUCI), or a public land mobile network (PLMN) identifier.

[0015] According to one aspect of the subject matter described herein, the first network node includes a Security Edge Protection Proxy (SEPP), a 5G core network function, a network proxy, or a network gateway.

[0016] According to one aspect of the subject matter described herein, the at least one AKA procedure-related message is transmitted via a second network node of a second network, the second network node including a Consumer Network Function (NF), a Policy Control Function (PCF), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a Network Repository Function (NRF), a Network Slice Selection Function (NSSF), or a 5G Core Network Function.

[0017] In accordance with one aspect of the subject matter described herein, the invalid message action may include discarding the request message or notifying a network administrator or management system.

[0018] According to one aspect of the subject matter described herein, the first network may be a home PLMN and the second network may be a visited PLMN.

[0019] The subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof. Thus, as used herein, the terms “function,” “node,” or “module” may include software and / or firmware components and refer to hardware for implementing the described features. In one exemplary implementation, the subject matter described herein may be implemented using a computer-readable medium that stores computer-executable instructions that, when executed by a computer processor, control a computer to perform 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. Furthermore, computer-readable media implementing the subject matter described herein may be located on one device or computing platform or distributed across multiple devices or computing platforms.

[0020] The subject matter described herein will be explained with reference to the accompanying drawings. [Brief explanation of the drawings]

[0021] [Figure 1] FIG. 1 is a network diagram illustrating an exemplary fifth-generation (5G) network architecture. [Figure 2] FIG. 1 illustrates an exemplary node for performing message verification in a 5G communication network. [Figure 3] FIG. 1 is a message flow diagram illustrating an exemplary authentication and key agreement (AKA) procedure involving a consumer network function (NF) and an authentication server function (AUSF). [Figure 4] 1 illustrates exemplary identification data associated with various 5G service messages. [Figure 5A]FIG. 10 is a message flow diagram illustrating obtaining a user equipment (UE) identifier from messages related to an authentication procedure. [Figure 5B] FIG. 10 is a message flow diagram illustrating obtaining a user equipment (UE) identifier from messages related to an authentication procedure. [Figure 6] FIG. 1 is a message flow diagram illustrating exemplary message validation in a 5G communication network. [Figure 7] 1 is a flowchart illustrating an example process for performing message verification in a 5G communication network. DETAILED DESCRIPTION OF THE INVENTION

[0022] Detailed Description The subject matter described herein relates to methods, systems, and computer-readable media for performing message verification in fifth-generation (5G) communication networks. According to some aspects of the subject matter described herein, methods, systems, mechanisms, and / or techniques are provided for performing message verification using stored authentication information obtained or derived from a user equipment (UE) authentication procedure (e.g., a 5G authentication and key agreement (AKA) procedure). For example, according to various aspects described herein, a security edge protection proxy (SEPP) can obtain or derive authentication information (e.g., a UE identifier, a serving PLMN identifier, and a UE authentication status) associated with a UE by monitoring messages associated with a 5G AKA procedure for authenticating the UE. In this example, the SEPP can avoid or mitigate security attacks and other problems by using the same authentication information to verify subsequent inter-PLMN messages associated with the UE. Advantageously, by utilizing one or more of the techniques and / or methods described herein, a SEPP or another network node may prevent DOS attacks using inter-PLMN traffic, prevent theft of subscriber data from the home network, and / or provide subscriber-level authentication.

[0023] DETAILED DESCRIPTION OF THE INVENTION Various embodiments of the subject matter described herein will now be described in detail, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

[0024] FIG. 1 is a block diagram illustrating an example 5G system network architecture, e.g., a Home 5G Core (5GC) network. The architecture of FIG. 1 includes an NRF 100 and an SCP 101, which may be located in the same home public land mobile network (PLMN). As described above, the NRF 100 maintains profiles of available producer NF service instances and supported services and can enable consumer NFs or SCPs to subscribe to and be notified of new / updated producer NF service instance registrations. The SCP 101 can also support service discovery and selection of producer NF instances. The SCP 101 can perform load balancing of connections between consumer NFs and producer NFs. Furthermore, the SCP 101 can perform selection and routing based on preferred NF locations using the methods described herein.

[0025] The NRF 100 is a repository of NF or service profiles of producer NF instances. To communicate with producer NF instances, consumer NFs or SCPs must obtain NF or service profiles or producer NF instances from the NRF 100. An NF or service profile is a JavaScript Object Notation (JSON) data structure defined in 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 29.510. An NF or service profile definition includes 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 FIG. 1 , any node (other than the NRF 100) may be either a consumer NF or a producer NF, depending on whether it is requesting or providing a service. In the illustrated example, the node includes a Policy Control Function (PCF) 102 that performs policy-related actions in the network, a User Data Management (UDM) function 104 that manages user data, and an Application Function (AF) 106 that provides application services. 1 further includes 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 4G networks. An Authentication Server Function (AUSF) 112 performs authentication services for user equipment, such as User Equipment (UE) 114, seeking access to the network.

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

[0027] The Radio Access Network (RAN) 120 connects the 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 FIG. 1) or other wireless access point. The User Plane Function (UPF) 122 can support various proxy functions for user plane services. One example of such a proxy function is a Multipath Transmission Control Protocol (MPTCP) proxy function. The UPF 122 can also support a performance measurement function. The UE 114 can use the performance measurement function to obtain network performance measurements. FIG. 1 also shows a Data Network (DN) 124, through which the UE uses data network services, such as Internet services.

[0028] The Security Edge Protection Proxy (SEPP) 126 filters traffic coming from another PLMN and performs topology hiding for traffic going out from the home PLMN. The SEPP 126 can be deployed in a foreign PLMN and communicate with an SEPP for managing the security of the foreign PLMN. Thus, traffic between NFs deployed in different PLMNs can traverse two SEPP functions: one for the home PLMN and one for the foreign PLMN.

[0029] The SEPP 126 may utilize an N32-c interface and an N32-f interface. The N32-c interface is a control plane interface between the two SEPPs that can be used to perform an initial handshake (e.g., a TLS handshake) and negotiate various parameters for the N32-f interface connection and associated message transfer. The N32-f interface is a transport interface between the two SEPPs that can be used to transport various communications (e.g., 5GC requests) between the consumer NF and the producer NF after applying application-level security protections.

[0030] One challenge with the existing 5G architecture is that it does not utilize resource or object-level authentication. Instead, it utilizes an authorization model based on API access. For example, if a compromised AMF in a trusted (but compromised or hacked) visited PLMN (V-PLMN) has access to the nudm-sdm service, the AMF can request and receive UE subscription data from the home network's UDM without verifying that the home network or a network node therein is indeed roaming the associated UE. In another example, a compromised SEPP in a trusted V-PLMN can trigger a signaling storm or launch a denial of service (DOS) attack by sending a significant number of inter-PLMN messages to the SEPP in the home PLMN. Therefore, the SEPP in the home PLMN can provide little protection for the trusted but compromised V-PLMN.

[0031] 2 is a diagram illustrating an example node 200 for performing message validation in a 5G communication network. Node 200 may represent any suitable entity for performing message validation. In some embodiments, node 200 may represent or include one or more 5GC NFs, such as a SEPP, NRF, PCF, NSSF, NEF, UDM, AUSF, UDR, Binding Support Function (BSF), or Unstructured Data Storage Function (UDSF). In some embodiments, node 200 may represent or include a network gateway, network proxy, edge security device, or related functionality.

[0032] In some embodiments, node 200 or an associated module may be configured to reduce or mitigate the influence of unauthorized and / or malicious entities interacting with network nodes in the 5G home network by performing message validation of inter-PLMN messages (e.g., via programming logic) using UE-related authentication information obtained during the AKA procedure. For example, node 200 or an associated module may be configured to identify and store authentication information (e.g., one or more UE identifiers and a serving network name associated with UE 114) when UE 114 is authenticated by the home network, and then determine whether an inter-PLMN message (e.g., a UDM information request) appearing to be associated with UE 114 is valid, e.g., by verifying, using the stored authentication information, that UE 114 is roaming in the network from which the inter-PLMN message originated.

[0033] 2, node 200 may include one or more communication interfaces 202 for communicating messages over a communication environment, e.g., a home 5GC network. In some embodiments, communication interface 202 may include a first communication interface for communicating with one or more SEPPs 126 in a first network, a second communication interface for communicating with one or more SEPPs 126 in a second network, and a third communication interface for communicating with one or more SEPPs 126 in a home network, e.g., a home 5GC network.

[0034] Node 200 may include a message verification tool (MV) 204. MV 204 may be any suitable entity (e.g., software executing on at least one processor) for performing one or more message verifications. In some embodiments, MV 204 may include functionality for obtaining authentication information identifying user equipment from at least one AKA procedure-related message associated with user equipment communicating over the second network and for validating subsequent messages associated with (or appearing to be associated with) the user equipment using the authentication information. In some embodiments, obtaining authentication information from the at least one AKA procedure-related message may include monitoring or inspecting AKA procedure-related messages traversing node 200. In another example, obtaining authentication information from the at least one AKA procedure-related message may include inspecting copies of the AKA procedure-related messages sent to MV 204. In some embodiments, MV204 may obtain one or more identifiers (e.g., SUPI or SUCI and serving network name) from a first AKA procedure-related message (e.g., nausf-ue authentication request) and obtain additional information (e.g., authentication context identifier) ​​from a second AKA procedure-related message (e.g., nausf-ue authentication response).

[0035] In some embodiments, the MV 204 may be configured to monitor the N32-f interface connection for inter-PLMN messages (e.g., HTTP / 2 messages). For example, for a received inter-PLMN message, the MV 204 may use stored associated authentication information to determine whether the inter-PLMN message is valid. In this example, the MV 204 may identify the UE identity in the inter-PLMN message and use that information to query the data store 206 and obtain the associated authentication information. Continuing with this example, the MV 204 may analyze the stored authentication information to determine whether the authentication information is used to confirm or confirm that the UE 114 is roaming in the network from which the inter-PLMN message originated. If the authentication information is used to confirm or confirm that the UE 114 is roaming in the network from which the inter-PLMN message originated, the inter-PLMN message may be considered valid. If the authentication information is not used to confirm or confirm that the UE 114 is roaming in the network from which the inter-PLMN message originated, the inter-PLMN message may be considered invalid.

[0036] In some embodiments, the MV 204 may be configured to determine that an incoming inter-PLMN message associated with the UE 114 is invalid if there is no associated stored authentication information available. For example, if the UE 114 is not authenticated by the H-PLMN 490 and / or stored authentication information is unavailable, the MV 204 may consider any inter-PLMN message associated with the UE 114 to be invalid.

[0037] Node 200 can access (e.g., read and / or write information from) data store 206. Data store 206 may be any suitable entity (e.g., computer-readable medium or memory) for storing various data. In some embodiments, data store 206 may include user equipment authentication information and / or related information used in performing message verification. For example, data store 206 may include data records or entries that include various types of authentication information (e.g., information usable to identify and / or authenticate a UE) and are indexed using one or more keys, such as a unique UE identifier, a unique authentication context identifier, or a combination of unique identifiers. In this example, each data record or entry may be associated with a roaming subscriber or an associated UE and may include one or more UE identifiers and other authentication information (e.g., a serving network name or identifier, an authentication context identifier, an authentication result indicating successful authentication). Exemplary authentication information may include an authentication status, a network identifier, a user equipment identifier, a network node identifier, a subscription persistent identifier (SUPI), a subscription concealment identifier (SUCI), or a PLMN identifier.

[0038] In some embodiments, the data store 206 may include logic for obtaining authentication information from various AKA procedure related messages, logic for obtaining UE identification information from various inter-PLMN messages, logic for performing message verification using the stored authentication information, and logic for performing or triggering invalid message or valid message operations.

[0039] It should be understood that FIG. 2 and the associated description are for illustrative purposes, and that node 200 may include additional and / or different modules, components, or functionality.

[0040] 3 is a message flow diagram illustrating an example AKA procedure involving a consumer NF 300 and an AUSF 112. In some embodiments, the consumer NF 300 may represent a network node in a V-PLMN that interacts with the AUSF 112. For example, the consumer NF 300 (e.g., an AMF (V-AMF) in a V-PLMN) may request authentication of the UE 114 by providing information related to the UE and a serving network name to the AUSF 112, and the AUSF 112 may obtain the information related to the UE and the authentication method from the UDM 104. In this example, an intermediate node (e.g., the H-SEPP 126 between the consumer NF 300 and the AUSF 112) that receives and forwards various messages included in the 5G AKA procedure may be configured to obtain and store authentication information related to the UE 114 to validate subsequent inter-PLMN messages related to the UE 114.

[0041] 5G AKA procedures and other security procedures are defined in 3GPP (Third Generation Partnership Project) Technical Specification (TS) 33.501. 5G AKA procedures related to the Nausf_UE authentication service are further defined in TS 29.509. As defined in TS 29.509, various messages may include various structured data types that contain authentication information used for 5G AKA procedures and that can be used to perform message validation as described herein. For example, some structured data types may include a UE identifier (e.g., SUPI, SUCI, etc.), a serving network identifier (e.g., serving network name), an authentication type (e.g., authType), an authentication result (e.g., authResult), and / or other information.

[0042] An example of some exemplary structured data types defined in TS29.509 that may contain authentication information is shown below: The exemplary structured data types include an AuthenticationInfo data type, a UEAuthenticationCtx data type, a ConfirmationData data type, and a ConfirmationDataResponse data type.

[0043]

number

[0044] 3, in step 301, the consumer NF 300 may send a POST request to the AUSF 112. The payload of this POST request may include an AuthenticationInfo data type that includes a UE identifier (e.g., a SUPI or SUCI) and a serving network identifier (e.g., a serving network name) associated with the UE 114.

[0045] If successful, step 302A returns a "201 Created" message, which may include a UEAuthenticationCtx data type containing various authentication related information.

[0046] In step 302B, if unsuccessful, a "4XX or 5XX" message is returned indicating the HTTP status code, which includes a problem details structure with a "cause" attribute set.

[0047] In step 303, the consumer NF 300 may send a PUT request to the AUSF 112. This PUT request may include a ConfirmationData data type that includes the “RES*” information provided by the UE 114 or a null value if the “RES*” information is not provided.

[0048] In step 304A, if successful, a "200 OK" message is returned. This message may indicate whether the UE 114 is authenticated. For example, if the UE 114 is not authenticated because the "RES*" information was not successfully verified by the AUSF 112, the authentication result value in the message may be set to "authentication failed."

[0049] In step 304B, if unsuccessful, a "4XX or 5XX" message is returned indicating the HTTP status code, which includes a problem details structure with a "cause" attribute set.

[0050] It should be understood that Figure 3 is for illustrative purposes and that different and / or additional messages and / or actions may be used, and that the various messages and / or actions described herein may occur in a different order or sequence.

[0051] FIG. 4 illustrates example identification data 400 associated with various 5G service messages. In some embodiments, the data 400 may illustrate message entries found in an inter-PLMN message for identifying the 5G service, the consumer NF using the 5G service, and the UE or associated serving network (e.g., the network to which the UE is roaming). For example, if the UE 114 is roaming in a visited PLMN (V-PLMN), various communications are required between the UE 114's home PLMN (H-PLMN) and the V-PLMN to obtain or provide information relevant to the UE 114. As disclosed above, inter-PLMN messages are transmitted between the H-PLMN and the V-PLMN via the SEPP 126 in each network. However, the inter-PLMN messages represent various types of messages associated with different 5G interfaces or services and originating from different network nodes (see Table 1 below). Thus, different inter-PLMN messages may include different types of UE or network identification information.

[0052] Table 1 shows various inter-PLMN messages that can traverse the H-SEPP 126. As shown in Table 1, different 5G services or associated interfaces may utilize messages that include different message inputs and / or message formats.

[0053] Table 1. Example Inter-PLMN Messages

[0054] [Table 1]

[0055] In some embodiments, node 200, H-SEPP 126, or MV 204 may be configured to identify message inputs or values ​​associated with various inter-PLMN messages (such as in Table 1) when performing message validation. For example, node 200 or MV 204 may parse different types of UE identity information (e.g., SUPI or SUCI) depending on what type of inter-PLMN message is received and what type of UE identity information is available in the received inter-PLMN message.

[0056] Referring to FIG. 4 , the table illustrating data 400 includes columns and / or fields for service name, V-PLMN consumer NF, and message input. The service name field may store information representing a set of inter-PLMN messages associated with a particular service or associated interface. For example, the first data row of the table of FIG. 4 indicates a service name field value “npcf-uepolicycontrol.” In this example, the service name field value “npcf-uepolicycontrol” may represent a set of messages associated with a UE policy control service. In another example, the second data row of the table of FIG. 4 indicates a service name field value “nudm-sdm.” In this example, the service name field value “nudm-sdm” may represent a set of messages associated with a service for obtaining UE subscription data from a UDM. Example service names may include npcf-uepolicycontrol, nudm-sdm, nudm-uecm, nausf-ueauthentication, nsmf-pdusession, nssf-nsselection, nnrf-disc, or nnrf-nfm.

[0057] The V-PLMN consumer NF field may store information indicating a particular consumer NF transmitting or originating an inter-PLMN message of a particular type or group (e.g., service-related). For example, the first data row of the table in FIG. 4 indicates a V-PLMN consumer NF field value of "PCF." In this example, the V-PLMN consumer NF field value of "PCF" indicates that a PCF located in the V-PLMN can transmit an npcf-uepolicycontrol service message. In another example, the fifth data row of the table in FIG. 4 indicates a V-PLMN consumer NF field value of "SMF." In this example, the V-PLMN consumer NF field value of "SMF" indicates that an SMF located in the V-PLMN can transmit an nsmf-pdusession service message. An example V-PLMN consumer NF may include an AMF (e.g., an AMF in a V-PLMN), an SMF (e.g., an SMF in a V-PLMN), an NSSF (e.g., an NSSF in a V-PLMN), or an NRF (e.g., an NFR in a V-PLMN).

[0058] The message entry field may store information for a particular type or group (e.g., service-related) of inter-PLMN messages that can be used to identify the UE or an associated serving network (e.g., a network to which the UE is roaming). For example, the first data row of the table of FIG. 4 shows a message entry field value "SUPI." In this example, the message entry field value "SUPI" indicates that the npcf-uepolicycontrol service message may include a SUPI that can be used to identify a roaming UE, e.g., UE 114. In another example, the fourth data row of the table of FIG. 4 shows a message entry field value "SUCI." In this example, the message entry field value "SUCI" indicates that the nausf-ueauthentication service message may include a SUCI that can be used to identify a roaming UE, e.g., UE 114. Exemplary message entries for various inter-PLMN messages may include a SUPI, a SUCI, a PLMN ID of the SUPI, or an optional SUPI.

[0059] It should be understood that data 400 is for illustrative purposes and that different and / or additional data than that shown in Figure 4 may be used to indicate default values ​​for particular data portions or other information. Additionally, data 400 may be stored and managed (e.g., within data storage device 206) using a variety of data structures and / or computer-readable media.

[0060] 5A-5B are message flow diagrams illustrating obtaining authentication information from messages related to an authentication procedure. With reference to FIGURES 5A-5B, the UE 114 can trigger an AKA procedure that involves the AMF 110 in the V-PLMN1 488 communicating with the AUSF 112 in the H-PLMN 490. As shown in FIGURES 5A-5B, during the AKA procedure, various AKA-related messages can traverse the V-SEPP 126 and the H-SEPP 126.

[0061] In some embodiments, the H-SEPP 126 or node 200 (e.g., a network node involved in the AKA procedure) may include an MV 204 or similar functionality to monitor AKA procedure-related messages and obtain and store authentication information (e.g., a UE identifier and a serving network name) from these messages. For example, the H-SEPP 126 or the MV 204 therein may obtain and store authentication information (e.g., a SUPI or SUCI and a serving network name) from a nausf-u eauthentication request. In this example, the H-SEPP 126 or the MV 204 therein may also obtain authentication session identification information (e.g., an authentication context identifier) ​​from a nausf-u eauthentication response and associate this session identification information with previously stored authentication information. Continuing with this example, the H-SEPP 126 or the MV 204 therein may also obtain additional authentication-related information (e.g., an optional SUPI and authentication result) from another nausf-u eauthentication response.

[0062] Referring to FIG. 5A, in step 501, the AMF 110 may send an authentication request message (e.g., a nausf-ueauthentication message) to the AUSF 112 via the V-SEPP 126, indicating the SUPI or SUCI and serving network name information for authenticating the UE 114.

[0063] In step 502, V-SEPP 126 may receive the authentication request message and send the authentication request message or a version thereof to H-SEPP 126 over the N-32 interface.

[0064] In step 503, the H-SEPP 126 and / or the MV 204 may receive the authentication request message and store identification information associated with the UE 114 (eg, SUPI or SUCI and serving network name information).

[0065] In step 504 , the H-SEPP 126 may send an authentication request message or a version thereof to the AUSF 112 in the H-PLMN 490 .

[0066] In step 505 , after receiving the authentication request message, the AUSF 112 may send the obtained identification information (eg, in the nudm-u eauthentication request message) to the UDM 104 in the H-PLMN 490 .

[0067] In step 506, the UDM 104 may receive the identification information and, in response, send authentication response information to the AUSF 112, including a 5G Home Environment (HE) Authentication Vector (AV) and optionally a SUPI (e.g., in a nudm-ueauthentication response message).

[0068] In step 507, the AUSF 112 receives the authentication response information and can send an authentication response message (e.g., a nausf-u eauthentication response message) including authentication-related information (e.g., 5G HE AV and authentication context identifier) ​​to the AMF 110 via the H-SEPP 126.

[0069] In step 508, the H-SEPP 126 and / or MV 204 may receive the authentication response message, obtain authentication-related information therein (e.g., an authentication context identifier), store this authentication-related information, and associate it with the stored identification information associated with the UE 114.

[0070] In step 509, H-SEPP 126 may send the authentication response message, or a version thereof, to V-SEPP 126 over the N-32 interface.

[0071] In step 510, the V-SEPP 126 receives the authentication response message and may send the authentication response message or a version thereof to the AMF 110.

[0072] Referring to FIG. 5B, in step 511, the AMF 110 may send an authentication confirmation message (e.g., a nausf-ueauthentication message) to the AUSF 112 indicating the authentication context identifier and response data from the UE 114.

[0073] In step 512, V-SEPP 126 receives the authentication confirmation message and may send the authentication confirmation message or a version thereof to H-SEPP 126 via the N-32 interface.

[0074] In step 513 , the H-SEPP 126 receives the authentication confirmation message and may send the authentication confirmation message or a version thereof to the AUSF 112 in the H-PLMN 490 .

[0075] In step 514 , after receiving the authentication confirmation message, the AUSF 112 may send the obtained authentication confirmation information (eg, in the nudm-u eauthentication confirmation message) to the UDM 104 in the H-PLMN 490 .

[0076] In step 515, the UDM 104 may receive the authentication confirmation information and, in response, send the authentication result and optionally the SUPI (eg, in a nudm-ueauthentication acknowledgement message) to the AUSF 112.

[0077] In step 516, the AUSF 112 receives the authentication acknowledgement information and may send an authentication acknowledgement message (e.g., a nausf-u eauthentication response message) toward the AMF 110 via the H-SEPP 126.

[0078] In step 517, the H-SEPP 126 and / or MV 204 may receive the authentication acknowledgement message and store the authentication acknowledgement information (e.g., authentication result and SUPI) along with other information related to the UE 114 that is stored.

[0079] In step 518, H-SEPP 126 may send the response message or a version thereof to V-SEPP 126 via the N-32 interface.

[0080] In step 519, the V-SEPP 126 receives the authentication acknowledgement message and may send the authentication acknowledgement message or a version thereof to the AMF 110.

[0081] 5A-5B are for illustrative purposes, and different and / or additional messages and / or actions may be used. It should also be understood that the various messages and / or actions described herein may occur in a different order or sequence.

[0082] 6 is a message flow diagram illustrating exemplary message validation in a 5G communication network. In some embodiments, the H-SEPP 126 or the MV 204 therein may be configured to perform message validation using one or more identifiers derived or obtained from an AKA procedure or associated messages. For example, after identifying one or more UE-related identifiers (e.g., SUPI, SUCI, serving network name, etc.) from the AKA procedure associated with the UE 114, the H-SEPP 126 or the MV 204 therein may monitor incoming inter-PLMN messages (e.g., HTTP / 2 messages) associated with the UE 114 and determine whether each of the inter-PLMN messages is valid based on stored authentication information associated with the UE 114 before processing, forwarding, and / or responding to the inter-PLMN messages. If the H-SEPP 126 or the MV 204 determines, using the authentication information, that it cannot verify or support that the UE 114 is roaming in the network from which the inter-PLMN message originated, it may consider the message invalid and perform an invalid message action, such as discarding one or more inter-PLMN messages and / or reporting the event to a network administrator or network management system. If the H-SEPP 126 or MV 204 determines using the authentication information to confirm or support that the UE 114 is roaming in the network from which the inter-PLMN message originated, it may consider the message valid and perform valid message operations, e.g., operations that enable the inter-PLMN message to be received and processed at its intended destination.

[0083] 6, for example, prior to steps 601-605, the H-SEPP 126 or the MV 204 therein may derive or obtain authentication information from an AKA-related procedure. For example, the H-SEPP 126 or the MV 204 therein may derive or obtain an identifier and a serving network name associated with the UE from an AKA-related message used in authenticating the UE 114 when the UE 114 attempts to connect to a 5G home network or an associated network (e.g., after the UE 114 powers on). In this example, the H-SEPP 126 or the MV 204 therein may store the identifier and the serving network name associated with the UE for validating subsequent inter-PLMN messages (e.g., HTTP / 2 messages) associated with the UE 114 that traverse the H-SEPP 126.

[0084] In step 601, a 5GC request associated (or appearing to be associated) with UE 114 may be sent from consumer NF 300 in V-PLMN1 488 to V-SEPP 126 for forwarding to H-SEPP 126 in H-PLMN 490, e.g., after an associated AKA procedure. For example, consumer NF 300 in V-PLMN1 488 may represent a network node that requests information from UDM 104, PCF 102, or SMF 108 in H-PLMN 490.

[0085] In step 602, the 5GC request may be forwarded from V-SEPP126 to H-SEPP126 (e.g., as an HTTP / 2 message) via the N32-f interface.

[0086] In step 603, the H-SEPP 126 or the MV 204 therein may receive the 5GC request and perform a message verification procedure. For example, the H-SEPP 126 or the MV 204 may identify a UE identifier (e.g., a SUPI) and an originating network identifier associated with the received 5GC request, and then compare the UE identifier and network identifier associated with the 5GC request with stored authentication information associated with the UE 114 (e.g., derived or obtained from a message associated with a recent AKA procedure for the UE 114). In this example, the H-SEPP 126 or the MV 204 may consider the 5GC request valid if it can use the stored authentication information associated with the UE 114 to support or confirm that the UE 114 is roaming in the network from which the 5GC request originated. Continuing with this example, if the H-SEPP126 or MV204 cannot use stored authentication information associated with the UE114 to support or confirm that the UE114 is roaming in the network from which the 5GC request originated, for example, if the stored authentication information indicates that the UE114 is not roaming or is roaming in a different network, the 5GC request may be considered invalid.

[0087] In step 604, for example, after determining that the 5GC request is valid, the 5GC request or a version thereof may be sent to the producer NF 498 for further processing. For example, the producer NF 498 may be a network node (e.g., UDM 104, PCF 102, or SMF 108) that receives requests for information and responds to those requests with the requested information.

[0088] In step 605, another 5GC request related (or appearing to be related) to the UE 114 may be sent (e.g., as an HTTP / 2 message) from the consumer NF 300 in V-PLMN2 600 to the H-SEPP 126 in the H-PLMN 490. For example, the consumer NF 300 in V-PLMN2 600 may be, or appear to be, a network node such as a V-SEPP or another entity in the actual PLMN. In this example, the consumer NF 300 in V-PLMN2 600 may be compromised, hacked, or otherwise configured to perform or attempt to perform malicious or inappropriate behavior, such as launching a denial of service (DOS) attack using inter-PLMN traffic or stealing subscriber information from the H-PLMN 490.

[0089] In step 606, upon receiving the 5GC request, the H-SEPP 126 or the MV 204 therein may perform a message verification procedure, determine that the 5GC request is invalid, and perform an invalid message action, such as discarding the 5GC request. For example, the H-SEPP 126 or the MV 204 may identify a UE identifier (e.g., SUCI) and an originating network identifier associated with the received 5GC request, and then compare the UE identifier and network identifier associated with the 5GC request with stored authentication information associated with the UE 114. In this example, the stored authentication information indicates that the UE 114 is not roaming, and therefore indicates that the 5GC request is invalid (e.g., fraudulent) and should not be responded to.

[0090] It should be understood that Figure 6 is for illustrative purposes and that different and / or additional messages and / or actions may be used. It should also be understood that the various messages and / or actions described herein may occur in a different order or sequence.

[0091] 7 illustrates an example process 700 for performing message validation in a 5G communication network. In some embodiments, the example process 700 described herein, or portions thereof, may be performed in or by node 200, MV 204, and / or another module or node.

[0092] With reference to the exemplary process 700, aspects (e.g., processing steps or operations) may occur in a network node of the first network (e.g., the SEPP 126 or node 200 including the MV 204 in the home 5GC network).

[0093] In step 702, authentication information may be obtained from at least one AKA procedure-related message associated with user equipment communicating over the second network, the authentication information being usable to identify the subscriber, the user equipment, or the second network.

[0094] In some embodiments, obtaining authentication information from at least one AKA procedure-related message includes obtaining a first identifier from a first AKA procedure-related message and obtaining a second identifier from a second AKA procedure-related message, the second identifier being different from the first identifier.

[0095] In some embodiments, at least one AKA procedure-related message may include one or more data types that include authentication information. For example, the AKA procedure-related message may include an AuthenticationInfo data type, a UEAuthenticationCtx data type, a ConfirmationData data type, or a ConfirmationDataResponse data type.

[0096] In some embodiments, authentication information usable to identify a user equipment may include a network identifier, a user equipment identifier, a network node identifier, a SUPI, a SUCI, a serving network name, or a PLMN identifier.

[0097] In some embodiments, the first network node may include a SEPP, a 5GC network function, a network proxy, or a network gateway.

[0098] In some embodiments, the at least one AKA procedure-related message may be transmitted to a first network node in the first network via a second network node in the second network. In such embodiments, the second network node may include a consumer NF, a PCF, an AMF, an SMF, an NRF, an NSSF, or a 5GC network function.

[0099] At step 704, the authentication information may be stored in a data store for validating subsequent messages. For example, the data store 206 may include records or entries that associate a UE identifier (e.g., a SUPI or SUCI) with other authentication information (e.g., a serving network name or identifier, an authentication context identifier, and / or an authentication result indicating successful authentication). In another example, the data store 206 may include records or entries related to various types of information that can be used to identify and / or authenticate a user equipment or UE, records or entries that are indexed using one or more keys, e.g., a unique UE identifier, a unique authentication context identifier, or a unique combination of identifiers.

[0100] In step 706, a request message associated with the user equipment may be received. For example, an entity appearing to be the AMF 110 may send a nudm-uecm service request associated with the UE 114 towards the UDM 104, which the H-SEPP 126 may receive via the N32-f interface.

[0101] In some embodiments, the request message may include a 5GC request message. For example, the request message may be a nudm-sdm service message, a nudm-uecm service message, a npcf-uepolicy service message, a nsmf-pdusession service message, an nnrf-disc service message, or an nnrf-nfm service message.

[0102] In step 708, the authentication information can be used to determine that the request message is invalid. For example, the H-SEPP 126 or a function therein (e.g., MV 204) can identify the UE identifier and originating network associated with the request message and compare it to stored authentication information corresponding to the UE identifier. In this example, if the stored authentication information is not used to confirm or support that the associated UE is currently roaming in the network from which the request originated, the message is considered invalid.

[0103] In some embodiments, using the authentication information to determine that the request message is invalid may include retrieving the authentication information from a data store (e.g., data store 206) using a user equipment identifier (e.g., a SUPI) in the request message, and determining that the authentication information does not verify that the user equipment is roaming on the network from which the request message originated.

[0104] In response to determining that the request message is invalid, an invalid message action may be performed in step 710. For example, the invalid message action may include discarding the request message or notifying a network administrator or management system.

[0105] In some embodiments, the first network may be a home PLMN (eg, H-PLMN 490) and the second network may be a visited PLMN (eg, V-PLMN2 600).

[0106] It should be understood that process 700 is for illustrative purposes and that different and / or additional messages and / or actions may be used, and that the various messages and / or actions described herein may occur in a different order or sequence.

[0107] It should be understood that although some aspects of the subject matter described herein have been described with reference to 5G networks, various other networks may utilize some aspects of the subject matter described herein. For example, any network utilizing a 5G AKA procedure or similar authentication procedure may use the features, mechanisms, and techniques described herein to obtain or derive authentication information and use the authentication information when performing message verification.

[0108] It should be noted that the node 200, the MV 204, and / or the functionality described herein may constitute dedicated computing devices. The node 200, the MV 204, and / or the functionality described herein may also improve the technical fields of network security and / or message validation in 5G networks. For example, by performing message validation based on UE authentication information (e.g., SUPI, PLMN identifier, and UE authentication status) in the H-SEPP 126, malicious behavior and its adverse effects (e.g., revenue fraud, network congestion, service disruptions, and / or user experience degradation) may be mitigated and / or prevented. In this example, the H-SEPP 126 or the MV 204 therein may utilize one or more techniques and / or methods described herein to prevent DOS attacks using inter-PLMN traffic, prevent theft of subscriber data from the H-PLMN 490, and / or implement SUPI or subscriber-level authorization (e.g., allowing consumer NFs to access only specific UE data). Additionally, the techniques and / or methods described herein may be applicable to multiple services or related interfaces, including, for example, nudm-sdm, nudm-uecm, npcf-uepolicy, nsmf-pdusession, nssf-nsselection, nnrf-disc, and / or nnrf-nfm.

[0109] The disclosure of each of the following references is incorporated herein by reference in its entirety to the extent not inconsistent with this specification and to the extent that it supplements, explains, provides background to, or teaches the methods, techniques, and / or systems used herein.

[0110] It should be understood that various details of the presently disclosed subject matter can be changed without departing from the scope of the presently disclosed subject matter. Furthermore, the foregoing description is for purposes of illustration only, and not limitation.

[0111] References 1. 3GPP TS 29.510; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminal; 5G Systems; Network Function Repository Services; Stage 3 (Release 16), V16.5.0 (2020-09). 2. 3GPP TS 23.003; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminal; Numbering, Addressing and Identification (Release 16), V16.4.0 (2020-09). 3. 3GPP TS 29.573; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminal; 5G Systems; Public Land Mobile Network (PLMN) Interconnection; Stage 3 (Release 16) V16.4.0 (2020-09). 4. 3GPP TS 33.501; 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security Architecture and Procedures for 5G Systems; (Release 16), V16.4.0 (2020-09). 5. 3GPP TS 29.509; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminal; 5G Systems; Authentication Server Services; Stage 3 (Release 16), V16.5.0 (2020-09).

Claims

1. 1. A method for performing message verification in a fifth generation (5G) communications network, the method comprising: At a first network node of a first network, Obtaining authentication information for identifying a user equipment from at least one authentication and key agreement (AKA) procedure related message associated with the user equipment communicating via the second network; and storing the authentication information in a data store for verifying subsequent messages; receiving a request message associated with the user equipment; using the authentication information to determine that the request message is invalid; and performing an invalid message operation in response to determining that the request message is invalid; Determining that the request message is invalid using the authentication information includes: retrieving the authentication information from the data store using a user equipment identifier in the request message; and determining that the authentication information cannot be used to verify that the user equipment is roaming in the network from which the request message originated.

2. 2. The method of claim 1, wherein the request message comprises a 5G Core Request message.

3. The method of claim 1 or 2, wherein the at least one AKA procedure related message includes one or more data types that include the authentication information.

4. The method according to any one of claims 1 to 3, wherein the authentication information comprises an authentication status, a network identifier, a network node identifier, a subscription permanent identifier (SUPI), a serving network name, or a public land mobile network (PLMN) identifier.

5. The method of any one of claims 1 to 4, wherein the first network node comprises a Security Edge Protection Proxy (SEPP), a 5G Core Network Function, a network proxy, or a network gateway.

6. the at least one AKA procedure related message is transmitted via a second network node of the second network; The method according to any one of claims 1 to 5, wherein the second network node comprises a Consumer Network Function (NF), a Policy Control Function (PCF), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a Network Repository Function (NRF), a Network Slice Selection Function (NSSF), or a 5G Core Network Function.

7. The method of any of claims 1 to 6, wherein the invalid message action includes discarding the request message or notifying a network administrator or management system.

8. the first network is a home public land mobile network (PLMN); The method according to any one of claims 1 to 7, wherein the second network is a visited PLMN.

9. 1. A system for performing message verification in a fifth generation (5G) communications network, the system comprising: a first network node of a first network; the first network node includes at least one processor and a memory; The first network node obtaining authentication information for identifying a user equipment from at least one authentication and key agreement (AKA) procedure related message associated with the user equipment communicating via the second network; storing the authentication information in a data store for verifying subsequent messages; receiving a request message associated with the user equipment; Using the authentication information, determine that the request message is invalid; configured to perform an invalid message operation in response to determining that the request message is invalid; the first network node is configured to use a user equipment identifier in the request message to retrieve the authentication information from the data store, and to use the authentication information to determine that the request message is invalid by determining that it cannot verify that the user equipment is roaming in the network from which the request message originated.

10. 10. The system of claim 9, wherein the request message comprises a 5G Core Request Message.

11. 11. The system of claim 9 or 10, wherein the at least one AKA procedure related message includes one or more data types including the authentication information.

12. The system of any of claims 9 to 11, wherein the authentication information includes an authentication status, a network identifier, a network node identifier, a subscription permanent identifier (SUPI), a serving network name, or a public land mobile network (PLMN) identifier.

13. 13. The system of claim 9, wherein the first network node comprises a Security Edge Protection Proxy (SEPP), a 5G core network function, a network proxy, or a network gateway.

14. the at least one AKA procedure related message is transmitted via a second network node of the second network; The system according to any one of claims 9 to 13, wherein the second network node includes a Consumer Network Function (NF), a Policy Control Function (PCF), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a Network Repository Function (NRF), a Network Slice Selection Function (NSSF), or a 5G Core Network Function.

15. The system of any of claims 9 to 14, wherein the invalid message action includes discarding the request message or notifying a network administrator or management system.

16. the first network is a home public land mobile network (PLMN); The system of any of claims 9 to 15, wherein the second network is a visited PLMN.

17. A program for causing a computer to execute the method according to any one of claims 1 to 8.

Images