Methods, systems, and computer-readable media for message authentication in fifth generation (5G) communication networks

Abstract

Methods, systems, and computer-readable media for message validation in fifth generation (5G) communication networks are disclosed. One method occurring at a first network node of a first network includes obtaining authentication information 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 action in response to determining that the request message is invalid.

Description

[0001] Priority Statement

[0002] This application claims priority to U.S. Patent Application Serial No. 17 / 123,038, filed December 15, 2020, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The topics described herein relate to enhancing security in fifth-generation (5G) communication networks. More specifically, the topics described herein relate to methods, systems, and computer-readable media for message authentication in 5G communication networks. Background Technology

[0004] In fifth-generation (5G) communication networks, network nodes that provide services are called producer network functions (NFs). Network nodes that consume services are called consumer NFs. A network function can be either a producer NF or a consumer NF, depending on whether it is consuming or providing services.

[0005] A given producer NF may have multiple 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 Internet Protocol (IP) addresses and port numbers or a fully qualified domain name (FQDN), which resolves to the IP address and port number on the network node hosting the producer NF. An NF instance is an instance of the producer NF that provides a service. A given producer NF may include more than one NF instance. It should also be noted that multiple NF instances can share the same service endpoint.

[0006] Producer NFs register with the Network Functions Store (NRF). The NRF maintains service profiles for available NF instances, identifying the services supported by each NF instance. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF. Besides consumer NFs, another type of network node that can subscribe to receive information about NF service instances is the Service Communication Agent (SCP). The SCP subscribes to the NRF and obtains reachability and service profile information about producer NF service instances. Consumer NFs connect to the Service Communication Agent, which load balances traffic between producer NF service instances providing the required services or routes traffic directly to the destination producer NF instance.

[0007] Besides SCPs, other examples of intermediate proxy nodes or groups of network nodes that route traffic between producer NFs and consumer NFs include Secure Edge Protection Proxies (SEPPs), serving gateways, and nodes in the 5G serving mesh. SEPPs are network nodes used to protect control plane traffic exchanged between different 5G Public Land Mobile Networks (PLMNs). Therefore, SEPPs perform message filtering, censorship, and topology hiding for all Application Programming Interface (API) messages.

[0008] However, there is a need for improved security measures in one or more NFs. Summary of the Invention

[0009] Methods, systems, and computer-readable media for message verification in fifth-generation (5G) communication networks are disclosed. An example method for message verification in a 5G communication network includes: at a first network node in a first network: obtaining authentication information identifying the user equipment from at least one authentication and key agreement (AKA) process-related message associated with a user equipment communicating via a second network; storing the authentication information in a data repository for verifying 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 action in response to determining that the request message is invalid.

[0010] An example system for message verification in a 5G communication network includes a first network node of a first network, the first network node including at least one processor and a memory. The first node is configured to: obtain authentication information identifying a user equipment (UE) from at least one AKA process-related message associated with a UE communicating via a second network; store the authentication information in a data repository for verifying subsequent messages; receive a request message associated with the UE; determine that the request message is invalid using the authentication information; and, in response to determining that the request message is invalid, perform an invalid message action.

[0011] An example non-transitory computer-readable medium includes computer-executable instructions embodied in the non-transitory computer-readable medium, which, when executed by at least one processor of at least one computer, cause the at least one computer to perform steps, the steps including: at a first network node of a first network: obtaining authentication information identifying the user equipment from at least one AKA process-related message associated with a user equipment communicating via a second network; storing the authentication information in a data repository for verifying 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 action in response to determining that the request message is invalid.

[0012] According to aspects of the subject matter described herein, determining that a request message is invalid using authentication information may include retrieving the authentication information from the data repository using the user equipment identifier in the request message, and determining that the authentication information fails to confirm that the user equipment is roaming in the network from which the request message originated.

[0013] According to the aspects of the subject described in this article, request messages for message verification may include nudm-sdm service messages, nudm-uecm service messages, npcf-uepolicy service messages, nsmf-pdusession service messages, nnrf-disc service messages, or nnrf-nfm service messages.

[0014] According to the aspects of the subject described in this article, AKA process-related messages may include messages containing the AuthenticationInfo data type, UEAuthenticationCtx data type, ConfirmationData data type, or ConfirmationDataResponse data type.

[0015] According to aspects of the subject matter described herein, authentication information that can be used to identify a user equipment or 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.

[0016] According to the aspects of the subject matter described in this article, the first network node includes a Security Edge Protection Agent (SEPP), a 5G core network function, a network proxy, or a network gateway.

[0017] In accordance with the aspects of the subject matter described herein, at least one AKA process-related message is sent via a second network node of a second network, wherein the second network node includes a Consumer Network Function (NF), Policy Control Function (PCF), Access and Mobility Management Function (AMF), Session Management Function (SMF), Network Repository Function (NRF), Network Slice Selection Function (NSSF), or 5G core network function.

[0018] Based on aspects of the subject matter described in this article, invalid message actions may include discarding the request message or notifying the network operator or management system.

[0019] According to the themes described in this article, the first network can be the belonging PLMN, and the second network can be the interviewed PLMN.

[0020] The subjects described herein can be implemented using hardware, software, firmware, or any combination thereof. Therefore, the terms “function,” “node,” or “module” as used herein refer to hardware used to implement the described features, but may also include software and / or firmware components. In one example implementation, the subjects described herein can be implemented using a computer-readable medium storing computer-executable instructions that, when executed by a computer’s processor, control the computer to perform steps. Example computer-readable media suitable for implementing the subjects described herein include non-transitory computer-readable media, such as disk storage devices, on-chip memory devices, programmable logic devices, and application-specific integrated circuits (ASICs). Furthermore, computer-readable media implementing the subjects described herein can reside on a single device or computing platform, or can be distributed across multiple devices or computing platforms. Attached Figure Description

[0021] The subject matter described herein will now be explained with reference to the accompanying drawings, in which:

[0022] Figure 1 This is a network diagram illustrating the fifth-generation (5G) network architecture.

[0023] Figure 2 This is a diagram illustrating an example node used for message verification in a 5G communication network;

[0024] Figure 3 This is a message flow diagram illustrating an example authentication and key negotiation (AKA) process involving the Consumer Network Function (NF) and the Authentication Server Function (AUSF);

[0025] Figure 4 This is a diagram illustrating example identifier data associated with various 5G service messages;

[0026] Figures 5A-5B A message flow diagram illustrating the process of obtaining the User Equipment (UE) identifier from messages related to the authentication process is provided.

[0027] Figure 6 This is a message flow diagram illustrating example message verification in a 5G communication network; and

[0028] Figure 7 This is a flowchart illustrating an example process for message verification in a 5G communication network. Detailed Implementation

[0029] The subjects described herein relate to methods, systems, and computer-readable media for message authentication in fifth-generation (5G) communication networks. According to some aspects of the subjects described herein, methods, systems, mechanisms, and / or techniques are provided for message authentication using stored authentication information obtained or derived from user equipment (UE) authentication processes (e.g., 5G Authentication and Key Agreement (AKA) processes). For example, a Security Edge Protection Agent (SEPP) according to various aspects described herein can obtain or derive UE-related authentication information (e.g., UE identifier, serving PLMN identifier, and UE authentication status) obtained by monitoring messages related to the 5G AKA process used to authenticate 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 techniques and / or methods described herein, the SEPP or other network nodes can prevent DoS attacks using inter-PLMN traffic, prevent the theft of subscriber data from the home network, and / or achieve subscriber-level authorization.

[0030] Reference will now be made in detail to various embodiments of the subject matter described herein, examples of which are illustrated in the accompanying drawings. Where possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts.

[0031] Figure 1 It is a diagram illustrating an example 5G system network architecture, such as a block diagram of the 5G Core (5GC) network. Figure 1 The architecture includes NRF 100 and SCP 101, which can reside within the same Home Public Land Mobile Network (PLMN). As described above, NRF 100 can maintain profiles of available producer NF service instances and their supported services, and allow consumer NFs or SCPs to subscribe to and be notified of new / updated producer NF service instance registrations. SCP 101 can also support service discovery and producer NF instance selection. SCP 101 can perform load balancing of connections between consumer NFs and producer NFs. Additionally, using the methods described herein, SCP 101 can perform selection and routing based on preferred NF locations.

[0032] NRF 100 is a repository of NF or service profiles for producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP must obtain the producer NF instance or NF or service profile from NRF 100. The NF or service profile is a JavaScript Object Notation (JSON) data structure defined in 3GPP Technical Specification (TS) 29.510. The NF or service profile definition includes at least one of a Fully Qualified Domain Name (FQDN), an Internet Protocol Version 4 (IPv4) address, or an IPv6 (IPv6) address. Figure 1 In this context, any node (except NRF 100) can be either a consumer NF or a producer NF, depending on whether it is requesting or providing services. In the example illustrated, the nodes include a Policy Control Function (PCF) 102 that performs policy-related operations in the network, a User Data Management (UDM) function 104 that manages user data, and an Application Function (AF) 106 that provides application services. Figure 1 The nodes shown in the diagram also include a Session Management Function (SMF) 108, which manages the session between the 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. The Authentication Server Function (AUSF) 112 provides authentication services for user equipment seeking network access, such as User Equipment (UE) 114.

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

[0034] Radio Access Network (RAN) 120 connects UE 114 to the network via a radio link. This can be achieved using a g-Node B (gNB). Figure 1 (Not shown in the image) or other wireless access points to access the radio access network 120. The User Plane Function (UPF) 122 can support various proxy functions for user plane services. An example of such a proxy function is the Multipath Transmission Control Protocol (MPTCP) proxy function. The UPF 122 can also support performance measurement functions, which the UE 114 can use to obtain network performance measurement results. Figure 1 The diagram also illustrates data network (DN) 124, through which the UE accesses data network services, such as Internet services.

[0035] The Security Edge Protection Agent (SEPP) 126 filters incoming traffic from other PLMNs and performs topology hiding for traffic leaving the home PLMN. SEPP 126 can communicate with the SEPP in the external PLMN, which manages security for that external PLMN. Therefore, traffic between NFs in different PLMNs can traverse two SEPP functions, one for the home PLMN and the other for the external PLMN.

[0036] SEPP 126 can utilize the N32-c and N32-f interfaces. The N32-c interface is the control plane interface between two SEPPs, used to perform initial handshakes (e.g., TLS handshakes) and negotiate various parameters for N32-f interface connections and related message forwarding. The N32-f interface is the forwarding interface between two SEPPs, used to forward various communications (e.g., 5GC requests) between consumer NFs and producer NFs after application-level security protection has been applied.

[0037] One problem with existing 5G architectures is their lack of resource or object-level authorization. Instead, they rely on API-based authorization models. For example, if a compromised AMF in a trusted (but compromised or hacked) visitor PLMN (V-PLMN) has access to nudm-sdm services, the AMF can request and receive UE subscription data from the home network's UDM without confirmation from the home network or its network nodes that the relevant UE is actually roaming. 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 large number of inter-PLMN messages to the home PLMN's SEPP. Therefore, the home PLMN's SEPP provides little protection for a trusted but compromised V-PLMN.

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

[0039] In some embodiments, node 200 or related modules may be configured (e.g., via programming logic) to perform message verification on inter-PLMN messages using UE-related authentication information obtained during the AKA process, thereby reducing or mitigating the impact of unauthorized and / or malicious entities interacting with network nodes in the 5G home network. For example, node 200 or related modules may be configured to identify and store authentication information (e.g., one or more UE identifiers and service network names 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) that appears to be related to UE 114 is valid, for example, by using the stored authentication information to confirm that UE 114 is roaming in the network from which the inter-PLMN message originates.

[0040] See Figure 2 Node 200 may include one or more communication interfaces 202 for transmitting messages via a communication environment, such as a home 5GC network. In some embodiments, the 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 a home network, such as one or more SEPPs 126 in a home 5GC network.

[0041] Node 200 may include a message authenticator (MV) 204. MV 204 may be any suitable entity (e.g., software executing on at least one processor) for performing one or more aspects of message authentication. In some embodiments, MV 204 may include functionality for obtaining authentication information identifying the user equipment from at least one AKA process-related message associated with a user equipment communicating via a second network, and for using that authentication information to verify subsequent messages associated with (or appearing to be associated with) the user equipment. In some embodiments, obtaining authentication information from at least one AKA process-related message may include monitoring or inspecting AKA process-related messages passing through node 200. In another example, obtaining authentication information from at least one AKA process-related message may include inspecting copies of AKA process-related messages sent to MV 204. In some embodiments, MV 204 may obtain one or more identifiers (e.g., SUPI or SUCI and service network name) from a first AKA process-related message (e.g., a nausf-ueauthentication request) and additional information (e.g., an authentication context identifier) ​​from a second AKA process-related message (e.g., a nausf-ueauthentication response).

[0042] In some embodiments, MV 204 can be configured to monitor N32-f interface connections for inter-PLMN messages (e.g., HTTP / 2 messages). For example, for a received inter-PLMN message, MV 204 can use stored relevant authentication information to determine whether the inter-PLMN message is valid. In this example, MV 204 can identify UE identification information in the inter-PLMN message and use this information to query data storage 206 and obtain relevant authentication information. Continuing with this example, MV 204 can analyze the stored authentication information to determine whether the authentication information confirms or supports that UE 114 is roaming in the network from which the inter-PLMN message originated. If the authentication information confirms or supports that UE 114 is roaming in the network from which the inter-PLMN message originated, the inter-PLMN message can be considered valid. If the authentication information does not confirm or support that UE 114 is roaming in the network from which the inter-PLMN message originated, the inter-PLMN message can be considered invalid.

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

[0044] Node 200 can access data storage 206 (e.g., read information from and / or write information to it). Data storage 206 can be any suitable entity for storing various types of data (e.g., computer-readable media or memory). In some embodiments, data storage 206 may include authentication information for user equipment and / or related information used during message verification. For example, data storage 206 may include data records or entries containing various types of authentication information (e.g., information that can be used to identify and / or authenticate a UE) and indexed using one or more keywords (e.g., a unique UE identifier, a unique authentication context identifier, or a unique combination of identifiers). In this example, each data record or entry may relate to a roaming subscriber or 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). Example authentication information may include authentication status, network identifier, user equipment identifier, network node identifier, subscription persistent identifier (SUPI), subscription hidden identifier (SUCI), or PLMN identifier.

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

[0046] It is important to realize that, Figure 2 The descriptions and related information are for illustrative purposes, and node 200 may include additional and / or different modules, components or functions.

[0047] Figure 3 This is a message flow diagram illustrating an example AKA procedure involving consumer NF 300 and AUSF 112. In some embodiments, consumer NF 300 may represent a network node in a V-PLMN interacting with AUSF 112. For example, consumer NF 300 (e.g., an AMF (V-AMF) in the V-PLMN) can request authentication of UE 114 by providing UE-related information and the service network name to AUSF 112, which can then retrieve UE-related information and the authentication method from UDM 104. In this example, intermediate nodes (e.g., H-SEPP 126 between consumer NF 300 and AUSF 112) that receive and forward various messages involved in the 5G AKA procedure can be configured to obtain and store authentication information associated with UE 114 for message verification of subsequent inter-PLMN messages associated with UE 114.

[0048] The 5G AKA process and other security processes are defined in 3GPP Technical Specification (TS) 33.501. The 5G AKA process associated with the Nausf_UEAuthentication service is further defined in TS 29.509. As defined in TS 29.509, various messages are used in the 5G AKA process, and various structured data types may be included, containing authentication information that can be used to perform message verification 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., servingNetworkName), an authentication type (e.g., authType), an authentication result (e.g., authResult), and / or other information.

[0049] The following describes some example structured data types that can contain authentication information, as defined in TS 29.509, including the AuthenticationInfo data type, the UEAuthenticationCtx data type, the ConfirmationData data type, and the ConfirmationDataResponse data type.

[0050]

[0051]

[0052] See Figure 3 In step 301, consumer NF 300 may send a POST request to AUSF 112. The payload of the POST request may include an AuthenticationInfo data type, which contains the UE identifier (e.g., SUPI or SUCI) associated with UE 114 and the service network identifier (e.g., servingnetworkname).

[0053] If successful in step 302A, a "201Created" message can be returned. This message may include a UEAuthenticationCtx data type, which contains various authentication-related information.

[0054] In step 302B, if unsuccessful, a “4XX or 5XX” message can be returned, which indicates the HTTP status code and contains a ProblemDetails structure with a “reason” attribute set.

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

[0056] In step 304A, if successful, a "200 OK" message can be returned. This message can indicate whether UE 114 has been authenticated. If UE 114 has not been authenticated, for example because AUSF 112 failed to verify the "RES*" information, the AuthResult value in this message can be set to "AUTHENTICATION_FAILURE".

[0057] In step 304B, if unsuccessful, a “4XX or 5XX” message can be returned, which indicates the HTTP status code and contains a ProblemDetails structure with a “reason” attribute set.

[0058] It is important to realize that, Figure 3 For illustrative purposes only, 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 different orders or sequences.

[0059] Figure 4 This is a diagram illustrating example identification data 400 associated with various 5G service messages. In some embodiments, data 400 may indicate inter-PLMN messages associated with 5G services, consumer NFs using 5G services, and message inputs found in inter-PLMN messages for identifying the UE or associated service network (e.g., the network in which the UE is roaming). For example, when UE 114 roams in an visited PLMN (V-PLMN), various communications between UE 114's home PLMN and V-PLMN may be needed to obtain or provide information associated with UE 114. As described above, inter-PLMN messages can be sent between H-PLMN and V-PLMN via SEPP 126 in the respective networks. However, 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). Therefore, different inter-PLMN messages may include different types of UE identification information or network identification information.

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

[0061]

[0062]

[0063] Table 1 - Example Inter-PLMN Messages In some embodiments, node 200, H-SEPP 126, or MV 204 can be configured to identify relevant message inputs or values ​​for various inter-PLMN messages (such as those in Table 1) during message verification. For example, node 200 or MV 204 can analyze different types of UE identification information (e.g., SUPI or SUCI) based on the type of inter-PLMN message received and the type of UE identification information available in the received inter-PLMN message.

[0064] See Figure 4The table representing data 400 includes columns and / or fields for service name, V-PLMN consumer NF, and message input. The service name field can store information representing a set of inter-PLMN messages associated with a specific service or related interface. For example, Figure 4 The first data row of the table indicates the service name field value 'npcf-uepolicycontrol'. In this example, the service name field value 'npcf-uepolicycontrol' could represent a set of messages associated with the UE policy control service. In another example, Figure 4 The second data row of the table indicates the service name field value 'nudm-sdm'. In this example, the service name field value 'nudm-sdm' could represent a set of messages associated with the service used to retrieve UE subscription data from the UDM. Example service names could include npcf-uepolicycontrol, nudm-sdm, nudm-uecm, nausf-ueauthentication, nsmf-pdusession, nssf-nsselection, nnrf-disc, or nnrf-nfm.

[0065] The V-PLMN consumer NF field can store information indicating a specific consumer NF that is sending or initiating a particular type or set of (e.g., service-related) inter-PLMN messages. For example, Figure 4 The first data row of the table indicates the V-PLMN consumer NF field value 'PCF'. In this example, the V-PLMN consumer NF field value 'PCF' could indicate that a PCF located in the V-PLMN can send the npcf-uepolicycontrol service message. In another example, Figure 4 The fifth data row of the table indicates the V-PLMN consumer NF field value 'SMF'. In this example, the V-PLMN consumer NF field value 'SMF' could indicate that the SMF located in the V-PLMN can send nsmf-pdusession service messages. Example V-PLMN consumer NFs could include AMF (e.g., the AMF in the V-PLMN), SMF (e.g., the SMF in the V-PLLN), NSSF (e.g., the NSSF in the V-PLMN), or NRF (e.g., the NFR in the V-PLMN).

[0066] The message input field can store information in a specific type or a specific set of (e.g., service-related) inter-PLMN messages that can be used to identify the UE or the relevant service network (e.g., the network in which the UE is roaming). For example... Figure 4The first data row of the table indicates the message input field value 'SUPI'. In this example, the message input 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, Figure 4 The fourth data row of the table indicates the message input field value 'SUCI'. In this example, the message input 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., UE114). Example message inputs for various inter-PLMN messages may include SUPI, SUCI, the PLMN ID of the SUPI, or an optional SUPI.

[0067] It should also be recognized that the purpose of using data 400 as an example is related to... Figure 4 Different and / or additional data shown may be used to indicate default values ​​for specific data portions or other information. Furthermore, various data structures and / or computer-readable media may be used to store (e.g., in data storage 206) and manage data 400.

[0068] Figures 5A-5B This diagram illustrates the message flow for obtaining authentication information from messages related to the authentication process. (Reference) Figures 5A-5B UE 114 can trigger the AKA procedure, which involves communication between AMF 110 in V-PLMN 1 488 and AUSF 112 in H-PLMN 490. For example... Figures 5A-5B As shown, during the AKA process, various AKA-related messages can pass through V-SEPP 126 and H-SEPP 126.

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

[0070] See Figure 5A In step 501, AMF 110 may send an authentication request message (e.g., nausf-ueauthentication message) to AMF 112 via V-SEPP 126, indicating the SUPI or SUCI and service network name information for authenticating UE 114.

[0071] In step 502, V-SEPP 126 can receive authentication request messages and can send authentication request messages or their versions to H-SEPP 126 via the N-32 interface.

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

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

[0074] In step 505, after receiving the authentication request message, AUSF 112 may send the obtained identification information (e.g., in the nudm-ueauthentication request message) to UDM 104 in H-PLMN 490.

[0075] In step 506, UDM 104 can receive the identification information and respond by sending authentication response information (e.g., in a nudm-ueauthentication response message) to AUSF 112, including the 5G Home Environment (HE) authentication vector (AV) and optional SUPI.

[0076] In step 507, AUSF 112 can receive authentication response information and can send an authentication response message (e.g., nausf-ueauthentication response message) containing authentication-related information (e.g., 5G HE AV and authentication context identifier) ​​to AMF 110 via H-SEPP 126.

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

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

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

[0080] See Figure 5B In step 511, AMF 110 may send an authentication confirmation message (e.g., nausf-ueauthentication message) to AMF 112, indicating the authentication context identifier and response data from UE 114.

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

[0082] In step 513, H-SEPP 126 can receive an authentication confirmation message and can send the authentication confirmation message or a version thereof to AUSF 112 in H-PLMN 490.

[0083] In step 514, after receiving the authentication confirmation message, AUSF 112 may send the obtained authentication confirmation information (e.g., in the nudm-ueauthentication confirmation message) to UDM 104 in H-PLMN 490.

[0084] In step 515, UDM 104 may receive authentication confirmation information and respond by sending authentication result and optional SUPI (e.g., in nudm-ueauthentication confirmation response message) to AUSF 112.

[0085] In step 516, AUSF 112 can receive authentication confirmation response information and can send an authentication confirmation response message (e.g., nausf-ueauthentication response message) to AMF 110 via H-SEPP 126.

[0086] In step 517, H-SEPP 126 and / or MV 204 may receive the authentication confirmation response message and may store the authentication confirmation response information therein (e.g., authentication result and SUPI) and other stored information associated with UE 114.

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

[0088] In step 519, V-SEPP 126 may receive an authentication confirmation response message and may send the authentication confirmation response message or a version thereof to AMF 110.

[0089] It is important to realize that, Figures 5A-5B For illustrative purposes only, 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 different orders or sequences.

[0090] Figure 6This is a message flow diagram illustrating example message verification in a 5G communication network. In some embodiments, H-SEPP 126 or MV 204 therein can be configured to perform message verification using one or more identifiers derived or obtained from the AKA process or related messages. For example, after identifying one or more UE-related identifiers (e.g., SUPI, SUCI, serving network name, etc.) from the AKA process associated with UE 114, H-SEPP 126 or MV 204 therein can monitor ingress PLMN messages (e.g., HTTP / 2 messages) associated with UE 114 and can determine the validity of each PLMN message based on stored authentication information associated with UE 114 before processing, forwarding, and / or responding to PLMN messages. If H-SEPP 126 or MV 204 determines that the authentication information fails to confirm or support that UE 114 is roaming in the network from which the inter-PLMN message originated, then H-SEPP 26 or MV 204 may consider the message invalid and perform invalid message actions, such as discarding one or more inter-PLMN messages and / or reporting the event to the network operator or network management system. If H-SEPP 126 or MV 204 determines that the authentication information confirms or supports that UE 114 is roaming in the network from which the inter-PLMN message originated, then H-SEPP 26 or MV 204 may consider the message valid and perform valid message actions, such as allowing the inter-PLMN message to be received and processed at the predetermined destination.

[0091] See Figure 6 For example, prior to steps 601-605, H-SEPP 126 or its MV 204 can derive or obtain authentication information from the AKA-related process. For instance, H-SEPP 126 or its MV 204 can derive or obtain the UE-related identifier and service network name from the AKA-related messages used to authenticate UE 114 when it attempts to connect to its 5G home network or related network (e.g., after UE 114 powers on). In this example, H-SEPP 126 or its MV 204 can store the UE-related identifier and service network name for verifying subsequent PLMN-to-PLMN messages (e.g., HTTP / 2 messages) associated with UE 114 that pass through H-SEPP 126.

[0092] In step 601, for example, after the relevant AKA procedure, a 5GC request associated with (or appearing to be associated with) UE 114 can be sent from consumer NF 300 in V-PLMN 1 488 to V-SEPP 126 for forwarding to H-SEPP 126 in H-PLMN 490. For example, consumer NF 300 in V-PLMN 1 488 could represent a network node requesting information from UDM104, PCF 102, or SMF 108 in H-PLMN 490.

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

[0094] In step 603, H-SEPP 126 or MV 204 therein may receive a 5GC request and perform a message verification process. For example, H-SEPP 126 or MV 204 may identify the UE identifier (e.g., SUPI) and the initiating network identifier associated with the received 5GC request, and may then compare the UE identifier and network identifier associated with the 5GC request with stored authentication information associated with UE 114 (e.g., derived or obtained from messages related to the most recent AKA procedure for UE 114). In this example, if the stored authentication information associated with UE 114 supports or confirms that UE 114 is roaming in the network from which the 5GC request originated, then H-SEPP 126 or MV 204 may consider the 5GC request valid. Continuing with this example, if the stored authentication information associated with UE 114 does not support or confirm that UE 114 is roaming in the network from which the 5GC request originated, for example, if the stored authentication information indicates that UE 114 is not roaming or is roaming in a different network, then H-SEPP 126 or MV 204 may consider the 5GC request invalid.

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

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

[0097] In step 606, H-SEPP 126 or MV 204 therein can receive a 5GC request, perform a message verification process, determine that the 5GC request is invalid, and perform an invalid message action, such as discarding the 5GC request. For example, H-SEPP 126 or MV 204 can identify the UE identifier (e.g., SUCI) and the initiating 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 UE 114. In this example, the stored authentication information may indicate that UE 114 is not roaming, thereby indicating that the 5GC request is invalid (e.g., fraudulent) and should not be answered.

[0098] It is important to realize that, Figure 6 For illustrative purposes only, 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 different orders or sequences.

[0099] Figure 7 This is a diagram illustrating an example process 700 for message verification in a 5G communication network. In some embodiments, the example process 700 or its various parts described herein may be performed by or on node 200, MV 204 and / or another module or node.

[0100] Referring to example processing 700, various aspects (e.g., processing steps or actions) may occur at network nodes of the first network (e.g., SEPP 126 in the 5GC network or node 200 including MV 204).

[0101] In step 702, authentication information can be obtained from at least one AKA process-related message associated with a user equipment communicating via the second network, wherein the authentication information can be used to identify the subscriber, user equipment, or second network.

[0102] In some embodiments, obtaining authentication information from at least one AKA process-related message includes obtaining a first identifier from a first AKA process-related message and obtaining a second identifier that is different from the first identifier from a second AKA process-related message.

[0103] In some embodiments, at least one AKA process-related message may include one or more data types, including authentication information. For example, an AKA process-related message may contain an AuthenticationInfo data type, a UEAuthenticationCtx data type, a ConfirmationData data type, or a ConfirmationDataResponse data type.

[0104] In some embodiments, authentication information that can be used to identify a user equipment may include a network identifier, a user equipment identifier, a network node identifier, a SUPI, a SUCI, a service network name, or a PLMN identifier.

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

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

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

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

[0109] 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, an npcf-uepolicy service message, an nsmf-pdusession service message, an nnrf-disc service message, or an nnrf-nfm service message.

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

[0111] In some embodiments, determining that a request message is invalid using authentication information may include retrieving authentication information from a data repository (e.g., data storage 206) using a user equipment identifier (e.g., SUPI) in the request message, and determining that the authentication information fails to confirm that the user equipment is roaming in the network from which the request message originated.

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

[0113] In some embodiments, the first network may be a home PLMN (e.g., H-PLMN 490) and the second network may be a visited PLMN (e.g., V-PLMN 2 600).

[0114] It should be recognized that the 700 is used for illustrative purposes and different and / or additional OR actions may be used. It should also be recognized that the various actions described herein may occur in different orders or sequences.

[0115] It should be recognized that while some aspects of the topics described in this article have been discussed with reference to 5G networks, various other networks can utilize aspects of the topics described in this article. For example, any network utilizing the 5G AKA process or a similar authentication process can use the features, mechanisms, and techniques described in this article to obtain or derive authentication information and use that authentication information when performing message verification.

[0116] It should be noted that the nodes 200, MV 204, and / or functions described herein can constitute a dedicated computing device. Furthermore, the nodes 200, MV 204, and / or functions described herein can improve network security and / or message authentication techniques in 5G networks. For example, by performing message authentication based on UE authentication information (e.g., SUPI, PLMN identifier, and UE authentication status) in H-SEPP 126, malicious activities and their negative consequences (e.g., revenue fraud, network congestion, service failure, and / or poor user experience) can be mitigated and / or prevented. In this example, by utilizing one or more technologies and / or methods described herein, H-SEPP 126 or MV 204 therein can prevent DoS attacks using inter-PLMN traffic, prevent the theft of subscriber data from H-PLMN 490, and / or implement SUPI or subscriber-level authorization (e.g., enabling consumer NFs to access only specific UE data). Furthermore, the techniques and / or methods described herein are applicable to a variety of services or related interfaces, including, for example, nudm-sdm, nudm-uecm, npcf-uepolicy, nsmf-pdusession, nssf-nsselection, nnrf-disc, and / or nnrf-nfm.

[0117] The public information contained in the following references is incorporated herein by reference in its entirety, without contradicting this document, and in connection with supplementing, explaining, or providing background or teaching on the methods, techniques, and / or systems used herein.

[0118] References:

[0119] 1.3GPP TS 29.510; 3 rd Generation Partnership Project; TechnicalSpecification Group Core Network and Terminals; 5G System; Network FunctionRepository Services; Stage 3(Release 16),V16.5.0(2020-09).

[0120] 2.3GPP TS 23.003; 3 rd Generation Partnership Project; TechnicalSpecification Group Core Network and Terminals; Numbering, addressing and identification (Release 16), V16.4.0 (2020-09).

[0121] 3.3GPP TS 29.573; 3 rd Generation Partnership Project; TechnicalSpecification Group Core Network and Terminals; 5G System; Public Land Mobile Network (PLMN) Interconnection; Stage 3 (Release 16) V16.4.0 (2020-09).

[0122] 4.3GPP TS 33.501; 3 rd Generation Partnership Project; TechnicalSpecification Group Services and System Aspects; Security Architecture and Procedures for the 5G System; (Release 16), V16.4.0 (2020-09).

[0123] 5.3GPP TS 29.509; 3 rd Generation Partnership Project; TechnicalSpecification Group Core Network and Terminals; 5G System; AuthenticationServer Services; Stage 3(Release 16),V16.5.0(2020-09).

[0124] It should be understood that various details of the currently disclosed subject matter can be changed without departing from the scope of the currently disclosed subject matter. Furthermore, the above description is for illustrative purposes only and not for limitation.

Claims

1. A method for message verification in a fifth-generation (5G) communication network, the method comprising: At the Security Edge Protection Agent (SEPP) of the first network: When at least one authentication and key negotiation (AKA) process-related message associated with a user equipment communicating via a second network is passing through the SEPP to reach a destination different from the SEPP, authentication information identifying the user equipment is obtained from the at least one AKA process-related message by examining the at least one AKA process-related message; The authentication information is stored in a data repository for use in verifying subsequent messages; Receive a request message associated with the user equipment; Determining that the request message is invalid using the authentication information includes retrieving the authentication information from the data repository using the user equipment identifier in the request message, and determining that the authentication information fails to confirm that the user equipment is roaming in the network from which the request message originated; as well as In response to determining that the request message is invalid, an invalid message action is performed.

2. The method according to claim 1, wherein the request message includes a 5G core request message.

3. The method according to claim 1, wherein the at least one AKA process-related message includes one or more data types, and the one or more data types include the authentication information.

4. The method according to claim 1, wherein the authentication information includes authentication status, network identifier, network node identifier, subscription permanent identifier (SUPI), service network name or public land mobile network (PLMN) identifier.

5. The method according to claim 1, wherein the at least one AKA process-related message is sent via a second network node of the second network, 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.

6. The method according to claim 1, wherein the invalid message action includes discarding the request message or notifying the network operator or management system.

7. The method according to claim 1, wherein the first network is a Home Public Land Mobile Network (PLMN) and the second network is a visited PLMN.

8. A system for message verification in a fifth-generation (5G) communication network, the system comprising: The first network's Security Edge Protection Agent (SEPP), the SEPP comprising: At least one processor; and memory, The SEPP is configured to: When at least one authentication and key negotiation (AKA) process-related message associated with a user equipment communicating via a second network is passing through the SEPP to reach a destination different from the SEPP, authentication information identifying the user equipment is obtained from the at least one AKA process-related message by examining the at least one AKA process-related message; The authentication information is stored in a data repository for use in verifying subsequent messages; Receive a request message associated with the user equipment; Determining the invalidity of the request message using the authentication information includes retrieving the authentication information from the data repository using the user equipment identifier in the request message, and determining that the authentication information fails to confirm that the user equipment is roaming in the network from which the request message originated; and In response to determining that the request message is invalid, an invalid message action is performed.

9. The system according to claim 8, wherein the request message includes a 5G core request message.

10. The system according to claim 8, wherein the at least one AKA process-related message includes one or more data types, and the one or more data types include the authentication information.

11. The system according to claim 8, wherein the authentication information includes authentication status, network identifier, network node identifier, subscription permanent identifier (SUPI), service network name or public land mobile network (PLMN) identifier.

12. The system according to claim 8, wherein the at least one AKA process-related message is sent via a second network node of the second network, 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.

13. The system of claim 8, wherein the invalid message action includes discarding the request message or notifying the network operator or management system.

14. The system according to claim 8, wherein the first network is a Home Public Land Mobile Network (PLMN) and the second network is a visited PLMN.

15. A non-transitory computer-readable medium having stored executable instructions thereon, the executable instructions, when executed by at least one processor of a computer, causing the computer to perform steps, the steps comprising: At the Security Edge Protection Agent (SEPP) of the first network: When at least one authentication and key negotiation (AKA) process-related message associated with a user equipment communicating via a second network is passing through the SEPP to reach a destination different from the SEPP, authentication information identifying the user equipment is obtained from the at least one AKA process-related message by examining the at least one AKA process-related message; The authentication information is stored in a data repository for use in verifying subsequent messages; Receive a request message associated with the user equipment; Determining that the request message is invalid using the authentication information includes retrieving the authentication information from the data repository using the user equipment identifier in the request message, and determining that the authentication information fails to confirm that the user equipment is roaming in the network from which the request message originated; as well as In response to determining that the request message is invalid, an invalid message action is performed.

Images