Method, system and computer-readable medium for detecting stolen access tokens

Abstract

[0009] Methods, systems, and computer-readable media for detecting a stolen access token are disclosed. One exemplary method for detecting a stolen access token includes receiving, at a network function (NF) including at least one processor, a service request from a sender over a Transport Layer Security (TLS) connection, the service request including the access token, the access token including ownership information indicating TLS parameters for verifying an owner of the access token, the method including using the ownership information of the access token and TLS information in a TLS certificate obtained from the sender to determine whether the ownership information and the TLS information match, and rejecting the service request in response to determining that the ownership information and the TLS information do not match.

Description

[Technical Field]

[0001] Priority claims This application claims priority to U.S. Patent Application No. 17 / 987,820, filed November 15, 2022, which is incorporated herein by reference in its entirety.

[0002] Technical Field 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 technology]

[0003] background In fifth-generation (5G) telecommunications networks, a network function that provides a service is called a producer Network Function (NF) or an NF service producer. A network function that consumes a service is called a consumer NF or an NF service consumer. A network function may be a producer NF, a consumer NF, or both, depending on whether the network function consumes, produces, or both consumes and produces a service. In this specification, the terms "producer NF" and "NF service producer" are used interchangeably. Similarly, in this specification, the terms "consumer NF" and "NF service consumer" are used interchangeably.

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

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

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

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

[0008] The current security procedure defined in 3GPP TS33.501 for accessing a Service-Based Architecture (SBA) interface is called Service Access Authorization. The message used to access an SBA interface is called a Service-Based Interface (SBI) message, and the service provided over this interface is called an SBI service. According to the service access authorization procedure, a consumer NF attempting to access an SBI service provided by a producer NF needs to obtain an OAuth 2.0 access token from the NRF. To obtain an OAuth 2.0 access token from the NRF, the consumer NF sends an access token request to the NRF. The NRF validates the request, generates an access token, and returns the access token to the consumer NF. When the consumer NF attempts to access a service, it 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 grants access to the requested service.

[0009] One problem with this architecture is that access tokens can be stolen by a hacker and used to obtain services from producer NFs without authorization and / or to carry out attacks. Even though access tokens have an expiration date, because access tokens are reusable, a hacker who steals an access token can use it to maliciously access SBI services before it expires and / or to carry out a denial-of-service attack (e.g., by sending a large number of high-priority service requests to one or more producer NFs). Summary of the Invention [Means for solving the problem]

[0010] overview

[0009] Methods, systems, and computer-readable media for detecting a stolen access token are disclosed. One exemplary method for detecting a stolen access token includes receiving, at a network function (NF) including at least one processor, a service request from a sender over a Transport Layer Security (TLS) connection, the service request including the access token, the access token including ownership information indicating TLS parameters for verifying an owner of the access token, the method including using the ownership information of the access token and TLS information in a TLS certificate obtained from the sender to determine whether the ownership information and the TLS information match, and rejecting the service request in response to determining that the ownership information and the TLS information do not match.

[0011] One exemplary 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 from a sender over a TLS connection, the service request including the access token, the access token including ownership information indicating TLS parameters for verifying an owner of the access token, the NF is configured to use the ownership information in the access token and TLS information in a TLS certificate obtained from the sender to determine whether the ownership information and the TLS information match, and to reject the service request in response to determining that the ownership information and the TLS information do not match.

[0012] One example non-transitory computer-readable medium includes computer-executable instructions embodied in the non-transitory computer-readable medium that, when executed by at least one processor of the NF, cause the NF to perform steps including receiving a service request from a sender over a TLS connection, the service request including an access token, the access token including ownership information indicating TLS parameters for verifying an owner of the access token, using the ownership information of the access token and TLS information in a TLS certificate obtained from the sender to determine whether the ownership information and the TLS information match, and rejecting the service request in response to determining that the ownership information and the TLS information do not match.

[0013] The subject matter described herein can be implemented in hardware, software, firmware, or any combination thereof. Thus, as used herein, the terms "function," "node," or "module" refer to hardware, which may also include software and / or firmware components, for implementing the described features. In an exemplary embodiment, the subject matter described herein can be implemented using a computer-readable medium having stored thereon computer-executable instructions that, when executed by a processor of a computer, control a computer to perform steps. Examples of computer-readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media such as disk memory devices, chip memory devices, programmable logic devices, and application-specific integrated circuits. Furthermore, computer-readable media embodying the subject matter described herein can be located on a single device or computer platform or distributed across multiple devices or computing platforms.

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

[0015] [Figure 1] FIG. 1 is a network diagram illustrating an example fifth-generation (5G) network architecture. [Figure 2] 1 is a message flow diagram illustrating a scenario involving obtaining an access token from a Network Function (NF) Repository Function (NRF). [Figure 3] 1 is a message flow diagram illustrating an example of a denial of service (DoS) attack scenario involving a stolen access token. [Figure 4] FIG. 1 is a block diagram illustrating an example NF for detecting stolen access tokens. [Figure 5]10 is a message flow diagram illustrating a scenario involving a consumer NF providing ownership information when requesting an access token from an NRF. [Figure 6] 10 is a message flow diagram illustrating a scenario involving an intermediate NF providing ownership information when registering with an NRF. [Figure 7] 1 is a message flow diagram illustrating a scenario involving a consumer NF sending a service request to a producer NF via an intermediate NF. [Figure 8] 10 is a message flow diagram illustrating a scenario involving an NF detecting that the access token in a service request is owned by the requesting entity. [Figure 9] 10 is a message flow diagram illustrating a scenario involving an NF detecting that an access token in a service request is stolen. [Figure 10] FIG. 10 illustrates example ownership data that can be used to determine ownership attributes of an access token. [Figure 11] 10 is a flowchart illustrating an example process for detecting a stolen access token. DETAILED DESCRIPTION OF THE INVENTION

[0016] Detailed Description The subject matter described herein relates to a method, system, and computer-readable medium for detecting stolen access tokens. As described above, one problem with the 5G Service-Based Interface (SBI) architecture is that access tokens can 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 though access tokens have expiration dates, because access tokens are reusable, a hacker or malicious entity that steals an access token can use the access token to maliciously access SBI services before the access token expires and / or to perform denial-of-service attacks (e.g., by sending a large number of high-priority service requests to one or more producer NFs).

[0017] In general, a node or NF cannot detect if 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, attributes (e.g., 3GPP-defined claims) in an OAuth 2.0 access token may or may not be present in the header or body attributes of a service request. Therefore, a receiving entity (e.g., a producer NF or an intermediate proxy NF) may not be able to use attributes in the OAuth 2.0 access token to perform custom validation (e.g., to ensure that the access token is being used by its legitimate owner). Furthermore, even if attributes in the OAuth 2.0 access token are also present in the header or body attributes of a service request, a malicious entity may also copy those attribute values ​​(along with the OAuth 2.0 access token) in the service request. Therefore, even in this case, the receiving entity will not be able to detect the use of the OAuth 2.0 access token by a malicious entity. To address these issues, access tokens may require ownership information (e.g., one or more attributes unique to a given consumer NF) that can be used to verify the owner of the access token and that uses validation or verification techniques that are not easily defeated, for example, by copying the appropriate information into a service request.

[0018] According to some aspects of the subject matter described herein, methods, systems, mechanisms, and / or techniques are provided that use Transport Layer Security (TLS) data to determine whether an access token was sent by its owner (e.g., a token creator or an entity that requested the access token from an authorization server). For example, when sending or forwarding a Service-Based Interface (SBI) message, a TLS connection can be established between successive or adjacent hops (e.g., a consumer NF and a first hop) by performing 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 use a Subject Alternative Name (SAN) extension to indicate a Domain Name System (DNS) name, Internet Protocol (IP) address, or Uniform Resource Identifier (URI) that identifies the subject of the TLS certificate; the SAN data is verified by a certificate authority and therefore difficult to spoof. In some embodiments, when a first-hop NF (e.g., a module or node) according to various aspects described herein receives a service request from a consumer NF that includes an access token, the first-hop NF may compare ownership information in the access token (e.g., values ​​of TLS parameters that identify or are associated with the owner of the access token) with the actual values ​​of the TLS parameters in the TLS certificate (previously received from the consumer NF during the TLS handshake). In such embodiments, if the ownership information matches the SAN identifier, 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, 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 take suppressive action (e.g., deny the service request with an error response message).

[0019] According to some aspects of the subject matter described herein, methods, systems, mechanisms, and / or techniques are provided for including ownership information in an access token (e.g., an OAuth 2.0 access token, a JWT, etc.). For example, an NF Repository Function (NRF) (e.g., a module or node) according to various aspects described herein can be configured to receive ownership information identifying a consumer NF (e.g., attributes or claims identifying an owner of the access token or indicating TLS parameters associated with the owner of the access token and values ​​of the TLS parameters) when the consumer NF requests an access token to access a service of a producer NF. In this example, the NRF can be configured to generate an access token including appropriate ownership attributes (e.g., claims) based on, for example, the received ownership information. In another example, the NRF can 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 can be configured to generate a trust token (e.g., an OAuth 2.0 access token, a JWT, etc.) including appropriate ownership attributes (e.g., claims) based on, for example, the received ownership information. Continuing with this example, when the 5G core NF issues a service request to the producer NF, it may add a trust token to the service request as a header, where the trust token may indicate that ownership of the access token has already been verified.

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

[0021] 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 numbers will be used throughout the drawings to refer to the same or like parts.

[0022] FIG. 1 is a block diagram illustrating an example 5G system network architecture, e.g., a Home 5G Core (5GC) network. The architecture of FIG. 1 includes 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 maintains profiles of available producer NF service instances and their supported services, allowing consumer NFs or SCPs to subscribe to new / updated producer NF service instances and be notified of registrations. The SCP 101 may also support service discovery and selection of producer NF instances. The SCP 101 may perform load balancing of connections between consumer NFs and producer NFs. Additionally, using the methods described herein, the SCP 101 may perform preferred NF location-based selection and routing.

[0023] The NRF 100 is a repository for NF profiles or service profiles of producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP needs to obtain the NF profile or service profile of the producer NF instance from the NRF 100. The NF profile or service profile is a JavaScript Object Notation (JSON) data structure defined in 3GPP TS 29.510. The NF profile or service profile definition includes at least one of an FQDN, an IP version 4 (IPv4) address, or an IP version 6 (IPv6) address. In FIG. 1, any of the nodes (other than the NRF 100) can be a consumer NF or a producer NF, depending on whether it requests or provides a service. In the illustrated embodiment, 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. 1 also includes a Session Management Function (SMF) 108 that manages sessions between an Access and Mobility Management Function (AMF) 110 and the PCF 102. The AMF 110 performs mobility management operations similar to those performed by a Mobility Management Entity (MME) in 4G networks. An Authentication Server Function (AUSF) 112 performs authentication services for user devices, such as User Equipment (UE) 114, that attempt to access the network.

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

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

[0026] A security edge protection proxy (SEPP) 126 filters incoming traffic from another PLMN and provides topology hiding for traffic egressing from the home PLMN. The SEPP 126 can communicate with a SEPP 126 in a foreign PLMN that manages security for the foreign PLMN. Thus, traffic between NFs in different PLMNs can traverse two SEPP functions, one for the home PLMN and one for the foreign PLMN.

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

[0028] As mentioned above, one security issue in 5G and next-generation networks is that 3GPP TS33.501 advocates the use of the OAuth 2.0 framework for authorization, and OAuth 2.0 access tokens issued by the NRF can be used multiple times before expiring. Because access tokens can be used multiple times, they can be misused by hackers if stolen. 3GPP TS33.501 does not provide a technique to enforce that access tokens are only used by their owners, nor does it provide a technique to detect stolen or compromised access tokens.

[0029] It will be appreciated that FIG. 1 is for illustrative purposes and that the various nodes and / or modules, locations and / or functions described above with respect to FIG. 1 may be changed, modified, added or deleted.

[0030] 2 is a message flow diagram illustrating a scenario 200 involving obtaining an access token from an NRF 100. As shown, scenario 200 includes aspects of an example service access token authorization process, for example, as defined in section 13.4 of 3GPP TS33.501.

[0031] 2, in step 201, a consumer NF 199 (also referred to herein as an NF service consumer) may send a token request message (e.g., an Nnrf_AccessToken_Get request message) to an NRF 100 (e.g., functioning as an OAuth 2.0 authorization server) to request an access token (e.g., an OAuth 2.0 access token). The token request message may include an expected service name, a producer NF type, a consumer NF type, a client ID, and / or other parameters.

[0032] In step 202, 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).

[0033] 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_GetResponse). The access token may include an expiration date and / or other attributes or claims. However, the access token may still be stolen and reused before it expires.

[0034] It will be appreciated that Figure 2 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 may be performed in a different order or sequence.

[0035] Figure 3 is a message flow diagram illustrating an example denial of service (DoS) attack scenario 300 involving an access token. As shown in Figure 3, a malicious entity 298 may perform or launch a DoS or distributed DoS (DDoS) attack against a producer NF 299. For example, the malicious entity 298 may correspond to an entity that steals or otherwise obtains an access token without authorization (e.g., by exploiting a network security issue or an application vulnerability) and / or attempts to use the access token to cause one or more problems, e.g., a DoS attack, against the producer NF 299.

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

[0037] 3, a malicious entity 298 may obtain an access token without authorization in step 301. For example, the malicious entity 298 may exploit a network security issue or an application vulnerability to obtain the access token obtained by the consumer NF 199 in FIG.

[0038] In step 302, the malicious entity 298 may send a large number of NF service requests (e.g., at a high rate) to a producer NF 299. For example, each NF service request may include an access token that was originally obtained from the NRF 100 by the consumer NF 199. In some embodiments, if the scope of the access token allows for use at multiple or different producer NFs 299 (e.g., a set of NFs), 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 create service problems for the various consumer NFs 199.

[0039] In some embodiments, for each service request, the producer NF299 receives the service request and can validate or verify the associated access token of the service request. For example, the producer NF299 can verify or validate the integrity and attributes (e.g., claims) of the access token, and if the verification or validation is successful, can perform or provide the requested service.

[0040] In some embodiments, the producer NF299 can validate an access token (e.g., an OAuth2.0 access token) by verifying the access token's signature using the NRF100's public key, by verifying that the access token's audience claim matches its own identification information, by verifying the access token's scope and "extra scope" information, and by ensuring the integrity of the access token by verifying that the access token has not expired (e.g., by checking the access token's expiration attribute).

[0041] In step 303, the producer NF299 may experience a failure or overload in response to a large number of high priority service requests from the malicious entity 298. For example, if the producer NF299 is configured to process high priority service requests first (e.g., regardless of the time of receipt), and if the malicious entity 298 sends an unusually large number of such service requests, the producer NF299 may be unable to provide service to other consumer NF199, thereby causing the malicious entity 298 to effectively cause the other consumer NF199 to be denied service from the producer NF299.

[0042] Thus, Figure 3 illustrates that a stolen access token can allow a malicious entity 298 (e.g., a hacker) to access services provided by producer NF 299 and / or cause various related problems, as long as the access token has valid claims. Note that the access token in Figure 3 can be used with multiple different SBI request messages and is not specific to any SBI request message or message type.

[0043] Table 1 below shows the attributes, also known as claims, that are included in an OAuth 2.0 access token. The complete claims data structure of an OAuth 2.0 access token is defined in 3GPP TS29.510, Table 6.3.5.2.4-1.

[0044] [Table 1]

[0045] As shown in Table 1, an OAuth 2.0 access token may include various claims that identify the issuing NRF, the producer NF, the expiration date, the consumer PLMN, the producer PLMN, the producer network slice identity, and the producer NF set identity. However, the predefined format for an OAuth 2.0 access token does not include claims that would prevent a hacker from stealing the access token and using it to gain unauthorized access to services offered by the producer NF, or otherwise misusing the access token. Also, the predefined format for an OAuth 2.0 access token does not include claims that would prevent a hacker from stealing the access token and using it to gain unauthorized access to services offered by the producer NF, or otherwise misusing the access token.

[0046] The following are examples of access token claims that can be conveyed in coded text format in an OAuth 2.0 access token for AMF 110: { "iss": "6faf1bbc-6e4a-4454-a507-a14ef8e1bc5c", "sub": "6faf1bbc-6e4a-4454-a507-a14ef8e1dc5d", "aud": [ "6faf1bbc-6e4a-4454-a507-b14ef8e1bc4c" ], "scope" : "namf-mt", "exp": 1586169019 } In the example shown above, the access token claim includes the issuer NF instance ID, consumer NF instance ID, producer NF details, token scope, and expiry date. However, as shown above, a hacker could copy the OAuth 2.0 access token claim and use the access token to access services provided by the producer NF 299 and / or to launch a denial of service attack against the producer NF 299.

[0047] As mentioned above, 3GPP TS33.501 advocates 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 a network. Therefore, there is a need to detect stolen or compromised access tokens, as detection can curtail or even prevent the use of stolen or compromised access tokens.

[0048] It will be appreciated that Figure 3 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 may be performed in a different order or sequence.

[0049] 4 illustrates an example NF 400 for detecting stolen access tokens. The NF 400 may represent any suitable entity or entities (e.g., one or more nodes, devices, or computing platforms) for performing various aspects related to the generation, transmission, or use of access tokens having ownership information (e.g., data or attributes indicative of information for comparison with TLS certificate data) to determine whether the sender is the owner of the access token and / or to mitigate unauthorized use (e.g., by malicious entity 298).

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

[0051] 4, the NF 400 may include one or more communication interfaces 402 for communicating messages over a communication environment, e.g., one or more 5G or 5GC networks. For example, the communication interface 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)).

[0052] The NF 400 may include a TM 404. The TM 404 may be any suitable entity (e.g., software executing on at least one processor) for implementing one or more aspects related to detecting stolen or compromised access tokens. In some embodiments, the NF 400 and / or TM 404 may include functionality for using TLS certificate data along with ownership information in the access token (e.g., custom or private claims and TLS parameter values ​​that identify the access token owner or indicate TLS parameters associated with the access token owner) to determine whether the access token was sent by its owner (e.g., the token creator or the NF that requested the access token from the authorization server).

[0053] In some embodiments, when transmitting or forwarding the SBI message, a TLS connection can be established between successive or adjacent hops (e.g., the consumer NF and the first hop), which may include performing a TLS handshake protocol. For example, the TLS handshake protocol defined in Internet Engineering Task Force (IETF) Request for Comments (RFC) 5246 may be used, which includes an exchange of certificate messages by both ends of the TLS connection. The structure of a TLS handshake message defined in IETF RFC5246, including the certificate message, is shown below: enum { hello_request(0), client_hello(1), server_hello(2), certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20), (255) } HandshakeType; struct { HandshakeType msg_type; / *Handshake type* / uint24 length; / *Number of bytes in the message* / select (HandshakeType) { case hello_request: HelloRequest; case client_hello: ClientHello; case server_hello: ServerHello; case certificate: Certificate; case server_key_exchange: ServerKeyExchange; case certificate_request: CertificateRequest; case server_hello_done: ServerHelloDone; case certificate_verify: CertificateVerify; case client_key_exchange: ClientKeyExchange; case finished: Finished; } body; } Handshake; As illustrated by the TLS handshake message structure above, one of the defined handshake message types is a Certificate message, which contains either a client or server certificate, depending on whether the sender is acting as a client or server. In establishing secure TLS communications over 5G interfaces, mutual TLS is used, in which each end of the TLS connection receives and verifies the other end's X.509 certificate. IETF RFC 5246 dictates that the certificate type must be X.509v3 unless explicitly negotiated otherwise. While at least some embodiments described herein reference X.509v3 certificates, the subject matter described herein is not limited to the use of data in X.509v3 certificates when verifying ownership of access or trust tokens.

[0054] The X.509v3 certificate format is defined in IETF RFC3280. According to IETF RFC3280, one extension that can be included in an X.509v3 certificate is the SAN extension, which is defined as follows:

[0055] The Subject Alternative Name extension allows additional identifying information to be bound to the subject of a certificate. Defined choices include Internet email addresses, DNS names, IP addresses, and uniform resource identifiers (URIs). Other choices exist, including entirely local definitions. Multiple name formats, and multiple instances of each name format, may be included. When binding such identifying information to a certificate, the Subject Alternative Name (or Issuer Alternative Name) extension MUST be used. However, as described in Section 4.1.2.4, DNS names MAY be represented using the domainComponent attribute in the Subject field. Because the Subject Alternative Name is considered unambiguously bound to the public key, all parts of the Subject Alternative Name MUST be verified by the CA.

[0056] As noted above, the SAN extension of an X.509v3 certificate can contain a DNS name, IP address, URI, or other information that identifies the certificate subject, and this SAN data is verified by a certification authority. Because the SAN data is verified by a certification authority, spoofing the SAN data is difficult. Therefore, by comparing the TLS certificate data (e.g., the SAN IP address parameter value) with the value of a TLS parameter that identifies or is associated with the owner of the access token in the access token (e.g., stored as an ownership-related attribute or private claim), the 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 in the private claim of the access token matches the value of a TLS parameter in a TLS certificate (e.g., previously received from the consumer NF 199 during the TLS handshake), the NF 400 and / or TM 404 can determine that the consumer NF 199 is the owner of the access token. However, if these values ​​do not match, the NF400 and / or TM404 may determine that the consumer NF199 is not the owner of the access token (e.g., the access token is stolen or compromised) and may take suppressive action (e.g., deny the service request with an error response message).

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

[0058] In some embodiments in which the NF 400 includes an NRF 100 or related functionality, the NF 400 can be configured to receive ownership information identifying a 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 can be configured to generate a trust token (e.g., an OAuth 2.0 access token, JWT, etc.) that includes appropriate ownership attributes (e.g., claims) based on the ownership information received from the 5G core NF during the registration procedure with the NF 100. In this example, after verifying ownership of the access token from the consumer NF 199, the 5G core NF can 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 can indicate to the next hop that ownership of the access token has already been verified.

[0059] In some embodiments, the NF 400 and / or the TM 404 may include functionality to determine whether an access token requires or will include proprietary information. For example, a network operator may include criteria or rules that require some NFs to use access tokens with proprietary information. In this example, the criteria 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 NF), and / or expected workload or traffic volume.

[0060] In some embodiments, the NF 400 and / or TM 404 may include functionality for detecting stolen or compromised access tokens. For example, the NF 400 and / or TM 404 may be configured to receive a service request from a sender over a TLS connection, the service request including an access token, the access token including ownership information indicating an owner of the access token, the NF 400 and / or TM 404 may be configured to use the ownership information of the access token (e.g., a particular SAN parameter value that identifies or is associated with the owner of the access token) and TLS information in a TLS certificate obtained from the sender (e.g., a SAN parameter value such as a DNS name, IP address, email address, etc.) to determine whether the ownership information and the TLS information match, and to take suppressive action, such as denying the service request, in response to determining that the ownership information and the TLS information do not match.

[0061] In some embodiments, the NF 400 and / or the TM 404 may include functionality for verifying the owner or subject of a trust token. For example, if the NF 400 is not the first hop from the sender of a service request that includes an access token, the NF 400 and / or the 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 previous hop. In this example, the trust token verification procedure may include using the trust token owner information to identify values ​​of TLS parameters associated with or identifying the trust token owner, and then obtaining the TLS parameter values ​​from a TLS certificate (e.g., obtained from the previous hop during the TLS handshake protocol). If the two values ​​match (e.g., the values ​​are equal or the same), the NF 400 and / or the TM 404 may determine that the previous hop is the true owner or subject of the trust token. However, if the two values ​​do not match (e.g., the values ​​are different), the NF 400 or TM 404 can determine that the previous hop is not the true owner or subject of the trust token (e.g., the trust token is stolen or compromised) and can take suppressive action, such as denying the service request.

[0062] In some embodiments, access or trust tokens generated or used by the NF 400 or TM 404 (or other entities) may include JSON Web Tokens (JWTs), for example, as defined in Request for Comments (RFC) 7519. In such embodiments, each token may include or indicate custom or private attributes (e.g., “private claim names” or vendor-specific claims) that can be used to indicate or provide ownership information. For 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 the TLS certificate parameter to inspect (e.g., a SAN-extended IP address parameter or san.ipAddress) and an “owner_tls_value” private claim indicating the value of the TLS certificate parameter identifying the owner of the access token (e.g., “233.156.42.62”). In another embodiment, when generating or issuing an access token, the NF400 acting as the NRF100 may add an "owner_tls_key" private claim (e.g., a parameter or attribute) indicating the TLS certificate parameter to inspect (e.g., a SAN-extended DNS name parameter or san.dNSName) and an "owner_tls_value" private claim indicating the value of the TLS certificate parameter identifying the owner of the access token (e.g., "SMF1.site1.com").

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

[0064] In some embodiments, data storage 406 may include logic for implementing various aspects of security procedures for access token authorization and / or detecting stolen access tokens. For example, data storage 406 may include ownership verification logic for verifying 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 verifying that ownership information in a credit token matches TLS certificate data provided by the sender of the credit token.

[0065] It will be appreciated that FIG. 4 and the associated description are for illustrative purposes and that NF 400 may include additional and / or different modules, components, or functionality.

[0066] 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, Figure 5 illustrates an NRF 100 that includes a TM 404. In some embodiments, the TM 404 can perform various aspects related to generating and providing an access token with ownership information (e.g., information to identify the consumer NF 199 that requested the access token).

[0067] In some embodiments, the consumer NF 199 may include a TM 404 or associated functionality for sending ownership information in a header of a 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 the trust token when generating and transmitting an SBI message (e.g., a service request). For example, the consumer NF 199 may send a service request with an access token that includes ownership information to indicate TLS parameters to use to verify the owner of the access token. In this example, the ownership information may also include values ​​of TLS parameters that identify 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 a TLS certificate associated with the consumer NF 199 to verify that the access token is not stolen.

[0068] 5, in step 501, the consumer NF 199 may send a token request message (e.g., an Nnrf_AccessToken_Get request message) requesting an access token (e.g., an OAuth2.0 access token) to the NRF 100 (e.g., functioning as an OAuth2.0 authorization server). The Nnrf_AccessToken_Get request message may include an expected service name, a producer NF type, a consumer NF type, a client ID, and other parameters.

[0069] In some embodiments, the token request message may include ownership information to indicate TLS parameters to use when verifying that the access token is not stolen and to indicate a value or identifier that identifies the owner of the access token. For example, the consumer NF 199 may generate an Nnrf_AccessToken_Get request message having an ownership header that includes an “owner_tls_key” value (e.g., a parameter or attribute) that indicates a TLS certificate parameter (e.g., a SAN-extended IP address parameter) to check for a value to compare with the value in the access token when verifying ownership of the access token, and an owner_tls_value value that indicates the value of the 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 the ownership information, the consumer NF 199 may indicate which TLS parameters to check when verifying ownership of the requested access token.

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

[0071] In some embodiments, the NRF 100 and / or a module therein (e.g., TM 404) can 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) can generate a private claim in 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.

[0072] In some embodiments, the NRF 100 and / or a module therein (e.g., TM 404) can be configured to append ownership information (e.g., "owner_tls_key" and "owner_tls_value" private claims) to an access token when the access token is requested by the consumer NF 199 (e.g., without the consumer NF 199 explicitly providing the ownership information). For example, as part of the token request, "nfInstanceId" is a required parameter indicating the NF instance identifying the consumer NF 199. In this example, if the network operator allows the access token to use a SAN extension to indicate the NF instance ID that identifies the consumer NF 199 in the registeredID or otherName parameter, the NRF 100 can use the value in the required “nfInstanceId” parameter as ownership information in the access token (e.g., the “owner_tls_key” private claim of the access token may indicate “san.registeredID” or “san.otherName” (depending on a network operator configured or preferred value, e.g., based on NF type or location), and the “owner_tls_value” private claim of the access token may indicate the value of the “nfInstanceId” parameter provided by the consumer NF 199 in the access token request).

[0073] In step 503, the NRF 100 may send the access token with the ownership information to the consumer NF 199 in a token response message (e.g., Nnrf_AccessToken_Get Response). 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.

[0074] In some embodiments, when a consumer NF 199 wants to request a service from a producer NF 299, the consumer NF 199 can send a service request including an access token with ownership information to the producer NF 299. In such an embodiment, a first-hop NF (e.g., an NF that receives a service request directly from the consumer NF 199 via a TLS connection) can receive the service request including the access token with ownership information and can verify that the access token is not stolen, for example, by comparing at least some of the ownership information in the access token (e.g., an IP address or DNS name that identifies the owner of the access token) with actual TLS parameter values ​​in the 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).

[0075] In some embodiments, if the TLS data, for example in the TLS certificate, changes (e.g., data used in access token ownership validation changes), the consumer NF199 can reject the existing access token and obtain a new set of access tokens with updated ownership information for subsequent service requests.

[0076] It will be appreciated that Figure 5 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 Figure 5 may be performed in a different order or sequence.

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

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

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

[0080] In some embodiments, the registration request message may include ownership information to indicate TLS parameters to use in verifying that the trust token is not stolen and to indicate a value or identifier that identifies the owner of the trust token. For example, the intermediate NF 598 may generate an Nnrf_NFManagement_NFRegister request message with an ownership header that includes an "owner_tls_key" value (e.g., a parameter or attribute) that indicates the TLS certificate parameter to check (e.g., a SAN-extended DNS name parameter) and an owner_tls_value value that indicates the value of the TLS certificate parameter (e.g., "SEPP1.site.com") that identifies the intermediate NF 598 as the owner of the trust token.

[0081] 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), may generate a trust token (e.g., an OAuth2.0 access token or JWT) with ownership information or associated 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 in the registration response message.

[0082] In some embodiments, the NRF 100 and / or a module therein (e.g., TM 404) can 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) can generate a private claim in 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.

[0083] 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., without the intermediate NF 598 explicitly providing the ownership information). For example, as part of the registration request, "nfInstanceId" is a required parameter indicating the NF instance that identifies the intermediate NF 598. In this embodiment, if the network operator allows the trust token to use SAN extensions to indicate the NF instance ID that identifies the intermediate NF598 in the registeredID or otherName parameter, the NRF100 can use the value in the mandatory "nfInstanceId" parameter as ownership information in the trust token (e.g., the "owner_tls_key" private claim of the trust token may indicate "san.registeredID" or "san.otherName" (depending on a network operator configured or preferred value based on, e.g., NF type or location), and the "owner_tls_value" private claim of the trust token may indicate the value of the "nfInstanceId" parameter provided by the intermediate NF598 in the registration request).

[0084] In step 603, the NRF 100 may send the trust token with the 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.

[0085] In some embodiments, for example, after the intermediate NF 598 verifies that the access token in the service request is not stolen, the intermediate NF 598 may add a trust token to the service request (e.g., as a header) before forwarding the service request onward. In such embodiments, the trust token may indicate to the next hop (e.g., a second intermediate NF or the producer NF 299) that the access token in the associated message has been pre-verified as belonging to the original sender (e.g., the NF that originated the service request), and thus the next hop may avoid the access token ownership verification procedure.

[0086] In some embodiments, for example, instead of verifying the owner of an access token associated with a service request, the next-hop NF (e.g., the NF immediately after the intermediate NF 598) may verify the trust token in the service request. For example, the next-hop NF may receive a service request having an access token and a trust token. In this example, the next-hop NF may verify the trust token by, for example, 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 the actual TLS parameter values ​​of the TLS certificate (e.g., received from the intermediate NF 598 when a TLS connection was established between the intermediate NF 598 and the next-hop NF).

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

[0088] It will be appreciated that Figure 6 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 Figure 6 may be performed in a different order or sequence.

[0089] 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, Figure 7 illustrates various NFs including a TM 404 or related functionality. In some embodiments, the TM 404 may perform various aspects related to verifying ownership of the access token (or trust token) using ownership information in the access token (or trust token) and TLS information from a TLS certificate associated with the sender of a message (e.g., a service request message) that includes the access token (or trust token). In some embodiments, the TM 404 (e.g., intermediate NF 598 or 698) may perform various aspects related to appending or replacing the trust token in the header of a service request that includes the access token before forwarding or sending the service request to the next hop.

[0090] In some embodiments, scenario 700 may correspond to 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 correspond to an inter-PLMN routing scenario. For example, consumer NF 199 may correspond to an NF in a V-PLMN, intermediate NF 598 may correspond to a proxy NF (e.g., SEPP 126 and / or SCP 101) in the V-PLMN, intermediate NF 698 may correspond to a proxy NF (e.g., SEPP 126 and / or SCP 101) in an H-PLMN, and producer NF 299 may correspond to an NF in the H-PLMN. In this example, when consumer NF 199 sends a service request addressed to producer NF 299, the first hop may be intermediate NF 598, the second hop may be intermediate NF 698, and the third and final hop may be producer NF 299.

[0091] 7, before step 701, TLS connections between successive hops may be established, for example, a TLS connection between the consumer NF 199 and the intermediate NF 598, another TLS connection between the intermediate NF 598 and the intermediate NF 698, and another TLS connection between the intermediate NF 698 and the producer NF 299. For each TLS connection established, the respective NFs may exchange TLS certificates containing various information. For example, each exchanged TLS certificate may include one or more attributes (e.g., a SAN extension parameter value) that can uniquely identify the respective 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., an email address or another identifier). Continuing with this example, the TLS certificate data (e.g., a DNS name) of the consumer NF 199 (or the previous hop) and ownership information (e.g., a custom attribute indicating the DNS name of the token owner) in the access token (or trust token) may indicate whether the service request or its access token has been stolen or compromised.

[0092] In step 701, the consumer NF199 may send a service request including an access token with ownership information (e.g., an “owner_tls_key” value and / or an “owner_tls_value” value) over a TLS connection to the intermediate NF598 for delivery to the producer NF299.

[0093] In step 702, the intermediate NF 598 may receive a service request including an access token with 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) to identify the intermediate NF 598 as the owner or subject of the trust token.

[0094] In some embodiments, the intermediate NF 598 or the TM 404 therein can perform an ownership verification procedure to verify the ownership of the access token. For example, the ownership verification procedure may include using the access token's owner information 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 (indicated by the ownership information in the access token) from a 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 the same), the intermediate NF 598 or the TM 404 therein can determine that the consumer NF 199 is the true owner of the access token. However, if the two values ​​do not match (e.g., the values ​​are different), the intermediate NF 598 or the TM 404 therein can determine that the consumer NF 199 is not the true owner of the access token (e.g., the access token has been stolen or compromised) and can take suppressive action (e.g., return an error response message to the consumer NF 199).

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

[0096] In step 704, the intermediate NF698 may receive a service request including the access token and the trust token "1", may use ownership information in the trust token "1" to verify the ownership (or subject) of the trust token, and after verifying the ownership (or subject) of the trust token, the intermediate NF698 may replace the trust token "1" with a trust token "2" that includes identification information (e.g., ownership information) to identify the intermediate NF698 as the owner or subject of the trust token.

[0097] In some embodiments, the intermediate NF 698 or the TM 404 therein may perform a trust token verification procedure to verify the owner or subject of the trust token. For example, the trust token verification procedure may include using the ownership information of the trust token “1” 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 (indicated by the ownership information in the trust token) from a 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), the intermediate NF 698 or the TM 404 therein may 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), the intermediate NF 698 or the TM 404 therein may determine that the intermediate NF 598 is not the true owner or subject of the trust token (e.g., the trust token has been stolen or compromised) and may take suppressive action (e.g., return an error response message to the consumer NF 199).

[0098] 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.

[0099] In step 706, the producer NF299 may receive a service request including the access token and the 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 NF299 may perform additional verification or validation of the access token.

[0100] In some embodiments, the producer NF299 or the TM404 therein may perform a trust token verification procedure to verify the owner or subject of the trust token. For example, the trust token verification procedure may include using ownership information of the trust token "2" to identify values ​​of TLS parameters associated with or identifying the owner of the trust token, and then obtaining the TLS parameter values ​​(indicated by the ownership information in the trust token) from a TLS certificate (e.g., obtained from the intermediate NF698 during the TLS handshake protocol). If the two values ​​match (e.g., the values ​​are equal or the same), the producer NF299 or the TM404 therein may determine that the intermediate NF698 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 NF299 or the TM404 therein can determine that the intermediate NF698 is not the true owner or subject of trust token "2" (e.g., the trust token is stolen or compromised) and can take suppressive action (e.g., return an error response message to the consumer NF199).

[0101] In some embodiments, for example, instead of or in addition to verifying ownership of the access token or trust token, the producer NF299 can validate the access token (e.g., OAuth2.0 access token) by ensuring the integrity of the access token including verifying the signature of the access token using the NRF100's public key, by verifying that the audience claim of the access token matches its own identity, by verifying the scope and "extra scope" information of the access token, and by verifying that the access token has not expired (e.g., by checking the expiry attribute of the access token).

[0102] For example, in some embodiments where there is an "allowed list" of connections for the producer NF299 indicating that the previous hop (e.g., intermediate NF 698) is trusted, the producer NF299 may skip or avoid the trust token verification procedure that verifies the owner or subject of the trust token associated with the service request. In such embodiments, the ownership verification procedure performed by the first hop in the sequence (e.g., intermediate NF 598) to verify the owner of the access token in the service request may be sufficient to detect whether the access token is stolen, and can be implemented without requiring additional ownership verification logic in the producer NF299.

[0103] 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 NF299 may authorize or grant the service request message, for example, by sending a service response message containing the requested service or related information.

[0104] It will be appreciated that Figure 7 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 Figure 7 may be performed in a different order or sequence.

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

[0106] In some embodiments, the producer NF 299 represents the next hop (e.g., first hop) from the consumer NF 199. For example, in a direct communication scenario (e.g., no intermediate NF 598), the producer NF 299 may receive a service request directly from the consumer NF 199.

[0107] 8, prior to step 801, a TLS connection may be established between the consumer NF 199 and the producer NF 299, where 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 the respective NF. In this example, the SAN extension parameters may include or indicate an IP address, a DNS name, a registration ID (e.g., an NF instance identifier), or other name (e.g., another identifier).

[0108] In step 801, the consumer NF199 may send a service request including an access token with ownership information (eg, an "owner_tls_key" value and / or an "owner_tls_value" value) to the producer NF299.

[0109] In step 802, the producer NF299 may receive a service request including an access token with ownership information and may use the ownership information to verify or attempt to verify the ownership of the access token (e.g., determine or detect that the consumer NF199 is the owner of the access token and / or that the access token has not been stolen). For example, the producer NF299 or the TM 404 therein may perform an ownership verification procedure that includes using the ownership information of the access token to identify values ​​of TLS parameters associated with or identifying the owner of the access token, and then obtaining the TLS parameter values ​​from a TLS certificate (e.g., obtained from the consumer NF199 during the TLS handshake protocol). In this example, if the two values ​​match (e.g., the values ​​are equal or the same), the producer NF299 or the TM 404 therein may determine that the consumer NF199 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), the producer NF299 or the TM404 therein can determine that the consumer NF199 is not the true owner of the access token (e.g., the access token is stolen or compromised).

[0110] In some embodiments, for example, instead of or in addition to verifying ownership of the access token (e.g., verifying that the access token is not stolen), the producer NF299 can validate the access token (e.g., OAuth2.0 access token) by ensuring the integrity of the access token including verifying the signature of the access token using the NRF100's public key, by verifying that the audience claim of the access token matches its own identity, by verifying the scope and "extra scope" information of the access token, and by verifying that the access token has not expired (e.g., by checking the expiry attribute of the access token).

[0111] After determining in step 803 that the access token is not stolen and / or that the access token is valid, the producer NF299 may authorize or grant the service request message by sending a service response message containing the requested service or related information.

[0112] It will be appreciated that Figure 8 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 Figure 8 may be performed in a different order or sequence.

[0113] 9 is a message flow diagram illustrating a scenario 900 involving an NF 400 detecting that an access token in a service request is stolen. As shown, FIG. 9 illustrates an NF 400 that includes a TM 404. In some embodiments, the TM 404 may perform various aspects related to verifying ownership of the access token using ownership information in the access token and information from a TLS certificate associated with the sender of a message (e.g., a service request message) that includes the access token.

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

[0115] 9, prior to step 901, a TLS connection may be established between the malicious entity 298 and the NF 400, where 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 the respective NF. In this example, the SAN extension parameters 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).

[0116] In step 901, a 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 send a service request including the access token to the NF 400. For example, the malicious entity 298 may exploit a network security issue or an application vulnerability to obtain the access token requested by the consumer NF 199 of FIG. 2 .

[0117] In step 902, the 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 the ownership of the access token (e.g., determine or detect that a malicious entity 298 is the owner of the access token and / or that the access token is not stolen). For example, the NF 400, or the TM 404 therein, may perform an ownership verification procedure that includes using the access token's ownership information to identify values ​​of TLS parameters associated with or identifying the access token's owner, and then obtaining the TLS parameter values ​​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 the same), the NF 400, or the TM 404 therein, may determine that the consumer NF 199 is the true owner of the access token. However, in this embodiment, if the two values ​​do not match (e.g., the values ​​are different), the NF400 or the TM404 therein can determine that the malicious entity 298 is not the true owner of the access token (e.g., the access token has been stolen or compromised).

[0118] In some embodiments, for example, instead of or in addition to verifying ownership of the access token, the NF400 can validate the access token (e.g., an OAuth 2.0 access token) by ensuring the integrity of the access token, including verifying the signature of the access token using the NRF100's public key, by verifying that the access token's audience claim matches its own identity, by verifying the access token's scope and "extra scope" information, and by verifying that the access token has not expired (e.g., by checking the access token's expiration attribute).

[0119] After determining in step 903 that the access token is stolen, the NF400 may reject the service request message by sending a service response message indicating an error code or related error, such as the request not being authorized, the access token being compromised, etc.

[0120] It will be appreciated that Figure 9 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 Figure 9 may be performed in a different order or sequence.

[0121] 10 illustrates example ownership data 1000 that can be used to determine ownership attributes of an access token. Data 1000 may include information 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) (e.g., TLS parameters or key and TLS parameter values ​​that identify the owner of the access token). In some embodiments, data 1000, or portions thereof, may be predetermined or configured by a network operator. In some embodiments, data 1000, or portions thereof, may be received or generated during a registration procedure or an access token request procedure.

[0122] In some embodiments, data 1000 can be used when the NRF 100 or a similarly functional entity (e.g., NF 400) is configured to automatically add ownership attributes (e.g., “owner_tls_key” and “owner_tls_value” values) to an access token (e.g., an OAuth 2.0 access token) when the access token is requested by the consumer NF. For example, data 1000 can include or represent default ownership attributes (e.g., derived from NF registration information or provided by a network operator) for a particular NF, NF type, or NF location. In this example, the default ownership attributes or related information in the NRF 100 or a similarly functional entity can allow the consumer NF to dispense with logic for requesting an access token with explicit ownership attributes, because the NRF 100 or a similarly functional entity can use data 1000 to automatically provide the related ownership attributes in the access token.

[0123] 10, a table illustrating data 1000 may include columns and / or fields for an NF instance identifier, an ownership or trust key (e.g., an “owner_tls_key” value), and an ownership or trust value (e.g., an “owner_tls_value” value). As shown in FIG. 10, each row may associate an NF instance identifier with ownership information that identifies the owner of the corresponding access token (e.g., an access token requestor).

[0124] In some embodiments, the "NF Instance ID" field may store information to identify a particular 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 the 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 RFC4122. For example, the NF instance identifier "SCP1" can represent a 128-bit UUID where the 16 bytes (e.g., octets) of the UUID are represented as 32 hexadecimal digits, presented in five groups separated by hyphens in the format 8-4-4-4-12 for a total of 36 characters (32 hexadecimal characters and four hyphens), e.g., "2967a69a-f61b-4bc1-b9da-47c9c5d14b64" (e.g., "san.dNSName", "san.ipAddress", "san.otherName", or "san.registeredID").

[0125] In some embodiments, the "Ownership / Trust Key" field may store information to indicate which TLS certificate parameters to examine 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 an associated SAN extension parameter, such as an IP address, a DNS name, a registration ID (e.g., an NF instance identifier), or other name. For example, an "Ownership / Trust Key" field value of "san.dNSName" may be included in a private claim of the corresponding access token. In this example, the value "san.dNSName" may indicate (e.g., to a validating entity such as an NF 400) that a TLS certificate SAN extension parameter that stores a DNS name associated with the sender of a service request should be examined for a parameter value, and that this parameter value in the TLS certificate should be compared to the value in the "Ownership / Trust Value" private claim when determining whether the sender of a service request that includes the access token is the owner of the access token.

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

[0127] It will also be appreciated that data 1000 is for illustrative purposes and that different and / or additional data than that shown in Figure 10 may be used to determine or identify appropriate ownership information for various access tokens. Data 1000 may also be stored and managed (e.g., in data storage 406) using various data structures and / or computer-readable media.

[0128] FIG. 11 illustrates an example process 1100 for detecting a stolen access token. In some embodiments, the example process 1100 described herein, or portions thereof (e.g., operations or steps), may be performed in or by the NF 400, the TM 404, and / or another module, NF, or node. In some embodiments, the process 1100, or portions thereof, may be performed in 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 3GPP-defined Model C or D scenario), the process 1100, or portions 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 3GPP-defined Model B scenario), the process 1100, or portions thereof, may be performed by a producer NF 299 that receives a service request message directly from the consumer NF 199.

[0129] Referring to process 1100, a service request including an access token may be received from a sender over a TLS connection at step 1102. In some embodiments, the access token may include ownership information (e.g., as a private claim) indicating TLS parameters for verifying the owner of the access token.

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

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

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

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

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

[0135] In some embodiments, process 1100 may occur at a producer NF 299 that may grant a service request from a consumer NF 199. In such an embodiment, the producer NF 299 may be configured to validate the service request, determine that the service request is valid (e.g., using an access token validation procedure), and allow the service request in response to determining that the ownership information of the access token matches the TLS information associated with the sender.

[0136] In some embodiments, the access token may include an OAuth2.0 access token, and the ownership information for verifying ownership of the OAuth2.0 access token is one or more claims of the OAuth2.0 access token.

[0137] In some embodiments, the TLS certificate used in verifying the owner of the access token can be obtained from the sender during the TLS handshake protocol for establishing a TLS connection between the sender and the next hop NF (e.g., NF 400 or intermediate NF 598).

[0138] 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 the TLS certificate for verifying 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 claim of the access token. In this example, the "owner_tls_key" value may indicate a TLS parameter or field name in the TLS certificate from which the first-hop NF needs to obtain a value. Continuing with this example, the first hop NF can compare the value obtained from the TLS certificate with the value from the “owner_tls_value” value in another private claim of the access token, and if the two values ​​do not match, the first hop NF can determine that the access token is stolen.

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

[0140] In some embodiments, the NRF 100 can be configured to receive an access token request, which may include information indicative of ownership information, from a second NF (e.g., consumer NF 199) before the NF (e.g., NF 400) receives the service request, generate an access token that includes the ownership information, and send the access token to the second NF. In such embodiments, the second NF (e.g., the owner of the access token) can be the sender of the service request, or the second NF can be different from the sender of the service request.

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

[0142] 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 be performed in a different order or sequence.

[0143] Although some aspects of the subject matter described herein have been described with reference to 5G networks, it will be appreciated that various other networks may use some aspects of the subject matter described herein. For example, any network that allows and uses access tokens with customizable attributes or claims may use the features, systems, mechanisms, and / or techniques described herein to indicate ownership information to curb the use of stolen or compromised access tokens.

[0144] It should be noted that the NF 400, TM 404, and / or functionality described herein can constitute a dedicated computing device. Additionally, the NF 400, TM 404, and / or functionality described herein can improve the technology field of network communications. For example, the NF 400 can include the TM 404, which can be enabled to reject service requests (e.g., CRUD calls) associated with stolen or compromised access tokens, thereby enabling the NF 400 (e.g., producer NF 299, SCP 101, SEPP 126, etc.) to mitigate various attacks or abuses involving stolen or compromised access tokens (e.g., stolen by a malicious entity 298).

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

[0146] References 1. 3GPP TS 33.501; 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security architecture and procedures for 5G system; (Release 16); V16.8.0 (2021-09). 2. 3GPP TS 29.510; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 16); V16.9.0 (2021-09). 3. Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", IETF RFC 7519, May 2015. 4. Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", IETF RFC 5246, August 2008. 5. Hardt et al., "The OAuth 2.0 Authorization Framework", IETF RFC 6749, October 2012. It will be understood that various details of the presently disclosed subject matter can be changed without departing from the scope of the presently disclosed subject matter, and the foregoing description has been given by way of example only, and not by way of limitation.

Claims

1. A method for detecting a stolen access token, comprising a network function (NF) including at least one processor, The process includes receiving a service request from a sender via a Transport Layer Security (TLS) connection, the access token including ownership information that indicates TLS parameters for verifying the owner of the access token. The aforementioned method, Using the ownership information of the access token and the TLS information in the TLS certificate obtained from the sender, it is determined whether the ownership information and the TLS information match. A method comprising rejecting the service request in response to a determination that the ownership information and the TLS information do not match.

2. The aforementioned NF is an intermediate NF between the sender and a producer NF capable of granting the service request, and in the aforementioned NF, In response to the determination that the ownership information and the TLS information match, a credit token indicating identification information that identifies the NF is added to the service request, The method according to claim 1, comprising transmitting the service request, which includes the access token and the trust token, to a second intermediate NF or the producer NF.

3. In the second intermediate NF, The service request, including the access token and the trust token, is received from the NF via a second TLS connection. Using the identification information of the credit token and the second TLS information in the second TLS certificate obtained from the NF, it is determined whether the identification information and the second TLS information match. In response to a determination that the aforementioned identification information and the second TLS information do not match, the service request is rejected. In response to the determination that the identification information and the second TLS information match, the credit token in the service request is replaced with a second credit token representing the second identification information that identifies the second intermediate NF, The method according to claim 2, comprising transmitting the service request, which includes the access token and the second trust token, to the producer NF.

4. In the aforementioned producer NF, Receiving the service request, including the access token and the second trust token, from the second intermediate NF via a third TLS connection, 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, it is determined whether the second identification information and the third TLS information match. In response to a determination that the second identification information and the third TLS information do not match, the service request is rejected. In response to the determination that the second identification information and the third TLS information match, the service request is validated. Determining that the aforementioned service request is valid, The method according to claim 3, further comprising granting the aforementioned service request.

5. The aforementioned NF is a producer NF capable of granting the service request, and in the aforementioned NF, In response to the determination that the ownership information and the TLS information match, the service request is validated. Determining that the aforementioned service request is valid, The method according to claim 1, further comprising granting the aforementioned service request.

6. The method according to claim 1, wherein the access token includes an OAuth 2.0 access token, the ownership information is stored as one or more attributes of the OAuth 2.0 access token, and the TLS certificate is obtained from the sender during a TLS handshake protocol to establish the TLS connection between the sender and the NF.

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

8. In the NF repository function (NRF), before the NF receives the service request, The second NF receives an access token request containing information indicating the ownership information, To generate the access token which includes the aforementioned ownership information, The method according to claim 1, comprising transmitting the access token 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 according to claim 1, wherein the NF includes 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 stolen access tokens, At least one processor, Memory and Includes a network function (NF) implemented using the at least one processor and the memory, The NF is configured to receive a service request from the sender, including an access token, via a Transport Layer Security (TLS) connection, and the access token includes ownership information indicating TLS parameters for verifying the owner of the access token. The aforementioned NF is, Using the ownership information of the access token and the TLS information in the TLS certificate obtained from the sender, it is determined whether the ownership information and the TLS information match. A system further configured to reject the service request in response to a determination that the ownership information and the TLS information do not match.

11. The aforementioned NF is an intermediate NF between the sender and the producer NF that can authorize the service request, The aforementioned NF is, In response to the determination that the ownership information and the TLS information match, a credit token indicating identification information that identifies the NF is added to the service request. The system according to claim 10, configured to transmit the service request, including the access token and the trust token, to a second intermediate NF or the producer NF.

12. The second intermediate NF is, The service request, including the access token and the trust token, is received from the NF via a second TLS connection. Using the identification information of the credit token and the second TLS information in the second TLS certificate obtained from the NF, it is determined whether the identification information and the second TLS information match. In response to the determination that the identification information and the second TLS information do not match, the service request is rejected. In response to the determination that the identification information and the second TLS information match, the credit token in the service request is replaced with a second credit token representing the second identification information that identifies the second intermediate NF. The system according to claim 11, configured to transmit the service request, which includes the access token and the second trust token, to the producer NF.

13. The aforementioned producer NF is, The service request, including the access token and the second trust token, is received from the second intermediate NF via a third TLS connection. 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, it is determined whether the second identification information and the third TLS information match. In response to the determination that the second identification information and the third TLS information do not match, the service request is rejected. In response to the determination that the second identification information and the third TLS information match, the service request is validated. The service request is determined to be valid, The system according to claim 12, configured to allow the aforementioned service request.

14. The aforementioned NF is a producer NF capable of granting the service request, The aforementioned NF is, In response to the determination that the ownership information and the TLS information match, the service request is validated. The service request is determined to be valid, The system according to claim 10, configured to allow the aforementioned service request.

15. The system according to claim 10, wherein the access token includes an OAuth2.0 access token, the ownership information is stored as one or more attributes of the OAuth2.0 access token, and the TLS certificate is obtained from the sender during a TLS handshake protocol to establish the TLS connection between the sender and the NF.

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

17. The system according to claim 16, wherein the TLS parameters include or indicate a subject alias extension parameter, an Internet Protocol (IP) address, a domain name system (DNS) name, a uniform resource identifier (URI), an NF instance identifier, or an email address.

18. Includes NF Repository function (NRF), The NRF, before the NF receives the service request, The second NF receives an access token request containing information indicating the ownership information, Generate the access token containing the aforementioned ownership information, The system according to any one of claims 10 to 17, wherein the access token is configured to transmit to the second NF, the second NF being the sender of the service request, or the second NF being different from the sender of the service request.

19. The system according to any one of claims 10 to 17, wherein the NF includes a service communication proxy (SCP), a security edge protection proxy (SEPP), a proxy NF, an intermediate NF, or a producer NF.

20. A computer-readable program that causes at least one processor to execute the method according to any one of claims 1 to 9.

Images