Methods, systems, and computer readable media for integrity protection of subscription / notification and discovery messages between network functions (nfs) and nff repository functions (nfs)

Abstract

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

Description

[0001] Priority claim

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

[0003] 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 subscription / notification and discovery messages between NFs and NRFs. Background Art

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

[0005] A given producer NF may have many service endpoints, where a service endpoint is a contact point for one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of an Internet Protocol (IP) address and a port number or a fully qualified domain name (FQDN) that resolves to an IP address and a port number on a network node hosting the producer NF. An NF instance is an instance of a producer NF that provides a service. A given producer NF may include more than one NF instance. It should also be noted that multiple NF instances may share the same service endpoint.

[0006] NF registers with the Network Function Repository Function (NRF). NRF maintains profiles of available NF instances identifying the services supported by each NF instance. The profile of an NF instance is referred to as NF profile in 3GPP TS29.510. NF instances can obtain information about other NF instances registered with NRF through NF discovery service operations. According to the NF discovery service operation, the consumer NF sends an NF discovery request to the NRF. The NF discovery request includes query parameters, which the NRF uses to locate the NF profile of the producer NF that can provide the service identified by the query parameters. NF profile is a data structure that defines the type of service provided by the NF instance and contact and capacity information about the NF instance.

[0007] The Service Communication Proxy (SCP) can also call the NF Discovery service operation to learn about the available producer NF instances. The case where the SCP uses the NF Service Discovery process to obtain information about the producer NF instances on behalf of the consumer NF is called delegated discovery. The consumer NF connects to the SCP, and the SCP balances the traffic load between the producer NF service instances that provide the required service or directly routes the traffic to the destination producer NF instance.

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

[0009] One problem that may arise in 5G and other communication networks is that hackers can gain access to the communication between the NRF and NF and manipulate the parameters in the discovery response and notification messages to disrupt the communication. Hackers can also gain access to the discovery request and subscription request to manipulate the parameters in the request. The 3GPP standard provides an authentication mechanism between communicating entities. However, the existing authentication mechanism cannot prevent eavesdropping and modification of communications between mutually authenticated entities.

[0010] Therefore, in view of these and other difficulties, there is a need for methods, systems, and computer-readable media for integrity protection of subscription / notification and discovery messages between NFs and NRFs. Summary of the invention

[0011] A method for integrity protection of subscription / notification and NF discovery transactions between a network function (NF) and an NF repository function (NRF) includes receiving a subscription or discovery request message from the NF at the NRF. The method also includes determining that the subscription or discovery request message includes at least one indicator requesting NRF communication integrity protection. The method also includes: in response to determining that the subscription or discovery request includes at least one indicator requesting NRF communication integrity protection, calculating an integrity check value for at least a portion of the subscription or discovery request, and comparing the calculated integrity check value with the integrity check value included in the subscription or discovery request. The method also includes: determining that the calculated integrity check value matches the integrity check value included in the subscription or discovery request, and in response, formulating a response message to the subscription 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.

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

[0013] According to another aspect of the subject matter described herein, a method for integrity protection of subscription / notification and NF discovery transactions between NF and NRF includes detecting an event that needs to be notified to the NF, generating a notification request message, and including a digital signature of the body of the notification request message in the notification request message.

[0014] According to another aspect of the subject matter described herein, receiving a subscription or discovery request message includes receiving a NF discovery request message, formulating a response message includes formulating a NF discovery 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 discovery request message and a second digital signature of the body of the NF discovery response message.

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

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

[0017] According to another aspect of the subject matter described herein, the integrity check algorithm includes a hash algorithm.

[0018] 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 used by the NRF for OAuth 2.0 authorization.

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

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

[0021] According to another aspect of the subject matter described herein, a system for integrity protection of subscription / notification and NF discovery transactions between a network function (NF) and a NF repository function (NRF) is provided. The system includes an NRF, which includes at least one processor for receiving a subscription or discovery request message. The system also includes a subscription / discovery communication integrity protector implemented by at least one processor, for determining that the subscription or discovery request message includes at least one indicator for requesting NRF communication integrity protection, in response to determining that the subscription or discovery request message includes at least one indicator for requesting NRF communication integrity protection, calculating the integrity check value of at least a portion of the subscription or discovery request message, comparing the calculated integrity check value with the integrity check value included in the subscription or discovery request message, determining that the calculated integrity check value matches the integrity check value included in the subscription or discovery request message, and in response, formulating a response message to the subscription 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.

[0022] According to another aspect of the subject matter described herein, the subscription or discovery request message includes an NF status subscription message, the response message includes an NF status subscription response message, and the at least one digital signature includes a digital signature of an integrity check value received in the NF status subscription message from the consumer NF.

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

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

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

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

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

[0028] 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 paired with a public key of a NF-specific public-private key pair.

[0029] According to another aspect of the subject matter described herein, the subscription or discovery request message originates from a public land mobile network (PLMN) different from 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.

[0030] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium having executable instructions stored thereon is provided, and the executable instructions control the computer to perform steps when executed by the processor of the computer. These steps are performed at a network function (NF) repository function (NRF). These steps include receiving a subscription or discovery request message from the NF. These steps also include determining that the subscription or discovery request message includes at least one indicator requesting NRF communication integrity protection. These steps also include: in response to determining that the subscription or discovery request message includes at least one indicator requesting NRF communication integrity protection, calculating the integrity check value of at least a part of the subscription or discovery request message, and comparing the calculated integrity check value with the integrity check value included in the subscription or discovery request message. These steps also include determining that the calculated integrity check value matches the integrity check value included in the subscription or discovery request message, and in response, formulating a response message to the subscription or discovery request message, generating a digital signature, adding the digital signature to the response, and transmitting the response message to the NF.

[0031] The subject matter described herein can be implemented in software in combination with hardware and / or firmware. For example, the subject matter described herein can be implemented in software executed by a processor. In an exemplary embodiment, the subject matter described herein can be implemented using a non-transient computer-readable medium having computer executable instructions stored thereon, which controls the computer to perform steps when executed by the processor of the computer. Exemplary computer-readable media suitable 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. In addition, the computer-readable medium implementing the subject matter described herein can be located on a single device or computing platform or can be distributed on multiple devices or computing platforms. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Exemplary embodiments of the subject matter described herein will now be explained with reference to the accompanying drawings, in which:

[0033] Figure 1 is a network diagram illustrating an exemplary 5G system network architecture;

[0034] Figure 2 is a network diagram illustrating a 5G NF, an NRF, and a hacker who can gain access to communications between the 5G NF and the NRF, modify the communications, and disrupt services in the network;

[0035] Figure 3 is a message flow diagram illustrating exemplary messages exchanged in a subscription / notification transaction between a NF and an NRF, wherein integrity protection is used to detect unauthorized modification of a subscription request, a subscription response, and a subsequent notification request;

[0036] Figure 4 is a message flow diagram illustrating exemplary messages exchanged in a NF Discovery transaction between a NF and an NRF, wherein integrity protection is used to detect unauthorized modification of an NF Discovery Request and / or an NF Discovery Response;

[0037] Figure 5 is a message flow diagram illustrating exemplary messages exchanged in an inter-PLMN NF discovery transaction between a NF and an NRF, wherein integrity protection is used to detect unauthorized modification of an NF discovery request and / or an NF discovery response;

[0038] Figure 6 is a block diagram illustrating an exemplary architecture of NFs and NRFs for providing integrity protection in subscription / notification and NF discovery transactions; and

[0039] Figure 7 is a flow chart illustrating an example process for integrity protection in subscription / notification and NF discovery transactions. DETAILED DESCRIPTION

[0040] Figure 1 is a block diagram illustrating an exemplary 5G system network architecture. Figure 1 The architecture in includes NRF 100 and SCP 101, which can be located in the same home public land mobile network (HPLMN). As described above, NRF 100 can maintain profiles of available NF instances and the services they support, and allow consumer NFs or SCPs to subscribe to and be notified of registrations of new / updated NF instances. SCP 101 can also support service discovery and selection of NF instances. SCP 101 can perform load balancing of connections between consumer NFs and producer NFs.

[0041] NRF 100 is a repository for profiles of NF instances. In order to communicate with a producer NF instance, a consumer NF or SCP must obtain the NF profile of the producer NF instance from NRF 100. NF profile is a JavaScript Object Notation (JSON) data structure defined in 3GPP TS29.510. NF profile includes attributes indicating the type of service provided, the capacity of the NF instance, and information for contacting the NF instance.

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

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

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

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

[0046] SEPP 126 filters incoming traffic from another PLMN and performs topology hiding for traffic leaving the home PLMN. SEPP 126 can communicate with a SEPP in a foreign PLMN that manages the security of the foreign PLMN. Thus, traffic between NFs in different PLMNs can traverse two SEPP functions, one for the home PLMN and the other for the foreign PLMN.

[0047] As mentioned above, one problem that can arise in 5G and other networks is that hackers can eavesdrop on service communications between the NRF and NF, modify the communications, and disrupt services in the network. One operation that hackers 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:

[0048] Create subscriptions so that NF service consumers can request to be notified when a given set of NF instances are registered / deregistered / suspended in NRF as per certain filtering criteria or when the profile of a NF instance is modified; and

[0049] Create a subscription to a specific NF instance so that NF service consumers can request to be notified when the profile of this NF instance is modified or when the NF instance is deregistered / suspended from NRF.

[0050] Another service operation between the NRF and the NF that may be expected to provide integrity protection is the NFStatusNotify service operation specified in Section 5.2.2.6 of 3GPP TS29.510. The NFStatusNotify service operation notifies each NF service consumer that has previously subscribed to receive NF instance registration / deregistration notifications or NF profile change notifications for a given NF instance. The notification is sent to the callback URI provided by each NF service consumer during subscription (see NFStatusSubscribe operation in Section 5.2.2.5 of 3GPP TS29.510).

[0051] Yet another service operation between the NRF and the NF that may be expected 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 of NF instances in the set of NF instances (and their associated NF service instances) that are represented by their NF profiles, are currently registered with the NRF and satisfy a number of input query parameters.

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

[0053] Multiple connections between NRF and NF may enable hackers to gain access to the communication between NRF and NF. With this unauthorized access, for subscription / discovery requests, hackers can eavesdrop on requests to NRF and manipulate parameters in the request. For notifications, hackers can eavesdrop on notification requests from NRF and manipulate parameters in the notification body. Hackers can also push fake notifications to consumer NFs. For NF discovery service operations, hackers can eavesdrop on discovery responses from NRF and manipulate parameters in the discovery response. Since NF discovery and notification results are used by NF to make important routing decisions, this vulnerability may undermine the normal operation of the 5G core network. Therefore, it is necessary to enable integrity protection of notification requests and discovery responses from NRF.

[0054] An existing authentication mechanism is defined in 3GPP TS 33.501, section 13.3.1.2.

[0055] For indirect communication, NF and NRF can use one of the following methods for authentication:

[0056] Transport layer protection solution provides mutual authentication between NF and NRF.

[0057] · Client Credentials Assertion (CCA) based authentication as specified in clause 13.3.8.

[0058] Note 1: Client Credentials Assertion Authentication is based on a CCA token sent by the NF Service Consumer to the NRF via an intermediate NF, such as SCP. CCA based authentication does not provide authentication of the NRF to the NF Service Consumer or protection of the service requests sent by the NF Service Consumer to the NRF.

[0059] Implicitly, i.e., by relying on authentication between NF service consumers and SCPs, and between SCPs and NRFs, provided by hop-by-hop security protection at the transport layer, NDS / IP, or physical security.

[0060] Figure 2is a network diagram illustrating 5G NF, NRF, and a hacker who can gain access to the communication between 5G NF and NRF, modify the communication, and disrupt services in the network. Figure 2 , NRF 100 provides management services for 5G NFs such as PCF 102, Binding Support Function (BSF) 200, Unified Data Register (UDR) 202, and other NFs. Hacker 204 can gain unauthorized access to the communication between NRF 100 and 5G NFs. For example, hacker 204 can modify the response message from NRF 100 to 5GNF to include invalid data, which may disrupt services in the network. Hacker 204 can also modify the request message transmitted from 5G NF to NRF 100.

[0061] In view of the defects of existing authentication mechanisms, the subject matter described herein includes a method for an NF service consumer to indicate to the NRF that the consumer NF expects a signed response from the NRF, and the NF will send an integrity check value with the request message to the NRF. When access token support is enabled, the NF needs to have the key of its service NRF to perform verification of the access token. In an exemplary embodiment of the subject matter described herein, the same key pair used for CCA signing and verification can be used for signing and verifying notification requests and discovery responses. In another exemplary embodiment of the subject matter described herein, the NRF can be provisioned with a private key manually or through a public key infrastructure (PKI) in an operator network, and the corresponding public key can be provisioned for the consumer NF. Then, the NRF and the consumer NF can use the public-private key pair for signing and verifying notification requests and discovery responses.

[0062] To indicate the desire to participate in the integrity protection mechanism described in this document, the NF publishes the following additional data in a Subscribe or Discovery request:

[0063] A custom header vendor_request_signing, whose value is set to 1 to indicate to the NRF that the NF is requesting signed notification requests and discovery responses. The NF can update its existing subscription to turn on or off the signed message flow by setting the value to 1 or 0 respectively;

[0064] A custom header with a vendor_request_hash attribute that specifies a hash value (of the request body of a subscription request or the query parameters of a NF discovery request) and a vendor_request_algo attribute that specifies a hash algorithm, for example, SHA256.

[0065] Optionally, if the NRF manages separate key pairs for each NfInstance / NfType / Locality etc pair, then the NF can publish its nfInstance id as "reqNfInstanceId" in the SubscriptionData and as "requester-nf-instance-id" in the NF Discovery Request. The NRF can use the nfInstanceId to select an appropriate private key for signing the message (in the case where the NRF manages separate key pairs for each NF instance). For a subscription request, when the NRF receives a request with 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 matches the hash value with 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, then 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 NRF, then NRF adds a custom header vendor_signed_request (with the signature value of the hash value received in the vendor_request_hash header from the subscription request) to the subscription response. For notification requests for NFs that have requested signed messages from NRF, NRF signs each message by generating a hash value of the notification request body and digitally signing the hash value. NRF publishes the digital signature as a JWS value using the custom header vendor_signed_body.

[0066] For NF discovery request, when NRF receives a request with a vendor_request_hash header, NRF uses the algorithm identified by the vendor_request_algo header to calculate the hash value of the query parameters of the discovery request. NRF compares the hash value calculated by NRF with the hash value in the vendor_request_hash header. If the hash value calculated by NRF does not match the hash value in the vendor_request_hash header, then NRF rejects the request. If the hash value calculated by NRF matches the hash value in the vendor_request_hash header, then NRF processes the request, adds a custom header vendor_signed_request (with the signature value of the hash value received in the vendor_request_hash header from the discovery request) in 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 the custom header vendor_signed_body.

[0067] For the subscription response, the consumer NF verifies the response by reading the JWS value from the vendor_signed_request custom header. The consumer NF verifies the signature using the public key of the NRF, which in one example is the same as the public key used to verify the OAuth 2.0 access token in the service request. Verifying the digital signature includes 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 inserted by the consumer NF in the vendor_request_hash header in the subscription request message. If the verification of the subscription response fails, the consumer NF can, for example, re-subscribe to an alternative NRF. If the verification of the subscription response succeeds, the consumer NF processes the response.

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

[0069] For discovery response verification, the consumer NF reads the JWS value from the vendor_signed_request custom header and verifies the signature using the public key of its NRF, which in one example is the same key used to verify the OAuth2.0 access token in the service request. The consumer NF verifies that the decrypted hash value or unsigned hash value in the discovery response message is the same as the hash value inserted by the consumer NF in the vendor_request_hash header in the discovery request. The consumer NF also verifies the body of the NF discovery request message by reading the JWS value from the vendor_signed_body custom header and verifying the signature using the public key of its NRF, which in one example is the same key used to verify the OAuth 2.0 access token in the service request. The consumer NF verifies the discovery response body by calculating the hash of the discovery response message body and comparing the calculated hash with the unsigned hash value or decrypted hash value in the JWS payload. If the hash does not match, then the verification fails and the consumer NF can, for example, resend the discovery request to an alternative NRF. If the verification 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.

[0070] Figure 3 is a message flow diagram illustrating exemplary messages exchanged in a subscription / notification transaction between a NF and an NRF, where integrity protection is used to detect unauthorized modification of a subscription request, subscription response, and subsequent notification request. Figure 3, in line 1, the consumer NF 300 sends a subscription request, wherein the vendor_request_signing header is set to 1, and the vendor_request_hash header includes a hash of the subscription request message body and indicates 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 requester NF instance ID attribute in the subscription data. The NRF 100 receives the subscription request, calculates the 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 hash matches. In line 2, the NRF 100 sends a subscription response to the consumer NF 300. The NRF 100 includes a vendor_signed_request header in the subscription response, which includes the digital signature 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, and verifies the signature by decrypting the signature value using the public key of the NRF and verifying that the hash value included in the subscription response message is the same as the hash value included in the vendor_request_hash header of the subscription request message by the consumer NF 300. In this example, it is assumed that the subscription response message is valid.

[0071] In line 3 of the message flow diagram, NRF 100 detects an event that triggers a notification according to the parameters specified in the subscription created by the subscription request in line 1. In response to detecting the event, NRF 100 generates a signed notification response message using its private key for NRF to generate an OAuth 2.0 authorization token. In line 4, NRF 100 sends a notification request, wherein the vendor_signed_body header carries a digital signature hash of the notification request message body. Consumer NF 300 receives the notification request, decrypts the signature hash value carried in the vendor_signed_body header, calculates the hash of the notification request message body, and compares the unsigned hash or decrypted hash in the vendor_signed_body header with the calculated hash value. If the values ​​match, the notification request is verified, and consumer NF 300 processes the notification data in the notification request message body. If the verification fails, consumer NF 300 can reject the notification request and attempt to create a subscription to the same or alternative NRF instance.

[0072] Figure 4is a message flow diagram illustrating exemplary messages exchanged in an NF Discovery transaction between a NF and an NRF, wherein integrity protection is used to detect unauthorized modification of an NF Discovery Request and / or an NF Discovery Response. Figure 4 , in line 1, the consumer NF 300 sends a NF discovery request, where the vendor_request_signing header is set to 1, and the vendor_request_hash header 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 the requester NF instance ID attribute in the discovery parameters. The NRF 100 receives the NF discovery request, calculates the 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 hash matches. In line 2, the NRF 100 sends a NF discovery response to the consumer NF 300. The NRF 100 includes a vendor_signed-_request header and a vendor_signed_body header in the NF discovery response, the vendor_signed_request header includes the digital signature value of the vendor_request_hash header received in the NF discovery request, and the vendor_signed_body header 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 two signatures using the public key of the NRF. Verifying the digital signature in the vendor_signed_request header includes decrypting the hash value in the vendor_signed_request header using the public key, and comparing the decrypted hash value or the unsigned hash value with the hash value inserted by the consumer NF 300 in the discovery request message. Verifying 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, calculating the hash of the discovery response message body, and comparing the decrypted hash value or the unsigned hash value with the calculated hash value. In this example, it is assumed that the NF discovery response message is valid. If the verification of any digital signature fails, the consumer NF 300 rejects the NF discovery response and retries the NF discovery to the same or alternative NRF.

[0073] In one example of the subject matter described herein, the NRF may sign the discovery response message and the subscription response message using the same signing process specified in Section 5.4.2.2 of 3GPP TS29.510 and IETF RFC 7515. According to Section 5.4.2.2, the NRF acts as an OAuth 2.0 authorization server that provides a signed OAuth 2.0 access token to the NF service consumer. The access token is a JSON web token (JWT) specified in IETF RFC 7519. The NRF digitally signs the access token as specified in IETF RFC 7515.

[0074] In one embodiment of the subject matter described herein, the NRF uses the same private key and algorithm as used to sign the access token of the corresponding NF as a service provider. As defined in IETF RFC 7515:

[0075] JWS is a digital signature created using the following logical values:

[0076] JOSE header (i.e., protected header)

[0077] "typ" is set to "TEXT"

[0078] "alg" as defined by the operator (for NRF access tokens) JWS payload (as described above)

[0079] JWS Signature

[0080] The NRF may sign the Notification Response and Discovery Response using the same algorithm and private key that the NRF used to create the JWS signature for the NF's access token.

[0081] JWS compact serialization:

[0082] BASE64URL(UTF8(JWS protected header))||'.'||

[0083] BASE64URL(JWS payload)||'.'||

[0084] BASE64URL (JWS signature)

[0085] According to another aspect of the subject matter described herein, NRF can provide integrity protection for subscription responses and notification responses sent to consumer NFs in PLMNs different from NRFs. According to Section 5.2.2.6.3 of 3GPP TS29.510, notifications from home NRFs are delivered directly to consumer NFs in service PLMNs. Unless a cross-certification process is established between two PLMNs (via the mechanism discussed in 3GPP TS33.310), consumer NFs in service PLMNs cannot request signed notification requests from NRFs across PLMNs. If a cross-certification process is established between two PLMNs, consumer NFs (in service PLMNs) can follow the same process as their local NRFs to subscribe and verify notification requests. For inter-PLMN situations, consumer NFs do not need to provide reqNfInstanceId in SubscriptionData as described above. However, according to 3GPP specifications, for inter-PLMN subscriptions, NFs must provide reqPlmnList in SubscriptionData. NRFs can sign notification requests for a given PLMN identified by the reqPlmnList parameter in a subscription request using an agreed private key.

[0086] Figure 5 is a message flow diagram illustrating exemplary messages exchanged in an inter-PLMN NF discovery transaction between a NF and an NRF, wherein integrity protection is used to detect unauthorized modification of an NF discovery request and / or an NF discovery response. Figure 5, in line 1, if the local NRF supports signed NF discovery, the consumer NF 300 sends a NF discovery request with the vendor_request_signing header set to 1, and the vendor_request_hash header including the digitally signed hash of the query parameters and indicating 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 the requester NF instance ID attribute in the discovery parameters. The NRF 100A receives the NF discovery request, calculates the 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 in the vendor_request_hash value, and compares the calculated hash value with the decrypted hash value in the vendor_request_hash header. In this example, it is assumed that the hash matches. The NRF 100A determines that the NF discovery request needs to be forwarded to the NRF 100B in another PLMN. The NRF 100A also determines that the network of the NRF 100B supports cross-PLMN authentication. In this example, it is assumed that the PLMN of NRF 100B supports cross-PLMN authentication, and in line 2, a NF discovery request requesting a signed discovery response is formulated and sent to NRF 100B, regardless of whether the consumer NF requests a signed discovery response. The NF discovery request includes a vendor_request_signing header and a vendor_request_hash header, which includes a hash of query parameters signed using a private key in a private key-public key pair used by the PLMN of NRF 100B to verify inter-PLMN discovery requests. NRF 100B verifies the digital signature in the inter-PLMN discovery request, and in line 3, NRF 100B sends a signed NF discovery response to NRF 100A. The NF discovery response includes a vendor_signed_request header and a vendor_signed_body header, the vendor_signed_request header carries the digital signature hash received in the NF discovery request, and the vendor_signed_body header carries a hash of the message body of the discovery response message. The NRF 100A verifies the digital signature in the NF Discovery Response using the public key corresponding to the private key used for inter-PLMN authentication, and in line 4 , generates and sends the NF Discovery Response to the consumer NF 300 .In the NF discovery response, the NRF 100A includes a vendor_signed_request header and a vendor_signed_body header, the vendor_signed_request header includes the digital signature value of the vendor_request_hash header received in the NF discovery request, and the vendor_signed_body header carries the digital signature value of the NF discovery response message body. The consumer NF 300 receives the NF discovery response message, reads the digital signature, and uses the public key of the local NRF to verify the digital signature. In this example, it is assumed that the NF discovery response message is verified. If the verification of any digital signature fails, the consumer NF 300 rejects the NF discovery response and retries the NF discovery to the same or alternative NRF.

[0087] Figure 6 is a block diagram illustrating an exemplary architecture of NFs and NRFs for providing integrity protection in subscription / notification and NF discovery transactions. Figure 6 , NF 300 includes at least one processor 600 and memory 602. NF 300 also includes a subscription / discovery request generator / response verifier 604 implemented by the processor 600 for performing the NF functions described herein for requesting and implementing integrity protection in communications with the NRF. These functions include requesting signed notification and discovery responses, generating signed hashes of portions of NF discovery and subscription request messages, and verifying digital signatures in subscription responses, NF discovery responses, and notification request messages.

[0088] The NRF 100 includes at least one processor 606 and a memory 608. The NRF 100 also includes a subscription / discovery communication integrity protector 610 implemented by the processor 606 for performing the NRF side functions described herein for protecting the integrity of the communication with the NF. These functions include receiving a subscription or discovery request message from the NF, and determining that the subscription or discovery request message includes at least one indicator for NRF communication integrity protection. In response to determining that the subscription or discovery request includes at least one indicator for NRF communication integrity protection, the subscription / discovery communication integrity protector 610 calculates an integrity check value of at least a portion of the subscription or discovery request message, and compares the calculated integrity check value with the integrity check value included in the subscription or discovery request message. If the subscription / discovery communication integrity protector 610 determines that the calculated integrity check value matches the integrity check value included in the subscription or discovery request message, then the subscription / discovery communication integrity protector formulates a response message to the subscription or discovery request message, generates at least one digital signature, adds the digital signature to the response message, and transmits the response message to the NF. In one example, the integrity check value includes a hash value created using a hash function.

[0089] Figure 7 is a flow chart illustrating an exemplary process for integrity protection of subscription / notification and NF discovery transactions between NF and NRF. Figure 7 In step 700, the process includes receiving a subscription or discovery request message from the NF. For example, the NRF 100 may receive a NF status subscription request or a NF discovery request from a consumer NF or SCP.

[0090] In step 702, the process includes determining that the subscription or discovery request includes at least one indicator requesting NRF communication integrity protection. For example, the NRF 100 may determine that the NF Discovery Request or NF Status Subscription message includes vendor_request_signing and vendor_request_hash custom headers.

[0091] In step 704, the processing includes: in response to determining that the subscription or discovery request message includes at least one indicator requesting NRF communication integrity protection, calculating an integrity check value for at least a portion of the subscription or discovery request message, and comparing the calculated integrity check value with the integrity check value included in the subscription or discovery request message. For example, in the case of an NF status subscription message, the NRF 100 can calculate a hash of the message body and compare the hash with the hash in the vendor_request_hash custom header. In the case of an NF discovery request message, the NRF 100 can calculate a hash of the query parameters in the NF discovery request message and compare the hash with the hash contained in the vendor_request_hash custom header.

[0092] In step 706, the processing includes determining that the calculated integrity check value matches the integrity check value contained in the subscription or discovery request message, and in response, formulating a response to the subscription 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. If the response is a subscription response, the NRF may generate a vendor_signed_request header using the digital signature of the hash from the subscription request, and send the response to the consumer NF. If the response is a NF discovery response, the NRF may generate a vendor_signed_request header using the digital signature of the hash from the NF discovery request, and generate a vendor_signed_body header using the digital signature of the hash of the NF discovery response body.

[0093] In step 708, for the case where the consumer NF requests a signed response, the process includes digitally signing subsequent notification requests transmitted to the NF. For example, for each notification request transmitted to the consumer NF requesting 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 transmitted to the consumer NF along with the notification request message.

[0094] The following are the reasons why the integrity protection measures described in this paper reduce the possibility of successful attacks in the communication between NRF and NF.

[0095] 1. If a hacker / agent attempts to modify subscriptionData (for subscription request) or discovery parameters (for discovery request), then the consumer NF can detect such modifications by comparing the signature vendor_request_hash republished by the NRF in the subscription or discovery response.

[0096] 2. If a hacker / agent attempts to modify any content of the notification / discovery data from the NRF, then the hash value of the response message body will change. Hence, the verification of the digital signature of the hash of the message body will fail at the consumer NF.

[0097] 3. If a hacker / agent attempts to generate a fake notification request to the NF, the hacker / agent will not be able to generate a valid signed notification request without the private key of the real NRF. Therefore, the hacker will not be able to apply fake notifications at the NF that supports the integrity protection mechanism described in this article.

[0098] Exemplary features / advantages of the subject matter described herein include:

[0099] The subject described in this article provides integrity protection for Subscription Request, Discovery Request, Notification Request and Discovery Response between NRF and consumer NF. Hence, the subject described in this article acts as a protection measure to prevent any kind of intrusion on the request and response flows between NF and NRF.

[0100] The topics described in this article can be enhanced to apply to the registration and access token request / response flows between NF and NRF.

[0101] • When a cross-authentication process is established between two PLMNs, the subject matter described herein also applies to the signing of Notification Requests and Discovery Responses across PLMNs.

[0102] The NRF generates signed Notification Requests or Discovery Responses only for NFs that requested signed responses in the Subscription or Discovery Requests. Therefore, unless a consumer NF explicitly requests signed Notification Requests and Discovery Responses, the behavior of the NRF remains unchanged.

[0103] Since the NF explicitly controls support for requesting signed messages from the NRF, network operators can choose to selectively enable and disable support for signed messages from the NRF on a per-NF basis.

[0104] If the NRF manages separate key pairs for each NfInstance / NfType / Locality etc., then the subject matter described herein is applicable to NFs registered at the NRF. If an endpoint attempts to subscribe without being registered with the NRF, then the NRF cannot determine the private key that will be used to sign notifications for such endpoints. Hence, a NF that does not have a registered profile at the NRF cannot request a signed message flow from the NRF.

[0105] NFs can 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 functionality described herein. Otherwise, if a given NRF does not support signatures, the NF(s) performing the validation of the signed flows from the NRF will reject any Notification Request or Discovery Response generated by the NRF.

[0106] The disclosures of each of the following references are hereby incorporated by reference in their entirety.

[0107] References

[0108] 1.3 rd Generation Partnership Project; Technical Specification GroupServices and System Aspects; Security architecture and procedures for the 5Gsystem (version 17) 3GPP TS 33.501V17.4.2 (2022-01)

[0109] 2.3 rdGeneration Partnership Project; Technical Specification GroupServices and System Aspects; Network Domain Security (NDS); AuthenticationFramework (AF) (Version 17) 3GPP TS 33.310V17.1.0 (2021-12)

[0110] 3.3 rd Generation Partnership Project; Technical Specification GroupCore Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (version 17) 3GPP TS29.510V17.4.0 (2021-12)

[0111] 4.Hardt, D., The OAuth 2.0Authorization Framework, IETF RFC 6749 (October 2012)

[0112] 5. Jones et al., JSON Web Signature (JWS) IETF RFC 7515 (May 2015)

[0113] 6. Jones et al., JSON Web Token (JWT), IETF RFC 7519 (May 2015)

[0114] It should be understood that various details of the subject matter described herein can be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for illustrative purposes only and not for limiting purposes, as the subject matter described herein is defined by the claims set forth below.

Claims

1. A method for integrity protection of subscription / notification and NF discovery transactions between a network function (NF) and an NF repository function (NRF), the method comprising: At NRF: Receive a subscription or discovery request message from the NF; determining that the subscription or discovery request message includes at least one indicator requesting NRF communication integrity protection; responsive to determining that the subscription or discovery request message includes the at least one indicator requesting NRF communication integrity protection, calculating an integrity check value for at least a portion of the subscription or discovery request message, and comparing the calculated integrity check value with the integrity check value included in the subscription or discovery request message; as well as Determine that the calculated integrity check value matches the integrity check value included in the subscription or discovery request, and in response, formulate a response message to the subscription or discovery request message, generate at least one digital signature, add the at least one digital signature to the response message, and transmit the response message to the NF.

2. The method of claim 1, wherein receiving a subscription or discovery request message comprises receiving an NF status subscription message, formulating a response message comprises formulating an NF status subscription response message, and generating the at least one digital signature comprises digitally signing an integrity check value received in the NF status subscription message from the consumer NF.

3. The method of claim 1 or 2, comprising detecting, at the NRF, an event that needs to be notified to the NF, generating a notification request message, and including a digital signature of the body of the notification request message in the notification request message.

4. A method as claimed in claim 1, 2 or 3, wherein receiving a subscription or discovery request message includes receiving an NF discovery request message, formulating a response message includes formulating an NF discovery 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 discovery request message from the consumer NF and a second digital signature of the body of the NF discovery response message.

5. The method according to any of the preceding claims, wherein the at least one indicator requesting NRF communication integrity protection comprises a custom vendor_request_signing header having a value indicating that the NF expects a digitally signed response message.

6. The method of any of the preceding claims, wherein the at least one indicator requesting NRF communication integrity protection comprises a custom vendor_request_hash header containing an integrity check value and an identifier of an integrity check algorithm used to create the integrity check value. The method of claim 6 , wherein the integrity check algorithm comprises a hash algorithm.

8. The method of any one of the preceding claims, wherein generating the at least one digital signature comprises generating the digital signature using a private key of the NRF used by the NRF for OAuth2.0 authorization.

9. The method of any of the preceding claims, wherein generating the at least one digital signature comprises generating a digital signature using a private key paired with a public key of a public-private key pair specific to the NF.

10. The method of any of the preceding claims, wherein receiving a subscription or discovery request message comprises receiving a subscription or discovery request from a public land mobile network (PLMN) different from the NRF, and wherein generating the at least one digital signature comprises generating the at least one digital signature using a private key of a private key-public key pair used to protect inter-PLMN communications.

11. A system for integrity protection of subscription / notification and NF discovery transactions between a network function (NF) and a NF repository function (NRF), the system comprising: The NRF comprises at least one processor for receiving a subscription or discovery request message; as well as a subscription / discovery communication integrity protector, implemented by the at least one processor, for determining that a subscription or discovery request message includes at least one indicator requesting NRF communication integrity protection; In response to determining that the subscription or discovery request message includes the at least one indicator requesting NRF communication integrity protection, calculating an integrity check value for at least a portion of the subscription or discovery request message; comparing the calculated integrity check value with the integrity check value included in the subscription or discovery request message; determining that the calculated integrity check value matches the integrity check value included in the subscription or discovery request message; and in response, formulating a response message to the subscription 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.

12. The system of claim 11, wherein the subscription or discovery request message comprises an NF status subscription message, the response message comprises an NF status subscription response message, and the at least one digital signature comprises a digital signature of an integrity check value received in the NF status subscription message from the consumer NF.

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

14. A system as described in any one of claims 11, 12 or 13, wherein the subscription or discovery request message includes an NF discovery request message, the response message includes an NF discovery response message, and the at least one digital signature includes a first digital signature of an integrity check value received in the NF discovery request message from the consumer NF and a second digital signature of the body of the NF discovery response message.

15. The system of any one of claims 11 to 14, wherein the at least one indicator requesting NRF communication integrity protection comprises a custom vendor_request_signing header having a value indicating that the NF expects a digitally signed response message.

16. The system of any one of claims 11 to 15, wherein the at least one indicator requesting NRF communication integrity protection comprises a custom vendor_request_hash header containing an integrity check value and an identifier of a hash algorithm used to create the integrity check value.

17. The system of any one of claims 11 to 16, wherein the subscription / discovery communication integrity protector is configured to generate the at least one digital signature using a private key of the NRF used by the NRF for OAuth 2.0 authorization.

18. The system of any one of claims 11 to 17, wherein the subscription / discovery communication integrity protector is configured to generate the at least one digital signature using a private key paired with a public key in a NF-specific public-private key pair.

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

20. A non-transitory computer readable medium having executable instructions stored thereon, wherein when the instructions are executed by a processor of a computer, the computer is controlled to perform the following steps: At the Network Function (NF) Repository Function (NRF): Receive a subscription or discovery request message from the NF; determining that the subscription or discovery request message includes at least one indicator requesting NRF communication integrity protection; responsive to determining that the subscription or discovery request message includes the at least one indicator requesting NRF communication integrity protection, calculating an integrity check value for at least a portion of the subscription or discovery request, and comparing the calculated integrity check value with the integrity check value included in the subscription or discovery request message; as well as Determine that the calculated integrity check value matches the integrity check value included in the subscription or discovery request message, and in response, formulate a response message to the subscription or discovery request message, generate at least one digital signature, add the at least one digital signature to the response, and transmit the response message to the NF.

Images