Inter-slice attack and user equipment data theft prevention

Abstract

Methods are disclosed for validating that an NF consumer (NFc) is authorized to access User Equipment (UE) information and for detecting a compromised NFc that is attempting to gain unauthorized access to UE information. An NF provider (NFp) can receive a service request that includes an access token and then if the service request and token are valid, the NFp can determine whether there is an intersection between one or more Single Network Slice Selection Assistance Information (S-NSSAIs) that the NFc is allowed to access (as indicated by the NFp's NSSAIs in the access token presented by the NFc) and at least one of the network slice(s) that the UE has access to (e.g., allowed S-NSSAIs or subscribed S-NSSAIs). If there is a match, then the NFp can provide the UE information to the NFc, but if there is no match, the NFp can reject the service request.

Description

INTER-SLICE ATTACK AND USER EQUIPMENT DATA THEFT PREVENTIONRelated Applications

[0001] This application claims the benefit of provisional patent application serial number 63 / 555,168, filed February 19, 2024, the disclosure of which is hereby incorporated herein by reference in its entirety.Technical Field

[0002] The present disclosure relates methods for validating that a Network Function (NF) Consumer (NFc) is authorized to access User Equipment (UE) information and for detecting a compromised NFc that is attempting to gain unauthorized access to UE information in a wireless communication system.Background

[0003] The Fifth Generation (5G) network revolution is driven by the increasing number of Internet of Things (loT) devices and evolving services. These services belong to different vertical industries including but not limited to manufacturing, healthcare, augmented reality, among others and hence, demand various Quality of Service (QoS) requirements such as ultra-low latency, high reliability, high bandwidth, etc. To cater to these services, the 5G Core (5GC) network adopts a Service Based Architecture (SBA) leveraging cloud-native architecture and virtualization technologies, along with a network slicing concept.

[0004] While the SBA provides flexible deployment and service provisioning, network slicing allows portioning the 5G network into logical networks, each dedicated to serve a specific purpose such as providing services with specific QoS for a vertical industry. Despite the advantages brought by SBA and network slicing in fulfilling 5G services demands, they extend the 5G network attack surface and make it vulnerable to different attacks such as leakage and theft of User Equipment (UE) data through illegal network access.

[0005] Below is an overview of the 5G SBA, network slicing in 5G and presented is a network slicing attack pertaining to unauthorized access of a Network Function (NF) in the 5G SBA to UE information.

[0006] 5G SBA represents 5G network control plane and is represented in a simplified version in Figure 1.

[0007] 5G SBA adopts a cloud-native, service-driven deployment in which all NFs are virtualized, hence, allowing network operational efficiencies. It has a logically uniform service bus (Service Based Interface (SBI)) enabling everyone-to-everyone communication instead ofpoint-to-point communication as in Fourth Generation (4G) Evolved Packet Core (EPC). Further, it accounts for uniform protocol stack leveraging web-based protocols, mainly HTTP / 2, Restful Application Programming Interfaces (APIs), OAuth 2.0, Transport Layer Security (TLS) instead of many telecommunications’ specific protocols (i.e., Diameter, etc.) in 4G EPC.

[0008] In addition, 5G SBA encompasses a list of standardized NFs, each providing a list of standard services made available through APIs. This enables service extensibility given that a service can be provided by an NF producer (NFp) and consumed by an NF consumer (NFc). In such a setting, NFs communicate using the HTTP / 2 protocol through a Request- Response in which a request for a service is issued by a NFc (acting as HTTP / 2 client) and a response is provided by a NFp (acting as an HTTP / 2 server). Moreover, NFs can communicate using Subscribe-Notify in which a NFc subscribes to a certain event of the NFp where the latter notifies the NFc upon the occurrence of the event (TS29.501). Such event can be UE registration state, UE location provided by Access and Mobility Management Function (AMF) to Session Management Function (SMF), Network Data Analytics Function (NWDAF), etc.). Finally, it is worth noting that an NFc needs to be authorized from the Network Repository Function (NRF) to access NFp specific services. In case of successful authorization, the NRF provides the NFc with an OAuth 2.0 authorization token that can be sent by the NFc to the NFp within its request for the NFp service. Then, the NFp verifies the integrity and claims in the access token, processes the request, and sends response to the NFc.

[0009] A 5G network can be virtualized into a set of logical networks, each defining a network slice. A network slice is identified by a Single Network Slice Selection Assistance Information (S-NSSAI) in 5G networks. It is composed of a chain of NFs to fulfill the specific QoS requirements of the vertical industries it is serving. NFs serving a network slice can either be dedicated to that slice or shared between different network slices.

[0010] A UE can request access to one or multiple network slices it is subscribed to. The list of subscribed slices, also known by “subscribed S-NSSAI”, is saved in the User Data Management (UDM) function (3GPPTS 23.502 VI 8.3.0). To gain access to a requested slice identified by an S-NSSAI, the UE needs to get the authorization from a home / serving Public Land Mobile Network (PLMN) (3GPP TS 33.501 VI 8.3.0). Such authorization can only be granted after successful primary authentication to the network after which the AMF and the UE may receive a list of allowed S-NSSAI, depicting the network slices the UE is allowed to access. For certain S-NSSAIs, additional Network Slice Specific Authentication and Authorization (NSSAA) may be required. In such a scenario, NSSAA is initiated by the AMF for those slicesthat will be added to the list of allowed S-NSSAI upon successful secondary authentication and authorization.

[0011] The use of network slicing and virtualization in 5G network extends its attack surface. In fact, the sharing of virtualized resources such as NFs between different network slices can be exploited by attackers to gain unauthorized access to services and UE information as is detailed herein.

[0012] In the following, an example of a network slicing attack is presented, in which an attacker compromises an NFc to gain unauthorized access to UE information for a UE served by another network slice that is different from the one the NFc is serving.

[0013] In such an attack, it can be assumed that:• A 5G network is configured with at least two network slices, namely, Network Slice 1(NS1) and Network Slice 2 (NS2).• An NFp such as an AMF is serving NS1 and NS2.• An NFc such as a peer AMF, a Gateway Mobile Eocation Centre (GMLC) or a UDM, serving NS2, is compromised by an attacker through exploiting vulnerabilities in virtualization technologies. The attacker can also be an insider who compromised the NFc TLS keys and impersonated it.• The NFc and NFp can belong to the same MNO or to different roaming partners.• The NFc and NFp can communicate directly or indirectly through Service Communication Proxy (SCP) and / or Security Edge Protection Proxy (SEPP) (i.e., in a roaming scenario).

[0014] The attack presented in the message sequence chart in Figure 2 can be performed as follows:

[0015] At step 1, the attacker compromises an NFc serving NS2.

[0016] At step 2, through the compromised NFc, the attacker establishes a secure connection with the NRF.

[0017] At step 3, the attacker sends an Nnrf_AccessToken_GetRequest (NS2, NF type, expected service name(s) etc.) request to the NRF to request an OAuth2.0 access token authorizing it to access the services belonging to NS2 from the NFp serving both network slices NS1 and NS2 (Adaptive Mobile Security, “A Slice in Time: Slicing Security in 5G Core Networks”, White Paper, v. 1.0, (2021-03) https: / / info.enea.com / Slicing-Security-in-5G-Core- Networks).

[0018] At step 4, the NRF checks whether the NFc is authorized to access the requested service(s) by verifying for example, that the NFc can serve a network slice which is included inthe allowed network slices of the NFp. In other words, the NRF verifies that the NFc is allowed to access the requested NFp services by making sure that both can serve the same NS2.

[0019] At step 5, the NRF generates the OAuth2.0 access token.

[0020] At step 6, the NRF sends the OAuth2.0 access token to the NFc through anNnrf_AccessToken_GetResponse (access token to NS2, expiration date) response.

[0021] At step 7, the NFc receives the authorization token from the NRF and sends it along its request to the NFp. In this request, the malicious NFc requests information of a UE belonging to (i.e., being served or can be served by) network slice (i.e., NS1) different than the one that the NFc is serving, and based on which it was provided the OAuth2.0 access token by the NRF. Such request can be, for example, an Namf_Location_ProvideLocationInfo request sent by a UDM NFc, or a Namf_Location_ProvidePositioningInfo request sent by a GMLC NFc or Namf_Communication_UEContextTransfer sent by a peer AMF NFc, etc.

[0022] At step 8, the NFp ensures the integrity of the OAuth2.0 access token and validates its claims as specified by 3GPP. More precisely, the NFp verifies that the malicious NFc can serve NS2 by verifying that it can serve the network slices specified in the access token.

[0023] At step 9, upon successful verification of the integrity and validity of the claims in the NFc OAuth2.0 access token, the NFp processes the NFc’s request.

[0024] At step 10, the NFp sends the service response to the NFc and provides it with the UE information, hence granting access to a NF serving NS2 to information of UE belonging to NS1 which leads to the attack.

[0025] It is worth noting that based on earlier releases prior to 3GPP TS 33.501, VI 8.3.0, the NFp does not verify that the NFc serves the same network slices the UE belongs to (i.e., NS2) which allows the attack depicting a malicious NF gaining unauthorized access to a UE information through an inter-slice attack to take place.Summary

[0026] Various embodiments disclosed herein provide methods for validating that an NF Consumer (NFc) is authorized to access User Equipment (UE) information and for detecting a compromised NFc that is attempting to gain unauthorized access to UE information. An NF provider (NFp) can receive a service request that includes an access token and then if the service request and token are valid, the NFp can determine whether there is an intersection between one or more Single Network Slice Selection Assistance Information (S-NSSAIs) that the NFc is allowed to access (as indicated by the NFp’s NSSAIs in the access token presented by the NFc) and at least one of the network slice(s) that the UE has access to (e.g., allowed S-NSSAIs orsubscribed S-NSSAIs). If there is a match, then the NFp can provide the UE information to the NFc, but if there is no match, the NFp can reject the service request. A Network Data Analytics Function (NWDAF) can collect lists of rejected requests from one or more NFps, and then determine whether any NFc may be compromised, and then provide the analytics to a security function.

[0027] In an embodiment, a method for validation that an NFc is authorized to access UE information is performed by an NFp, where the method includes receiving, from the NFc, a service request comprising an access token, and determining whether the access token and a request in the service request is valid. The method also includes in response to the access token being valid, and the service request comprising a request for UE information, determining whether one or more S-NSSAIs in the access token match one or more UE authorized S-NSSAIs in the service request, and in response to one of the S-NSSAIs in the access token matching one or more authorized S-NSSAIs, providing a response to the NFc, wherein the response comprises the UE information.

[0028] In an embodiment, the method also includes in response to the access token not being valid, rejecting the service request.

[0029] In an embodiment, the method also includes in response to one of the S-NSSAIs in the access token not matching the one or more authorized S-NSSAIs, rejecting the service request.

[0030] In an embodiment, the one or more authorized S-NSSAIs were previously retrieved from at least one of an Access and Mobility Management Function (AMF) or a Unified Data Management Function (UDM).

[0031] In an embodiment, in response to the UE information requested in the service request being real-time UE context information, the method further comprises providing another service request to an AMF with the other service request comprising the access token from the NFc.

[0032] In an embodiment, the method further includes receiving, from the AMF, at least one of a rejection or the one or more authorized S-NSSAIs.

[0033] In an embodiment, in response to the UE information requested in the service request being UE access authorization to a network or UE monitoring information, the method further comprises, providing another service request to a UDM with the other service request comprising the access token from the NFc.

[0034] In an embodiment, the method further includes receiving, from the UDM, at least one of a rejection or the one or more authorized S-NSSAIs.

[0035] In an embodiment, the method further includes subscribing, with UDM to updates on authorized S-NSSAIs for UEs associated with the NFp.

[0036] In an embodiment, the method further includes receiving, from a NWDAF, an event exposure subscription and providing to the NWDAF, rejected request information associated with an NFc.

[0037] In an embodiment, the rejected request information comprises a list of rejected requests associated with the NFc in a defined time period.

[0038] In an embodiment, a network node is provided that implements an NFp that is configured to validate that an NFc is authorized to access UE information, and the network node comprises processing circuitry configured to receive, from the NFc, a service request comprising an access token, and determine whether the access token and a request in the service request is valid. The processing circuitry is also configured to, in response to the access token being valid, and the service request comprising a request for UE information, determine whether one or more S-NSSAIs in the access token match one or more UE authorized S-NSSAIs in the service request, and in response to one of the S-NSSAIs in the access token matching one or more authorized S-NSSAIs, provide a response to the NFc, wherein the response comprises the UE information.

[0039] In an embodiment, network node is also configured to perform any of the embodiments described above with regard to the method.

[0040] A method performed by an NWDAF is provided for detecting a compromised NFc attempting to gain unauthorized access to UE information. The method includes providing, to one or more Network Function providers, NFps, an event exposure subscription, receiving from the one or more NFps, rejected request information comprising one or more lists of rejected requests associated with the NFc in a defined time period, based on the one or more lists of rejected requests, determining rejected request analytics, and providing the rejected request analytics to a security function. In an embodiment, the method further includes prior to providing the event exposure subscription to the one or more NFps, receiving a subscription from the security function.

[0041] A network node is provided that implements a NWDAF that is configured to detect a compromised NFc attempting to gain unauthorized access to UE information. The network node includes processing circuitry that is configured to provide, to one or more Network Function providers, NFps, an event exposure subscription, receive from the one or more NFps, rejected request information comprising one or more lists of rejected requests associated with the NFc in a defined time period, based on the one or more lists of rejected requests, determine rejectedrequest analytics, and provide the rejected request analytics to a security function. In an embodiment, the processing circuitry can further be configured to, prior to providing the event exposure subscription to the one or more NFps, receive a subscription from the security function.Brief Description of the Drawings

[0042] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain its principles.

[0043] Figure 1 illustrates an example of a Fifth Generation (5G) Service-Based Architecture according to one or more embodiments of the present disclosure;

[0044] Figure 2 illustrates an example of a message sequence chart of an exemplary attack according to one or more embodiments of the present disclosure;

[0045] Figure 3 illustrates one example of a cellular communications system in which embodiments of the present disclosure may be implemented;

[0046] Figure 4 illustrates a wireless communication system represented as a 5G network architecture including a subset of core Network Functions (NFs);

[0047] Figure 5 illustrates a 5G network architecture using service-based interfaces between the NFs in the Control Plane (CP);

[0048] Figure 6 illustrates an exemplary message sequence chart for a method for validating that a NF consumer (NFc) is authorized to access User Equipment (UE) information according to some embodiments of the present disclosure;

[0049] Figure 7 illustrates an exemplary message sequence chart for a method for detecting a compromised NFc that is attempting to gain unauthorized access to UE information according to some embodiments of the present disclosure;

[0050] Figure 8 is a schematic block diagram of a network node according to some embodiments of the present disclosure;

[0051] Figure 9 is a schematic block diagram that illustrates a virtualized embodiment of the network node according to some embodiments of the present disclosure; and

[0052] Figure 10 is a schematic block diagram of the network node according to some other embodiments of the present disclosure.Detailed Description

[0053] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within thescope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0054] Network Node: As used herein, a “network node” is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P- GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

[0055] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

[0056] There currently exist certain challenge(s). To prevent an unauthorized access to a User Equipment (UE) information through an inter-slice attack by a compromised NF, 3GPP TS 33.501, VI 8.3.0 noted the following “ “If applicable (e.g., when the request is for information related to a specific UE), the Network Function (NF) Service Producer may check that the NF Service Consumer is allowed to access (as indicated by the NF Service Producer’s Single Network Slice Selection Assistance Information (S-NSSAIs) in the access token presented by the NF Service Consumer) at least one of the slice(s) that the UE is currently registered to, e.g., by verifying that the UE’s allowed NSSAI(s) intersect with the NF Service Producer's NSSAIs in the access token ”

[0057] Although requiring the NF producer (NFp) to check if the NF consumer (NFc) is allowed to access at least one of the network slices the UE is currently registered to prevent the attack; the presented Third Generation Partnership Program (3GPP) solution has the following limitations.

[0058] It suggests verifying the network slices the UE is currently registered to, that is the allowed NSSAI list. However, the allowed NSSAI list is only available once the UE is registered to the network and is active. This prevents legitimate NFs from accessing UE information for UEs that are not currently registered or active in the network.

[0059] An NFc may be subscribed to certain UE related events and be automatically notified (periodic, one-time notification) upon their occurrence while the UE is not connected to the network.

[0060] Example: An Application Function (AF) may be subscribed to periodic or one-time event related to reporting UEs location that can be the current one or the last known one).

[0061] Some services including UE information are offered to enable a UE access to network slices and grant its connectivity to the network.

[0062] Example: During the registration procedure, the AMF requires the UE subscribed NS SAI from the UDM to determine the UE allowed NS SAI and grant its connectivity to a network slice.

[0063] It does not determine a clear procedure on how an NFp should verify that the NFc is allowed to access the requested UE information while accounting for the UE allowed NSSAI that includes the network slices a UE is authenticated to, and which are available in the AMF. There exists no standardized API allowing an NF to require UE slice related information from the AMF.

[0064] Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. Various embodiments disclosed herein provide for methods for validating that an NF consumer (NFc) is authorized to access User Equipment (UE) information and for detecting a compromised NFc that is attempting to gain unauthorized access to UE information. A NF provider (NFp) can receive a service request that includes an access token and then, if the request and token are both valid, the NFp can determine whether there is an intersection between one or more Single Network Slice Selection Assistance Information (S-NSSAIs) in the service request and S-NSSAIs that the NFc is authorized to access. If there is a match, then the NFp can provide the UE information to the NFc, but if there is no match, the NFp can reject the service request. A Network Data Analytics Function (NWDAF) can collect lists of rejected requests from one or more NFps, determine whether any NFc may be compromised, and then provide the analytics to a security function.

[0065] 5G networks leverage network slicing and virtualization technologies to serve the stringent services’ requirements of its vertical industries. However, the virtualization of 5G networks into a set of logical networks known as “network slices” extends its attack surface and makes it vulnerable to inter-slice attacks such as the unauthorized access to UE information attack through a compromised NF. This attack exploits the lack of a clear methodology by 3GPP allowing an NFp to verify if an NFc is allowed to access the requested UE information.

[0066] This disclosure presents a solution that prevents the mentioned attack by proposing a new mechanism to enable an NFp to validate if an NFc is allowed to access UE information. The proposed mechanism suggests: 1) adding a new Namf_Communication_UE_Information service operation to the Namf Communication API of the AMF to allow an NFp to get the UE allowed S-NSSAIs list and verify that it intersects with the NFc network slices, whenever the request is related to live UE information; 2) invoking the Nudm_SDM_get service operation from the UDM by the NFp to verify that the UE subscribed S-NSSAIs intersect with the NFc network slices, whenever the request is related to providing UE access to a network slice or to one-time or periodic notification, among others. To reduce the signaling in the network, the solution suggests that the NFp registers to UDM event to get notified with the UE subscribed S-NSSAIs when they are updated. Finally, the present disclosure proposes a mechanism to predict, detect, prevent, and mitigate potentially malicious NFcs trying to gain unauthorized access to UE information by allowing NFps to collect and report to the NWDAF the number of NFc requests that were rejected by the NFp due to unauthorized access attempts.

[0067] Certain embodiments may provide one or more of the following technical advantage(s): The methods and techniques disclosed herein can: prevent inter-slice attacks; prevent unauthorized access of an NF and a network slice to UE information; prevent sensitive data leakage between network slices; enable an NFp to validate if an NFc is allowed to access the requested UE information; enable an NF to verify that a UE is authenticated and authorized to receive a service from a network slice; minimize the communication overhead needed for an NFp to validate if an NFc is allowed to access UE information by providing it the possibility to subscribe to Nudm_SDM notification and receive the UE subscribed S-NSSAIs; predict, detect, prevent, and mitigate attack from a malicious NF; and is compliant with 3GPP.

[0068] Some of the embodiments of the present disclosure include a mechanism to enable an NFp to validate if an NFc is allowed to access UE information through: a.Allowing an NFp to determine based on the requested service if there is a need to verify if the UE is authenticated and authorized to access the network slice in question or if it is enough to validate that it is subscribed to it. b. Requesting UE allowed S-NSSAIs from the AMF using a new Namf_Communication_UE_Information service operation. c.Requesting UE subscribed S-NSSAI(s) from the UDM through the existingNudm_SDM_get service operation. d. Subscribing to Nudm_SE>M subscription data change notification to receive updated UE slice selection data.

[0069] Another embodiment includes a mechanism to verify at any time if the UE is authorized and authenticated to receive a requested service (through the new proposed Namf_Communication_UE_Information service operation).

[0070] Another embodiment includes a new Namf_Communication_UE_Information service operation, added to the Namf Communication API to enable NFs to acquire UE allowed S- NSSAIs from the AMF.

[0071] Another embodiment includes a mechanism that allows the prediction, detection, prevention, and mitigation of potentially malicious NFcs attempting to gain unauthorized access to UE information through: a. A new Key Performance Indicator (KPI), namely nb_rejected_requests_[NFc], collected at the different NFs to report the number of requests that were sent by an NFc and rejected due to unauthorized UE information attempts. b. A new NF_SECURITY event that allows NFs to provide to other NFcs the new proposed nb_rejected_requests_[NFc ] KPI. c.Modified versions of the N[NF]_EventExposure_Subscribe services corresponding to the different 5G NFs to allow their NFcs such as the NWDAF to subscribe to a new proposed NF_SECURITY event and be notified about the nb_rejected_requests_[NFc ] KPI.

[0072] Figure 3 illustrates one example of a cellular communications system 300 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 300 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC). In this example, the RAN includes base stations 302-1 and 302-2, which in the 5GS include NR base stations (gNBs) controlling corresponding (macro) cells 304-1 and 304-2. The base stations 302-1 and 302-2 are generally referred to herein collectively as base stations 302 and individually as base station 302.Eikewise, the (macro) cells 304-1 and 304-2 are generally referred to herein collectively as (macro) cells 304 and individually as (macro) cell 304. The RAN may also include a number of low power nodes 306-1 through 306-4 controlling corresponding small cells 308-1 through 308- 4. The low power nodes 306-1 through 306-4 can be small base stations (such as pico or femto base stations) or RRHs, or the like. Notably, while not illustrated, one or more of the small cells 308-1 through 308-4 may alternatively be provided by the base stations 302. The low power nodes 306-1 through 306-4 are generally referred to herein collectively as low power nodes 306 and individually as low power node 306. Likewise, the small cells 308-1 through 308-4 are generally referred to herein collectively as small cells 308 and individually as small cell 308.The cellular communications system 300 also includes a core network 310, which in the 5G System (5GS) is referred to as the 5GC. The base stations 302 (and optionally the low power nodes 306) are connected to the core network 310.

[0073] The base stations 302 and the low power nodes 306 provide service to wireless communication devices 312-1 through 312-5 in the corresponding cells 304 and 308. The wireless communication devices 312-1 through 312-5 are generally referred to herein collectively as wireless communication devices 312 and individually as wireless communication device 312. In the following description, the wireless communication devices 312 are oftentimes UEs, but the present disclosure is not limited thereto.

[0074] Figure 4 illustrates a wireless communication system represented as a 5G network architecture composed of core Network Functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point / interface. Figure 4 can be viewed as one particular implementation of the system 300 of Figure 3.

[0075] Seen from the access side the 5G network architecture shown in Figure 4 comprises a plurality of UEs 312 connected to either a RAN 302 or an Access Network (AN) as well as an AMF 400. Typically, the R(AN) 302 comprises base stations, e.g. such as eNBs or gNBs or similar. Seen from the core network side, the 5GC NFs shown in Figure 4 include a NSSF 402, an AUSF 404, a UDM 406, the AMF 400, a SMF 408, a PCF 410, and an Application Function (AF) 412.

[0076] Reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. The N 1 reference point is defined to carry signaling between the UE 312 and AMF 400. The reference points for connecting between the (R)AN 302 and AMF 400 and between the (R)AN 302 and UPF 414 are defined as N2 and N3, respectively. There is a reference point, Ni l, between the AMF 400 and SMF 408, which implies that the SMF 408 is at least partly controlled by the AMF 400. N4 is used by the SMF 408 and UPF 414 so that the UPF 414 can be set using the control signal generated by the SMF 408, and the UPF 414 can report its state to the SMF 408. N9 is the reference point for the connection between different UPFs 414, and N14 is the reference point connecting between different AMFs 400, respectively. N15 and N7 are defined since the PCF 410 applies policy to the AMF 400 and SMF 408, respectively. N12 is required for the AMF 400 to perform authentication of the UE 312. N8 and N10 are defined because the subscription data of the UE 312 is required for the AMF 400 and SMF 408.

[0077] The 5GC network aims at separating UP and CP. The UP carries user traffic while the CP carries signaling in the network. In Figure 4, the UPF 414 is in the UP and all other NFs,i.e., the AMF 400, SMF 408, PCF 410, AF 412, NSSF 402, AUSF 404, and UDM 406, are in the CP. Separating the UP and CP guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.

[0078] The core 5G network architecture is composed of modularized functions. For example, the AMF 400 and SMF 408 are independent functions in the CP. Separated AMF 400 and SMF 408 allow independent evolution and scaling. Other CP functions like the PCF 410 and AUSF 404 can be separated as shown in Figure 4. Modularized function design enables the 5GC network to support various services flexibly.

[0079] Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF. In the CP, a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity. The UP supports interactions such as forwarding operations between different UPFs.

[0080] Figure 5 illustrates a 5G network architecture using service-based interfaces between the NFs in the CP, instead of the point-to-point reference points / interfaces used in the 5G network architecture of Figure 4. However, the NFs described above with reference to Figure 4 correspond to the NFs shown in Figure 5. The service(s), etc., that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In Figure 5, the service based interfaces are indicated by the letter “N” followed by the name of the NF, e.g. Namf for the service based interface of the AMF 400 and Nsmf for the service based interface of the SMF 408, etc. The NEF 500 and the NRF 502, and NWDAF 508 in Figure 5 are not shown in Figure 4 discussed above. However, it should be clarified that all NFs depicted in Figure 4 can interact with the NEF 500, NRF 502, and NWDAF 508 of Figure 5 as necessary, though not explicitly indicated in Figure 4.

[0081] Some properties of the NFs shown in Figures 4 and 5 may be described in the following manner. The AMF 400 provides UE-based authentication, authorization, mobility management, etc. A UE 312 even using multiple access technologies is basically connected to a single AMF 400 because the AMF 400 is independent of the access technologies. The SMF 408 is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF 414 for data transfer. If a UE 312 has multiple sessions, different SMFs 408 may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF 412 provides information on the packet flow to the PCF 410 responsible for policy control in order to support QoS. Based on theinformation, the PCF 410 determines policies about mobility and session management to make the AMF 400 and SMF 408 operate properly. The AUSF 404 supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM 406 stores subscription data of the UE 312. The Data Network (DN), not part of the 5GC network, provides Internet access or operator services and similar.

[0082] An NF may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.

[0083] As used herein, a “consumer” can include any network function or network node in a role of "consuming" a service provided by a network node providing the service. Such a consumer can include a network function consumer that consumes a service or functionality that is provided by a corresponding network function provider. Various network functions, such as those described in Figures 4 and 5 can be network function consumers or providers at different times. As such, when reference is made to a Network Function consumer (NFc) or Network Function provider (NFp), any of the network functions described herein could be an NFc or NFp depending on the context.

[0084] To address the unauthorized access to UE information attack through a compromised NF, this disclosure proposes generally 1) a first embodiment, a mechanism to prevent this attack and in a 2) a second embodiment, a solution to predict, detect, prevent, and mitigate a compromised and misbehaving NF trying to gain unauthorized access to UE information.

[0085] Figure 6 illustrates an exemplary message sequence chart for a method for validating that a NF consumer (NFc) 604 is authorized to access User Equipment (UE) information according to some embodiments of the present disclosure. It is to be appreciated that in Figure 6 and in Figure 7, lines and boxes that are dashed are optional.

[0086] At step 606, the NFp 602 receives from the NFc 604 a service request that can also include the NFc 604’ s OAuth 2.0 access token. The service request may also include a request and / or one or more S-NSSAIs associated with the access token.

[0087] At step 608, the NFp 602 verifies the integrity of the OAuth 2.0 access token sent by the NFc and the validity of its claims.

[0088] On one hand, if the NFc 604’ s OAuth 2.0 access token integrity and claims are deemed invalid by the NFp 602, the NFp 602 rejects the NFc’s service request at step 610.

[0089] On the other hand, if the NFc 604’s OAuth 2.0 access token integrity and claims are deemed valid by the NFp 602, the NFp 602 verifies if the NFc 604’ s request requires sharing UE information. In such a scenario, the NFp 602 checks that NFc 604 is allowed to access ( asindicated by the NF Service Producer’s NSSAIs in the access token presented by the NF Service Consumer) at least one of the network slice(s) that the UE has access to (e.g., allowed S-NSSAIs, subscribed S-NSSAIs).

[0090] If the NFc 604 is requesting real-time UE context information, then the NFp 602 verifies that the NFc 604 network slices intersect with the UE allowed S-NSSAIs. To verify this, the NFp 602 acquires the UE allowed S-NSSAIs which are only available at the AMF 400.

[0091] Given that 3GPP does not currently define any AMF 400 service operation that allows any other NF to acquire UE allowed S-NSSAIs, proposed in this disclosure is a new service operation called Namf_Communication_UE_information part of the Namf —Communication API to enable an NFp 602 to require a UE or group of UEs allowed S-NSSAIs. Hence, the process continues as follows: At step 612, the NFp 602 sends an Namf_Communication_UE_Information service request to the AMF 400 with its related OAuth 2.0 access token.

[0092] The AMF 400 verifies at step 614 the integrity of the OAuth 2.0 access token sent by the NFp 602 and the validity of its claims.

[0093] If the NFp 602 OAuth 2.0 access token integrity and claims are deemed invalid by the AMF 400, the AMF 400 rejects the NFp 602 request. Given that the NFp 602 could not acquire the UE allowed S-NSSAIs, it will in turn reject the NFc 604 request.

[0094] Alternatively, if the NFp 602 OAuth 2.0 access token integrity and claims are deemed valid by the AMF 400, the AMF 400 processes the NFp 602 request and sends it the Namf_Communication_UE_Information service response including the UE allowed S-NSSAIs, among other information. The rejection or authorized S-NSSAIs are provided to the NFp 602 at step 616.

[0095] Upon receiving the UE allowed S-NSSAIs from the AMF 400, the NFp 602 determines, at step 624 if the NFc is allowed to access the UE information by validating that at least one of the allowed S-NSSAIs the UE is currently registered to intersect with NFp 602 NSSAI noted in the NFc 604 OAuth 2.0 access token.

[0096] Alternatively, if the NFc request pertains to a 5G procedure related to providing the UE in question access to the network (e.g., Namf_Communication_UEContextTransfer) and / or to a network slice; or considers reporting UE related information (e.g., UE last known location, etc.) the NFp 602 should verify that the NFc 604 network slices intersect with the UE subscribed S- NSSAIs. This can be performed based on one of the following methods.

[0097] The NFp sends an Nudm_SDM_Get request at step 618 to UDM 406 including its corresponding OAuth 2.0 access token to the UDM 406 with subscription data type set to sliceselection subscription to get the subscribed S-NSSAIs of the UE in question, for which 5G Subscription Permanent Identifier (SUPI) is also mentioned in the request.

[0098] The UDM 406 verifies at step 620 the integrity of the OAuth 2.0 access token sent by the NFp 602 and the validity of its claims.

[0099] If the NFp 602’s OAuth 2.0 access token integrity and claims are deemed invalid by the UDM 406, the UDM 406 rejects the NFp’s request. Given that the NFp’s could not acquire the UE subscribed S-NSSAIs, it will in turn reject the NFc 604’s request 606 (e.g., see step 626).

[0100] Alternatively, if the NFp 602’s OAuth 2.0 access token integrity and claims are deemed valid by the UDM 406, the UDM processes the NFp’s request and responds with the Nudm_SDM_Get service response including the UE subscribed S-NSSAIs, among other information. The rejection or approval with the S-NSSAIs is sent at step 622 from the UDM 406 to the NFp 602.

[0101] Upon receiving the UE subscribed S-NSSAIs from the UDM 406, the NFp 602 determines at step 624 if the NFc 604 is allowed to access the UE information by validating that at least one of the subscribed S-NSSAIs the UE is currently registered to intersect with NFp 602 NSSAI noted in the NFc 604’ s OAuth 2.0 access token.

[0102] In order to prevent network overload that may occur as a result of extra signaling entailed by potentially excessive Nudm_SDM_Get requests from the NFp 602 to the UDM 406 upon each NFc request to UE related information, the NFp 602 (i.e., through Nudm_SDM_Subscribe service operation) can subscribe at step 630 to receive notifications about slice selection subscription data for the different UEs it has access to their information in the network whenever these information are updated. This subscription step 630 is depicted last in the message sequence chart, but the subscription step 630 can occur at any time, including before receiving the initial service request from the NFc 604 at step 606.

[0103] Hence, if the NFp 602 was subscribed to receive the slice selection subscription data updates for the UE in question, the NFp 602 determines if the NFc 604 is allowed to access the UE information by validating that at least one of the subscribed S-NSSAIs, noted in the last notification received from the UDM 406 about the UE in question, intersect with NFp’s NSSAIs noted in the NFc’s OAuth 2.0 access token.

[0104] If, based on the matching step 624, the NFp 602 confirmed that the NFc 604 is allowed to access the UE information, the NFp 602 sends the NFc 604 the response at step 628 to its service request with the requested UE information.

[0105] If the NFc 604 is not allowed to access the UE information, the NFp 602 sends the rejection at step 626.

[0106] Figure 7 illustrates an exemplary message sequence chart for a method for detecting a compromised NFc that is attempting to gain unauthorized access to UE information according to some embodiments of the present disclosure.

[0107] An NFc trying to gain unauthorized access to UE information may be deemed malicious or compromised. Its security posture should be assessed to prevent any possible network disruption and data leakage. To detect such a malicious NFc, each NFp should calculate a new Key Performance Indicator (KPI) per NFc, namely nb_rejected_requests_[ NFc ], which represents the number of requests it received from the NFc, and which were rejected due to unauthorized UE information access attempts. Such KPI can be calculated per NFc over a certain period of time and reported to the Network Data Analytics Function (NWDAF). The NWDAF receives this KPI from all NFps in the network. It aggregates and derives related nb_rejected_requests_[NFc ] analytics and shares them with a security function. The security function can use these analytics to predict, detect and mitigate malicious NFcs. This process is described in Figure 7 and is compliant with 3GPP NWDAF functionality defined in 3GPP TS 23.288 VI 8.4.0. It can be detailed as follows.

[0108] At step 703 a security function 702 subscribes to the NWDAF analytics related to the proposed nb_rejected_requests_[NFc ] KPI by sending an Nnwdaf_AnalyticsSubscription_Subscribe (Analytics ID = NF security, NF type, NF ID). Given that 3GPP does not define any analytics related to NF security, it is proposed adding such analytics in Nnwdaf_AnalyticsSubscription API. The Nnwdaf_AnalyticsSubscription API should be updated accordingly to allow the security function 702 to specify to the NWDAF 508 the NF type and the NF Instance ID for which it is requiring the analytics. Note that the security function 702 may also specify a list of NFs.

[0109] At step 704, following the received subscription request, the NWDAF 508 issues one or many event exposure subscription requests to the corresponding NFs (e.g., NFp 602). That is, the NWDAF 508 sends an N [NF [_EventExposure Subscribe (e.g., Namf_EventExposure Subscribe) where [NF] is the NF acting as NFp 602 and for which the security function 702 requested the related analytics. The N[NF[_EventExposure_Subscribe related APIs defined in 3GPP for the different 5G NFs, need to be updated accordingly to support the new NF SECURITY event corresponding to reporting security related analytics such as the nb_ rejected— requests— [NFc ].

[0110] At step 706, upon receiving the N [NF [_EventExposure Subscribe, the [NF] acting as NFp 602 processes the request and calculates the nb_rejected_requests_[NFc ].

[0111] At step 708, the NF acting as NFp 602 then notifies the NWDAF 508 with the number of requests it rejected for each of its NFc’s because of unauthorized UE information access attempts. This is performed by sending the NWDAF 508 an N[NF]_EventExposure_Notify (nb_rejected_requests_[NFc] list). The notification of the NWDAF 508 can be one-time, periodic, etc., based on the NWDAF event subscription request parameters. Note that the N[NF ]_EventExposure _Notify related API needs to be updated to support reporting the nb_rejected_requests_[NFc ] list.

[0112] At step 710, the NWDAF 508 collects the nb_rejected_requests_[NFc] list from one or many NFs acting as NFps. It then derives the nb_rejected_requests_[NFc] (NWDAF) analytics for each NFc 604.

[0113] At step 712, the NWDAF 508 reports the derived nb_rejected_requests_[NFc] analytics to the security function 702 through an Nnwdaf_AnalyticsSubscription_Notify (nb_rejected_requests_[NFc] analytics). Note that the Nnwdaf_AnalyticsSubscription_Notify service operation defined in the Nnwdaf_AnalyticsSubscription API in 3GPP TS 23.288 V18.4.0 can be updated accordingly to support reporting the nb_rejected_requests_[NFc] analytics.

[0114] At step 714, the security function 702 may use the nb_rejected_requests_[NFc] analytics (e.g., as features in machine learning models, etc.) to predict, detect, prevent, and mitigate malicious NFcs.

[0115] Figure 8 is a schematic block diagram of a network node 800 according to some embodiments of the present disclosure. The network node 800 may be, for example, a network node that implements all or part of the functionality of the NFp 602, NWDAF 508, or any of the other core network nodes referred to herein. As illustrated, the network node 800 includes a control system 802 that includes one or more processors 804 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory 806, and a network interface 808. The one or more processors 804 are also referred to herein as processing circuitry. The one or more processors 804 operate to provide one or more functions of the network node 800 as described. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 806 and executed by the one or more processors 804.

[0116] Figure 9 is a schematic block diagram that illustrates a virtualized embodiment of the network node 800 of Figure 10 according to some embodiments of the present disclosure.Optional features are represented by dashed boxes. As used herein, a “virtualized” network node is an implementation of the network node 800 in which at least a portion of the functionality of the network node 800 is implemented as a virtual component(s) (e.g., via a virtual machine(s)running on a physical processing node(s) in a network(s). As illustrated, in this example, the network node 800 may include the control system 802, as described above. The network node 800 includes one or more processing nodes 900 coupled to or included as part of a network(s) 902. If present, the control system 802 is connected to the processing node(s) 900 via the network 902. Each processing node 900 includes one or more processors 904 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 906, and a network interface 908.

[0117] In this example, functions 910 of the network node 800 described herein are implemented at the one or more processing nodes 900 or distributed across the one or more processing nodes 900 and the control system 802 in any desired manner. In some particular embodiments, some or all of the functions 910 of the network node 800 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 900. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 900 and the control system 802 is used in order to carry out at least some of the desired functions 910.

[0118] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes at least one processor to carry out the functionality of the network node 800 or a node (e.g., a processing node 900) implementing one or more of the functions 910 of the network node 800 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0119] Figure 10 is a schematic block diagram of the network node 800 according to some other embodiments of the present disclosure. The network node 800 includes one or more functions which can be implemented in software. The functions include the NFp 602 as well as the NWDAF 508. It is to be appreciated that different network nodes 800 can implement the NFp 602 and NWDAF 508 respectively.

[0120] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitrymay be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0121] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0122] Some of the embodiments of the present disclosure include:

[0123] Embodiment 1: A method for validating that a Network Function consumer, NFc, (604) is authorized to access User Equipment device, UE, information performed by a Network Function provider, NFp, (602) the method comprising: receiving (606), from the NFc (604), a service request comprising an access token; determining (608) whether the access token and a request in the service request is valid; in response to the access token being valid, and the service request comprising a request for UE information, determining (624) whether one or more Single Network Slice Selection Assistance Information, S-NSSAIs, in the access token, match one or more UE authorized S-NSSAIs in the service request; in response to one of the S-NSSAIs in the access token matching one or more authorized S-NSSAIs, providing (628) a response to the NFc (604), wherein the response comprises the UE information.

[0124] Embodiment 2: The method of embodiment 1, further comprising: in response to the access token not being valid, rejecting (610) the service request.

[0125] Embodiment 3: The method of any of embodiments 1 to 2, further comprising: in response to one of the S-NSSAIs in the access token not matching the one or more authorized S- NSSAIs, rejecting (626) the service request.

[0126] Embodiment 4: The method of any of embodiments 1 to 3, wherein the authorized S- NSSAIs were previously retrieved from at least one of an Access and Mobility Management Function, AMF, (400) or a Unified Data Management Function, UDM (406).

[0127] Embodiment 5: The method of any of embodiments 1 to 3, wherein in response to the UE information requested in the service request being real-time UE context information, the method further comprises: providing (612) another service request to an Access and MobilityManagement Function, AMF, (400) with the other service request comprising the access token from the NFc (604).

[0128] Embodiment 6: The method of embodiment 5, further comprising: receiving (616), from the AMF (400), at least one of a rejection or the authorized S-NSSAIs.

[0129] Embodiment 7: The method of any of embodiments 1 to 3, wherein in response to the UE information requested in the service request being UE access authorization to a network or UE monitoring information, the method further comprises: providing (618) another service request to a Unified Data Management Function, UDM, (406) with the other service request comprising the access token from the NFc (604).

[0130] Embodiment 8: The method of embodiment 7, further comprising: receiving (622), from the UDM (406), at least one of a rejection or the authorized S-NSSAIs.

[0131] Embodiment 9: The method of any of embodiments 1 to 3, further comprising: subscribing (630), with a Unified Data Management Function, UDM, (406) to updates on authorized S-NSSAIs for UEs associated with the NFp (602).

[0132] Embodiment 10: The method of any of embodiments 1 to 9, further comprising: receiving (704), from a Network Data Analytics Function, NWDAF, (508) an event exposure subscription; and providing (708) to the NWDAF (508), rejected request information associated with an NFc (604).

[0133] Embodiment 11: The method of embodiment 10, wherein the rejected request information comprises a list of rejected requests associated with the NFc (604) in a defined time period.

[0134] Embodiment 12: A network node that implements a Network Function provider, NFp, (602) that is configured to validate that a Network Function consumer, NFc, (604) is authorized to access User Equipment device, UE, information, the network node comprising processing circuitry configured to cause the network node to perform any of the methods of embodiments 1 to 11.

[0135] Embodiment 13: A method for detecting a compromised Network Function consumer, NFc, (604) attempting to gain unauthorized access to User Equipment device, UE, information performed by a Network Data Analytics Function, NWDAF, (508) the method comprising: providing (704), to one or more Network Function providers, NFps, (602) and event exposure subscription; receiving (708) from the one or more NFps (602), rejected request information comprising one or more lists of rejected requests associated with the NFc (604) in a defined time period; based on the one or more lists of rejected requests, determining (710)rejected request analytics; and provide (712) the rejected request analytics to a security function (702).

[0136] Embodiment 14: The method of embodiment 13, further comprising: prior to providing the event exposure subscription to the one or more NFps (602), receiving (703) a subscription from the security function (702).

[0137] Embodiment 15: A network node that implements a Network Data Analytics Function, NWDAF, (508) that is configured to detect a compromised Network Function consumer, NFc, (604) attempting to gain unauthorized access to User Equipment device, UE, information, the network node comprising processing circuitry configured to cause the network node to perform any of the methods of embodiments 13 to 14.REFERENCES1. 3rd Generation Partnership (3GPP); “Technical Specification Group Services and System Aspects; Security architecture and procedures for 5G system (Release 18)”, TS 33.501, V18.3.0 (2023-09)2. 3rd Generation Partnership (3GPP); “Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 18)”, TS 23.502, V18.3.0 (2023-09)3. Adaptive Mobile Security, “A Slice in Time: Slicing Security in 5G Core Networks”, White Paper, v. 1.0, (2021-03) https: / / info.enea.com / Slicing-Security-in-5G-Core-Networks4. 3rd Generation Partnership (3GPP); “Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 18), TS 23.501, v 18.3.0, (2023-09)5. 3rd Generation Partnership (3GPP; Technical Specification Group Services and System Aspects; Architecture enhancements for 5G System (5GS) to support network data analytics services (Release 18), 3GPP TS 23.288 V18.4.0 (2023-12)6. 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Data Analytics Services; Stage 3 (Release 18), 3GPP TS 29.520 V18.4.0 (2023-12)

Claims

Claims1. A method for validating that a Network Function consumer, NFc, (604) is authorized to access User Equipment device, UE, information performed by a Network Function provider, NFp, (602) the method comprising: receiving (606), from the NFc (604), a service request comprising an access token; determining (608) whether the access token and a request in the service request is valid; in response to the access token being valid, and the service request comprising a request for UE information, determining (624) whether one or more Single Network Slice Selection Assistance Information, S-NSSAIs, in the access token match one or more UE authorized S- NSSAIs in the service request; in response to one of the S-NSSAIs in the access token matching one or more authorized S-NSSAIs, providing (628) a response to the NFc (604), wherein the response comprises the UE information.

2. The method of claim 1, further comprising: in response to the access token not being valid, rejecting (610) the service request.

3. The method of any of claims 1 to 2, further comprising: in response to one of the S-NSSAIs in the access token not matching the one or more authorized S-NSSAIs, rejecting (626) the service request.

4. The method of any of claims 1 to 3, wherein the one or more authorized S-NSSAIs were previously retrieved from at least one of an Access and Mobility Management Function, AMF, (400) or a Unified Data Management Function, UDM (406).

5. The method of any of claims 1 to 3, wherein in response to the UE information requested in the service request being real-time UE context information, the method further comprises: providing (612) another service request to an Access and Mobility Management Function, AMF, (400) with the other service request comprising the access token from the NFc (604).

6. The method of claim 5, further comprising: receiving (616), from the AMF (400), at least one of a rejection or the one or more authorized S-NSSAIs.

7. The method of any of claims 1 to 3, wherein in response to the UE information requested in the service request being UE access authorization to a network or UE monitoring information, the method further comprises: providing (618) another service request to a Unified Data Management Function, UDM, (406) with the other service request comprising the access token from the NFc (604).

8. The method of claim 7, further comprising: receiving (622), from the UDM (406), at least one of a rejection or the one or more authorized S-NSSAIs.

9. The method of any of claims 1 to 3, further comprising: subscribing (630), with a Unified Data Management Function, UDM, (406) to updates on authorized S-NSSAIs for UEs associated with the NFp (602).

10. The method of any of claims 1 to 9, further comprising: receiving (704), from a Network Data Analytics Function, NWDAF, (508) an event exposure subscription; and providing (708) to the NWDAF (508), rejected request information associated with an NFc (604).

11. The method of claim 10, wherein the rejected request information comprises a list of rejected requests associated with the NFc (604) in a defined time period.

12. A network node (800) that implements a Network Function provider, NFp, (602) that is configured to validate that a Network Function consumer, NFc, (604) is authorized to access User Equipment device, UE, information, the network node comprising processing circuitry configured to: receive (606), from the NFc (604), a service request comprising an access token; determine (608) whether the access token and a request in the service request is valid; in response to the access token being valid, and the service request comprising a request for UE information, determine (624) whether one or more Single Network Slice Selection Assistance Information, S-NSSAIs in the access token match one or more UE authorized S- NSSAIs in the service request;in response to one of the S-NSSAIs in the access token matching one or more authorized S-NSSAIs, provide (628) a response to the NFc (604), wherein the response comprises the UE information.

13. The network node (800) of claim 12, wherein the processing circuitry is further configured to: in response to the access token not being valid, reject (610) the service request.

14. The network node (800) of any of claims 12 to 13, wherein the processing circuitry is further configured to: in response to one of the S-NSSAIs in the access token not matching the one or more authorized S-NSSAIs, reject (626) the service request.

15. The network node (800) of any of claims 12 to 14, wherein the one or more authorized S- NSSAIs were previously retrieved from at least one of an Access and Mobility Management Function, AMF, (400) or a Unified Data Management Function, UDM (406).

16. The network node (800) of any of claims 12 to 14, wherein in response to the UE information requested in the service request being real-time UE context information, the processing circuitry is further configured to: provide (612) another service request to an Access and Mobility Management Function, AMF, (400) with the other service request comprising the access token from the NFc (604).

17. The network node (800) of claim 16, wherein the processing circuitry is further configured to: receive (616), from the AMF (400), at least one of a rejection or the one or more authorized S-NSSAIs.

18. The network node (800) of any of claims 12 to 14, wherein in response to the UE information requested in the service request being UE access authorization to a network or UE monitoring information, the method further comprises: providing (618) another service request to a Unified Data Management Function, UDM, (406) with the other service request comprising the access token from the NFc (604).

19. The network node (800) of claim 18, wherein the processing circuitry is further configured to: receive (622), from the UDM (406), at least one of a rejection or the one or more authorized S-NSSAIs.

20. The network node (800) of any of claims 12 to 14, wherein the processing circuitry is further configured to: subscribe (630), with a Unified Data Management Function, UDM, (406) to updates on authorized S-NSSAIs for UEs associated with the NFp (602).

21. The network node (800) of any of claims 12 to 20, wherein the processing circuitry is further configured to: receive (704), from a Network Data Analytics Function, NWDAF, (508) an event exposure subscription; and provide (708), to the NWDAF (508), rejected request information associated with the NFc (604).

22. The network node (800) of claim 21, wherein the rejected request information comprises a list of rejected requests associated with the NFc (604) in a defined time period.

23. A method for detecting a compromised Network Function consumer, NFc, (604) attempting to gain unauthorized access to User Equipment device, UE, information performed by a Network Data Analytics Function, NWDAF, (508) the method comprising: providing (704), to one or more Network Function providers, NFps, (602) an event exposure subscription; receiving (708) from the one or more NFps (602), rejected request information comprising one or more lists of rejected requests associated with the NFc (604) in a defined time period; based on the one or more lists of rejected requests, determining (710) rejected request analytics; and providing (712) the rejected request analytics to a security function (702).

24. The method of claim 23, further comprising:prior to providing the event exposure subscription to the one or more NFps (602), receiving (703) a subscription from the security function (702).

25. A network node (800) that implements a Network Data Analytics Function, NWDAF, (508) that is configured to detect a compromised Network Function Consumer, NFc, (604) attempting to gain unauthorized access to User Equipment device, UE, information, the network node comprising processing circuitry configured to: provide (704), to one or more Network Function providers, NFps, (602) an event exposure subscription; receive (708), from the one or more NFps (602), rejected request information comprising one or more lists of rejected requests associated with the NFc (604) in a defined time period; based on the one or more lists of rejected requests, determine (710) rejected request analytics; and provide (712) the rejected request analytics to a security function (702).

26. The network node (800) of claim 25, wherein the processing circuitry is further configured to: prior to providing the event exposure subscription to the one or more NFps (602), receive (703) a subscription from the security function (702).

Images