Methods, systems, and computer readable media for detecting stolen access tokens

Abstract

Methods, systems, and computer readable media for detecting stolen access tokens are disclosed. One example method for detecting a stolen access token includes, at a network function (NF) including at least one processor: receiving a service request including an access token from a sender via a transport layer security (TLS) connection, wherein the access token includes ownership information indicating a TLS parameter for verifying an owner of the access token; determining whether the ownership information and the TLS information are matched by using the ownership information of the access token and the TLS information in the TLS certificate obtained from the sender; and in response to determining that the ownership information and the TLS information are not matched, denying the service request.

Description

[0001] Priority claim

[0002] This application claims the benefit of priority to U.S. patent application serial number 17 / 987,820, filed on November 15, 2022, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The subject matter described herein relates to security in telecommunications networks. More particularly, the subject matter described herein relates to methods, systems, and computer-readable media for detecting stolen access tokens. Background Art

[0004] In the fifth generation (5G) telecommunication network, a network function that provides a service is referred to as a producer network function (NF) or NF service producer. A network function that consumes a service is referred to as a consumer NF or NF service consumer. A network function can be a producer NF, a consumer NF, or both, depending on whether the network function is consuming, producing, or consuming and producing a service. The terms "producer NF" and "NF service producer" are used interchangeably herein. Similarly, the terms "consumer NF" and "NF service consumer" are used interchangeably herein.

[0005] A given producer NF may have many service endpoints, where a service endpoint is a contact point for one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of an Internet Protocol (IP) address and a port number, or a fully qualified domain name that resolves to an IP address and a port number on a network node hosting the producer NF. An NF instance is an instance of a 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 may share the same service endpoint.

[0006] Producer NFs register with the NF Repository Function (NRF). NRF maintains service profiles of available NF instances that identify the services supported by each NF instance. The terms "service profile" and "NF profile" are used interchangeably in this article. Consumer NFs can subscribe to receive information about producer NF instances that have registered with NRF.

[0007] In addition to consumer NFs, another type of network node that can subscribe to receive information about NF service instances is a Service Communication Proxy (SCP). The SCP subscribes to the NRF and obtains reachability and service profile information about producer NF service instances. Consumer NFs connect to the SCP, and the SCP load balances traffic between producer NF service instances that provide the required service or routes traffic directly to the destination producer NF instance.

[0008] In addition to SCP, another example of an intermediate proxy node that routes traffic between producer and consumer NFs is the Security Edge Protection Proxy (SEPP). SEPP is a network node used to protect control plane traffic exchanged between different 5G Public Land Mobile Networks (PLMNs). Thus, SEPP performs message filtering, policing, and topology hiding on all Application Programming Interface (API) messages transmitted between PLMNs.

[0009] The current security process for accessing the service-based architecture (SBA) interface defined in 3GPP TS 33.501 is called service access authorization. The message for accessing the SBA interface is called a service-based interface (SBI) message, and the service provided on the interface is called an SBI service. According to the service access authorization process, a consumer NF seeking to access the SBI service provided by the producer NF must obtain an OAuth 2.0 access token from the NRF. In order to obtain an OAuth 2.0 access token from the NRF, the consumer NF sends an access token request to the NRF. The NRF verifies the request, generates an access token, and returns the access token to the consumer NF. When the consumer NF seeks to access a service, the consumer NF sends an SBI service request message to the producer NF. The SBI service request message includes the access token obtained from the NRF. The producer NF verifies the integrity of the claims (e.g., attributes) in the access token, and if the claims are valid, the producer NF provides access to the requested service.

[0010] One problem with this architecture is that the access token may be stolen by a hacker and used to obtain services from the producer NF without authorization and / or to perform attacks. Even if the access token has an expiration time, since the access token can be reused, a hacker who steals the access token may maliciously use the access token to access SBI services and / or perform a denial of service attack (e.g., by sending a large number of service requests with high priority to one or more producer NFs) before the expiration time. Summary of the invention

[0011] Methods, systems, and computer-readable media for detecting stolen access tokens are disclosed. An example method for detecting stolen access tokens includes: at a network function (NF) including at least one processor: receiving a service request including an access token from a sender via a transport layer security (TLS) connection, wherein the access token includes ownership information indicating TLS parameters for verifying an owner of the access token; determining whether the ownership information and the TLS information match using the ownership information of the access token and TLS information in a TLS certificate obtained from the sender; and in response to determining that the ownership information and the TLS information do not match, rejecting the service request.

[0012] An example system for detecting a stolen access token includes at least one processor, a memory, and a NF using the at least one processor and the memory. The NF is configured to: receive a service request including an access token from a sender via a TLS connection, wherein the access token includes ownership information indicating TLS parameters for verifying an owner of the access token; determine whether the ownership information and the TLS information match using the ownership information of the access token and TLS information in a TLS certificate obtained from the sender; and in response to determining that the ownership information and the TLS information do not match, reject the service request.

[0013] 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 a NF, causes the NF to perform steps including: receiving a service request including an access token from a sender via a TLS connection, wherein the access token includes ownership information indicating TLS parameters for verifying an owner of the access token; determining whether the ownership information and the TLS information match using the ownership information of the access token and TLS information in a TLS certificate obtained from the sender; and in response to determining that the ownership information and the TLS information do not match, rejecting the service request.

[0014] The subject matter described herein can be implemented with hardware, software, firmware, or any combination thereof. Thus, the terms "function", "node", or "module" as used herein refer to hardware for implementing the described features, which may also include software and / or firmware components. In an example implementation, the subject matter described herein can be implemented using a computer-readable medium on which computer-executable instructions are stored, which, when executed by a processor of a computer, control the computer to perform steps. Example computer-readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application-specific integrated circuits. In addition, the computer-readable medium implementing the subject matter described herein can be located on a single device or computing platform, or can be distributed across multiple devices or computing platforms. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0016] Figure 1 is a network diagram illustrating an example fifth generation (5G) network architecture;

[0017] Figure 2 is a message flow diagram illustrating a scenario involving obtaining an access token from a network function (NF) repository function (NRF);

[0018] Figure 3 is a message flow diagram illustrating an example denial of service (DoS) attack scenario involving a stolen access token;

[0019] Figure 4 is a block diagram illustrating an example NF for detecting stolen access tokens;

[0020] Figure 5 is a message flow diagram illustrating a scenario involving a consumer NF providing ownership information when requesting an access token from an NRF;

[0021] Figure 6 is a message flow diagram illustrating a scenario involving an intermediate NF providing ownership information when registering with an NRF;

[0022] Figure 7 is a message flow diagram illustrating a scenario involving a consumer NF sending a service request to a producer NF via an intermediate NF;

[0023] Figure 8 is a message flow diagram illustrating a scenario involving a NF detecting that an access token in a service request is owned by a requesting entity;

[0024] Fig. 9 is a message flow diagram illustrating a scenario involving a stolen access token in a NF detection service request;

[0025] Fig.10 depicts example ownership data that may be used to determine ownership attributes of an access token; and

[0026] Fig.11 is a flow chart illustrating an example process for detecting stolen access tokens. DETAILED DESCRIPTION

[0027] The subject matter described herein relates to methods, systems, and computer-readable media for detecting stolen access tokens. As described above, one problem with the 5G service-based interface (SBI) architecture is that access tokens may be stolen by hackers or malicious entities and used to obtain services from producer network functions (NFs) without authorization and / or to perform denial of service attacks. Even if an access token has an expiration time, since the access token can be reused, a hacker or malicious entity that steals the access token may maliciously use the access token to access SBI services and / or perform a denial of service attack (e.g., by sending a large number of service requests with high priority to one or more producer NFs) before the access token expires.

[0028] In general, a node or NF cannot detect when an access token (e.g., an OAuth 2.0 access token, a JSON web token (JWT), etc.) is stolen and used by a malicious entity because the required content (e.g., claims or attributes) in the access token does not indicate whether the access token using entity is different from the entity that owns the access token. For example, the attributes in the OAuth 2.0 access token (e.g., the claims defined by 3GPP) may or may not be present in the header or body attributes of the service request. Therefore, the receiving entity (e.g., a producer NF or an intermediate proxy NF) may not be able to use the attributes in the OAuth 2.0 access token for custom validation (e.g., to ensure that the access token is used by its legitimate owner). In addition, even when the attributes of the OAuth 2.0 access token are also in the header or body attributes of the service request, the malicious entity may also copy these attribute values ​​(along with the OAuth 2.0 access token) in its service request. Therefore, even so, the receiving entity cannot detect the use of the OAuth 2.0 access token by the malicious entity. To address these issues, access tokens may require ownership information that can be used to verify the owner of the access token (e.g., one or more attributes unique to a given consumer NF), and use authentication or verification techniques that are not easily defeated, such as by copying the appropriate information into the service request.

[0029] According to some aspects of the subject matter described herein, methods, systems, mechanisms, and / or techniques are provided for using transport layer security (TLS) data to determine whether an access token is sent by its owner (e.g., an entity requesting an access token from a token creator or an authorization server). For example, when sending or forwarding a service-based interface (SBI) message, a TLS connection can be established between consecutive or adjacent hops (e.g., a consumer NF and a first hop) by executing a TLS handshake protocol in which endpoints (e.g., NFs) exchange TLS certificates (e.g., X.509v3 certificates). In this example, each TLS certificate can utilize a subject alternative name (SAN) extension to indicate a uniform resource identifier (URI) or domain name system (DNS) name, an Internet Protocol (IP) address that identifies the subject of the TLS certificate, and the SAN data is difficult to spoof because it is verified by a certificate authority. In some embodiments, when a first hop NF (e.g., a module or node) according to various aspects described herein receives a service request including an access token from a consumer NF, the first hop NF may compare ownership information in the access token (e.g., values ​​of TLS parameters used to identify the owner of or associated with the access token) with actual values ​​of TLS parameters in a TLS certificate (previously received from the consumer NF during a TLS handshake). In such embodiments, if the ownership information matches the SAN identifier, then the first hop NF may determine that the consumer NF is the owner of the access token. However, in such embodiments, if the ownership information does not match the SAN identifier, then the first hop NF may determine that the consumer NF is not the owner of the access token (e.g., the access token is stolen or compromised) and may perform a mitigation action (e.g., denying the service request with an error response message).

[0030] According to some aspects of the subject matter described herein, methods, systems, mechanisms, and / or techniques for including ownership information in an access token (e.g., an OAuth 2.0 access token, a JWT, etc.) are provided. For example, a NF repository function (NRF) (e.g., a module or a node) according to various aspects described herein may be configured to receive ownership information identifying a consumer NF (e.g., an attribute or statement indicating a TLS parameter and a value of a TLS parameter identifying an owner of the access token or associated therewith) when the consumer NF requests an access token for accessing a service of a producer NF. In this example, the NRF may be configured to generate an access token including appropriate ownership attributes (e.g., a statement), for example, based on the received ownership information. In another example, the NRF may be configured to receive ownership information identifying a 5G core NF (e.g., a service communication proxy (SCP), a security edge protection proxy (SEPP), etc.) when the 5G core NF registers with the NRF. In this example, the NRF may be configured to generate a trust token (e.g., an OAuth 2.0 access token, a JWT, etc.) containing appropriate ownership attributes (e.g., a statement), for example, based on the received ownership information. Continuing with the example, the 5G Core NF may add the trust token as a header to the service request when providing the service request to the producer NF, where the trust token may indicate that ownership of the access token has been verified.

[0031] According to some aspects of the subject matter described herein, methods, systems, mechanisms, and / or techniques for detecting stolen access tokens are provided. For example, a NF and / or module according to various aspects described herein may be configured to: receive a service request including an access token from a sender via a TLS connection, wherein the access token includes ownership information indicating a TLS parameter for verifying the owner of the access token; determine whether the ownership information and the TLS information match using the ownership information (e.g., an IP address of the owner of the access token that identifies the access token or associated with the access token) and TLS information in a TLS certificate obtained from the sender (e.g., a SAN parameter IP address); and in response to determining that the ownership information and the TLS information do not match, reject the service request.

[0032] 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. Wherever possible, the same reference numerals will be used throughout the drawings to refer to the same or like parts.

[0033] Figure 1 is a block diagram illustrating an example 5G system network architecture (e.g., a home 5G core (5GC) network). Figure 1The architecture in includes a network function (NF) repository function (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 may maintain profiles of available producer NF service instances and the services they support, and allow consumer NFs or SCPs to subscribe to and be notified of registrations of new / updated producer NF service instances. The SCP 101 may also support selection and service discovery of producer NF instances. The SCP 101 may perform load balancing of connections between consumer and producer NFs. In addition, using the methods described herein, the SCP 101 may perform selection and routing based on preferred NF locations.

[0034] NRF 100 is a repository of service profiles or NFs of producer NF instances. In order to communicate with producer NF instances, consumer NFs or SCPs must obtain NFs or service profiles or producer NF instances from NRF 100. NFs or service profiles are JavaScript Object Notation (JSON) data structures defined in 3GPP TS29.510. NFs or service profile definitions include at least one of FQDN, IP version 4 (IPv4) address, or IP version 6 (IPv6) address. Figure 1 In the example shown, any node (except NRF 100) can be a consumer NF or a producer NF, depending on whether they are requesting a service or providing a service. In the example shown, the nodes include a policy control function (PCF) 102 that performs policy-related operations in the network, a unified data management (UDM) function 104 that manages user data, and an application function (AF) 106 that provides application services. Figure 1 The nodes shown in FIG. 1 also include a session management function (SMF) 108 that manages sessions between an access and mobility management function (AMF) 110 and the PCF 102. The AMF 110 performs mobility management operations similar to those performed by a mobility management entity (MME) in a 4G network. An authentication server function (AUSF) 112 performs authentication services for user devices (such as user equipment (UE) 114) seeking to access the network.

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

[0036] Radio access network (RAN) 120 connects UE 114 to the network via a wireless link. g-Node B (gNB) ( Figure 1 The UE 114 may use a wireless access point (not shown) or other wireless access point to access the radio access network 120. The user plane function (UPF) 122 may support various proxy functions for user plane services. An example of such a proxy function is a multipath transmission control protocol (MPTCP) proxy function. The UPF 122 may also support a performance measurement function that the UE 114 may use to obtain network performance measurements. Figure 1 Also illustrated in FIG. 1 is a data network (DN) 124 through which the UE accesses data network services, such as Internet services.

[0037] A security edge protection proxy (SEPP) 126 filters incoming traffic from another PLMN and performs topology hiding for traffic leaving the home PLMN. The SEPP 126 can communicate with a SEPP 126 in a foreign PLMN that manages the security of the foreign PLMN. Thus, traffic between NFs in different PLMNs may pass through two SEPP functions, one for the home PLMN and the other for the foreign PLMN.

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

[0039] As mentioned above, one of the issues with security in 5G and subsequent generations of networks is that 3GPP TS 33.501 recommends using the OAuth 2.0 framework for authorization, and the OAuth 2.0 access token issued by the NRF can be used multiple times before expiration. Since the access token can be used multiple times, it can be abused by hackers if it is stolen. 3GPP TS33.501 does not provide a technique for enforcing that the access token is used only by its owner, nor does it provide a technique for detecting stolen or leaked access tokens.

[0040] It will be recognized that Figure 1 is for illustrative purposes only, and the above Figure 1 The various nodes and / or modules, locations and / or functions described may be changed, altered, added or removed.

[0041] Figure 2 is a message flow diagram illustrating a scenario 200 involving obtaining an access token from the NRF 100. As depicted, the scenario 200 includes aspects of an example service access token authorization process, such as defined in Section 13.4 of 3GPP TS 33.501.

[0042] refer to Figure 2 In step 201, the consumer NF 199 (also referred to herein as NF service consumer) may send a token request message (e.g., Nnrf_AccessToken_Get request message) for requesting an access token (e.g., OAuth 2.0 access token) to the NRF 100 (e.g., acting as an OAuth 2.0 authorization server). The token request message may include the desired service name, producer NF type, consumer NF type, client ID, and / or other parameters.

[0043] In step 202, the NRF 100 may authorize the consumer NF 199 (eg, using a client ID and / or other parameters) and may generate an access token (eg, an OAuth 2.0 access token).

[0044] In step 203, the NRF 100 may send the access token to the consumer NF 199 in a token response message (e.g., Nnrf_AccessToken_Get response). The access token may include an expiration time and / or other attributes or claims. However, the access token may still be stolen and reused before the expiration time.

[0045] It will be recognized that Figure 2 It is for illustrative purposes, and different and / or additional actions may be performed. It will also be appreciated that various actions described herein may occur in a different order or sequence.

[0046] Figure 3 is a message flow diagram illustrating an example denial of service (DoS) attack scenario 300 involving access tokens. Figure 3 , a malicious entity 298 may perform or initiate a DoS or distributed DoS (DDoS) attack against a producer NF 299. For example, a malicious entity 298 may represent an entity that has stolen or otherwise obtained an access token without authorization (e.g., by exploiting a network security issue or application vulnerability) and / or attempted to use the access token to cause one or more issues (e.g., a DoS attack against the producer NF 299).

[0047] In some embodiments, the malicious entity 298 may represent, include, or utilize one or more NFs, nodes, or endpoints to interact with various NFs, such as the producer NF 299. For example, the malicious entity 298 may attempt to perform a DoS attack on the producer NF 299 by sending a large number of service requests (each service request having a high 3gpp-Sbi-Message-Priority value and a stolen access token) from multiple endpoints, and thereby may attempt to overload the producer NF 299, thereby causing a DoS or causing service issues for the various consumer NFs 199.

[0048] refer to Figure 3 In step 301, the malicious entity 298 can obtain the access token without authorization. For example, the malicious entity 298 can obtain the access token by exploiting network security issues or application vulnerabilities. Figure 2 The access token obtained by the consumer NF 199.

[0049] In step 302, the malicious entity 298 may send a large number of NF service requests (e.g., at a high rate) to the producer NF 299. For example, each NF service request may include an access token that was originally obtained by the consumer NF 199 from the NRF 100. In some embodiments, if the scope of the access token allows use at multiple or different producer NFs 299 (e.g., NF sets), the malicious entity 298 may send service requests to multiple or different producer NFs 299 in an attempt to overload these producer NFs 299 and cause service problems for various consumer NFs 199.

[0050] In some embodiments, for each service request, the producer NF 299 can receive the service request and verify (validate) or verify its associated access token. For example, the producer NF 299 can verify or verify the integrity and attributes (e.g., claims) of the access token, and if the verification or validation is successful, the requested service can be executed or provided.

[0051] In some embodiments, the producer NF 299 can verify the access token (e.g., an OAuth 2.0 access token) by verifying the signature of the access token using the public key of the NRF 100, by verifying that the audience claim of the access token matches its own identity, by verifying the scope and "additional scope" information of the access token, and by verifying that the access token has not expired (e.g., by checking the expiration time attribute of the access token) to ensure the integrity of the access token.

[0052] In step 303, the producer NF 299 may experience a failure or overload in response to an onslaught of high-priority service requests from the malicious entity 298. For example, if the producer NF 299 is configured to handle high-priority service requests first (e.g., regardless of the time of receipt), and if the malicious entity 298 sends a substantial number of such service requests, then the producer NF 299 may be unable to provide services to other consumer NFs 199, such that the malicious entity 298 effectively causes other consumer NFs 199 to be denied services from the producer NF 299.

[0053] therefore, Figure 3 It is illustrated that as long as the access token has a valid claim, a malicious entity 298 (e.g., a hacker) can use the stolen access token to access services provided by the producer NF 299 and / or cause various related problems. It should be noted that Figure 3 The access token in can be used with multiple different SBI request messages and is not specific to an SBI request message or message type.

[0054] Table 1 shown below illustrates the attributes (also referred to as claims) contained in an OAuth 2.0 access token. The complete claims data structure of an OAuth 2.0 access token is defined in Table 6.3.5.2.4-1 of 3GPP TS 29.510.

[0055]

[0056]

[0057] Table 1: OAuth 2.0 access token claims

[0058] As shown in Table 1, the OAuth 2.0 access token may include various statements that identify the issuing NRF, the producer NF, the expiration time, the consumer PLMN, the producer PLMN, the producer network slice identification information, and the producer NF set identification information. However, there is no statement in the defined format of the OAuth 2.0 access token that prevents hackers from stealing the access token and using the access token to obtain unauthorized access to services provided by the producer NF or otherwise abusing the access token. In addition, there is no statement in the defined format of the OAuth 2.0 access token that prevents hackers from stealing the access token and using the access token to obtain unauthorized access to services provided by the producer NF or otherwise abusing the access token.

[0059] The following are examples of access token claims that may be carried in an AMF 110 OAuth 2.0 access token in encoded text format:

[0060] {

[0061] "iss":"6faf1bbc-6e4a-4454-a507-a14ef8e1bc5c",

[0062] "sub":"6faf1bbc-6e4a-4454-a507-a14ef8e1dc5d",

[0063] "aud":[

[0064] "6faf1bbc-6e4a-4454-a507-b14ef8e1bc4c"

[0065] ],

[0066] "scope":"namf-mt",

[0067] "exp":1586169019

[0068] }

[0069] In the example shown above, the access token claims include the issuer NF instance ID, the consumer NF instance ID, the producer NF details, the scope of the token, and the expiration time. However, as indicated above, a hacker can copy the OAuth 2.0 access token claims and use the access token to access services provided by the producer NF 299 and / or launch a denial of service attack on the producer NF 299.

[0070] As mentioned above, 3GPP TS 33.501 recommends the use of OAuth 2.0 access tokens for authorization of SBI communications. A hacker with access to a stolen OAuth 2.0 access token can use the stolen access token to invoke SBI messages in the network. Therefore, there is a need to detect stolen or leaked access tokens, as detection can mitigate or even prevent the use of stolen or leaked access tokens.

[0071] It will be recognized that Figure 3 It is for illustrative purposes, and different and / or additional actions may be performed. It will also be appreciated that various actions described herein may occur in a different order or sequence.

[0072] Figure 4is a diagram illustrating an example NF 400 for detecting stolen access tokens. NF 400 may represent any suitable entity or entities (e.g., one or more nodes, devices, or computing platforms) for performing various aspects associated with generating, sending, or using an access token having ownership information (e.g., data or (one or more) attributes indicating information to be compared with TLS certificate data) for determining whether the sender is the owner of the access token and / or mitigating unauthorized use (e.g., by malicious entity 298).

[0073] In some embodiments, NF 400 may represent or include an authorization server, a data repository, a network gateway, a network proxy, an edge security device, or other functions. In some embodiments, NF 400 may represent or include one or more 5GC NFs. For example, NF 400 may represent or include NRF 100, SEPP 126, SCP 101, producer NF 299, AF 106, AMF 110, SMF 108, NEF 118, PCF 102, etc.

[0074] refer to Figure 4 , NF 400 may include one or more communication interfaces 402 for communicating messages via a communication environment (e.g., one or more 5G or 5GC networks). For example, the communication interface(s) 402 may include one or more communication interfaces for communicating with various entities in a home network (e.g., a home PLMN (H-PLMN)) or a visited network (e.g., a visited PLMN (V-PLMN)).

[0075] NF 400 may include TM 404. TM 404 may be any suitable entity (e.g., software executed on at least one processor) for performing one or more aspects associated with detecting stolen or leaked access tokens. In some embodiments, NF 400 and / or TM 404 may include functionality for determining whether an access token was sent by its owner (e.g., a NF requesting an access token from a token creator or an authorization server) using TLS certificate data and ownership information in the access token (e.g., custom or private declarations indicating TLS parameters and values ​​of TLS parameters used to identify or be associated with the owner of the access token).

[0076] In some embodiments, when sending or forwarding an SBI message, a TLS connection may be established between consecutive or adjacent hops (e.g., a consumer NF and a first hop) and involves executing a TLS handshake protocol. For example, the TLS handshake protocol defined in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 5246 may be used, including the exchange of certificate messages by both ends of the TLS connection. The structure of the TLS handshake message defined in IETF RFC 5246 (including the certificate message) is as follows:

[0077] enum{

[0078] hello_request(0),client_hello(1),server_hello(2),

[0079] certificate(11),server_key_exchange(12),

[0080] certificate_request(13),server_hello_done(14),

[0081] certificate_verify(15),client_key_exchange(16),

[0082] finished(20),(255)

[0083] }HandshakeType;

[0084] struct{

[0085] HandshakeType msg_type; / *handshake type* /

[0086] uint24 length; / * bytes in the message * /

[0087] select(HandshakeType){

[0088] case hello_request:HelloRequest;

[0089] case client_hello:ClientHello;

[0090] case server_hello:ServerHello;

[0091] case certificate:Certificate;

[0092] case server_key_exchange:ServerKeyExchange;

[0093] case certificate_request:CertificateRequest;

[0094] case server_hello_done:ServerHelloDone;

[0095] case certificate_verify:CertificateVerify;

[0096] case client_key_exchange:ClientKeyExchange;

[0097] case finished: Finished;

[0098] }body;

[0099] }Handshake;

[0100] As shown in the TLS handshake message structure above, one of the defined handshake message types is a certificate message, which contains the certificate of the client or server, depending on whether the sender is operating as a client or server. When establishing secure TLS communications over a 5G interface, mutual TLS is used, where both ends of the TLS connection receive and verify the X.509 certificate of the other end. IETF RFC5246 indicates that the type of certificate must be X.509v3 unless explicitly negotiated otherwise. At least some of the examples described herein may involve X.509v3 certificates, but the subject matter described herein is not limited to using data in an X.509v3 certificate when verifying ownership of an access token or a trust token.

[0101] The X.509v3 certificate format is defined in IETF RFC 3280. According to IETF RFC 3280, one of the extensions that can be included in an X.509v3 certificate is the SAN extension. The SAN extension is defined as follows:

[0102] The Subject Alternative Name extension allows additional identities to be bound to the subject of a certificate.

[0103] Options include Internet email address, DNS name, IP address, and unified

[0104] Resource Identifier (URI). Other options exist, including fully local definitions.

[0105] You can include multiple name forms, and multiple instances of each name form.

[0106] When you want to bind such an identity into a certificate, you must use the Subject Alternative Name

[0107] (or Issuer Alternative Name) extension; however, a DNS name may be in the subject domain.

[0108] Use in paragraphs such as Section 4.1.2.4 The domainComponent property described in

[0109] Since subject alternative names are considered to be unambiguously bound to public keys, the subject alternative name

[0110] All parts of the physical alternative name MUST be verified by the CA.

[0111] As indicated above, the SAN extension of an X.509v3 certificate may contain a DNS name, IP address, URI, or other information identifying the subject of the certificate, and the SAN data is verified by a certificate authority. Because the SAN data is verified by a certificate authority, the SAN data is difficult to forge. Therefore, by comparing the TLS certificate data (e.g., the SAN IP address parameter value) and the value of a TLS parameter in the access token that identifies the owner of the access token (e.g., stored as an ownership-related attribute or private statement) or is associated with the owner of the access token, NF 400 and / or TM 404 can determine whether the sender of the access token is also the owner. For example, if the value of a TLS parameter located in the private statement of the access token matches the value of a TLS parameter from a TLS certificate (e.g., previously received from consumer NF 199 during a TLS handshake), then NF 400 and / or TM 404 can determine that consumer NF 199 is the owner of the access token. However, if the values ​​do not match, then NF 400 and / or TM 404 may determine that consumer NF 199 is not the owner of the access token (eg, the access token was stolen or leaked) and may perform mitigation actions (eg, denying the service request using an error response message).

[0112] In some embodiments, NF 400 and / or TM 404 may include functionality for including ownership information in an access token and / or a trust token (e.g., an OAuth 2.0 access token, a JWT, etc.). For example, where NF 400 includes NRF 100 or related functionality, NF 400 may be configured to receive ownership information identifying consumer NF 199 (e.g., attributes indicating TLS parameters and values ​​of TLS parameters) when consumer NF 199 requests an access token from NF 400. In this example, NF 400 may be configured to generate an access token containing appropriate ownership attributes (e.g., claims) using the received ownership information.

[0113] In some embodiments, where the NF 400 includes the NRF 100 or related functions, the NF 400 may be configured to receive ownership information identifying the 5G Core NF (e.g., SCP 101, SEPP 126, etc.) when the 5G Core NF registers with the NF 400. For example, the NF 400 may be configured to generate a trust token (e.g., OAuth 2.0 access token, JWT, etc.) containing appropriate ownership attributes (e.g., claims) based on the ownership information received from the 5G Core NF during the registration process with the NF 100. In this example, after verifying the ownership of the access token from the consumer NF 199, the 5G Core NF may add the trust token as a header to the service request when providing or forwarding the service request to the producer NF 299, and the trust token may indicate to the next hop that the ownership of the access token has been verified.

[0114] In some embodiments, NF 400 and / or TM 404 may include functionality for determining whether an access token needs to or will contain ownership information. For example, a network operator may include standards or rules for enabling some NFs to utilize access tokens with ownership information. In this example, the standards or rules may be based on various factors, such as NF type, network or location, historical data (e.g., known security issues in the network or at the NF), and / or expected workload or traffic volume.

[0115] In some embodiments, NF 400 and / or TM 404 may include functionality for detecting stolen or leaked access tokens. For example, NF 400 and / or TM 404 may be configured to: receive a service request including an access token from a sender via a TLS connection, wherein the access token includes ownership information indicating an owner of the access token; use the ownership information of the access token (e.g., the value of a specific SAN parameter that identifies the owner of the access token or is associated with the owner of the access token) and the TLS information in the TLS certificate obtained from the sender (e.g., SAN parameter values, such as DNS names, IP addresses, email addresses, etc.) to determine whether the ownership information and the TLS information match; and in response to determining that the ownership information and the TLS information do not match, perform a mitigation action, such as denying the service request.

[0116] In some embodiments, NF 400 and / or TM 404 may include functionality for verifying the owner or subject of a trust token. For example, in the case where NF 400 is not the first hop from the sender of a service request that includes an access token, NF 400 and / or TM 404 may detect the trust token in the header of the service request, and may verify or attempt to verify that the trust token is from the immediately preceding hop. In this example, the trust token verification process may involve using ownership information of the trust token to identify the value of a TLS parameter associated with or identifying the owner of the trust token, and then obtaining the TLS parameter value from a TLS certificate (e.g., obtained from the immediately preceding hop during the TLS handshake protocol). If the two values ​​match (e.g., the values ​​are equal or identical), then NF 400 and / or TM 404 may determine that the immediately preceding hop is the true owner or subject of the trust token. However, if the two values ​​do not match (eg, the values ​​are different), then NF 400 or TM 404 therein may determine that the immediately preceding hop is not the true owner or subject of the trust token (eg, the trust token was stolen or leaked) and may perform mitigation actions such as denying the service request.

[0117] In some embodiments, the access token or trust token generated or used by NF 400 or TM 404 (or other entity) may include, for example, a JSON web token (JWT) as defined in Request for Comments (RFC) 7519. In such embodiments, each token may include or indicate a custom or private attribute (e.g., a "private claim name" or a vendor-specific claim) that may be used to indicate or provide ownership information. For example, when generating or issuing an access token, NF 400 acting as NRF 100 may add an "owner_tls_key" private claim (e.g., parameter or attribute) indicating a TLS certificate parameter to be checked (e.g., a SAN extended IP address parameter or san.ipAddress), and an "owner_tls_value" private claim indicating a value of a TLS certificate parameter identifying the owner of the access token (e.g., "233.156.42.62"). In another example, when generating or issuing an access token, the NF 400 acting as the NRF 100 may add an “owner_tls_key” private claim (e.g., parameter or attribute) indicating a TLS certificate parameter to be checked (e.g., a SAN extended DNS name parameter or san.dNSName), and an “owner_tls_value” private claim indicating a value of a TLS certificate parameter that identifies the owner of the access token (e.g., “SMF1.site1.com”).

[0118] NF 400 may access (e.g., read from and / or write to) a data store 406. Data store 406 may be any suitable entity for storing various data (e.g., a computer-readable medium or memory). In some embodiments, data store 406 may include ownership information for access tokens. For example, data store 406 may include data records or entries indicating associations between NF instance identifiers and various ownership information to be included in corresponding access tokens. In another example, data store 406 may include network operator settings or preferences regarding aspects associated with detecting stolen or leaked access tokens and / or related mitigation actions.

[0119] In some embodiments, data store 406 may include logic for performing various aspects of access token authorization and / or security procedures for detecting stolen access tokens. For example, data store 406 may include ownership verification logic for checking that ownership information in an access token matches TLS certificate data provided by the sender of the access token, and may also include trust token verification logic for checking that ownership information in a trust token matches TLS certificate data provided by the sender of the trust token.

[0120] It will be recognized that Figure 4 and related descriptions are for illustrative purposes, and NF 400 may include additional and / or different modules, components, or functionalities.

[0121] Figure 5 is a message flow diagram illustrating a scenario 500 involving a consumer NF 199 obtaining an access token with ownership information from an NRF 100. As shown in the figure, Figure 5 The NRF 100 is depicted including the TM 404. In some embodiments, the TM 404 may perform various aspects associated with generating and providing access tokens with ownership information (eg, information identifying the consumer NF 199 requesting the access token).

[0122] In some embodiments, the consumer NF 199 may include a TM 404 or related functionality for sending ownership information in the header of the token request when requesting an access token from the NRF 100. The consumer NF 199 and / or the TM 404 may also include functionality for using a trust token when generating and sending an SBI message (e.g., a service request). For example, the consumer NF 199 may send a service request with an access token that contains ownership information indicating a TLS parameter for verifying the owner of the access token. In this example, the ownership information may also include the value of the TLS parameter that identifies the consumer NF 199 as the owner of the access token. Continuing with this example, the first hop NF may use the ownership information in the access token and data from the TLS certificate associated with the consumer NF 199 to verify that the access token has not been stolen.

[0123] refer to Figure 5 In step 501, the consumer NF 199 may send a token request message (e.g., Nnrf_AccessToken_Get request message) for requesting an access token (e.g., OAuth2.0 access token) to the NRF 100 (e.g., acting as an OAuth 2.0 authorization server). The Nnrf_AccessToken_Get request message may include the desired service name, producer NF type, consumer NF type, client ID, and other parameters.

[0124] In some embodiments, the token request message may include ownership information indicating TLS parameters to be used when verifying that the access token has not been compromised, and a value or identifier to indicate the owner of the access token. For example, the consumer NF 199 may generate an Nnrf_AccessToken_Get request message with an ownership header that includes an "owner_tls_key" value (e.g., parameter or attribute) indicating a value of a TLS certificate parameter to be checked when verifying ownership of the access token (e.g., a SAN extended IP address parameter) to be compared with a value in the access token, and an owner_tls_value value indicating a value of a TLS certificate parameter that identifies the consumer NF 199 as the owner of the access token (e.g., "123.56.32.65"). In this example, by providing ownership information, the consumer NF 199 may indicate which TLS parameter to check when verifying ownership of the requested access token.

[0125] In step 502, the NRF 100 may authorize the consumer NF 199 (e.g., using a client ID and / or other parameters) and may generate an access token (e.g., an OAuth 2.0 access token) with ownership information or related attributes (e.g., an “owner_tls_key” private claim and / or an “owner_tls_value” private claim).

[0126] In some embodiments, the NRF 100 and / or a module therein (e.g., TM 404) may be configured to add ownership information to the access token using an ownership header received from the consumer NF 199. For example, the NRF 100 and / or a module therein (e.g., TM 404) may generate a private claim for the access token indicating the ownership information based on the explicit ownership information provided by the consumer NF 199 in the ownership header of the token request message.

[0127] In some embodiments, the NRF 100 and / or a module therein (e.g., TM 404) may be configured to add ownership information (e.g., "owner_tls_key" and "owner_tls_value" private claims) to the access token when the consumer NF 199 requests the access token (e.g., in the case where the consumer NF 199 does not explicitly provide the ownership information). For example, as part of the token request, "nfInstanceId" is a mandatory parameter that indicates the NF instance that identifies the consumer NF 199. In this example, if the network operator enables the access token to utilize the SAN extension to indicate the NF instance ID that identifies the consumer NF 199 in the registeredID or otherName parameters, then the NRF 100 can use the value in the mandatory "nfInstanceId" parameter as the ownership information in the access token (e.g., the "owner_tls_key" private claim of the access token can indicate "san.registeredID" or "san.otherName" (depending on the network operator setting or preference, e.g., based on NF type or location), and the "owner_tls_value" private claim of the access token can indicate the value of the "nfInstanceId" parameter provided by the consumer NF 199 in the access token request).

[0128] In step 503, the NRF 100 may send the access token with ownership information in a token response message (e.g., Nnrf_AccessToken_Get response) to the consumer NF 199. In some embodiments, the access token may include an "owner_tls_key" private claim, an "owner_tls_value" private claim, and / or other attributes or claims.

[0129] In some embodiments, when the consumer NF 199 wants to request a service from the producer NF 299, the consumer NF 199 may send a service request including an access token with ownership information to the producer NF 299. In such an embodiment, the first-hop NF (e.g., the NF that receives the service request directly from the consumer NF 199 via a TLS connection) may receive the service request including the access token with ownership information, and may verify that the access token has not been stolen, for example, by comparing at least some ownership information in the access token (e.g., an IP address or DNS name identifying the owner of the access token) with an actual TLS parameter value of a TLS certificate (e.g., received from the consumer NF 199 when the TLS connection was established between the consumer NF 199 and the first-hop NF).

[0130] In some embodiments, for example, when TLS data in a TLS certificate changes (e.g., data used in access token ownership verification changes), consumer NF 199 can reject existing access tokens and obtain a new set of access tokens with updated ownership information for subsequent service requests.

[0131] It will be recognized that Figure 5 It is for illustrative purposes only and different and / or additional actions may be performed. It will also be appreciated that the Figure 5 The various actions involved may occur in different orders or sequences.

[0132] Figure 6 1 is a message flow diagram illustrating a scenario 600 involving an intermediate NF 598 (e.g., SCP 101, SEPP 126, or proxy NF) providing ownership information when registering with NRF 100. As shown in the figure, Figure 6 The NRF 100 is depicted including the TM 404. In some embodiments, the TM 404 may perform various aspects associated with generating a trust token (e.g., an OAuth2.0 access token or a JWT) including ownership information (e.g., information for identifying the intermediate NF 598 as a next-hop NF) in response to a registration request and providing the trust token with the ownership information to the registering NF.

[0133] In some embodiments, the intermediate NF 598 may include a TM 404 or related functionality for sending ownership information in the header of a registration request, for example, when registering with the NRF 100. The intermediate NF 598 and / or the TM 404 may also include functionality for using a trust token when forwarding an SBI message onward. For example, the intermediate NF 598 may use a trust token to indicate to the next hop (e.g., a second intermediate NF or producer NF 299) that the access token in the relevant message has previously been verified to belong to the original sender, and thus, the next hop may verify the trust token. In this example, the next hop may be configured to verify the trust token instead of performing an access token ownership verification process.

[0134] refer to Figure 6 In step 601, the intermediate NF 598 may send a registration request message (e.g., an Nnrf_NFManagement_NFRegister request message) for registering with the NRF 100. The Nnrf_NFManagement_NFRegister request message may include an NF instance ID, connection or access information, and / or other parameters.

[0135] In some embodiments, the registration request message may include ownership information indicating TLS parameters to be used when verifying that the trust token has not been compromised, and a value or identifier indicating identification of the owner of the trust token. For example, the intermediate NF 598 may generate an Nnrf_NFManagement_NFRegister request message with an ownership header including an "owner_tls_key" value (e.g., parameter or attribute) indicating a TLS certificate parameter to be checked (e.g., a SAN extended DNS name parameter), and an owner_tls_value value indicating a value of the TLS certificate parameter identifying the intermediate NF 598 as the owner of the trust token (e.g., "SEPP1.site.com").

[0136] In step 602, the NRF 100 may authorize the registration request and register the intermediate NF 598 (e.g., using the NF instance ID, connection or access information, and / or other parameters), and may generate a trust token (e.g., an OAuth2.0 access token or a JWT) with ownership information or related attributes (e.g., an “owner_tls_key” private claim and / or an “owner_tls_value” private claim), and may include the trust token as a header of the registration response message.

[0137] In some embodiments, the NRF 100 and / or a module therein (e.g., TM 404) may be configured to add ownership information to the trust token using an ownership header received from the intermediate NF 598. For example, the NRF 100 and / or a module therein (e.g., TM 404) may generate a private declaration of the trust token indicating the ownership information based on the explicit ownership information provided by the intermediate NF 598 in the ownership header of the registration request message.

[0138] In some embodiments, the NRF 100 and / or a module therein (e.g., the TM 404) may be configured to add ownership information (e.g., "owner_tls_key" and "owner_tls_value" private claims) to the trust token when the intermediate NF 598 registers with the NRF 100 (e.g., in the case where the intermediate NF 598 does not explicitly provide ownership information). For example, as part of the registration request, "nfInstanceId" is a mandatory parameter that indicates the NF instance that identifies the intermediate NF 598. In this example, if the network operator enables the trust token to utilize the SAN extension to indicate the NF instance ID that identifies the intermediate NF 598 in the registeredID or otherName parameter, then the NRF 100 can use the value in the mandatory "nfInstanceId" parameter as the ownership information in the trust token (e.g., the "owner_tls_key" private claim of the trust token can indicate "san.registeredID" or "san.otherName" (depending on the network operator setting or preference, e.g., based on NF type or location), and the "owner_tls_value" private claim of the trust token can indicate the value of the "nfInstanceId" parameter provided by the intermediate NF 598 in the registration request).

[0139] In step 603, the NRF 100 may send a trust token with ownership information as a header of a registration response message to the intermediate NF 598. In some embodiments, the trust token may include an "owner_tls_key" private claim, an "owner_tls_value" private claim, and / or other attributes or claims.

[0140] In some embodiments, for example, after the intermediate NF 598 has verified that the access token of the service request has not been stolen, the intermediate NF 598 can add a trust token (as a header) to the service request before forwarding it onward. In such embodiments, the trust token can indicate to the next hop (e.g., the second intermediate NF 598 or the producer NF 299) that the access token in the relevant message has been previously verified to belong to the original sender (e.g., the NF that initiated the service request), and thus, the next hop can bypass the access token ownership verification process.

[0141] In some embodiments, for example, instead of verifying ownership of an access token associated with a service request, a next-hop NF (e.g., a NF immediately following the intermediate NF 598) may verify a trust token of the service request. For example, the next-hop NF may receive a service request with an access token and a trust token. In this example, the next-hop NF may verify the trust token, for example, by comparing at least some ownership information in the trust token (e.g., an IP address or DNS name identifying the owner of the access token) with an actual TLS parameter value of a TLS certificate (e.g., received from the intermediate NF 598 when a TLS connection is established between the intermediate NF 598 and the next-hop NF).

[0142] In some embodiments, for example, when TLS data in a TLS certificate changes (e.g., data used in access token ownership verification), the intermediate NF 598 may send updated ownership information (e.g., updated “owner_tls_key” value and / or “owner_tls_value” value) in an NRF heartbeat or NFUpdate message to obtain an updated trust token in a corresponding message.

[0143] It will be recognized that Figure 6 It is for illustrative purposes only and different and / or additional actions may be performed. It will also be appreciated that the Figure 6 The various actions involved may occur in different orders or sequences.

[0144] Figure 7 is a message flow diagram illustrating a scenario 700 involving a consumer NF 199 sending a service request to a producer NF 299 via intermediate NFs 598 and 698. As shown in the figure, Figure 7 Various NFs including TM 404 or related functionality are depicted. In some embodiments, TM 404 can use ownership information in the access token (or trust token) and TLS information from a TLS certificate associated with a sender of a message (e.g., a service request message) including the access token (or trust token) to perform various aspects associated with verifying ownership of the access token (or trust token). In some embodiments, TM 404 (e.g., at intermediate NF 598 or 698) can perform various aspects associated with adding or replacing the trust token in the header of the service request before forwarding or sending the service request including the access token to the next hop.

[0145] In some embodiments, scenario 700 may represent an indirect communication scenario (e.g., communication model C or D defined in 3GPP Technical Specification (TS) 23.501). In some embodiments, scenario 700 may represent an inter-PLMN routing scenario. For example, consumer NF 199 may represent an NF in a V-PLMN; intermediate NF 598 may represent a proxy NF (e.g., SEPP 126 and / or SCP 101) in the V-PLMN; intermediate NF 698 may represent a proxy NF (e.g., SEPP 126 and / or SCP 101) in an H-PLMN; and producer NF 299 may represent an NF in an H-PLMN. In this example, when consumer NF 199 sends a service request destined for producer NF 299, the first hop may be intermediate NF 598, the second hop may be intermediate NF 698, and the third hop, i.e., the last hop, may be producer NF 299.

[0146] refer to Figure 7 , before step 701, TLS connections may be established between consecutive hops, for example, a TLS connection between consumer NF 199 and intermediate NF 598, another TLS connection between intermediate NF 598 and intermediate NF 698, and another TLS connection between intermediate NF 698 and producer NF 299. For each TLS connection established, the corresponding NFs may exchange TLS certificates containing various information. For example, each exchanged TLS certificate may include one or more attributes (e.g., SAN extension parameter values) that can uniquely identify its corresponding NF. In this example, the SAN extension parameter may include or indicate an IP address, a DNS name, a registered ID (e.g., an NF instance identifier), or another name (e.g., an email address or another identifier). Continuing with the example, the TLS certificate data (e.g., DNS name) of consumer NF 199 (or a previous hop) and ownership information in an access token (or trust token) (e.g., a custom attribute indicating the DNS name of the token owner) may indicate whether a service request or its access token has been stolen or leaked.

[0147] In step 701 , the consumer NF 199 may send a service request including an access token with ownership information (eg, “owner_tls_key” value and / or “owner_tls_value” value) to the intermediate NF 598 via a TLS connection for delivery to the producer NF 299 .

[0148] In step 702, the intermediate NF 598 may receive a service request including an access token having ownership information, and may use the ownership information to verify the ownership of the access token; and, after verifying the ownership of the access token, the intermediate NF 598 may add a trust token "1" as a header to the service request to indicate that the intermediate NF 598 has verified the ownership of the access token, and may include identification information (e.g., ownership information) for identifying the intermediate NF 598 as the owner or subject of the trust token.

[0149] In some embodiments, the intermediate NF 598 or the TM 404 therein may perform an ownership verification process to verify the ownership of the access token. For example, the ownership verification process may involve using the ownership information of the access token to identify the value of the TLS parameter associated with the owner of the access token or identifying the owner of the access token, and then obtaining the TLS parameter value (indicated by the ownership information in the access token) from the TLS certificate (e.g., obtained from the consumer NF 199 during the TLS handshake protocol). If the two values ​​match (e.g., the values ​​are equal or identical), then the intermediate NF 598 or the TM 404 therein may determine that the consumer NF 199 is the real owner of the access token. However, if the two values ​​do not match (e.g., the values ​​are different), then the intermediate NF 598 or the TM 404 therein may determine that the consumer NF 199 is not the real owner of the access token (e.g., the access token is stolen or leaked), and may perform mitigation actions (e.g., sending an error response message back to the consumer NF 199).

[0150] In step 703, the intermediate NF 598 may send a service request including the access token and the trust token "1" to the intermediate NF 698 via a TLS connection.

[0151] In step 704, the intermediate NF 698 may receive a service request including an access token and a trust token “1”, and may verify the ownership (or subject) of the trust token using the ownership information in the trust token “1”; and, after verifying the ownership (or subject) of the trust token, the intermediate NF 698 may replace the trust token “1” with a trust token “2” including identification information (e.g., ownership information) for identifying the intermediate NF 698 as the owner or subject of the trust token.

[0152] In some embodiments, the intermediate NF 698 or the TM 404 therein can perform a trust token verification process to verify the owner or subject of the trust token. For example, the trust token verification process can involve using the ownership information of the trust token "1" to identify the value of the TLS parameter associated with the owner of the trust token or identifying the owner of the trust token, and then obtain the TLS parameter value (indicated by the ownership information in the trust token) from the TLS certificate (e.g., obtained from the intermediate NF 598 during the TLS handshake protocol). If the two values ​​match (e.g., the values ​​are equal or the same), then the intermediate NF 698 or the TM 404 therein can determine that the intermediate NF 598 is the true owner or subject of the trust token "1". However, if the two values ​​do not match (e.g., the values ​​are different), then the intermediate NF 698 or the TM 404 therein can determine that the intermediate NF 598 is not the true owner or subject of the trust token (e.g., the trust token is stolen or leaked), and can perform mitigation actions (e.g., sending an error response message back to the consumer NF199).

[0153] In step 705, the intermediate NF 698 may send a service request including the access token and the trust token "2" to the producer NF 299 via a TLS connection.

[0154] In step 706, the producer NF 299 may receive a service request including an access token and a trust token "2", and may use the ownership information in the trust token "2" to verify the ownership (or subject) of the trust token; and, after verifying the ownership (or subject) of the trust token, the producer NF 299 may perform additional verification or validation of the access token.

[0155] In some embodiments, the producer NF 299 or the TM 404 therein can perform a trust token verification process to verify the owner or subject of the trust token. For example, the trust token verification process can involve using the ownership information of the trust token "2" to identify the value of the TLS parameter associated with the owner of the trust token or identifying the owner of the trust token, and then obtain the TLS parameter value (indicated by the ownership information in the trust token) from the TLS certificate (e.g., obtained from the intermediate NF 698 during the TLS handshake protocol). If the two values ​​match (e.g., the values ​​are equal or the same), the producer NF 299 or the TM 404 therein can determine that the intermediate NF 698 is the true owner or subject of the trust token "2". However, if the two values ​​do not match (e.g., the values ​​are different), the producer NF 299 or the TM 404 therein can determine that the intermediate NF 698 is not the true owner or subject of the trust token "2" (e.g., the trust token is stolen or leaked), and can perform mitigation actions (e.g., sending an error response message back to the consumer NF 199).

[0156] In some embodiments, for example, instead of or in addition to verifying ownership of an access token or trust token, the producer NF 299 may verify the access token by ensuring the integrity of the access token (e.g., an OAuth2.0 access token), including verifying the signature of the access token using the public key of NRF100, by verifying that the audience claim of the access token matches its own identity, by verifying the scope and "additional scope" information of the access token, and by verifying that the access token has not expired (e.g., by checking the expiration time attribute of the access token).

[0157] In some embodiments, for example, where an "allow list" for the connection exists for the producer NF 299 and indicates that the immediately preceding hop (e.g., intermediate NF 698) is trusted, the producer NF 299 may skip or bypass the trust token verification process for verifying the owner or subject of the trust token associated with the service request. In such embodiments, the ownership verification process performed by the first hop in the sequence (e.g., intermediate NF 598) for verifying ownership of the access token in the service request may be sufficient to detect whether the access token has been stolen, and may be implemented without the need for additional ownership verification logic at the producer NF 299.

[0158] In some embodiments, after determining that the access token in the service request message is not stolen and / or the access token is valid, the producer NF 299 may allow or grant the service request message, for example by sending a service response message including the requested service or related information.

[0159] It will be recognized that Figure 7 It is for illustrative purposes only and different and / or additional actions may be performed. It will also be appreciated that the Figure 7 The various actions involved may occur in different orders or sequences.

[0160] Figure 8 8 is a message flow diagram illustrating a scenario 800 involving NF 400 detecting that an access token in a service request is owned by consumer NF 199. As shown in the figure, Figure 8 Each of the consumer NF 199 and the producer NF 299 is depicted as including a TM 404. In some embodiments, the TM 404 may use ownership information in the access token and TLS information from a TLS certificate associated with a sender of a message (e.g., a service request message) that includes the access token to perform various aspects associated with verifying ownership of the access token.

[0161] In some embodiments, the producer NF 299 may represent the next hop (e.g., first hop) from the consumer NF 199. For example, in a direct communication scenario (e.g., without (one or more) intermediate NFs 598), the producer NF 299 may receive a service request directly from the consumer NF 199.

[0162] refer to Figure 8 , prior to step 801, a TLS connection may be established between the consumer NF 199 and the producer NF 299, wherein the TLS connection is established by exchanging TLS certificates containing various information. For example, each exchanged TLS certificate may include one or more SAN extension parameter values ​​that can uniquely identify its corresponding NF. In this example, the SAN extension parameter may include or indicate an IP address, a DNS name, a registered ID (e.g., an NF instance identifier), or another name (e.g., another identifier).

[0163] In step 801, the consumer NF 199 may send a service request including an access token having ownership information (eg, an “owner_tls_key” value and / or an “owner_tls_value” value) to the producer NF 299.

[0164] In step 802, the producer NF 299 may receive a service request including an access token with ownership information, and may use the ownership information to verify or attempt to verify ownership of the access token (e.g., determine or detect that the consumer NF 199 is the owner of the access token and / or the access token has not been stolen). For example, the producer NF 299 or the TM 404 therein may perform an ownership verification process that involves using the ownership information of the access token to identify the value of a TLS parameter associated with or identifying the owner of the access token, and then obtain the TLS parameter value from a TLS certificate (e.g., obtained from the consumer NF 199 during the TLS handshake protocol). In this example, if the two values ​​match (e.g., the values ​​are equal or identical), then the producer NF 299 or the TM 404 therein may determine that the consumer NF 199 is the true owner of the access token. However, in this example, if the two values ​​do not match (e.g., the values ​​are different), then the producer NF 299 or the TM 404 therein may determine that the consumer NF 199 is not the true owner of the access token (e.g., the access token has been stolen or leaked).

[0165] In some embodiments, for example, instead of or in addition to verifying ownership of the access token (e.g., verifying that the access token has not been stolen), the producer NF 299 may validate the access token by ensuring the integrity of the access token (e.g., an OAuth 2.0 access token), including verifying the signature of the access token using the public key of the NRF 100, by verifying that the audience claim of the access token matches its own identity, by verifying the scope and "additional scope" information of the access token, and by verifying that the access token has not expired (e.g., by checking the expiration time attribute of the access token).

[0166] In step 803, after determining that the access token is not stolen and / or the access token is valid, the producer NF 299 may allow or grant the service request message by sending a service response message including the requested service or related information.

[0167] It will be recognized that Figure 8 It is for illustrative purposes only and different and / or additional actions may be performed. It will also be appreciated that the Figure 8 The various actions involved may occur in different orders or sequences.

[0168] Fig. 9 is a message flow diagram illustrating a scenario 900 involving NF 400 detecting that an access token in a service request is stolen. As shown in the figure, Fig. 9 NF 400 is depicted including TM 404. In some embodiments, TM 404 may use ownership information in the access token and information from a TLS certificate associated with a sender of a message (eg, a service request message) that includes the access token to perform various aspects associated with verifying ownership of the access token.

[0169] In some embodiments, NF 400 may represent the next hop (e.g., the first hop) from the malicious entity 298. For example, in a direct communication scenario (e.g., without intermediate NF(s) 598), NF 400 may be a producer NF 299 that is capable of providing the service(s) requested by the malicious entity 298, and may receive the service request directly from the malicious entity 298. In another example, in an indirect communication scenario (e.g., with intermediate NF(s) 598), NF 400 may be an intermediate NF 598 and may be the first hop in a series of hops for communication from the malicious entity 298 to the producer NF 299.

[0170] refer to Fig. 9, prior to step 901, a TLS connection may be established between the malicious entity 298 and the NF 400, wherein the TLS connection is established by exchanging TLS certificates containing various information. For example, each exchanged TLS certificate may include one or more SAN extension parameter values ​​that can uniquely identify its corresponding NF. In this example, the SAN extension parameter may include or indicate an IP address, a DNS name, a registration ID (e.g., an NF instance identifier), or another name (e.g., another identifier).

[0171] In step 901, the malicious entity 298 may steal (e.g., obtain without authorization) an access token having ownership information (e.g., an “owner_tls_key” value and / or an “owner_tls_value” value), and may send a service request including the access token to the NF 400. For example, the malicious entity 298 may obtain the access token by exploiting a network security issue or an application vulnerability. Figure 2 The access token requested by the consumer in NF 199.

[0172] In step 902, NF 400 may receive a service request including an access token with ownership information, and may use the ownership information to verify or attempt to verify ownership of the access token (e.g., determine or detect that the malicious entity 298 is the owner of the access token and / or the access token has not been stolen). For example, NF 400 or a TM 404 therein may perform an ownership verification process that involves using the ownership information of the access token to identify the value of a TLS parameter associated with or identifying the owner of the access token, and then obtaining the TLS parameter value from a TLS certificate (e.g., obtained from the consumer NF 199 during the TLS handshake protocol). In this example, if the two values ​​match (e.g., the values ​​are equal or identical), then NF 400 or a TM 404 therein may determine that the consumer NF 199 is the true owner of the access token. However, in this example, if the two values ​​do not match (e.g., the values ​​are different), then NF 400 or a TM 404 therein may determine that the malicious entity 298 is not the true owner of the access token (e.g., the access token has been stolen or leaked).

[0173] In some embodiments, for example, instead of or in addition to verifying ownership of an access token, NF 400 may validate an access token by ensuring the integrity of an access token (e.g., an OAuth 2.0 access token), including verifying the signature of the access token using the public key of NRF 100, by verifying that the audience claim of the access token matches its own identity, by verifying the scope and "additional scope" information of the access token, and by verifying that the access token has not expired (e.g., by checking an expiration time attribute of the access token).

[0174] In step 903, after determining that the access token is stolen, NF 400 may reject the service request message by sending a service response message indicating an error code or related errors (eg, request unauthorized, access token leaked, etc.).

[0175] It will be recognized that Fig. 9 It is for illustrative purposes only and different and / or additional actions may be performed. It will also be appreciated that the Fig. 9 The various actions involved may occur in different orders or sequences.

[0176] Fig.10 1 is a diagram depicting example ownership data 1000 that can be used to determine ownership attributes of an access token. Data 1000 may include information (e.g., TLS parameters or keys and values ​​of TLS parameters for identifying the owner of the access token) that can be used to determine or identify appropriate ownership information for various access tokens (e.g., trust tokens, JWTs, or OAuth 2.0 access tokens). In some embodiments, data 1000 or portions thereof may be pre-determined or provisioned by a network operator. In some embodiments, data 1000 or portions thereof may be received or generated during a registration process or an access token request process.

[0177] In some embodiments, the data 1000 may be utilized when the NRF 100 or an entity with similar functionality (e.g., NF 400) is configured to automatically add ownership attributes (e.g., "owner_tls_key" value and "owner_tls_value" value) to an access token (e.g., an OAuth 2.0 access token) when a consumer NF requests an access token. For example, the data 1000 may include or represent default ownership attributes (e.g., derived from NF registration information or provided by a network operator) for a specific NF, a type of NF, or a location of the NF. In this example, the default ownership attributes or related information at the NRF 100 or an entity with similar functionality may allow the consumer NF to forgo logic for requesting an access token with explicit ownership attributes, because the NRF 100 or an entity with similar functionality may automatically provide the relevant ownership attributes in the access token using the data 1000.

[0178] refer to Fig.10 , a table representing data 1000 may include columns and / or fields for NF instance identifiers, ownership or trust keys (e.g., “owner_tls_key” values), and ownership or trust values ​​(e.g., “owner_tls_value” values). Fig.10As depicted in , each row can be associated with an NF instance identifier and ownership information for identifying the owner of the corresponding access token (e.g., the access token requestor).

[0179] In some embodiments, the "NF Instance ID" field may store information for identifying a specific NF instance. Example data in the "NF Instance ID" field may include an alphanumeric value or other identifier. In some embodiments, each NF instance identifier may be globally unique within a public land mobile network (PLMN) in which the corresponding NF instance is registered. In some embodiments, the format of the NF instance identifier may be a Universally Unique Identifier (UUID) version 4, as described in IETF RFC 4122. For example, the NF instance identifier "SCP 1" may represent a 128-bit UUID, where 16 bytes (e.g., octets) of the UUID are represented as 32 hexadecimal digits, and the digits are displayed in five groups separated by hyphens in the form of 8-4-4-4-12, for a total of 36 characters (32 hexadecimal characters and 4 hyphens), for example, "2967a69a-f61b-4bc1-b9da-47c9c5d14b64". (For example, "san.dNSName", "san.ipAddress", "san.otherName", or "san.registeredID").

[0180] In some embodiments, the "Ownership / Trust Key" field may store information indicating TLS certificate parameters to be checked when verifying the owner of an access token or trust token. Example data in the "Ownership / Trust Key" field may include an identifier or other information for identifying a TLS certificate parameter or a related SAN extension parameter, such as an IP address, a DNS name, a registration ID (e.g., an NF instance identifier), or another name. For example, the "Ownership / Trust Key" field value "san.dNSName" may be included in a private statement of the corresponding access token. In this example, the value "san.dNSName" may indicate (e.g., to a verification entity such as NF 400) that a parameter value of a TLS certificate SAN extension parameter storing a DNS name associated with the sender of a service request should be checked, and this parameter value in the TLS certificate should be compared with the value in the "Ownership / Trust Value" private statement when determining whether the sender of a service request including an access token is the owner of the access token.

[0181] In some embodiments, the "Ownership / Trust Value" field may store information indicating the value of a corresponding TLS certificate parameter used to identify the owner of an access token or trust token. Example data in the "Ownership / Trust Value" field may include a value or other information that can be used to identify the owner of an access token. For example, the "Ownership / Trust Value" field value "SCP1.SITE.COM" may be included in a private statement of the corresponding access token. In this example, the value "SCP1.SITE.COM" may be compared to the actual DNS name located in the TLS certificate when determining whether the sender of the access token is the owner of the access token.

[0182] It will also be appreciated that data 1000 is for illustrative purposes and that similar Fig.10 The data depicted in the data different and / or additional data to determine or identify the appropriate ownership information for various access tokens. In addition, various data structures and / or computer-readable media can be used to store (e.g., in data storage device 406) or manage data 1000.

[0183] Fig.11 1 is a diagram illustrating an example process 1100 for detecting a stolen access token. In some embodiments, the example process 1100 described herein or a portion thereof (e.g., an operation or step) may be performed at or by NF 400, TM 404, and / or another module, NF, or node. In some embodiments, the process 1100 or a portion thereof may be performed at or by a first-hop NF from a sender of an SBI request message (e.g., a service request) including an access token. For example, in an indirect communication scenario (e.g., a model C or D scenario defined by 3GPP), the process 1100 or a portion thereof may be performed by an intermediate NF 598 that receives a service request message from a consumer NF 199. In another example, in a direct communication scenario (e.g., a model B scenario defined by 3GPP), the process 1100 or a portion thereof may be performed by a producer NF 299 that directly receives a service request message from a consumer NF 199.

[0184] Referring to process 1100, a service request including an access token may be received from a sender via a TLS connection in step 1102. In some embodiments, the access token may include ownership information (eg, as a private statement) indicating TLS parameters for verifying the owner of the access token.

[0185] In step 1104, the ownership information of the access token and the TLS information in the TLS certificate obtained from the sender may be used to determine whether the ownership information and the TLS information match.

[0186] In step 1106, in response to determining that the ownership information and the TLS information do not match, the service request may be denied.

[0187] In some embodiments, the process 1100 may occur at an intermediate NF (e.g., intermediate NF 598) between a sender of a service request (e.g., consumer NF 199 or malicious entity 298) and a producer NF 299 that can grant the service request. In such an embodiment, the intermediate NF may be configured to: in response to determining that the ownership information and the TLS information match, add a trust token (e.g., as a header) to the service request, wherein the trust token indicates identification information that identifies the NF, and forward the service request including the access token and the trust token to a second intermediate NF (e.g., intermediate NF 698) or the producer NF 299.

[0188] In some embodiments, the second intermediate NF (e.g., intermediate NF 698) can be configured to: receive a service request including a trust token and an access token associated with the first intermediate NF from the first intermediate NF (e.g., intermediate NF 698) via a TLS connection; determine whether the identification information and the second TLS information match using the identification information of the trust token and the second TLS information in the second TLS certificate obtained from the first intermediate NF; in response to determining that the identification information and the second TLS information do not match, reject the service request; in response to determining that the identification information and the second TLS information match, replace the trust token in the service request with a second trust token, wherein the second trust token indicates the second identification information that identifies the second intermediate NF; and send the service request including the access token and the second trust token forward to the producer NF 299.

[0189] In some embodiments, the producer NF 299 can be configured to: receive a service request including a second trust token and an access token associated with the second intermediate NF from the second intermediate NF via a third TLS connection; determine whether the second identification information and the third TLS information match using the second identification information of the second trust token and the third TLS information in the third TLS certificate obtained from the second intermediate NF; in response to determining that the second identification information and the third TLS information do not match, reject the service request; in response to determining that the second ownership information and the third TLS information match, verify the service request; determine that the service request is valid; and allow the service request.

[0190] In some embodiments, process 1100 may occur at a producer NF 299 that is capable of granting a service request from a consumer NF 199. In such embodiments, producer NF 299 may be configured to: verify the service request in response to determining that ownership information of the access token and TLS information associated with the sender match; determine that the service request is valid (e.g., using an access token validation process); and allow the service request.

[0191] In some embodiments, the access token may include an OAuth 2.0 access token, wherein ownership information for verifying ownership of the OAuth 2.0 access token is in one or more claims of the OAuth 2.0 access token.

[0192] In some embodiments, the TLS certificate used in verifying the owner of the access token may be obtained from the sender during the TLS handshake protocol used to establish a TLS connection between the sender and the next-hop NF (eg, NF 400 or intermediate NF 598).

[0193] In some embodiments, the ownership information in the access token may include a TLS parameter identifier (e.g., a SAN parameter identifier) ​​that identifies a TLS parameter in a TLS certificate used to verify the owner of the access token (e.g., "san.dNSName", "san.ipAddress", "san.otherName", or "san.registeredID"), and a value of the TLS parameter that identifies the owner of the access token (e.g., "amf1.site1.com", "234.45.23.44", "34435FE46754bf@site.com", or "amf-1323534523"). For example, the first hop NF may obtain an "owner_tls_key" value in a private statement of the access token. In this example, the "owner_tls_key" value may indicate a field name or TLS parameter of the TLS certificate from which the first hop NF should obtain the value. Continuing with this example, the first hop NF may compare the value obtained from the TLS certificate with the value of an "owner_tls_value" value in another private statement of the access token, and if the two values ​​do not match, the first hop NF may determine that the access token is stolen.

[0194] In some embodiments, the TLS parameters of the TLS certificate (e.g., checked or used in determining whether an access token is stolen) may include a SAN extension parameter, an IP address, a DNS name, a URI, a NF instance identifier, or an email address.

[0195] In some embodiments, the NRF 100 may be configured to: receive an access token request from a second NF (e.g., consumer NF 199) before the NF (e.g., NF 400) receives a service request, wherein the access token request may include information indicating ownership information; generate an access token including ownership information; and send the access token to the second NF. In such an embodiment, the second NF (e.g., the owner of the access token) may be the sender of the service request, or the second NF may be different from the sender of the service request.

[0196] In some embodiments, a NF (eg, NF 400 or intermediate NF 598 ) for performing process 1100 may include SCP 101 , SEPP 126 , proxy NF, intermediate NF, or producer NF 299 .

[0197] It will be appreciated that process 1100 is for illustrative purposes and that different and / or additional actions may be performed. It will also be appreciated that the various actions described herein in connection with process 1100 may occur in a different order or sequence.

[0198] It will be appreciated that while some aspects of the subject matter described herein are discussed with reference to 5G networks, various other networks may also utilize some aspects of the subject matter described herein. For example, any network that allows or utilizes access tokens with customizable attributes or claims may use the features, systems, mechanisms, and / or techniques described herein to indicate ownership information to mitigate the use of stolen or leaked access tokens.

[0199] It should be noted that NF 400, TM 404 and / or the functions described herein may constitute a dedicated computing device. In addition, NF 400, TM 404 and / or the functions described herein may improve the technical field of network communications. For example, NF 400 may include TM 404 and may be able to reject service requests (e.g., CRUD calls) associated with stolen or leaked access tokens, thereby allowing NF 400 (e.g., producer NF 299, SCP 101, SEPP 126, etc.) to mitigate various attacks or abuses involving stolen or leaked access tokens (e.g., stolen by malicious entity 298).

[0200] To the extent not inconsistent with this document, and to the extent it supplements, explains, teaches, or provides background for the methods, techniques, and / or systems employed herein, the disclosure of each of the following references is incorporated herein by reference in its entirety.

[0201] References:

[0202] 1.3GPP TS 33.501; 3rd Generation Partnership Project; TechnicalSpecification Group Services and System Aspects; Security architecture and procedures for 5G system; (Release 16); V16.8.0 (2021-09).

[0203] 2.3GPP TS29.510; 3rd Generation Partnership Project; TechnicalSpecification Group Core Network and Terminals; 5GSystem; Network FunctionRepository Services; Stage 3 (Release 16); V16.9.0 (2021-09).

[0204] 3. Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", IETF RFC7519, May 2015.

[0205] 4. Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", IETF RFC 5246, August 2008.

[0206] 5.Hardt et al., "The OAuth 2.0Authorization Framework", IETF RFC 6749, October 2012.

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

Claims

1. A method for detecting a stolen access token, the method comprising: At a network function (NF) comprising at least one processor: receiving a service request including an access token from a sender via a transport layer security (TLS) connection, wherein the access token includes ownership information indicating TLS parameters for verifying an owner of the access token; using the ownership information of the access token and the TLS information in the TLS certificate obtained from the sender to determine whether the ownership information and the TLS information match; and In response to determining that the ownership information and the TLS information do not match, the service request is denied.

2. The method of claim 1, comprising: At the NF, which is an intermediate NF between the sender and the producer NF that can grant the service request: In response to determining that the ownership information and the TLS information match, adding a trust token to the service request, wherein the trust token indicates identification information identifying the NF; as well as The service request including the access token and the trust token is sent onward to the second intermediate NF or the producer NF.

3. The method of claim 2, comprising: At the second intermediate NF: receiving a service request including an access token and a trust token from the NF via a second TLS connection; determining whether the identification information and the second TLS information match using the identification information of the trust token and the second TLS information in the second TLS certificate obtained from the NF; In response to determining that the identification information and the second TLS information do not match, denying the service request; In response to determining that the identification information and the second TLS information match, replacing the trust token in the service request with a second trust token, wherein the second trust token indicates second identification information that identifies the second intermediate NF; as well as The service request including the access token and the second trust token is sent onwards to the producer NF.

4. The method of claim 3, comprising: At the producer NF: receiving, from the second intermediate NF via a third TLS connection, a service request including an access token and a second trust token; determining whether the second identification information and the third TLS information match using the second identification information of the second trust token and the third TLS information in the third TLS certificate obtained from the second intermediate NF; In response to determining that the second identification information and the third TLS information do not match, denying the service request; In response to determining that the second identification information and the third TLS information match, authenticating the service request; Determine that the service request is valid; and Allow the service request.

5. The method of claim 1, comprising: At the NF, wherein the NF is a producer NF capable of granting a service request: In response to determining that the ownership information and the TLS information match, authenticating the service request; Determine that the service request is valid; and Allow the service request.

6. A method as claimed in any preceding claim, wherein the access token comprises an OAuth 2.0 access token and the ownership information is stored as one or more attributes of the OAuth 2.0 access token, and wherein the TLS certificate is obtained from the sender during a TLS handshake protocol for establishing a TLS connection between the sender and the NF.

7. The method of claim 6, wherein the ownership information is stored as one or more custom attributes or private claims of the access token.

8. A method as claimed in any preceding claim, comprising: At the NF Repository Function (NRF) and before the NF receives a service request: receiving an access token request from the second NF, wherein the access token request includes information indicating ownership information; Generate an access token including ownership information; as well as The access token is sent to the second NF, wherein the second NF is the sender of the service request or the second NF is different from the sender of the service request.

9. The method of any preceding claim, wherein the NF comprises a Service Communication Proxy (SCP), a Security Edge Protection Proxy (SEPP), a Proxy NF, an Intermediate NF, or a Producer NF.

10. A system for detecting a stolen access token, the system comprising: at least one processor; Memory; as well as A network function (NF) implemented using the at least one processor and the memory, the NF being configured to: receiving a service request including an access token from a sender via a transport layer security (TLS) connection, wherein the access token includes ownership information indicating TLS parameters for verifying an owner of the access token; using the ownership information of the access token and the TLS information in the TLS certificate obtained from the sender to determine whether the ownership information and the TLS information match; and In response to determining that the ownership information and the TLS information do not match, the service request is denied.

11. The system of claim 10, wherein the NF is an intermediate NF between a sender and a producer NF capable of granting a service request, the NF being configured to: In response to determining that the ownership information and the TLS information match, adding a trust token to the service request, wherein the trust token indicates identification information identifying the NF; and The service request including the access token and the trust token is sent onward to the second intermediate NF or the producer NF.

12. The system of claim 11, comprising: The second intermediate NF is configured to: receiving a service request including an access token and a trust token from the NF via a second TLS connection; determining whether the identification information and the second TLS information match using the identification information of the trust token and the second TLS information in the second TLS certificate obtained from the NF; In response to determining that the identification information and the second TLS information do not match, denying the service request; In response to determining that the identification information and the second TLS information match, replacing the trust token in the service request with a second trust token, wherein the second trust token indicates second identification information that identifies the second intermediate NF; as well as The service request including the access token and the second trust token is sent onwards to the producer NF.

13. The system of claim 12, comprising: The producer NF is configured to: receiving, from the second intermediate NF via a third TLS connection, a service request including an access token and a second trust token; determining whether the second identification information and the third TLS information match using the second identification information of the second trust token and the third TLS information in the third TLS certificate obtained from the second intermediate NF; In response to determining that the second identification information and the third TLS information do not match, denying the service request; In response to determining that the second identification information and the third TLS information match, authenticating the service request; Determine that the service request is valid; and Allow the service request.

14. The system of claim 10, wherein the NF is a producer NF capable of granting service requests and is configured to: In response to determining that the ownership information and the TLS information match, authenticating the service request; Determine that the service request is valid; and Allow the service request.

15. The system of claims 10-14, wherein the access token comprises an OAuth 2.0 access token and the ownership information is stored as one or more attributes of the OAuth 2.0 access token, and wherein the TLS certificate is obtained from the sender during a TLS handshake protocol used to establish a TLS connection between the sender and the NF.

16. The system of claim 15, wherein the ownership information is stored as one or more custom attributes or private claims of the access token.

17. The system of claim 16, wherein the TLS parameter includes or indicates a Subject Alternative Name extension parameter, an Internet Protocol (IP) address, a Domain Name System (DNS) name, a Uniform Resource Identifier (URI), a NF instance identifier, or an email address.

18. The system of claims 10-17, comprising: NF Repository Function (NRF), configured to: Before the NF receives a service request: receiving an access token request from the second NF, wherein the access token request includes information indicating ownership information; Generate an access token including ownership information; as well as The access token is sent to the second NF, wherein the second NF is the sender of the service request or the second NF is different from the sender of the service request.

19. The system of claims 10-18, wherein the NF comprises a service communication proxy (SCP), a security edge protection proxy (SEPP), a proxy NF, an intermediate NF, or a producer NF.

20. A non-transitory computer-readable medium having executable instructions stored thereon, the executable instructions, when executed by at least one processor of a network function (NF), causing the NF to perform the steps comprising: receiving a service request including an access token from a sender via a transport layer security (TLS) connection, wherein the access token includes ownership information indicating TLS parameters for verifying an owner of the access token; using the ownership information of the access token and the TLS information in the TLS certificate obtained from the sender to determine whether the ownership information and the TLS information match; and In response to determining that the ownership information and the TLS information do not match, the service request is denied.

Images