A method, system, and computer-readable media for automated key management of public keys for Network Functions (NF) Repository Functions (NRF) access tokens for 5G Core (5GC) authorization to mitigate security attacks.

Abstract

A method for automated key management of network access token public keys for 5GC authorization to mitigate security attacks includes providing a network access token public key status update notification subscription interface in an NRF that enables a producer NF to subscribe to receive notifications of status updates of service access token public keys issued by the NRF. When the NRF determines that a status update of a service access token public key is necessary, the NRF updates the status of the public key in its local database and notifies the producer NF that it has subscribed to receive the update. The producer NF uses the public key to validate service requests from consumer NFs. In one variation, the NRF maintains and updates the status of service access token public keys associated with various service access levels.

Description

Technical Field

[0003]

[0001] Priority Claim This application claims the benefit of priority of U.S. Patent Application No. 17 / 115,746, filed on December 8, 2020, the disclosure of which is hereby incorporated by reference in its entirety.

[0002] Technical Field The subject matter described herein relates to improving security in 5G communication networks. More specifically, the subject matter described herein relates to methods, systems, and computer-readable media for automatic key management of NRF access token public keys for 5GC authentication to mitigate security attacks.

Background Art

[0003] Background In 5G telecommunications networks, network functions that provide services are referred to as producer network functions (NFs) or NF service producers. Network functions that consume services are referred to as consumer NFs or NF service consumers. A network function can be a producer NF, a consumer NF, or both, depending on whether it is consuming a service, producing a service, or both consuming and producing a service. The terms "producer NF" and "NF service producer" are used synonymously herein. Similarly, the terms "consumer NF" and "NF service consumer" are used synonymously herein.

Summary of the Invention

Problems to be Solved by the Invention

[0004] A given Producer NF may have many service endpoints, which are contact points for one or more NF instances hosted by the Producer NF. Service endpoints are identified by a combination of an IP address and port number or a fully qualified domain name, which can be broken down into an Internet Protocol (IP) address and port number on the network node hosting the Producer NF. An NF instance is an instance of the Producer NF that provides a service. A given Producer NF may contain two or more NF instances. It should also be noted that multiple NF instances can share the same service endpoint.

[0005] Producer NFs register with the Network Function Repository Function (NRF). The NRF maintains service profiles of available NF instances, identifying the services supported by each NF instance. 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 a Service Communications Proxy (SCP). SCPs subscribe to the NRF to obtain reachability and service profile information about producer NF service instances. Consumer NFs connect to the Service Communications Proxy, which either load balances traffic between producer NF service instances providing the required services or routes this traffic directly to the destination producer NF instance.

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

[0008] 3GPP® TS 33.501 defines a security architecture and procedure for accessing services in 5G networks. Section 13.4 of 3GPP TS 33.501 states that Consumer NFs should use OAuth 2.0 as an authorization procedure for accessing services provided by Producer NFs in 5G networks. OAuth 2.0 is defined in the Internet Engineering Task Force's Request for Comments (RFC) 6749. OAuth 2.0 is an authentication model for clients to obtain access to protected resources on a server by authenticating the server using the resource owner's credentials. OAuth 2.0 defines four roles. The first role is the resource owner, which is an entity that can grant access to protected resources. The second role is the resource server, which is a server that hosts protected resources and can accept and respond to requests for those resources and authenticate those requests using access tokens. The client is an entity that requests access to protected resources. The fourth role defined in OAuth 2.0 is that of an authorization server, which issues an access token to the client after successfully authenticating and authorizing the resource owner. Section 13.4.1 of 3GPP TS 33.501 defines the roles of 5G network elements in the OAuth 2.0 framework, specifying that the NRF is the OAuth 2.0 authorization server, the NF service consumer is the OAuth 2.0 client, and the NF service producer is the OAuth 2.0 resource server.

[0009] RFC 6749 defines a framework for authentication, but it does not define key management procedures for the cryptographic keys used when performing such authentication. While the framework defines the above roles as resource server, authorization server, and resource client, it does not specify key management by the authorization server for distributing public keys to authenticate service requests from resource clients and updating the status of public keys distributed to the resource server.

[0010] OAuth 2.0 authentication is performed using an access token issued by the NRF and used by the Consumer NF to access services provided by the Producer NF. In one possible authentication method based on asymmetric cryptographic algorithms, a portion of the access token is signed using the NRF's private key. The NRF's public key is distributed to the Producer NFs in the network and used to validate the access tokens received from the Consumer NFs. Specifically, 3GPP TS 33.501 states that the access token is a JSON web token as described in RFC 7519 and is secured by a digital signature based on a JSON Web Signature (JWS) as described in RFC 7515 or a Message Authentication Code (MAC).

[0011] One problem with this authentication mechanism is that 3GPP does not define key management procedures for the public keys held by the NRF for access token integrity checks at the Producer NF. For example, there is no procedure to revoke the OAuth2.0 NRF-issued public key if the key is compromised due to a security attack; instead, the key must be manually reprovisioned at the Producer NF. Performing manual reprovisioning can disrupt the services provided by the Producer NF.

[0012] Another related issue is that 3GPP has not defined procedures for managing NRF access token public keys associated with various service access levels, such as Public Land Mobile Network (PLMN) level, network slice level, network functionality level, and service level. Typically, an NRF deployment may contain a single access token public key for a given NRF. The inability to specify and manage access token public keys at various service access levels limits the flexibility of service access control and threat mitigation in 5G network deployments.

[0013] In light of these issues, improved methods, systems, and computer-readable media are needed for access token key management. [Means for solving the problem]

[0014] overview A method for automated key management of network access token public keys for 5G core (5GC) authorization to mitigate security attacks includes steps performed in a network function (NF) repository function (NRF) including at least one processor and memory. The steps include maintaining a network access token public key database in the memory for use by a producer NF when validating a network access token presented in a service request from a consumer NF. The steps further include providing the producer NF with a network access token public key status notification subscription interface to enable the producer NF to subscribe to receiving notifications of status updates of the at least one public key. The steps further include receiving a request from the producer NF via the network access token public key status notification subscription interface for which a status update of the at least one public key should be notified, and creating a subscription for the producer NF in response. The steps further include determining that a status update of the at least one public key is necessary. The above steps further include updating the status of the at least one public key in response to a determination that the status of the at least one public key needs to be updated; identifying from the subscription that the producer NF subscribes to receive notifications of updates to the status of the at least one public key; and notifying the producer NF of the update to the status of the at least one public key.

[0015] According to another aspect of the subject matter described herein, the step of maintaining the network access token public key database includes the step of maintaining a plurality of public keys in the network access token public key database, at least some of which are associated with different service access levels.

[0016] According to another aspect of the subject matter described herein, the various service access levels mentioned above include public land mobile network (PLMN) service levels, network slice levels, NF type levels, and service levels.

[0017] According to another aspect of the subject matter described herein, the at least one public key is associated with one of the service access levels, and the step of updating the status of the at least one public key includes the step of revoking the public key at one of the service access levels.

[0018] According to another aspect of the subject matter described herein, the step of providing the public key status notification subscription interface includes the step of providing an interface for receiving subscription requests from the producer NF, the subscription request may include service access level identification information and a request for an immediate key.

[0019] According to another aspect of the subject matter described herein, the subscription request includes the request for an immediate key and further comprises the step of communicating the public key to the producer NF in response to the subscription request.

[0020] According to another aspect of the subject matter described herein, the step of creating the above subscription includes the step of creating or updating a record in the above database for considering the above NF as a subscriber to the above update of the status of the above at least one public key.

[0021] According to another aspect of the subject matter described herein, the step of determining that the status of the above-mentioned at least one public key needs to be updated includes determining that at least one network access token signed using the above-mentioned at least one private key corresponding to the above-mentioned at least one public key has been compromised, and the step of updating the above-mentioned status of the above-mentioned at least one public key includes the step of revoking the above-mentioned at least one public key.

[0022] According to another aspect of the subject matter described herein, the step of determining that a change in the status of the above at least one public key is necessary includes the step of determining that the above at least one public key is necessary to revoke in response to the expiration of a configurable period, and the step of updating the above status of the above at least one public key includes the step of revoking the above at least one public key.

[0023] According to another aspect of the subject matter described herein, a method for automated key management to mitigate security attacks includes the steps of the Producer NF receiving the notification of an update to the status of the at least one public key, the notification of an update to the status of the at least one public key including at least one replacement public key for the at least one public key, receiving a service request from a Consumer NF, the service request including a network access token, attempting to validate the service request using the at least one replacement public key, determining that the validation fails, and preventing the Consumer NF from accessing the service specified in the service request.

[0024] According to another aspect of the subject matter described herein, a system for automated key management of network access token public keys for a 5G core (5GC) to mitigate security attacks is provided. The system includes a network function (NF) repository function (NRF) including at least one processor and memory. The system further includes a network access token public key database located in the memory and containing at least one public key for use by a producer NF when validating network access tokens presented in a service request from a consumer NF. The system further includes an automated access token key manager implemented by the at least one processor to hold the network access token public key database. The automated access token key manager is configured to provide the producer NF with a network access token public key status notification subscription interface to enable the producer NF to subscribe to receive notifications of status updates for the at least one public key, to receive requests from the producer NF to be notified of status updates for the at least one public key via the network access token public key status notification subscription interface, to create a subscription for the producer NF in response to such requests, to determine that an update to the status of the at least one public key is necessary, to update the status of the at least one public key in response to the determination that an update to the status of the at least one public key is necessary, to identify from the subscription that the producer NF will subscribe to receive notifications of status updates for the at least one public key, and to notify the producer NF of the update to the status of the at least one public key.

[0025] According to another aspect of the subject matter described herein, the automatic access token key manager is configured to hold a plurality of public keys in the network access token public key database, and at least some of the plurality of public keys are associated with different service access levels.

[0026] According to another aspect of the subject matter described herein, the different service access levels include a public land mobile network (PLMN) level, a network slice level, an NF type level, and a service level.

[0027] According to another aspect of the subject matter described herein, at least one of the public keys is associated with one of the service access levels, and the automatic access token key manager is configured to update the status of the at least one public key by canceling the public key at the one service access level.

[0028] According to another aspect of the subject matter described herein, the network access token public key status notification subscription interface is configured to receive a subscription request from the producer NF, and the subscription request may include service access level identification information and a request for an immediate key.

[0029] According to another aspect of the subject matter described herein, the subscription request includes the request for an immediate key, and in response thereto, the automatic access token key manager is configured to communicate a public key to the producer NF in response to the subscription request.

[0030] According to another aspect of the subject matter described herein, when creating the above subscription, the above automated access token key manager is configured to create or update a record in the above database to consider the above NF as a subscriber to the above update of the status of the above at least one public key.

[0031] According to another aspect of the subject matter described herein, the automated access token key manager is configured to determine, in response to a determination that at least one access token signed with at least one private key corresponding to the at least one public key has been compromised, that the status of the at least one public key needs to be updated, and to update the status of the at least one public key by revoking the at least one public key.

[0032] According to another aspect of the subject described herein, the Automated Access Token Key Manager is configured to determine that an update of the status of the at least one public key is required in response to the expiration of a configurable period, and to update the status of the at least one public key by revoking the at least one public key.

[0033] According to another aspect of the subject matter described herein, a non-temporary computer-readable medium is provided which stores executable instructions that, when executed by the computer's processor, control the computer to perform a step. The step includes maintaining in the non-temporary computer-readable medium a network access token public key database containing at least one public key for use by the Producer Network Function (NF) when validating a network access token presented in response to a service request from a Consumer NF. The step further includes providing the Producer NF with a network access token public key status notification subscription interface to enable the Producer NF to subscribe to receiving notifications of status updates of the at least one public key. The step further includes receiving a request from the Producer NF via the network access token public key status notification subscription interface for which a status update of the at least one public key should be notified, and creating a subscription for the Producer NF in response. The step further includes determining that a status update of the at least one public key is necessary. The above steps further include updating the status of the at least one public key in response to a determination that the status of the at least one public key needs to be updated; identifying from the subscription that the producer NF subscribes to receive notifications of updates to the status of the at least one public key; and notifying the producer NF of the update to the status of the at least one public key.

[0034] The subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof. Therefore, the terms “function,” “node,” or “module,” as used herein, refer to hardware that may also include software and / or firmware components to implement the features described herein. In one exemplary implementation, the subject matter described herein may be implemented using a computer-readable medium containing computer-executable instructions that, when executed by a computer's processor, control the computer to perform steps. Suitable exemplary computer-readable media for implementing the subject matter described herein include non-transient computer-readable media such as disk memory devices, chip memory devices, programmable logic devices, and application-specific integrated circuits. Furthermore, the computer-readable medium for implementing the subject matter described herein may reside on a single device or computing platform, or may be distributed across multiple devices or computing platforms. Additionally, the subject matter described herein may be implemented as a cloud-based service where each of the non-transient computer-readable media and the processor executing the instructions embodied in the computer-readable media resides within a cloud network.

[0035] The subject matter described herein will now be explained with reference to the attached drawings. [Brief explanation of the drawing]

[0036] [Figure 1] This is a network diagram illustrating an exemplary 5G network architecture. [Figure 2] This message flow diagram illustrates an exemplary message flow associated with an NF service consumer obtaining an access token from an NRF. [Figure 3]This message flow diagram shows how an NF service consumer obtains authorization from an NF service producer to access services provided by the NF service producer using an access token. [Figure 4] This message flow diagram illustrates the example messages exchanged between the NRF and the NF service consumer when the NF service consumer subscribes to receive notifications of status updates for the access token public key held by the NRF. [Figure 5] This message flow diagram shows how an NF service producer blocks access to a service in response to a service request that has an access token signed using an unauthorized key. [Figure 6] This is a block diagram showing an NRF with an automated access token key manager. [Figure 7] This flowchart shows an exemplary process for automated access token key management by NRF. [Modes for carrying out the invention]

[0037] Detailed explanation The subject matter described herein relates to methods, systems, and computer-readable media for automated NRF public key management to mitigate 5G security attacks. Figure 1 is a block diagram illustrating an exemplary 5G system network architecture. The architecture in Figure 1 includes an NRF100 and an SCP101, which may reside in the same Home Public Land Mobile Network (HPLMN). As described above, the NRF100 can maintain profiles of available producer NF service instances and their supported services, enabling consumer NFs or SCPs to subscribe to new / updated producer NF service instances and be notified of their registration. The NRF100 can also issue OAuth2.0 access tokens and perform automated access token key management. The SCP101 can also support service discovery and selection of producer NF instances. The SCP101 can perform load balancing of connections between consumer NFs and producer NFs. The SCP101 can also request and obtain OAuth2.0 access tokens from the NRF100 on behalf of consumer NFs.

[0038] NRF100 is a repository for NF or service profiles of producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP must obtain the NF or service profile or producer NF instance from NRF100. An NF or service profile is a JavaScript Object Notation (JSON) data structure defined in Third Generation Partnership Project (3GPP) Technical Specification (TS) 29.510. The definition of an NF or service profile includes at least one of the following: a Fully Qualified Domain Name (FQDN), an Internet Protocol (IP) version 4 (IPv4) address, or an IP version 6 (IPv6) address. In Figure 1, any network function (other than NRF100) can be a consumer NF, a producer NF, or both, depending on whether it is requesting a service, providing a service, or requesting and providing a service. In the example shown, the NF includes a Policy Control Function (PCF) 102 that performs policy-related operations within the network, a User Data Management (UDM) function 104 that manages user data, and an Application Function (AF) 106 that provides application services. The NF shown in Figure 1 further includes a Session Management Function (SMF) 108 that manages sessions between the Access and Mobility Management Function (AMF) 110 and the PCF 102.The AMF110 performs mobility management operations similar to those performed by a Mobility Management Entity (MME) within a 4G network. The Authentication Server Function (AUSF)112 performs authentication services for user equipment (UEs), such as user equipment (UEs)114, that request access to the network.

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

[0040] The Radio Access Network (RAN) 120 connects the User Equipment (UE) 114 to the network via a wireless link. The Radio Access Network 120 can be accessed using a g-Node B (gNB) (not shown in Figure 1) or other wireless access points. The User Plane Function (UPF) 122 can support various proxy functions for user plane services. One example of such a proxy function is the Multipath Transmission Control Protocol (MPTCP) proxy function. The UPF 122 can also support performance measurement functions that can be used by the UE 114 to obtain network performance measurements. A Data Network (DN) 124 is also shown in Figure 1, through which the UE accesses data network services such as Internet services.

[0041] SEPP126 filters traffic coming from other PLMNs and performs topology concealment for traffic leaving the home PLMN. SEPP126 can communicate with SEPPs within external PLMNs and manages the security of those external PLMNs. Therefore, traffic between NFs within different PLMNs traverses two SEPP functions (one for the home PLMN and the other for the external PLMN).

[0042] Figure 2 is a message flow diagram illustrating the procedure for obtaining an access token from an NRF according to the OAuth2.0 framework. According to the interface specification, the NRF acts as the OAuth2.0 authorization server. An NF service consumer acts as the OAuth2.0 client. An NF service producer acts as the OAuth2.0 resource server. Referring to the message flow in line 1 of Figure 2, consumer NF200 requests an access token from NRF100 within the same PLMN. The procedure used to obtain the access token is the Nnrf_AccessToken_Get request operation. The Nnrf_AccessToken_Get request message includes the NF instance ID of the NF service consumer, the requested scope (i.e., the requested resources and the requested actions (service operations) on those resources), which may optionally include additional scope information, along with the expected NF service name, the expected NF producer instance, and the NF type of the NF consumer. The service consumer may also include a list of NSSAIs or NF IDs for the expected NF producer instance. The message may also include the NF set ID of the expected NF service producer instance.

[0043] In response to receiving an Nnrf_AccessToken_Get request, the NRF may optionally authorize an NF service consumer. The NRF then generates an access token containing the appropriate claims. The NRF digitally signs a portion of the generated access token based on a shared or private key as specified in IETF RFC7515. The claims in the access token include the NF instance ID of the NRF (issuer), the NF instance ID of the NF service consumer (subject), the NF type of the NF service producer (audience), the expected service name, scope, expiration date, and optionally additional scope information (allowed resources and allowed actions). The claims may also include a list of NSSAI or NSSIDs for the expected producer NF instance. The claims may also include the NF set ID of the expected NF service producer instance.

[0044] If authorization of the NF service consumer is successful, in line 2A, the NRF sends an access token to the NF service consumer in the Nnrf_AccessToken_Get response operation. If authentication is unsuccessful, the NRF responds with an OAuth2.0 error response as defined in IETF RFC6749, as shown in line 2B. The digitally signed access token may be issued in the response sent to the consumer NF200 in the form of a JavaScript Object Notation (JSON) Web Signature (JWS) Compact Serialization Encoded String. JWS Compact Notation is defined in IETF RFC7515 and is a data structure that represents a digitally signed or message authentication encoded message.

[0045] The consumer NF200 stores an access token and includes it in service requests to a producer NF within the same PLMN. Upon receiving a service request containing an access token, the producer NF, pre-configured with the NRF's public key, uses the public key to verify the digital signature in the access token. If the digital signature in the access token is verified, the producer NF responds to the service request with a response granting the consumer NF access to the service. If the digital signature in the access token is not verified, the producer NF responds to the service request with a message indicating that access to the requested service is denied.

[0046] Figure 3 illustrates how to obtain a service from producer NF using an access token. Referring to row 1 in Figure 3, consumer NF200 sends a service request to producer NF300. Consumer NF200 includes an NRF-issued access token in the service request. As described above, the NRF-issued access token includes a JWS compact serialization signed using the NRF's public key.

[0047] Upon receiving a service request, producer NF300 ensures token integrity by verifying the signature using the public key of the NRF, which is provisioned by producer NF before producer NF receives the service request. In the example shown in Figure 3, the service request is validated. Therefore, in line 2, producer NF300 sends a message to consumer NF200 indicating that the service request has been validated, granting access to the requested service.

[0048] As described above, the problems with this architecture include the fact that the IETF and 3GPP specifications do not specify an automated management procedure for public keys issued by the NRF. As a result, OAuth2.0 access token NRF public keys may be manually provisioned and manually maintained in the producer NF. There is no defined automated mechanism for the NRF to update the status of the public key in the producer NF. Furthermore, there is currently no 3GPP defined mechanism for issuing access token public keys for different service access levels.

[0049] To address at least some of these issues, the subject matter described herein includes an automated access token public key management procedure performed by the NRF. This procedure provides automated provisioning, renewal, replacement, and revocation of access token public keys at producer NFs. Embodiments of the present invention can facilitate centralized control of provisioned keys, meaning that each subscribed producer NF is continuously informed of the status (e.g., revocation) of the provisioned keys in a secure, efficient, and scalable manner. Furthermore, the services provided by the NRF enable various public key management at various service access levels, including PLMN level, network slice level, NF type level, service level, etc.

[0050] In accordance with the Network Access Token Public Key Status Update Subscription Service, each Producer NF that a Network Operator wishes to participate in automated access token key management sends an Access Token NRF Public Key Update Subscription Request to the NRF to subscribe to receiving notifications of updates to the status of the access token public key. This subscription request may optionally include an immediate key request instructing the NRF to promptly send the access token public key in the subscription response if the Producer NF has not currently provisioned an access token public key. In response to the subscription request, the NRF creates a subscription in its local database to indicate that the Producer NF subscribes to receiving notifications of updates to the status of the public key.

[0051] The public key to which a subscription request is directed can be identified by the service access level parameter in the subscription request. For example, if a subscription request considers the requested service access level for the subscription to be PLMN, the NRF creates or updates a record in its database indicating that the requester subscribes to receive notifications of updates to the public key status for the PLMN service access level. If a subscription request considers the requested service access for the subscription to be NSSAI, the NRF creates or updates a record in its database indicating that the service access level for the subscription is a network slice identified by NSSAI, and provides updates to the public key status used for service verification at the NSSAI level.

[0052] For example, if the NRF determines that an access token signed using a private key corresponding to a public key is compromised, or that one of the public keys requires a status update due to the expiration of a configurable period, the NRF will generate a notification of the status update to the subscribed producer NF. A status update may be a renewal, revocation, replacement, or any other update of the public key's status. Also, as described above, the NRF can issue various public keys with various service access levels, including but not limited to the PLMN level, individual slice level, NF type level, and service level, based on subscription requests sent by producer NFs acting as consumers in this example. For example, a private key with a PLMN service access level can be used by the NRF to generate a network access token that spans the entire PLMN, which can then be used by a consumer NF to access services provided by any producer NF within the PLMN. Revocation of the public key corresponding to a private key with a PLMN service access level would prevent an attacker from using the PLMN-wide access token to access any NF within the PLMN. If a public key has an NSSAI service access level, the NRF can use the corresponding private key to generate an NSSAI network access token, which a consumer NF can then use to access services provided by a producer NF within the NSSAI. Subsequently, if the NRF revokes the NSSAI-specific public key, tokens generated using the corresponding private key can no longer be successfully used by an attacker to access services within the network slice. Since the revoked key is specific to the network slice, tokens signed with public keys having different service access levels remain unaffected.As a result, the methods described herein offer greater flexibility in managing access to network services compared to a single-level approach.

[0053] As an additional security measure, if a given producer NF is registered with the NRF, the NRF may process only subscription requests from that producer NF. Communication between the NRF and a producer NF that subscribes to receive notifications of key status updates can be secured using Mutual Transport Layer Security (MTLS) or Network Domain Security / Internet Protocol (NDS / IP), as with other SBI service operations.

[0054] Figure 4 is a message flow diagram illustrating the access token public key management service provided by the NRF. Referring to row 1 of Figure 4, 5G producer NF300, acting as a service consumer, sends a message to NRF100 to subscribe to receiving notifications of status updates for the access token public key, for the purpose of a subscription service. The subscription request includes a notification Uniform Resource Identifier (URI) to notify the subscribing NF of key status updates, a PLMN ID, and service access level identification parameters associated with the subscription. The service access level identification parameters, along with the PLMN ID, may be used by producer NF300 to select one or more public keys for which it wishes to subscribe to receiving status update notifications. In the example shown, the service level identification parameters include Single Network Slice Selection Assistance Information (S-NSSAI), the NF type, and the service type. The subscription request also includes an indicator of whether an immediate key is requested. If an immediate key is requested, this is a new subscription, and producer NF300 is subscribed not only to receive notifications of changes in key status, but also to receive the current public key from NRF100.

[0055] NRF100 uses the PLMN ID and service access level identification parameter to select the public key that producer NF300 wishes to receive status updates for, and creates a subscription by updating or creating a record in the key management database that considers producer NF300 as a subscribed NF to the public key identified by the parameters in the request. In line 2 of the message flow diagram, NRF100 sends a Subscribe Access Token Public Key 2XX response containing the public key and service access level identification parameter (if an immediate key is requested). If an immediate key is not requested, the response may simply indicate a successful subscription without containing the public key and service access level identification parameter.

[0056] If NRF100 determines that the status of a public key held in the database needs to be updated, NRF100 updates the status of the public key and notifies producer NF, which subscribes to receive notifications of status changes. One such example is shown by line 3 of the message flow diagram, where NRF100 sends a notification request to producer NF300. This notification request includes the new public key and, whenever the current public key is replaced or revoked, also includes the service access level identification parameter. In line 4 of the message flow diagram, producer NF300 responds to the notification request with a notification response.

[0057] Figure 5 is a message flow diagram illustrating the use of access tokens to block network attacks and the key management procedure from Figure 4. Referring to row 1 of Figure 5, attacker 500 sends a service request with an access token to producer NF300. The access token may be signed using a revoked or unauthorized private key. Note that attacker 500 does not need to have access to the private key to obtain the access token. For example, attacker 500 may obtain a network access token from NRF by impersonating the identity of a valid consumer NF in a network access token request. The possibility of successfully using an unauthorized access token is reduced by using the automated key management procedure described herein.

[0058] The validity verification procedure for an access token may be as follows: Producer NF300, acting as a resource server, receives a resource request with an access token from attacker 500, acting as a resource client. The access token is a JSON web token, specifying the algorithm used to sign the JWS signature input within the token. Assume the signature algorithm is RS256. This indicates that an RSA private key is used to sign the JWS signature input using the Secure Hash Algorithm (SHA)-256 digital signature algorithm. The JWS signature input, RSA public key, and JWS signature are provided to an RSA signature verifier, which uses the RSA public key to reverse the SHA-256 signing process to generate a value that should match the JWS signature input. If the output from the verifier matches the JWS signature input, the access token is validated and access to the requested service is granted. If the output from the verifier does not match the JWS signature input, the access token is not validated and access to the requested service is denied. In this example, the output from the verifier does not match the JWS signature input. Therefore, in line 2, after determining that the access token is invalid, producer NF300 can respond with a denial-of-service message indicating the reason for the denial, such as an invalid token.

[0059] While the above paragraphs disclose the use of RSA public keys and SHAs for signing, the subject matter described herein is not limited to any particular public key format or digital signature algorithm. The automated key management procedures described herein can be used to manage the distribution and status updates of any suitable type of cryptographic key that can be used with any suitable digital signature or message authentication code algorithm to sign and verify network access tokens. Thus, as used herein, the term “public key” refers to any suitable cryptographic key that can be used as input to a verifier for verifying a digital signature or message authentication code.

[0060] Figure 6 is a block diagram illustrating an exemplary architecture for NRF100. Referring to Figure 6, NRF100 includes at least one processor 600 and memory 602. NRF100 further includes an automated access token key manager 604 that performs the automated access token key management procedures described herein. NRF100 may also include an access token public key database 606 containing public keys used to validate service requests. As described above, NRF100 may hold different public keys associated with different service access levels. NRF100 may also include a secure element 608 that stores private keys 610 corresponding to the public keys in the public key database 606. As described above, in the public key infrastructure, pairs of public and private keys are used to sign and verify access tokens. An access token signed with a private key can only be verified using the corresponding public key. When an access token is verified using a public key, the producer NF verifying the access token knows that the access token was signed using a private key held by the NRF. In such cases, Producer NF grants access to protected resources, which are services provided by Producer NF in the 5G network. If the public key has been updated using the procedures described herein and the attacker presents an access token signed with the private key corresponding to the revoked public key, access to the protected resources will be denied.

[0061] Figure 7 is a flowchart illustrating an exemplary process for automated access token public key management. Referring to Figure 7, in step 700, the process includes maintaining a network access token key database containing at least one public key for validating network access tokens. For example, NRF100 may maintain the access token public key database 606 in memory 602. The public keys may correspond to producer NF, PLMN, network slice, or other service access levels.

[0062] In step 702, the process includes providing the Producer NF with a Network Access Token Public Key Status Notification Subscription Interface to enable the Producer NF to subscribe to receiving notifications of updates to the status of the public key associated with the Network Access Token. For example, NRF100 may provide an API that enables the Producer NF to subscribe to receiving notifications of changes in the status of the access token public key.

[0063] In step 704, the process includes receiving a request from the producer NF via the network access token public key status notification subscription interface to receive notification of updates to the public key status, and creating a subscription. For example, NRF100 may receive an access token public key subscription request from the producer NF and create or update a record in the local database to indicate that it will notify the producer NF if a change occurs in the status of the access token public key.

[0064] In step 706, the process includes determining that a change or update of the public key's status is necessary. For example, NRF100 may detect that a key or access token signed using the private key corresponding to the public key has been compromised. In an alternative scenario, NRF100 may automatically renew or revoke the access token public key after its expiration.

[0065] In step 708, the process includes updating the status of the public key. Updating the status of the public key may include renewing the public key or revoking the public key. Renewing the public key may simply include sending a renewal message to the producer NF indicating that the public key currently in use is still valid. Revoking the public key may include sending a message to the producer NF indicating that the public key is no longer valid and replacing the old key with a new one.

[0066] When the status is updated in the database maintained by the NRF, control proceeds to step 710, in which the NRF identifies from the subscriptions that the producer NF will subscribe to receive updates and status notifications. In step 712, the NRF notifies the consumer NF.

[0067] The benefits of the subject matter described herein include avoiding manual key management of access token public keys in the NRF. The subject matter described herein enables automatic renewal of NRF access token public keys in the producer NF without the need for manual intervention and without impact on the service. The NRF can use various key pairs at the PLMN level, slice level, NF type level, service level, or other service access level for signing access tokens. This provides further security enhancements to the management of NRF access token public keys. The subscription service described herein can be used as a value-added security feature by any 5G NF, including PCF, Binding Support Function (BSF), NSSF, NEF, UDM, AUSF, or UDR. Alternatively, the subscription service may be used by the SCP instead of the producer NF.

[0068] Each of the following references is incorporated herein by reference in its entirety. References

[0069] [Table 1]

[0070] It will be understood that various details of the subject matter disclosed herein may be modified without deviating from the scope of the subject matter disclosed herein. Furthermore, the above description is for illustrative purposes only and not intended to be limiting.

Claims

1. A method for automated key management of network access token public keys for 5G Core (5GC) authorization to mitigate security attacks, In a Network Function (NF) repository function (NRF) including at least one processor and memory, The steps include: maintaining in memory a network access token public key database containing at least one public key for use by the producer NF when validating a network access token presented in response to a service request from a consumer NF; The steps include providing the producer NF with a network access token public key status notification subscription interface to enable the producer NF to subscribe to receiving notifications of status updates for at least one public key, The steps include receiving a request from a producer NF that should be notified of an update in the status of at least one public key via the network access token public key status notification subscription interface, and creating a subscription for the producer NF in response to the request, The steps include determining that the status of at least one of the public keys needs to be updated, In response to the determination that the status of at least one of the public keys needs to be updated, The steps include updating the status of the at least one public key, The steps include identifying from the subscription that the producer NF subscribes to receive notifications of status updates for the at least one public key, A method comprising the step of notifying the producer NF of the update of the status of the at least one public key.

2. The method according to claim 1, wherein the step of maintaining the network access token public key database includes the step of maintaining a plurality of public keys in the network access token public key database, and at least some of the plurality of public keys are associated with different service access levels.

3. The various service access levels mentioned above are Public Land Mobile Networks (PLMNs). The method according to claim 2, comprising a Land Mobile Network service level, network slice level, NF type level, and service level.

4. The method according to claim 3, wherein the at least one public key is associated with one of the service access levels, and the step of updating the status of the at least one public key includes the step of revoking the public key in one of the service access levels.

5. The method according to any one of claims 1 to 4, wherein the step of providing the public key status notification subscription interface includes the step of providing an interface for receiving subscription requests from the producer NF, the subscription request may include service access level identification information and a request for an immediate key.

6. The method according to claim 5, wherein the subscription request includes the request for an immediate key, and further comprises the step of communicating a public key to the producer NF in response to the subscription request.

7. The method according to any one of claims 1 to 6, wherein the step of creating the subscription includes creating or updating a record in the database for considering the NF as a subscriber to the update of the status of the at least one public key.

8. The method according to any one of claims 1 to 7, wherein the step of determining that the status of the at least one public key needs to be updated includes determining that at least one network access token signed using the at least one private key corresponding to the at least one public key has been compromised, and the step of updating the status of the at least one public key includes revoking the at least one public key.

9. The method according to any one of claims 1 to 8, wherein the step of determining that a change in the status of the at least one public key is necessary includes the step of determining that the at least one public key is necessary to be revoked in response to the expiration of a configurable period, and the step of updating the status of the at least one public key includes the step of revoking the at least one public key.

10. In the aforementioned producer NF, The step further comprises receiving a notification of an update to the status of the at least one public key, wherein the notification of the update to the status includes at least one replacement public key for the at least one public key. The further step is to receive a service request from a consumer NF, wherein the service request includes a network access token. The steps include attempting to validate the service request using the aforementioned at least one replacement public key, The step of determining that the aforementioned effectiveness verification fails, The method according to any one of claims 1 to 9, further comprising the step of preventing the consumer NF from accessing the service specified in the service request.

11. A system for automated key management of network access token public keys for 5G cores (5GC) to mitigate security attacks, A network function (NF) repository function (NRF) including at least one processor and memory, A network access token public key database located in the aforementioned memory, which includes at least one public key for use by the producer NF when validating a network access token presented in response to a service request from a consumer NF, The system includes an automated access token key manager implemented by at least one processor to hold the network access token public key database, The aforementioned automatic access token key manager The Producer NF is provided with a Network Access Token Public Key Status Notification Subscription Interface to enable the Producer NF to subscribe to receiving notifications of status updates for at least one public key. A request is received from a producer NF via the network access token public key status notification subscription interface, which should be notified of an update in the status of at least one public key, and in response, a subscription is created for the producer NF. A system configured to determine that the status of at least one public key needs to be updated, to update the status of at least one public key in response to the determination that the status of at least one public key needs to be updated, to identify from the subscription that the producer NF subscribes to receive notifications of the status update of at least one public key, and to notify the producer NF of the update of the status of at least one public key.

12. The system according to claim 11, wherein the automatic access token key manager is configured to hold a plurality of public keys in the network access token public key database, and at least some of the plurality of public keys are associated with different service access levels.

13. The system according to claim 12, wherein the various service access levels include public land mobile network (PLMN) levels, network slice levels, NF type levels, and service levels.

14. The system according to claim 12 or 13, wherein the at least one public key is associated with one of the service access levels, and the automatic access token key manager is configured to update the status of the at least one public key by revoking the public key for one of the service access levels.

15. The system according to any one of claims 11 to 14, wherein the subscription interface is configured to receive subscription requests from the producer NF, and the subscription request may include service access level identification information and a request for an immediate key.

16. The system according to claim 15, wherein the subscription request includes the request for an immediate key, and in response thereto, the automatic access token key manager is configured to communicate a public key to the producer NF in response to the subscription request.

17. The system according to any one of claims 11 to 16, wherein, when creating the subscription, the automated access token key manager is configured to create or update a record in the database for considering the producer NF as a subscriber to the update of the status of the at least one public key.

18. The system according to any one of claims 11 to 17, wherein the automated access token key manager is configured to determine, in response to a determination that at least one network access token signed using at least one private key corresponding to the at least one public key has been compromised, that the status of the at least one public key needs to be updated, and to update the status of the at least one public key by revoking the at least one public key.

19. The system according to any one of claims 11 to 18, wherein the automatic access token key manager is configured to determine that an update of the status of the at least one public key is necessary in response to the expiration of a configurable period, and to update the status of the at least one public key by revoking the at least one public key.

20. A program for causing a computer to perform the method according to any one of claims 1 to 10.

Images