Method, system, and computer-readable medium for integrity protection of subscribe / notify and discover messages between a network function (NF) and an NF repository function (NRF) - Patents.com

Abstract

A method for integrity protection of subscribe / notify and NF discovery transactions between an NF and an NRF includes receiving a subscribe or discovery request message from the NF, determining that the subscribe or discovery request message includes at least one indicator requesting integrity protection of NRF communications, calculating an integrity check value of at least a portion of the subscribe or discovery request message, and comparing the calculated integrity check value to the integrity check value included in the subscribe or discovery request message. The method further includes determining that the calculated integrity check value matches the integrity check value included in the subscribe or discovery request message, forming a response to the subscribe or discovery request message, generating and adding at least one digital signature to the response message, and transmitting the response message to the NF.

Description

[Technical field]

[0001] Claiming priority This application claims the benefit of priority to U.S. patent application Ser. No. 17 / 702,762, filed March 23, 2022, the disclosure of which is incorporated herein by reference in its entirety.

[0002] Technical Field The subject matter described herein relates to integrity protection in 5G and other communication networks. More particularly, the subject matter described herein relates to methods, systems, and computer-readable media for integrity protection of subscribe / notify and discover messages between NFs and NRFs. [Background technology]

[0003] background In a 5G communication network, a network function that provides a service is called a producer 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 can be a producer NF, a consumer NF, or both, depending on whether the network function consumes, generates, or consumes and generates a service. The terms "producer NF" and "NF service producer" are used interchangeably herein. Similarly, the terms "consumer NF" and "NF service consumer" are used interchangeably herein.

[0004] A particular producer NF may have many service endpoints, which are contact points 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 on the network node hosting the producer NF, or a fully qualified domain name (FQDN) that resolves to an IP address and port number. An NF instance is an instance of a producer NF that provides a service. A particular 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] NFs are registered with a network function repository function (NRF). The NRF maintains profiles of available NF instances that identify the services supported by each NF instance. The profiles of NF instances are called NF profiles in 3GPP TS 29.510. An NF instance can obtain information about other NF instances registered with the NRF via an NF discovery service operation. According to the NF discovery service operation, a consumer NF sends an NF discovery request to the NRF. The NF discovery request includes query parameters that the NRF uses to find NF profiles of producer NFs that can provide the service identified by the query parameters. An NF profile is a data structure that defines contact and capability information about an NF instance in addition to the type of services provided by the NF instance.

[0006] A service communication proxy (SCP) can also invoke NF discovery service operations to learn about available producer NF instances. The case where an SCP uses NF service discovery procedures to obtain information about producer NF instances on behalf of a consumer NF is called delegated discovery. Consumer NFs contact 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 forwarding traffic between producer and consumer NFs is the security edge protection proxy (SEPP). A SEPP is a network function used to protect the control plane traffic exchanged between different 5G public land mobile networks (PLMNs). As such, a SEPP performs message filtering, policing, and topology hiding for all application programming interface (API) messages sent between PLMNs.

[0008] One problem that may arise in 5G and other communication networks is that a hacker can access communications between the NRF and the NF and manipulate parameters in discovery response and notification messages to disrupt the communications. Hackers can also access discovery and subscription requests and manipulate parameters in the requests. The 3GPP standards provide mechanisms for authentication between communicating entities. However, existing authentication mechanisms do not prevent eavesdropping and modification of communications between entities that have authenticated each other.

[0009] In view of these and other challenges, therefore, a need exists for a method, system, and computer-readable medium for integrity protection of subscribe / notify and discover messages between NFs and NRFs. Summary of the Invention

[0010] overview A method for integrity protection of subscribe / notify and NF discovery transactions between a network function (NF) and an NF repository function (NRF) includes receiving, at the NRF, a subscribe or discovery request message from the NF. The method further includes determining that the subscribe or discovery request message includes at least one indicator requesting integrity protection of NRF communications. The method further includes, in response to determining that the subscribe or discovery request includes at least one indicator requesting integrity protection of NRF communications, calculating an integrity check value of at least a portion of the subscribe or discovery request and comparing the calculated integrity check value to an integrity check value included in the subscribe or discovery request. The method further includes determining that the calculated integrity check value matches the integrity check value included in the subscribe or discovery request, and in response, forming a response message to the subscribe or discovery request message, generating at least one digital signature, adding the at least one digital signature to the response message, and transmitting the response message to the NF.

[0011] According to another aspect of the subject matter described in this specification, receiving the subscribe or discovery request message includes receiving a NF status subscribe message, forming the response message includes forming a NF status subscribe response message, and generating the at least one digital signature includes digitally signing an integrity check value received in the NF status subscribe message from the consumer NF.

[0012] According to another aspect of the subject matter described herein, a method for integrity protection of subscribe / notify and NF discovery transactions between an NF and an NRF includes detecting an event requiring notification to the NF, generating a notification request message, and including a digital signature of a body of the notification request message in the notification request message.

[0013] According to another aspect of the subject matter described herein, receiving the subscribe or detection request message includes receiving an NF detection request message, forming the response message includes forming an NF detection response message, and generating the at least one digital signature includes generating a first digital signature of an integrity check value received in the NF detection request message and a second digital signature of a body of the NF detection response message.

[0014] According to another aspect of the subject matter described herein, the at least one indicator requesting integrity protection of NRF communications includes a custom vendor_request_signing header having a value indicating that the NF expects a digitally signed response message.

[0015] According to another aspect of the subject matter described herein, the at least one indicator requesting integrity protection of the NRF communication includes a custom vendor_request_hash header containing an integrity check value and an identifier of the integrity check algorithm used to create the integrity check value.

[0016] In accordance with another aspect of the subject matter described herein, the integrity check algorithm includes a hash algorithm.

[0017] According to another aspect of the subject matter described herein, generating the digital signature includes generating the digital signature using a private key of the NRF that the NRF uses for OAuth 2.0 authorization.

[0018] According to another aspect of the subject matter described herein, generating the digital signature includes generating the digital signature using a public key and a private key paired with a public key-private key pair unique to the NF.

[0019] According to another aspect of the subject matter described herein, receiving the subscribe or discovery request message includes receiving the subscribe or discovery request message from a public land mobile network (PLMN) different from the NRF, and generating the at least one digital signature includes generating the at least one digital signature using a private key of a private-public key pair used to secure inter-PLMN communications.

[0020] According to another aspect of the subject matter described herein, a system is provided for integrity protection of subscribe / notify and NF discovery transactions between a Network Function (NF) and an NF Repository Function (NRF), the system including an NRF including at least one processor for receiving subscribe or discovery request messages. The system further includes a subscription / discovery communications integrity protector implemented by at least one processor for: determining that the subscribe or discovery request message includes at least one indicator requesting integrity protection of NRF communications; and, in response to determining that the subscribe or discovery request message includes at least one indicator requesting integrity protection of NRF communications, calculating an integrity check value of at least a portion of the subscribe or discovery request message, comparing the calculated integrity check value with the integrity check value included in the subscribe or discovery request message, determining that the calculated integrity check value matches the integrity check value included in the subscribe or discovery request message, and in response, forming a response message to the subscribe or discovery request message, generating at least one digital signature, adding the at least one digital signature to the response message, and transmitting the response message to the NF.

[0021] According to another aspect of the subject matter described in this specification, the subscribe or detect request message includes a NF status subscribe message, the response message includes a NF status subscribe response message, and the at least one digital signature includes a digital signature of an integrity check value received in the NF status subscribe message from the consumer NF.

[0022] According to another aspect of the subject matter described herein, the NRF is configured to detect an event requiring notification to the NF and generate a notification request message, and the subscription / detection communication integrity protector is configured to include a digital signature of a body of the notification request message in the notification request message.

[0023] According to another aspect of the subject matter described herein, the subscribe or detection request message includes an NF detection request message, the response message includes an NF detection response message, and the at least one digital signature includes a first digital signature of an integrity check value received in the NF detection request message and a second digital signature of a body of the NF detection response message.

[0024] According to another aspect of the subject matter described herein, the at least one indicator requesting integrity protection of NRF communications includes a custom vendor_request_signing header having a value indicating that the NF expects a digitally signed response message.

[0025] According to another aspect of the subject matter described herein, the at least one indicator requesting integrity protection of the NRF communications includes a custom vendor_request_hash header containing an integrity check value and an identifier of the hash algorithm used to create the integrity check value.

[0026] According to another aspect of the subject matter described herein, the subscription / discovery communication integrity protector is configured to generate a digital signature using a private key of the NRF that the NRF uses for OAuth 2.0 authorization.

[0027] According to another aspect of the subject matter described herein, the subscription / detection communication integrity protector is configured to generate a digital signature using a private key paired with a public key of a public key-private key pair specific to the NF.

[0028] According to another aspect of the subject matter described herein, the subscribe or discovery request message originates from a public land mobile network (PLMN) different from the NRF, and the subscription / discovery communications integrity protector is configured to generate at least one digital signature using a private key of a public-private key pair used to protect inter-PLMN communications.

[0029] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium is provided having executable instructions stored thereon that, when executed by a processor of the computer, control the computer to perform steps. The steps are performed at a Network Function (NF) Repository Function (NRF). The steps include receiving a subscribe or discovery request message from an NF. The steps further include determining that the subscribe or discovery request message includes at least one indicator that requests integrity protection of the NRF communications. The steps further include, in response to determining that the subscribe or discovery request message includes at least one indicator that requests integrity protection of the NRF communications, calculating an integrity check value of at least a portion of the subscribe or discovery request message and comparing the calculated integrity check value with an integrity check value included in the subscribe or discovery request message. The steps further include determining that the calculated integrity check value matches the integrity check value included in the subscribe or discovery request message and, in response, forming a response message to the subscribe or discovery request message, generating a digital signature, adding the digital signature to the response, and transmitting the response message to the NF.

[0030] The subject matter described herein may be implemented in software in combination with hardware and / or firmware. For example, the subject matter described herein may be implemented in software executed by a processor. In one exemplary implementation, the subject matter described herein may be implemented using a non-transitory computer-readable medium storing computer-executable instructions that, when executed by a processor of a computer, control a computer to perform steps. Exemplary computer-readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, the computer-readable medium implementing the subject matter described herein may be located in a single device or computing platform or distributed across multiple devices or computing platforms.

[0031] Exemplary implementations of the subject matter described herein will now be described with reference to the accompanying drawings. [Brief description of the drawings]

[0032] [Figure 1] FIG. 1 is a network diagram illustrating an example 5G system network architecture. [Diagram 2] FIG. 1 is a network diagram illustrating a hacker who may access a 5G NF, an NRF, and communications between the 5G NF and the NRF, altering the communications, and disrupting services in the network. [Diagram 3] FIG. 1 is a message flow diagram showing example messages exchanged in a subscription / notification transaction between an NF and an NRF, where integrity protection is used to detect unauthorized modification of the subscription request, subscription response, and subsequent notification request. [Figure 4]FIG. 13 is a message flow diagram showing example messages exchanged in an NF discovery transaction between an NF and an NRF, in which integrity protection is used to detect unauthorized modification of an NF discovery request and / or an NF discovery response. [Diagram 5] FIG. 13 is a message flow diagram illustrating example messages exchanged in an Inter-PLMN NF Discovery Transaction between an NF and an NRF, where integrity protection is used to detect unauthorized modification of the NF Discovery Request and / or NF Discovery Response. [Figure 6] FIG. 1 is a block diagram illustrating an example architecture of an NF and NRF for providing integrity protection in subscription / notification and NF discovery transactions. [Figure 7] 13 is a flowchart illustrating an example process of integrity protection in subscription / notification and NF discovery transactions. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0033] Detailed Description FIG. 1 is a block diagram illustrating an example 5G system network architecture. The architecture of FIG. 1 includes an NRF 100 and an SCP 101, which may be located in the same home public land mobile network (HPLMN). As mentioned above, the NRF 100 may maintain a profile of available NF instances and the services supported by them, and enable consumer NFs or SCPs to subscribe to new / updated NF instances and be notified of their registration. The SCP 101 may support service discovery and selection of NF instances. The SCP 101 may perform load balancing of connections between consumer NFs and producer NFs.

[0034] The NRF 100 is a repository of profiles of NF instances. To communicate with a producer NF instance, a consumer NF or SCP must obtain the NF profile of the producer NF instance from the NRF 100. An NF profile is a JavaScript object notation (JSON) data structure defined in 3GPP TS 29.510. An NF profile contains attributes that indicate the type of service provided, the capabilities of the NF instance, and information for contacting the NF instance.

[0035] In Figure 1, any of the network functions can be a consumer NF, a producer NF, or both, depending on whether the network function is requesting, providing, or requesting and providing a service. In the example shown, the NFs include a policy control function (PCF) 102 that performs policy-related operations within the network, a unified data management (UDM) function 104 that manages user data, and an application function (AF) 106 that provides application services.

[0036] 1 further includes a session management function (SMF) 108 that manages sessions between an access and mobility management function (AMF) 110 and the PCF 102. The AMF 110 performs mobility management operations similar to those performed by a mobility management entity (MME) in a 4G network. An authentication server function (AUSF) 112 performs authentication services for user equipment (UE), such as user equipment (UE) 114, seeking access to the network.

[0037] The network slice selection function (NSSF) 116 provides network slicing services to devices that want to access the capabilities and characteristics of a particular network associated with a network slice. The network exposure function (NEF) 118 provides application programming interfaces (APIs) for application functions that want to obtain information about Internet of things (IoT) devices and other UEs connected to the network. The NEF 118 performs a similar function to the service capability exposure function (SCEF) in 4G networks.

[0038] The radio access network (RAN) 120 connects the user equipment (UE) 114 to the network via wireless links. The radio access network 120 may be accessed using a g-Node B (gNB) (not shown in FIG. 1) or other wireless access points. The user plane function (UPF) 122 may 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 may support a performance measurement function that may be used by the UE 114 to obtain network performance measurements. Also shown in FIG. 1 is a data network (DN) 124 that the UE uses to access data network services, such as Internet services.

[0039] The SEPP 126 filters incoming traffic from another PLMN and performs topology hiding for traffic egressing from the home PLMN. The SEPP 126 may communicate with a SEPP in a foreign PLMN that manages security for the foreign PLMN. Thus, traffic between NFs in different PLMNs may traverse two SEPP functions: a SEPP function for the home PLMN and another SEPP function for the foreign PLMN.

[0040] As previously mentioned, one issue that can arise within 5G and other networks is that a hacker can eavesdrop on service communications between the NRF and the NFs, modify the communications, and disrupt services within the network. One operation that a hacker may be able to access and disrupt is the NFStatusSubscribe service operation, described in section 5.2.2.5 of 3GPP TS 29.510. The NFStatusSubscribe service operation is used to perform the following:

[0041] Creating subscriptions so that NF service consumers can request to be notified when a particular set of NF instances are registered / deregistered / suspended at the NRF according to certain filter criteria or when the profile of an NF instance is changed; and Creating subscriptions to specific NF instances allows NF service consumers to request to be notified when the profile of such NF instance changes or when an NF instance is paused / deregistered from the NRF.

[0042] Another service operation between the NRF and the NF for which it is desirable to provide integrity protection is the NFStatusNotify service operation specified in 3GPP TS 29.510, section 5.2.2.6. The NFStatusNotify service operation notifies each NF service consumer that is already subscribed to receive notifications of registration / deregistration of an NF instance or of changes in the NF profile of a particular NF instance. This notification is sent to the callback URI that each NF service consumer provided during subscription (see the NFStatusSubscribe operation in 3GPP TS 29.510, section 5.2.2.5).

[0043] Yet another service operation between an NRF and an NF for which it may be desirable to provide integrity protection is the NFDiscover service operation, specified in section 5.3.2.2 of 3GPP TS 29.510. The NFDiscover service operation is used to discover the NF profiles (and their associated NF service instances) of NF instances in a set of NF instances, represented by NF profiles that satisfy several input query parameters, currently registered with the NRF.

[0044] 3GPP and IETF provide some authentication and security mechanisms for these and other service operations. For example, the service operations use HTTP or HTTPS. HTTPS uses transport layer security to encrypt the transport layer communication between the endpoints. Physical network security may also be used to protect the network. Complicating factors in protecting the integrity of the communication between the NRF and the NF include the fact that the communication may be direct or through an SCP. In addition, one or more stateless or stateful proxies may be placed between the NF and NRF endpoints.

[0045] Multiple connections between the NRF and NFs may allow a hacker to access the communication between the NRF and NFs. A hacker can use such unauthorized access for subscription / discovery requests to eavesdrop on requests going to the NRF and manipulate parameters in the request. In the case of notifications, a hacker can eavesdrop on notification requests from the NRF and manipulate parameters in the notification body. A hacker can also push fake notifications to consumer NFs. In the case of NF discovery service manipulation, a hacker can eavesdrop on discovery responses from the NRF and manipulate parameters in the discovery response. Since the results of NF discovery and notification are used by NFs to make critical decisions regarding routing, such vulnerabilities may disrupt the normal functioning of 5G core networks. Therefore, it is necessary to enable integrity protection of notification requests and discovery responses from the NRF.

[0046] One existing authentication mechanism is defined in 3GPP TS 33.501, section 13.3.1.2. In indirect communication, the NF and NRF may use one of the following methods for authentication: · Mutual authentication between NF and NRF provided by the transport layer protection solution. · Authentication based on a Client Credentials Assertion (CCA) as specified in Section 13.3.8. NOTE 1: Client credential assertion authentication is based on a CCA token sent by the NF service consumer to the NRF via an intermediate NF such as an SCP. CCA-based authentication does not provide authentication of the NRF towards the NF service consumer, nor protection of the service request sent by the NF service consumer to the NRF. Hop-by-hop security protection at the transport layer, provided by NDS / IP, or physical security; implicit, i.e. by relying on authentication between NF service consumers and SCPs, and between SCPs and NRFs.

[0047] FIG. 2 is a network diagram illustrating a 5G NF, an NRF, and a hacker who may access and modify communications between the 5G NFs and the NRFs, disrupting services in the network. With reference to FIG. 2, the NRF 100 provides management services to 5G NFs, such as the PCF 102, a binding support function (BSF) 200, a unified data register (UDR) 202, and other NFs. A hacker 204 may gain unauthorized access to communications between the NRF 100 and the 5G NFs. For example, the hacker 204 may modify a response message from the NRF 100 to the 5G NF to include invalid data, thereby disrupting services in the network. The hacker 204 may also modify a request message sent from the 5G NF to the NRF 100.

[0048] Considering the deficiencies with existing authentication mechanisms, the subject matter described herein includes a method for an NF service consumer to indicate to an NRF that the consumer NF expects a signed response from the NRF and the NF sends an integrity check value with the request message to the NRF. If access token support is enabled, the NF is required to have a key for the NRF it is serving to perform access token validation. In one example implementation of the subject matter described herein, the same key pair used for signing and validating the CCA may be used for signing and validating the notification request and discovery response. In another example implementation of the subject matter described herein, the NRF may be manually provisioned with a private key or via a public key infrastructure (PKI) in the operator's network, and the consumer NF may be provisioned with the corresponding public key. The NRF and consumer NF may then use the public-private key pair for signing and validating the notification request and discovery response.

[0049] To indicate its desire to participate in the integrity protection mechanism described herein, in the subscription or discovery request, the NF publishes the following additional data:

[0050] A custom header vendor_request_signing with a value set to 1 to indicate to the NRF that the NF is requesting signed notification requests and discovery responses. The NF can update an existing subscription to turn on or off the flow of signed messages by setting this value to 1 or 0, respectively. And A custom header with a vendor_request_hash attribute that specifies a hash value (of the request body for subscription requests, or of the query parameters for NF discovery requests), and a vendor_request_algo attribute that specifies the algorithm for the hashing, for example, SHA256.

[0051] Optionally, if the NRF manages a separate key pair for each NfInstance / NfType / Locality etc. pair, the NF may expose its nfInstance id as "reqNfInstanceId" in SubscriptionData and "requester-nf-instance-id" in the NF discovery request. The nfInstanceId may be used by the NRF to select the appropriate private key for signing messages (if the NRF manages a separate key pair for each NF instance). For subscription requests, when the NRF receives a request containing a vendor_request_hash header, the NRF calculates a hash value of the request body of the subscription request using the algorithm identified by the vendor_request_algo header. The NRF checks this hash value against the value in the vendor_request_hash header. If the hash value in the vendor_request_hash header does not match the hash value calculated by the NRF, the NRF rejects the request. Otherwise, the NRF processes the request. If the hash value in the vendor_request_hash header matches the hash value calculated by the NRF, the NRF adds a custom header vendor_signed_request (containing the signed value of the hash value received in the vendor_request_hash header from the subscription request) to the subscription response. For notification requests going to NFs that have requested signed messages from the NRF, the NRF signs each message by generating a hash value of the notification request body and digitally signing the hash value. The NRF exposes the digital signature as a JWS value using the custom header vendor_signed_body.

[0052] For an NF discovery request, when the NRF receives a request that includes a vendor_request_hash header, the NRF calculates a hash value of the discovery request's query parameters using the algorithm identified by the vendor_request_algo header. The NRF compares the NRF-calculated hash value to the hash value in the vendor_request_hash header. If the NRF-calculated hash value does not match the hash value in the vendor_request_hash header, the NRF rejects the request. If the NRF-calculated hash value matches the hash value in the vendor_request_hash header, the NRF processes the request, adds a custom header vendor_signed_request (containing the signed value of the hash value received in the vendor_request_hash header from the discovery request) to the discovery response, generates a hash value of the discovery response body, digitally signs the hash value, encodes the signature as a JSON web signature (JWS), and publishes the resulting JWS value using a custom header vendor_signed_body.

[0053] In the case of a subscription response, the consumer NF validates the response by reading the JWS value from the vendor_signed_request custom header. The consumer NF validates the signature using the public key of the NRF, which in one example is the same public key used to validate the OAuth 2.0 access token in the service request. Validating the digital signature involves decrypting the signed hash value using the public key provided by the NRF and verifying that the unsigned hash value is the same as the value that the consumer NF inserted in the vendor_request_hash header in the subscription request message. If the subscription response validation fails, the consumer NF may resubscribe, for example using an alternative NRF. If the subscription response validation is successful, the consumer NF processes the response.

[0054] For a notification request, the consumer NF performs validation by reading the JWS value from the vendor_signed_body custom header and validating the signature using the NRF's public key, which in one example is the same key used to validate the OAuth 2.0 access token in the service request message. Validating the JWS value includes decrypting the signed hash value, computing the hash of the notification request message body, and determining whether the decrypted or unsigned hash value is the same as the hash of the notification request message body. If the validation fails, the consumer NF rejects the notification request with error code 401. If the hash values ​​match, the NF processes the notification response and adds the notification data to the runtime content.

[0055] For the discovery response validation, the consumer NF reads the JWS value from the vendor_signed_request custom header and verifies the validity of the signature using the NRF's public key, which in one example is the same key used to validate the OAuth 2.0 access token in the service request. The consumer NF verifies the validity that the decrypted or unsigned hash value in the discovery response message is the same hash value that the consumer NF inserted in the vendor_request_hash header in the discovery request. The consumer NF also verifies the validity of the NF discovery request message body by reading the JWS value from the vendor_signed_body custom header and verifies the validity of the signature using the NRF's public key, which in one example is the same key used to validate the OAuth 2.0 access token in the service request. The consumer NF verifies the validity of the discovery response message body by computing a hash of the discovery response message body and comparing the computed hash with the unsigned or decrypted hash value from the JWS payload. If the hashes do not match, the validation fails and the consumer NF may resend the discovery request, for example to an alternative NRF. If the validation passes, the consumer NF processes the NF discovery response, extracts the NF profile, and uses the NF profile to select a producer NF to provide the service required by the consumer NF.

[0056] FIG. 3 is a message flow diagram illustrating exemplary messages exchanged in a subscription / notification transaction between an NF and an NRF, where integrity protection is used to detect unauthorized modification of the subscription request, subscription response, and subsequent notification requests. Referring to FIG. 3, at line 1, the consumer NF 300 sends a subscription request including a vendor_request_signing header set to 1, and a vendor_request_hash header containing a hash of the subscription request message body and indicating the hash algorithm used to create the hash value. The subscription request may optionally include the NF instance ID of the consumer NF 300 in the requesting NF instance ID attribute in the subscription data. The NRF 100 receives the subscription request, calculates a hash of the subscription request message body using the hash algorithm specified in the vendor request algorithm attribute of the vendor_request_hash header, and compares the calculated hash with the hash value in the vendor_request_hash header. In this example, it is assumed that the hashes match. At line 2, the NRF 100 sends a subscription response to the consumer NF 300. In the subscription response, the NRF 100 includes a vendor_signed_request header that contains a digitally signed value of the hash value in the vendor_request_hash header received in the subscription request. The consumer NF 300 receives the subscription response message, reads the digital signature from the vendor_signed_request header, decrypts the signed value using the NRF's public key, and verifies the validity of the signature by verifying that the hash value included in the subscription response message is the same as the hash value that the consumer NF 300 included in the vendor_request_hash header of the discovery request message.In this example, it is assumed that the subscription response message is valid.

[0057] At line 3 of the message flow diagram, the NRF 100 detects an event that triggers a notification according to parameters specified in the subscription created by the subscription request at line 1. In response to detecting the event, the NRF 100 generates a signed notification response message using the private key used by the NRF to generate the OAuth 2.0 authorization token. At line 4, the NRF 100 sends a notification request that includes a digitally signed hash of the notification request message body carried in the vendor_signed_body header. The consumer NF 300 receives the notification request, decrypts the signed hash value carried in the vendor_signed_body header, calculates the hash of the notification request message body, and compares the unsigned hash or the decrypted hash from the vendor_signed_body header with the calculated hash value. If the values ​​match, the validity of the notification request is confirmed and the consumer NF 300 processes the notification data in the notification request message body. If the validation fails, the consumer NF 300 may reject the notification request and attempt to create the subscription using the same NRF instance or an alternative NRF instance.

[0058] FIG. 4 is a message flow diagram illustrating exemplary messages exchanged in an NF discovery transaction between an NF and an NRF, where integrity protection is used to detect unauthorized modification of an NF discovery request and / or an NF discovery response. With reference to FIG. 4, at line 1, the consumer NF 300 sends an NF discovery request including a vendor_request_signing header set to 1 and a vendor_request_hash header that includes a hash of the query parameters in the discovery request message and indicates the hash algorithm used to create the hash value. The NF discovery request may optionally include the NF instance ID of the consumer NF 300 in a requesting NF instance ID attribute in the discovery parameters. The NRF 100 receives the NF discovery request, calculates a hash of the query parameters using the hash algorithm specified in the vendor request algorithm attribute of the vendor_request_hash header, and compares the calculated hash with the hash value in the vendor_request_hash header. In this example, it is assumed that the hashes match. At line 2, the NRF 100 sends an NF discovery response to the consumer NF 300. In the NF discovery response, the NRF 100 includes a vendor_signed_request header, which contains a digitally signed value of the vendor_request_hash header received in the NF discovery request, and a vendor_signed_body header that carries a hash of the discovery response message body. The consumer NF 300 receives the NF discovery response message, reads the digital signature from the vendor_signed_request header, reads the digital signature from the vendor_signed_body header, and verifies the validity of both signatures using the NRF's public key.Verifying the validity of the digital signature in the vendor_signed_request header includes decrypting the hash value in the vendor_signed_request header using a public key, and comparing the decrypted or unsigned hash value with the hash value that the consumer NF 300 inserted in the discovery request message. Verifying the validity of the digital signature in the vendor_signed_body header includes decrypting the hash value in the vendor_signed_body header using the public key of the NRF, computing a hash of the discovery response message body, and comparing the decrypted or unsigned hash value with the computed hash value. In this example, it is assumed that the NF discovery response message is valid. If any digital signature validation fails, the consumer NF 300 rejects the NF discovery response and retries NF discovery using the same NRF or an alternative NRF.

[0059] In one example of the subject matter described herein, the NRF may sign discovery response messages and subscription response messages using the same procedures for signing as specified in section 5.4.2.2 of 3GPP TS 29.510 and IETF RFC 7515. According to section 5.4.2.2, the NRF acts as an OAuth 2.0 authorization server that provides signed OAuth 2.0 access tokens to NF service consumers. The access tokens are JSON web tokens (JWTs) as specified in IETF RFC 7519. The NRF digitally signs the access tokens as specified in IETF RFC 7515.

[0060] In one implementation of the subject matter described herein, the NRF uses the same private key and algorithm that is used to sign the access tokens of each NF as the service provider. As defined by IETF RFC 7515, A JWS is a digital signature created using the following logical values: JOSE headers (i.e. protected headers) such as: "typ" set to "TEXT" "alg" defined by the operator (for NRF access tokens) JWS Payload (as mentioned above) JWS Signature The NRF MAY sign the notification and discovery responses using the same algorithm and private key used by the NRF to create the JWS signature of the NF's access token. JWS Compact Serialization: ·BASE64URL(UTF8(JWS Protected Header)) || '.'|| ·BASE64URL(JWS Payload) || '.'|| BASE64URL(JWS Signature) According to another aspect of the subject matter described herein, the NRF may provide integrity protection for subscription and notification responses sent from the NRF to consumer NFs in different PLMNs. In accordance with section 5.2.2.6.3 of 3GPP TS 29.510, notifications from the home NRF are delivered directly to the consumer NFs in the serving PLMN. Unless a mutual authentication process has been established between the two PLMNs (by the mechanisms described in 3GPP TS 33.310), the consumer NF in the serving PLMN may not request a signed notification request from the NRF between PLMNs. If a mutual authentication process has been established between the two PLMNs, the consumer NF (in the serving PLMN) may follow the same procedure as the local NRF for subscription and validation of notification requests. In the inter-PLMN case, the consumer NF does not need to provide the reqNfInstanceId in the SubscriptionData as described above. However, in accordance with the 3GPP standard, in the case of inter-PLMN subscriptions, the NF must provide the reqPlmnList in the SubscriptionData. The NRF may use the agreed upon private key to sign notification requests for specific PLMNs identified from the reqPlmnList parameter in the subscription request.

[0061] FIG. 5 is a message flow diagram illustrating exemplary messages exchanged in an inter-PLMN NF discovery transaction between an NF and an NRF, where integrity protection is used to detect unauthorized modification of the NF discovery request and / or the NF discovery response. Referring to FIG. 5, at line 1, if signed NF discovery is supported by the local NRF, the consumer NF 300 sends an NF discovery request including a vendor_request_signing header set to 1 and a vendor_request_hash header that includes a digitally signed hash of the query parameters and indicates the hash algorithm used to create the hash value. The NF discovery request may optionally include the NF instance ID of the consumer NF 300 in a requesting NF instance ID attribute in the discovery parameters. The NRF 100A receives the NF discovery request, calculates a hash of the query parameters using the hash algorithm specified in the vendor request algorithm attribute of the vendor_request_hash header, decrypts the hash value of the vendor_request_hash value, and compares the calculated hash to the hash value decoded from the vendor_request_hash header. In this example, it is assumed that the hashes match. NRF 100A determines that the NF discovery request needs to be forwarded to NRF 100B in another PLMN. NRF 100A also determines that inter-PLMN authentication is supported by NRF 100B's network. In this example, it is assumed that NRF 100B's PLMN supports inter-PLMN authentication and forms and sends an NF discovery request to NRF 100B requesting a signed discovery response, line 2, regardless of whether the consumer NF requested a signed discovery response. The NF discovery request includes a vendor_request_signing header and a vendor_request_hash header that contains a hash of the query parameters signed using the private key of a private-public key pair used by NRF 100B's PLMN to verify the validity of the inter-PLMN discovery request.The NRF 100B validates the digital signature in the inter-PLMN discovery request, and in line 3, the NRF 100B sends a signed NF discovery response to the NRF 100A. The NF discovery response includes a vendor_signed_request header carrying a digitally signed hash received in the NF discovery request, and a vendor_signed_body header carrying a hash of the message body of the discovery response message. The NRF 100A validates the digital signature in the NF discovery response using a public key corresponding to the private key used for the inter-PLMN validation, and in line 4, generates and sends an NF discovery response to the consumer NF 300. In the NF discovery response, the NRF 100A includes a vendor_signed_request header, which includes a vendor_signed_body header carrying the digitally signed value of the vendor_request_hash header received in the NF discovery request, and the digitally signed value of the NF discovery response message body. The consumer NF 300 receives the NF discovery response message, reads the digital signature, and verifies the validity of the digital signature using the public key of the local NRF. In this example, it is assumed that the validity of the NF discovery response message is verified. If any validation of the digital signature fails, the consumer NF 300 rejects the NF discovery response and retries NF discovery using the same NRF or an alternative NRF.

[0062] FIG. 6 is a block diagram illustrating an example architecture of an NF and an NRF for providing integrity protection in subscription / notification and NF discovery transactions. Referring to FIG. 6, the NF 300 includes at least one processor 600 and a memory 602. The NF 300 further includes a subscription / discovery request generator / response verifier 604 implemented by the processor 600 to perform the NF functions described herein for requesting and enforcing integrity protection communicating with the NRF. These functions include requesting signed notification and discovery responses, generating signed hashes of portions of NF discovery request messages and subscription request messages, and verifying the validity of digital signatures in subscription responses, NF discovery responses, and notification request messages.

[0063] The NRF 100 includes at least one processor 606 and a memory 608. The NRF 100 further includes a subscription / discovery communications integrity protector 610 implemented by the processor 606 to perform NRF-side functions described herein for protecting the integrity of communications with an NF. Such functions include receiving a subscribe or discovery request message from an NF and determining that the subscribe or discovery request message includes at least one indicator for integrity protection of NRF communications. In response to determining that the subscribe or discovery request includes at least one indicator for integrity protection of NRF communications, the subscription / discovery communications integrity protector 610 calculates an integrity check value of at least a portion of the subscribe or discovery request message and compares the calculated integrity check value to an integrity check value included in the subscribe or discovery request message. If the subscription / discovery communications integrity protector 610 determines that the calculated integrity check value matches the integrity check value included in the subscribe or discover request message, the subscription / discovery communications integrity protector forms a response message to the subscribe or discover request message, generates at least one digital signature, adds the digital signature to the response message, and sends the response message to the NF. In one example, the integrity check value includes a hash value created using a hash function.

[0064] 7 is a flow chart illustrating an example process of integrity protection for subscribe / notify and NF discovery transactions between an NF and an NRF. With reference to FIG. 7, in step 700, the process includes receiving a subscribe or discovery request message from an NF. For example, the NRF 100 may receive an NF status subscribe request or an NF discovery request from a consumer NF or SCP.

[0065] At step 702, the process includes determining that the subscribe or discovery request includes at least one indicator that requests integrity protection of NRF communications. For example, the NRF 100 may determine that the NF discovery request or NF status subscribe message includes a vendor_request_signing custom header and a vendor_request_hash custom header.

[0066] In step 704, the process includes, in response to determining that the subscribe or discovery request message includes at least one indicator requesting integrity protection of NRF communications, calculating an integrity check value of at least a portion of the subscribe or discovery request message and comparing the calculated integrity check value to the integrity check value included in the subscribe or discovery request message. For example, in the case of a NF status subscribe message, the NRF 100 may calculate a hash of the message body and compare this hash to the hash in the vendor_request_hash custom header. In the case of a NF discovery request message, the NRF 100 may calculate a hash of the query parameters in the NF discovery request message and compare this hash to the hash included in the vendor_request_hash custom header.

[0067] In step 706, the process includes determining that the calculated integrity check value matches the integrity check value included in the subscribe or discover request message, forming a response to the subscribe or discover request message accordingly, generating at least one digital signature, adding the at least one digital signature to the response message, and sending the response message to the NF. If the response is a subscription response, the NRF may generate a vendor_signed_request header including a digital signature of a hash from the subscription request and send the response to the consumer NF. If the response is an NF discovery response, the NRF may generate a vendor_signed_request header including a digital signature of a hash from the NF discovery request and a vendor_signed_body header including a digital signature of a hash of the NF discovery response body.

[0068] In step 708, the process includes digitally signing subsequent notification requests sent to the NF if a signed response was requested by the consumer NF. For example, for each notification request sent to a consumer NF that requested a signed response, the NRF 100 may digitally sign a hash of the notification request message body and include the digital signature in a vendor_signed_body header sent with the notification request message to the consumer NF.

[0069] Below we show why the integrity protection measures described herein reduce the likelihood of successful attacks on communications between the NRF and the NF. 1. If a hacker / proxy tries to modify the subscriptionData (in case of subscription request) or discovery parameters (in case of discovery request), the consumer NF can detect such modification by comparing the signed vendor_request_hash that is republished by the NRF in the subscription response or discovery response. 2. If a hacker / proxy tries to change the content of any of the notification / discovery data from the NRF, the hash value of the response message body will change, and therefore the validation of the digital signature of the hash of the message body will fail at the consumer NF. 3. If a hacker / proxy tries to generate a fake notification request destined for an NF, the hacker / proxy cannot generate a valid signed notification request without the private key of the real NRF. Thus, the hacker cannot apply the fake notification in an NF that supports the integrity protection mechanism described herein.

[0070] Exemplary features / advantages of the subject matter described herein include the following. The subject matter described herein provides integrity protection of subscription requests, discovery requests, notification requests, and discovery responses between the NRF and consumer NFs. Thus, the subject matter described herein acts as a defense against any kind of intrusion into the flow of requests and responses between the NFs and the NRFs. The subject matter described herein may be extended to apply to registration and access token request / response flows between the NF and the NRF. If a mutual authentication process has been established between two PLMNs, the subject matter described herein also works for signing notification requests and discovery responses between PLMNs. The NRF generates signed notification requests or discovery responses only for NFs that requested signed responses in their subscription or discovery requests. As a result, the behavior of the NRF remains unchanged unless a consumer NF explicitly requests signed notification requests and discovery responses. · NFs explicitly control support for requesting signed messages from the NRF, so network operators can choose to selectively enable or disable support for signed messages from the NRF on a per-NF basis.

[0071] If the NRF manages separate key pairs per NfInstance / NfType / Locality etc., then the subject matter described herein works with NFs that are registered with the NRF. If an endpoint attempts to subscribe without being registered with the NRF, the NRF cannot determine the private key used to sign notifications going to such endpoint. Thus, an NF that does not have a profile registered with the NRF cannot request a signed message flow from the NRF.

[0072] An NF may be configured to request signed message flows only if the network operator has configured all NRFs (in the home PLMN) to support the integrity protection features described herein. Otherwise, if a particular NRF does not support signing, all notification requests or discovery responses generated by this NRF will be rejected by the NF, which performs validation of signed flows from the NRF.

[0073] The disclosure of each of the following references is incorporated herein by reference in its entirety.

[0074] References 1. 3 rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security architecture and procedures for the 5G system (Release 17) 3GPP TS 33.501 V17.4.2 (2022-01) twenty three rdGeneration Partnership Project; Technical Specification Group Services and System Aspects; Network Domain Security (NDS); Authentication Framework (AF) (Release 17) 3GPP TS 33.310 V17.1.0 (2021-12) 3.3 rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 17) 3GPP TS 29.510 V17.4.0 (2021-12) 4. Hardt, D., The OAuth 2.0 Authorization Framework, IETF RFC 6749 (October 2012) 5. Jones et al., JSON Web Signature (JWS) IETF RFC 7515 (May 2015) 6. Jones et al., JSON Web Token (JWT), IETF RFC 7519 (May 2015) It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Moreover, the foregoing description is for purposes of illustration only, and not for purposes of limitation, as the subject matter described herein is defined by the claims set forth below.

Claims

1. 1. A method for integrity protection of subscribe / notify and NF discover transactions between a Network Function (NF) and an NF Repository Function (NRF), the method comprising: In the NRF, receiving a subscribe or detect request message from the NF; determining that the subscribe or detect request message includes at least one indicator requesting integrity protection of NRF communications; In response to determining that the subscribe or detect request message includes the at least one indicator requiring integrity protection of NRF communications, calculating an integrity check value for at least a portion of the subscribe or detect request message and comparing the calculated integrity check value with an integrity check value included in the subscribe or detect request message; determining that the calculated integrity check value matches the integrity check value included in the subscribe or detect request, and accordingly forming a response message to the subscribe or detect request message, generating at least one digital signature, adding the at least one digital signature to the response message, and sending the response message to the NF; A method comprising:

2. 2. The method of claim 1, wherein receiving the subscribe or detect request message includes receiving an NF state subscribe message, forming the response message includes forming an NF state subscribe response message, and generating the at least one digital signature includes digitally signing the integrity check value included in the NF state subscribe message from a consumer NF.

3. 3. The method of claim 1, comprising: detecting, at the NRF, an event requiring notification to the NF; generating a notification request message; and including a digital signature of a body of the notification request message in the notification request message.

4. 3. The method of claim 1 or 2, wherein receiving the subscribe or detection request message includes receiving an NF detection request message, forming the response message includes forming an NF detection response message, and generating the at least one digital signature includes generating a first digital signature of the integrity check value included in the NF detection request message from a consumer NF and a second digital signature of a body of the NF detection response message.

5. 3. The method of claim 1, wherein the at least one indicator requesting integrity protection of NRF communications includes a custom vendor_request_signing header having a value indicating that the NF expects a digitally signed response message.

6. 3. The method of claim 1, wherein the at least one indicator requesting integrity protection of NRF communications includes a custom vendor_request_hash header containing the integrity check value and an identifier of an integrity check algorithm used to create the integrity check value.

7. The method of claim 6 , wherein the integrity check algorithm comprises a hash algorithm.

8. The method of claim 1 or 2, wherein generating the at least one digital signature includes generating the digital signature using a private key of the NRF that the NRF uses for OAuth 2.0 authorization.

9. 3. The method of claim 1, wherein generating the at least one digital signature comprises generating the digital signature using a private key paired with a public key of a public-private key pair unique to the NF.

10. 3. The method of claim 1, wherein receiving the subscribe or discovery request message includes receiving the subscribe or discovery request from a public land mobile network (PLMN) different from the NRF, and generating the at least one digital signature includes generating the at least one digital signature using a private key of a private-public key pair used to secure inter-PLMN communications.

11. 1. A system for integrity protection of subscribe / notify and NF discover transactions between a Network Function (NF) and an NF Repository Function (NRF), the system comprising: an NRF including at least one processor for receiving subscribe or detection request messages; and a subscription / detection communication integrity protector implemented by the at least one processor for: determining that the subscribe or detection request message includes at least one indicator requesting integrity protection of NRF communications; calculating an integrity check value for at least a portion of the subscribe or detection request message in response to determining that the subscribe or detection request message includes the at least one indicator requesting integrity protection of NRF communications; comparing the calculated integrity check value with an integrity check value included in the subscribe or detection request message; determining that the calculated integrity check value matches the integrity check value included in the subscribe or detection request message; and in response, forming a response message to the subscribe or detection request message; generating at least one digital signature; adding the at least one digital signature to the response message; and transmitting the response message to the NF.

12. 12. The system of claim 11, wherein the subscribe or detect request message includes an NF state subscribe message, the response message includes an NF state subscribe response message, and the at least one digital signature includes a digital signature of the integrity check value included in the NF state subscribe message from a consumer NF.

13. 13. The system of claim 11 or 12, wherein the NRF is configured to detect an event requiring notification to the NF and generate a notification request message, and the subscription / detection communication integrity protector is configured to include a digital signature of a body of the notification request message in the notification request message.

14. 13. The system of claim 11 or 12, wherein the subscribe or detection request message includes an NF detection request message, the response message includes an NF detection response message, and the at least one digital signature includes a first digital signature of the integrity check value included in the NF detection request message from a consumer NF and a second digital signature of a body of the NF detection response message.

15. 13. The system of claim 11 or 12, wherein the at least one indicator requiring integrity protection of NRF communications includes a custom vendor_request_signing header having a value indicating that the NF expects a digitally signed response message.

16. 13. The system of claim 11 or 12, wherein the at least one indicator requesting integrity protection of NRF communications includes a custom vendor_request_hash header containing the integrity check value and an identifier of the hash algorithm used to create the integrity check value.

17. 13. The system of claim 11 or 12, wherein the subscription / discovery communication integrity protector is configured to generate the at least one digital signature using a private key of the NRF that the NRF uses for OAuth 2.0 authorization.

18. 13. The system of claim 11 or 12, wherein the subscription / detection communication integrity protector is configured to generate the at least one digital signature using a private key paired with a public key of a public-private key pair unique to the NF.

19. 13. The system of claim 11 or 12, wherein the subscribe or discover request message originates from a different public land mobile network (PLMN) than the NRF, and the subscription / discovery communication integrity protector is configured to generate the at least one digital signature using a private key of a public-private key pair used to protect inter-PLMN communications.

20. A program for causing one or more processors to execute the method described in claim 1 or 2.

Images