FORM 2
THE PATENTS ACT, 1970 (39 of 1970) THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10; rule 13)
TITLE OF THE INVENTION
SYSTEM AND METHOD FOR NETWORK FUNCTION (NF) WHITELISTING IN
COMMUNICATION NETWORK
APPLICANT
JIO PLATFORMS LIMITED
of Office-101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad -
380006, Gujarat, India; Nationality : India
The following specification particularly describes
the invention and the manner in which
it is to be performed

RESERVATION OF RIGHTS
[001] A portion of the disclosure of this patent document contains
material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, integrated circuit (IC) layout design, and/or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (herein after referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.
TECHNICAL FIELD
[002] The present disclosure relates to a field of a communication network,
and specifically to a system and a method for Network Function (NF) whitelisting in a communication network.
BACKGROUND
[003] The following description of related art is intended to provide
background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.
[004] Generally, 3rd Generation Partnership Project (3GPP) release 33.501
provides methods for authentication and authorization between a Network Function (NF) and a Network Repository Function (NRF). An existing NRF already provides support for direct method authentication, which are also used in InDirect approach. In the InDirect approach, the NF Service Producer and NF Service Consumer shall use implicit authentication by relying on authentication between NF Service Consumer and Service Communication Proxy (SCP), and between the SCP and the NF Service Producer, provided by the transport layer protection solution, NDS/IP, or physical security. These methods either use protection at a transport layer by

Transport Layer Security/Hypertext Transfer Protocol Secure (TLS/HTTPS) or Physical Security. TLS/HTTPS support is provided by NRF but not all NFs use authentication approach for TLS. Similarly, although the existing NRF is closely guarded and provides physical security, still there might be attack avenues that hacker may use.
[005] To plug some of those avenues, standard has also provided with
direction of using the Client Credentials Assertion (CCA) especially during an indirect communication with NRF which is currently not supported by the NRF. But even if the NRF offers the CCA based authentication in future, it might happen that not all NFs are ready with CCA. Using either CCA or HTTPS may limit those types of NFs. In addition, CCA may not be used with Route Processor (RP) NFs, thus further tuning needs to be done at the NRF.
[006] Thus, there is, a need to provide a solution which includes HTTPS
and CCA as option but also provides other means to whitelist/blacklist the NFs that may communicate with the NRF by overcoming the deficiencies of the prior arts.
OBJECTS OF THE PRESENT DISCLOSURE
[007] It is an object of the present disclosure to provide a system for
Network Function (NF) whitelisting in a communication network.
[008] It is an object of the present disclosure to support authentication
based on Client Credentials Assertion (CCA).
[009] It is an object of the present disclosure to support authentication
based on whitelisting conditions/list with ability to enable or disable the feature.
[0010] It is an object of the present disclosure to support authorization for
own services (Management and Discovery) based on Open Authorization (OAuth)
Token.
[0011] It is an object of the present disclosure to provide support for
counters and logs for authentication and authorization.
SUMMARY

[0012] A method for performing authentication of a plurality of network
functions (NFs) in a network is described. The method comprises receiving, by a
network repository function (NRF), a message from one of the plurality of NFs.
The method comprises authenticating, by the NRF, the NF based on a whitelisting
authentication. The whitelisting authentication comprises of checking, by the NRF,
whether a runtime user configurable flag is enabled. On detecting that the runtime
user configurable flag is enabled, performing, by the NRF, authentication of the
message by checking whether the message match present in a whitelist and missing
in a blacklist. On detecting that the message match present in the whitelist and
missing in the blacklist, authenticating, by the NRF, the NF.
[0013] In some embodiment, the message comprises a registration request
or an access request.
[0014] In some embodiment, the method further comprises on detecting that
the message match present in the blacklist, rejecting, by the NRF, the authentication
of the NF.
[0015] In some embodiment, the whitelist and the blacklist comprise
combination of NF instance identifier (ID) and a NF type or combination of an
internet protocol (IP) subnet and the NF type. The NRF is configured to enable or
disable the whitelisting authentication.
[0016] In some embodiment, the combination of NF instance ID and the NF
type comprises a NF instance ID range, the NF type, and a public land mobile
network (PLMN). The combination of the IP subnet and the NF type comprises an
IP range, the NF type and the PLMN.
[0017] In some embodiment, the NRF is configured to create counters for
authentication and authorization, wherein the NRF is configured to generate a log
for failed authentication attempts.
[0018] In some embodiment, the NRF is configured to support
authentication based on a client credentials assertion (CCA).
[0019] In some embodiment, the NRF is configured to support authorization
by providing an open authorization token for NRF services and management and
discovery services.

[0020] In some embodiment, the NRF is configured to perform one or more
authentication methods. The authentication methods comprise a hypertext transfer
protocol secure (HTTPS), a client credentials assertion (CCA) and the whitelisting.
The method comprises performing authentication in order of the HTTPS, the CCA
and the whitelisting authentication.
[0021] In some embodiment, the method further comprises authenticating a
first message received from a direct peer node and allowing subsequent messages
from the direct peer node, wherein the first message is a NF register message.
[0022] In another exemplary embodiment, a system for performing
authentication of a plurality of network functions (NFs) in a network by a network
repository function (NRF) is described. The NRF comprises a receiving unit
configured to receive a message from one of the plurality of NFs. An authentication
unit configured to authenticate the NF based on a whitelisting authentication. The
whitelisting authentication comprises of a processing unit configured to check
whether a runtime user configurable flag is enabled. On detecting that the runtime
user configurable flag is enabled, the authentication unit configured to perform
authentication of the message by checking whether the message match present in a
whitelist and missing in a blacklist. On detecting that the message match present in
the whitelist and missing in the blacklist, the authentication unit configured to
authenticate the NF.
[0023] In some embodiment, the message comprises a registration request
or an access request.
[0024] In some embodiment, on detecting that the message match present
in the blacklist, the authentication unit configured to reject the authentication of the
NF.
[0025] In some embodiment, the whitelist and the blacklist comprise
combination of NF instance identifier (ID) and a NF type or combination of an
internet protocol (IP) subnet and the NF type. The NRF is configured to enable or
disable the whitelisting authentication.
[0026] In some embodiment, the combination of NF instance identifier (ID)
and the NF type comprises a NF instance ID range, the NF type and a public land

mobile network (PLMN). The combination of the IP subnet and the NF type
comprises an IP range, the NF type and the PLMN.
[0027] In some embodiment, the NRF is configured to create counters for
authentication and authorization. The NRF is configured to generate a log for failed
authentication attempts.
[0028] In some embodiment, the NRF is configured to support
authentication based on a client credentials assertion (CCA).
[0029] In some embodiment, the NRF is configured to support authorization
by providing an open authorization token for NRF services and management and
discovery services.
[0030] In some embodiment, the NRF is configured to perform one or more
of authentication methods. The authentication methods comprise a hypertext
transfer protocol secure (HTTPS), a client credentials assertion (CCA) and the
whitelisting authentication. The NRF is configured to perform authentication in
order of the https, the CCA and the whitelisting authentication.
[0031] In some embodiment, the NRF is configured to authenticate a first
message received from a direct peer node and not authenticating for subsequent
messages from the direct peer node, wherein the first message is a NF register
message.
BRIEF DESCRIPTION OF THE DRAWINGS
[0032] In the figures, similar components and/or features may have the
same reference label. Further, various components of the same type may be
distinguished by following the reference label with a second label that distinguishes
among the similar components. If only the first reference label is used in the
specification, the description is applicable to any one of the similar components
having the same first reference label irrespective of the second reference label.
[0033] The diagrams are for illustration only, which thus is not a limitation
of the present disclosure, and wherein:
[0034] FIG. 1 illustrates an exemplary network architecture (100) in which
or with which embodiments of the present disclosure may be implemented.

[0035] FIG. 2A illustrates an exemplary block diagram (200A) of a network
repository function (NRF) having a NF whitelisting system (108), in accordance
with an embodiment of the present disclosure.
[0036] FIG. 2B illustrates an exemplary flow diagram (200B) of performing
whitelisting authentication of a plurality of network functions (NFs) in a network
by a network repository function (NRF), in accordance with an embodiment of the
present disclosure.
[0037] FIG. 3 illustrates an exemplary computer system (300) in which or
with which embodiments of the present disclosure may be implemented.
LIST OF REFERENCE NUMERICAL 100 - Network architecture 102 - Users
102-1, 102-2…102-N - Individual users 104 - User equipment (collective)
104-1, 104-2…104-N - Individual computing devices or user equipments 200 – NF whitelisting system 202 - Processor(s) 204 – Memory 206 - Interface
208 - Processing unit/engine(s) 210 - Database 212 – Authorization Unit 214 - Authentication Unit 216 – Other Units 220 – Receiving Unit 300 - Computer system 310 - External storage device 320 - Bus
330 - Main memory 340 - Read only memory (ROM)

350 - Mass storage device 360 - Communication port 370 - Processor (within computer system)
DETAILED DESCRIPTION
[0038] In the following description, for the purposes of explanation, various
specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.
[0039] The ensuing description provides exemplary embodiments only, and
is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.
[0040] Specific details are given in the following description to provide a
thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known

circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
[0041] Also, it is noted that individual embodiments may be described as a
process that is depicted as a flowchart, a flow diagram, a data flow diagram, a 5 structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a 10 procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
[0042] The word “exemplary” and/or “demonstrative” is used herein to
mean serving as an example, instance, or illustration. For the avoidance of doubt,
15 the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms
20 “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.
[0043] Reference throughout this specification to “one embodiment” or “an
25 embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment.
9

Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0044] The terminology used herein is to describe particular embodiments
only and is not intended to be limiting the disclosure. As used herein, the singular 5 forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other
10 features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any combinations of one or more of the associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms
15 are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without
20 departing from the scope of the invention as defined herein.
[0045] As used herein, an “electronic device”, or “portable electronic
device”, or “user device” or “communication device” or “user equipment” or “device” refers to any electrical, electronic, electromechanical, and computing device. The user device is capable of receiving and/or transmitting one or
25 parameters, performing function/s, communicating with other user devices, and transmitting data to the other user devices. The user equipment may have a processor, a display, a memory, a battery, and an input-means such as a hard keypad and/or a soft keypad. The user equipment may be capable of operating on any radio access technology including but not limited to IP-enabled communication, Zig Bee,
30 Bluetooth, Bluetooth Low Energy, Near Field Communication, Z-Wave, Wi-Fi,
10

Wi-Fi direct, etc. For instance, the user equipment may include, but not limited to, a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other device as may be obvious to a 5 person skilled in the art for implementation of the features of the present disclosure.
[0046] Further, the user device may also comprise a “processor” or
“processing unit” includes processing unit, wherein processor refers to any logic circuitry for processing instructions. The processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal
10 processor, a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input/output processing, and/or any other functionality that enables the working of
15 the system according to the present disclosure. More specifically, the processor is a hardware processor.
[0047] Generally, 3rd Generation Partnership Project (3GPP) release 33.501
provides methods for authentication and authorization between a Network Function (NF) and a Network Repository Function (NRF). An existing NRF already provides
20 support for direct method authentication, which are also used in InDirect approach. These methods either use protection at a transport layer by Transport Layer Security/Hypertext Transfer Protocol Secure (TLS/HTTPS) or Physical Security. TLS/HTTPS support is provided by NRF but not all NFs use authentication approach for TLS. Similarly, although the existing NRF is closely guarded and
25 provides world class physical security, still there might be attack avenues that hacker may use.
[0048] The present disclosure may provide a system for network function
(NF) whitelisting in a communication network. The present disclosure may support authentication based on Client Credentials Assertion (CCA). The present disclosure
30 may support authentication based on whitelisting conditions/list with ability to
11

enable or disable the feature. The present disclosure may support authorization for
own services (Management and Discovery) based on Open Authorization (OAuth)
Token. The present disclosure may provide support for counters and logs for
authentication and authorization.
5 [0049] The present disclosure may be valid for home Public Land Mobile
Network (PLMN) and may be optional. In case NFs may not use the CCA, then the NRF may support authentication based on whitelisting of NF for communication sent towards NRF based on various criteria such as combination of NFInstanceID and NFType or Internet Protocol (IP) Subnet/Range and NFType etc. NRF may be
10 able to enable or disable whitelisting feature.
[0050] The NRF already provides support for providing the open
authentication (OAuth) Token for authorization for other NF provided NF services. NRF may also extend the same for self-provided services i.e., NRF may be able to provide token for NRF services and also authenticate the token received from
15 consumers for management/discovery services.
[0051] The NRF may be able to create counters for authentication and
authorization and may generate logs in case NF authentication fails and similar for
authorization failed cases.
[0052] In an aspect, the network repository function (NRF) may work as a
20 centralized repository for all the network functions (NFs) in the operator's network. The NRF may allow NFs to register and discover each other. The network functions are the logical entities or software-based functionalities that define how the network operates and processes data. Examples of the network functions (NFs) comprise access and mobility management function (AMF), session management function
25 (SMF), user plane function (UPF), policy control function (PCF), authentication server function (AUSF), and other logical components that define the behavior and operation of the network.
[0053] The various embodiments of the present disclosure will be explained
in detail with reference to FIGs. 1 to 3.
30 [0054] FIG. 1 illustrates an exemplary network architecture (100) in which
or with which embodiments of the present disclosure may be implemented.
12

[0055] Referring to FIG. 1, the network architecture (100) may include one
or more computing devices or user equipments (104-1, 104-2…104-N) associated with one or more users (102-1, 102-2…102-N) in an environment. A person of ordinary skill in the art will understand that one or more users (102-1, 102-2…102-5 N) may be individually referred to as the user (102) and collectively referred to as the users (102). Similarly, a person of ordinary skill in the art will understand that one or more user equipments (104-1, 104-2…104-N) may be individually referred to as the user equipment (104) and collectively referred to as the user equipment (104). A person of ordinary skill in the art will appreciate that the terms “computing 10 device(s)” and “user equipment” may be used interchangeably throughout the disclosure. Although three user equipments (104) are depicted in FIG. 1, however any number of the user equipments (104) may be included without departing from the scope of the ongoing description.
[0056] In an embodiment, the user equipment (104) may include smart
15 devices operating in a smart environment, for example, an Internet of Things (IoT)
system. In such an embodiment, the user equipment (104) may include, but is not
limited to, smart phones, smart watches, smart sensors (e.g., mechanical, thermal,
electrical, magnetic, etc.), networked appliances, networked peripheral devices,
networked lighting system, communication devices, networked vehicle accessories,
20 networked vehicular devices, smart accessories, tablets, smart television (TV),
computers, smart security system, smart home system, other devices for monitoring
or interacting with or for the users (102) and/or entities, or any combination thereof.
A person of ordinary skill in the art will appreciate that the user equipment (104)
may include, but is not limited to, intelligent, multi-sensing, network-connected
25 devices, that can integrate seamlessly with each other and/or with a central server
or a cloud-computing system or any other device that is network-connected.
[0057] In an embodiment, the user equipment (104) may include, but is not
limited to, a handheld wireless communication device (e.g., a mobile phone, a smart phone, a phablet device, and so on), a wearable computer device (e.g., a head-30 mounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop
13

computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and/or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the user equipment (104) may include, but is not limited to, any electrical, electronic, 5 electro-mechanical, or an equipment, or a combination of one or more of the above devices such as virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device, wherein the user equipment (104) may include one or more in-built or externally coupled accessories 10 including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user (102) or an entity (110) such as touch pad, touch enabled screen, electronic pen, and the like. The entity (110) may be an administrator. A person of ordinary skill in the art will appreciate that the user equipment (104) may not be restricted to the mentioned 15 devices and various other devices may be used.
[0058] Referring to FIG. 1, the user equipment (104) may communicate
with a system (108), for example, a NF whitelisting system, through a network (106). In an embodiment, the network (106) may include at least one of a Fifth Generation (5G) network, 6G network, or the like. The network (106) may enable 20 the user equipment (104) to communicate with other devices in the network architecture (100) and/or with the system (108). The network (106) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (106) may be implemented as, or include any of a variety of different communication technologies such as a wide area network 25 (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like.
[0059] In another exemplary embodiment, the centralized server (112) may
include or comprise, by way of example but not limitation, one or more of: a stand-30 alone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a
14

virtualized server, one or more processors executing code to function as a server,
one or more machines performing server-side functionality as described herein, at
least a portion of any of the above, some combination thereof.
[0060] In accordance with embodiments of the present disclosure, the NF
5 whitelisting system (108) may be designed and configured for supporting authentication based on CCA. The NF whitelisting system (108) may support authentication based on whitelisting conditions/list with ability to enable or disable the feature. The NF whitelisting system (108) may support authorization for own services (Management and Discovery) based on OAuth Token. The NF whitelisting
10 system (108) may provide support for counters for authentication and authorization. The NF whitelisting system (108) may provide for logs for authentication and authorization failure.
[0061] Although FIG. 1 shows exemplary components of the network
architecture (100), in other embodiments, the network architecture (100) may
15 include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other components of the network architecture (100).
20 [0062] FIG. 2A illustrates an exemplary block diagram (200A) of a network
repository function (NRF) having the NF whitelisting system (108), in accordance with an embodiment of the present disclosure.
[0063] In an aspect, the system (108) may include one or more processor(s)
(202). The one or more processor(s) (202) may be implemented as one or more
25 microprocessors, microcomputers, microcontrollers, edge or fog microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, one or more processor(s) (202) may be configured to fetch and execute computer-readable instructions stored in a memory (204) of the system (108). The
30 memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium,
15

which may be fetched and executed to create or share data packets over a network service. The memory (204) may comprise any non-transitory storage device including, for example, volatile memory such as Random-Access Memory (RAM), or non-volatile memory such as Erasable Programmable Read-Only Memory 5 (EPROM), flash memory, and the like.
[0064] In an embodiment, the system (108) may include an interface(s)
(206). The interface(s) (206) may include a variety of interfaces, for example, interfaces for data input and output devices, referred to as I/O devices, storage devices, and the like. The interface(s) (206) may facilitate communication of the
10 system (108). The interface(s) (206) may also provide a communication pathway
for one or more components of the system (108). Examples of such components
include, but are not limited to, processing unit/engine(s) (208) and a database (210).
[0065] The processing unit/engine(s) (208) may be implemented as a
combination of hardware and programming (for example, programmable
15 instructions) to implement one or more functionalities of the processing unit(s) (208). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing unit(s) (208) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the
20 hardware for the processing unit(s) (208) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing unit(s) (208). In such examples, the system (108) may comprise the machine-readable storage
25 medium storing the instructions and the processing resource to execute the
instructions, or the machine-readable storage medium may be separate but
accessible to the system (108) and the processing resource. In other examples, the
processing unit(s) (208) may be implemented by an electronic circuitry.
[0066] In an embodiment, the system (108) may include an authorization
30 unit (212), an authentication unit (214), a receiving unit (220), and other units (216). The authorisation unit (212) may authorize services (e.g., Nnrf_NFManagement
16

and Nnrf_NFDiscovery) by means of open authorization 2 (OAuth2) protocol. In
an aspect, The NnrfNFManagement service may allow a network function NF
instance in the serving PLMN to register, update or deregister its profile in the NRF.
The Nnrf_NFDiscovery service may allow a network function instance to discover
5 services offered by other network function instances, by querying the local NRF.
In an aspect, the OAuth 2 is an authorization protocol for granting access to a set of
resources, for example, remote APIs or user data. The OAuth 2 uses access tokens.
[0067] The NRF may act as an authorization server for self-services and
may be able to provide an access token requested for NnrfNFManagement and 10 Nnrf_NFDiscovery services for self by acting as producer for the Nnrf_AccessToken service. The NRF may also act as a resource server to be able to respond to requests sent using the access token generated earlier. The NRF may also provide means for authorization between NRF-to-NRF communication for NRF to NRF forwarding cases. The NRF may support both forwarding token 15 requests towards Security Edge Protection Proxy (SEPP) for other PLMNs and also accept and authorize the token services request from other PLMNs via SEPP for allowed service operations (such as subscribe/discovery but not for operations such as registration etc).
[0068] The receiving unit (220) may receive messages from the NFs. The
20 message may be a registration request or an access request.
[0069] NRF authorization for self-services may be performed by following
steps:
. Initially message from each internal NF may be NFRegister. Further for
NFRegister message, no authorization (i.e., OAuth token) may be required
25 rather NF may make use of CCA/HTTPS/Whitelisting for authentication.
All NFManagement service operation may be secured with OAuth token.
The SEPP or NRF may register with other NRFs. Also, NRF to NRF
registration may not be unidirectional rather will be bidirectional.
. Once NF has registered to NRF and if NF supports OAuth token,
30 AccessToken service may be used to get the access token for NRF service
operations as well i.e., token may need to be sent for other NFManagement
17

and NFDiscovery service operation. Currently, NRF may provide a runtime
user configurable flag (NFServiceAuth, NRFServiceAuth and
SEPPServiceAuth: 3 separate flags for NF to NRF/NRF to NRF/SEPP to
NRF authorization) for enforcing NRF service operations (NFManagement
5 and NFDiscovery) authentication. If flag is set to false, then NF (or SEPP/
other NRF) may make use of NRF service operations including
management and discovery with or without access token. But, in case flag
is set to true, then all NFs (or message received from SEPP or other NRF)
may make use of authentication token for using the discovery and
10 management service of NRF. Default value of flag may be false.
[0070] The NRF may support access token request forwarding from one
NRF to other NRF or NRF to SEPP depending on PLMN or other criteria. Similarly, the NRF may also support generating token for requests received from other NRF or via SEPP (where NRF or SEPP may be pre-authenticated during 15 registration as optional).
[0071] The NRF may have counters for the operations (i.e., token generated
for self-service, token generated for other NFs, token generated for requests received from other PLMNs, tokens validated for self, token validated for self (from other NRF), token validated for self (from SEPP), token validation failed (separate 20 for NFs, other NRF, SEPP), token request forwarded to other NRF, token request forwarded to SEPP). The NRF may also support logging for failed validation in error mode (in error mode all may be logged).
[0072] The authentication unit (214) may perform NF authentication which
supports following additional cases:
25 a. Client Credentials Assertion (CCA): This method may be for self NFs (not
roaming partner NFs). The NRF may support receiving a NF consumer
signed CCA (token). Key used by NF for signing may be pre-shared
between NRF and the self NF. This token may include NFInstance Identifier
(ID), timestamp, expiration time, audience. CCA may also include x5u/x5c
30 header parameter for public key certificate or certificate chain used for
signing the client authentication assertion. The NRF may validate the
18

signature, timestamp, expiration time, audience claim and instance ID in
CCA matches instance ID in public key certificate used for signing the
CCA. The NRF may generate counter for CCA requests received. Any CCA
authentication failure may be logged in error mode as well. NF sending
5 CCA may be optional and may not be mandatory. For using CCA, NF may
include CCA token in first message towards NRF. NRF may validate CCA token and mark the NF as authenticated which may allow subsequent messages from that NF to be deemed authenticated and no further authentication may be needed till NF is deregistered or registers again with
10 NRF.
b. Whitelist and Blacklist combination: NRF may provide a runtime user configurable flag for enabling or disabling use of this feature with default value as enabled. Further with this feature, NRF may provide two major blocks with 1st being “Whitelist” and 2nd being “Blacklist”. For
15 authentication for individual message/NF pass, the message match may be
present in Whitelist and may be missing in blacklist. This list may check all messages received by the NRF. Whitelist and Blacklist may contain following sub configuration lists/ Table.
. NFInstanceID and NFType Combination: This table may contain 4
20 columns as depicted with possible values examples below.

NFInstanceID Start NFInstanceID End NFType
(Comma
Separated
Values) PLMN (Comma
Separated
Values)
494e524a-4d55-
4bc1-b9da-055046000001 494e524a-4d55-
4bc1-b9da-055046000025 PCF Home1, Home2
494e524a-*-*-*-* 494e524d-*-*-*-* All Home1, RP2
* * All All
19

494e524a-4d55- 494e524a-4d55- PCF, BSF, Home3
4bc1-b9da- 4bc1-b9da- CHF, NRF
055046* 05504f*
494e524a-*-*- 494e524a-*-*- AMF RP4, RP5
b9da- b9da-
055046000001 055046000100
1. NFInstanceID Start and End may indicate the NFInstance ID
range that may be present for any incoming message to NRF.
2. NFType may be comma separated list with option of “All” for
5 which NFInsatnceIDlist be valid.
3. PLMN may contain comma separated values for PLMN list.
Those PLMN list may be given name as chosen by user. Default
PLMN List “All” may be present by default. PLMN List
examples given below.
10 4. default. PLMN List examples given below.

PLMN List name PLMN Values
All *
Home1 405-862, 405-851
Home2 405-907, 405-872, 405-87?
RP1 Non-Home
RP2 311-0?1, 31?-012,*-102
Special value of RP1 with non-Home may also be provided which may cover all none home PLMNs.
Single entry with NFInstance ID “*”, NFType as “All” and PLMN
List “All” may already be present for whitelist while no config may be
15 present for Blacklist.
. IP and NFType Combination: This table should contain 4 columns as depicted with possible values examples below.
20

IP Start IP End NFType
(Comma
Separated
Values) PLMN
(Comma
Separated
Values)
192.168.0.0 192.168.0.255 PCF.BSF Home1, Home2
2001:0db8:85a3:0000:0 000:8a2e:0370:0000 2001:0db8:85a3:fff f:ffff:8a2e:0370:ffff All Home1, RP2
0.0.0.0 255.255.255.255 All All
0000:0000:0000:0000:0 000:0000:0000:0000 ffff: ffff: ffff: ffff: ffff: ffff: ffff: ffff All All
[0073] IP Start and IP End may indicate the IP range that may be present
for any incoming message to NRF. Both IPv4 and IPv6 may be supported. Two default entry as mentioned in last two rows in example above may be present by 5 default.
[0074] Note: If RP whitelisting is to be done for all, SEPP IP may be
whitelisted with NFType as “All” (or specific NFType) and PLMN as “All” at NRF connected with SEPP, and for other NRF, IP for NRFs, NFType as “All” and PLMN as “All” may be whitelisted separately.
10 [0075] For authentication, any one of 3 methods of authentication may be
present i.e., either HTTPS or CCA or Whitelisting (if enabled). Authentication failure if one of these 3 are not checked may be controllable by runtime user configurable flag which if set true may mean that default authentication may be passed else if false at-least one of 3 authentication method may pass for message to
15 be authenticated. If more than one authentication is provided by NF, then order may be HTTPS ^CCA ^Whitelist. This is valid for all messages that may be sent towards NRF from any NF. Authentication currently may be applicable for NF to NRF communication whereas internal NRF to NRF as well as SEPP to NRF may be able to work with or without authentication. As an example, if SEPP is connected
20 to NRF over HTTPS then all messages received from SEPP may be considered
21

authenticated but even if SEPP is not connected over HTTPS and sends message from other operator whose InstanceID may not be mentioned in whitelist (and as CCA is not supported for other operators connecting with home), may also pass authentication. For NRF-to-NRF case, the NRF while registering with other NRF 5 may use CCA or may be whitelisted or may use HTTPS. But even if the authentication is not used between NRFs, NRF may be assumed authenticated. Enforcing either of authentication for SEPP and NRF may be runtime user configurable based on separate flag for NRF and SEPP. Once NF is marked authenticated, all subsequent messages received from that NF (including
10 NRF/SEPP) may be considered authenticated even if NF/NRF/SEPP is just
forwarding message for some other NF. Also, limitations relating to specific
message supported for message to/from SEPP with NRF may still be applicable.
[0076] NRF may create counters for each authentication method. Also, for
any failed authentication logging may be enabled. In some aspects, authentication
15 may be considered for first message being received from direct peer node and not the subsequent messages. Thus, for the SEPP, messages from roaming partners may not go through authentication (rather they may need authorization by NF or NRF) rather the SEPP while sending first message (i.e. NFRegister or AccessToken) may be optionally authenticated.
20 [0077] In an embodiment, the database (210) may comprise data that may
be either stored or generated as a result of functionalities implemented by any of
the components of the processor(s) (202) or the processing unit(s) (208) or the
system (108).
[0078] Although FIG. 2A shows an exemplary block diagram (200A) of the
25 NF whitelisting system (108), in other embodiments, the NF whitelisting system (108) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 2A. Additionally, or alternatively, one or more components of the NF whitelisting system (108) may perform functions described as being performed by one or more
30 other components of the NF whitelisting system (108).
22

[0079] The present invention relates to a communication network system
and method for authenticating and authorizing Network Functions (NFs) within the system. The system comprises one or more processors and a memory that stores instructions, which when executed by the one or more processors, enable the system 5 to perform a variety of functions.
[0080] The system is configured to authenticate NFs based on Client
Credentials Assertion (CCA) (as defined in 3GPP TS 33.501). The CCA is a security mechanism that allows NFs to assert their identity using credentials that are verified by the Network Repository Function (NRF). Upon receipt of a
10 communication from an NF, the NRF determines whether the communication includes a CCA. If a CCA is present, the NRF authenticates the NF based on the CCA. The CCA includes a signature, timestamp, expiration time, audience claim, and instance ID, which are validated against the instance ID in the public key certificate used for signing the CCA.
15 [0081] In the absence of a CCA, the system may authenticate the NF based
on a whitelist. The whitelist comprises a set of criteria, including combinations of NFInstanceID and NFType, against which incoming communications are verified. The system supports the addition and removal of entries to the whitelist, as well as the ability to enable or disable the whitelisting feature.
20 [0082] The system further supports authorization for own services, such as
Management and Discovery services, based on Open Authorization (OAuth) Token. The NRF acts as an authorization server and generates OAuth tokens for NFs that have been authenticated. These tokens are used to secure operations and access to services provided by the NRF.
25 [0083] Counters are created for each authentication method utilized by the
system. These counters track the number of authentication attempts and successes
for each method, providing a means to monitor and manage the authentication
processes.
[0084] In the event of an authentication failure, the system is configured to
30 enable logging. The logs capture details of the failed authentication attempt, including the time of the attempt, the identity of the NF attempting authentication,
23

and the reason for the failure. This information is crucial for security audits and for
improving the system's security measures.
[0085] The system provides runtime user configurable flags that allow for
the enabling or disabling of authentication and authorization features. These flags 5 can be set to control whether default authentication should be passed, or whether at
least one of the authentication methods should pass for a message to be
authenticated.
[0086] The system is further configured to handle Access token requests,
which may be forwarded from one NRF to another NRF or to a Security Edge 10 Protection Proxy (SEPP) based on criteria such as PLMN. This forwarding
mechanism ensures that NFs can obtain the necessary tokens for accessing services
across different network domains.
[0087] Authentication within the system is primarily considered for the first
message received from a direct peer node. Subsequent messages from the same peer 15 node are not subject to authentication, although they may require authorization.
This approach reduces the overhead of re-authenticating NFs for every
communication, while still maintaining a secure environment.
[0088] The method for authenticating and authorizing NFs within the
communication network includes receiving a communication from an NF, 20 determining the presence of a CCA, authenticating the NF based on the CCA or a
whitelist, generating an OAuth token for the authenticated NF, creating counters
for each authentication method, and logging any failed authentication attempts.
[0089] FIG. 2B illustrates an exemplary flow diagram (200B) of performing
whitelisting authentication of a plurality of network functions (NFs) in a network 25 by a network repository function (NRF), in accordance with an embodiment of the
present disclosure.
[0090] At step 222, receiving, by a network repository function (NRF), a
message from one of the plurality of NFs. The message a registration request or an
access request.
30 [0091] At step 224, authenticating, by the NRF, the NF based on a
whitelisting authentication. The NRF is configured to create counters for
24

authentication and authorization. The NRF is configured to generate a log for failed authentication attempts.
[0092] At step 226, the whitelisting authentication comprises of:
[0093] At step 226-1, checking, by the NRF, whether a runtime user
5 configurable flag is enabled.
[0094] At step 226-2, on detecting that the runtime user configurable flag is
enabled, performing, by the NRF, authentication of a message/NF pass by checking whether the message match present in a whitelist and missing in a blacklist. The whitelist and the blacklist comprise combination of NF instance identifier (ID) and
10 a NF type and combination of an internet protocol (IP) and the NF type. The NRF is configured to enable or disable the whitelisting authentication. The combination of NF instance identifier (ID) and the NF type comprises a NF instance ID range, the NF type and a public land mobile network (PLMN). The combination of the IP and the NF type comprises an IP range, the NF type and the PLMN.
15 [0095] At step 226-3, on detecting that the message match present in the
whitelist and missing in the blacklist, authenticating, by the NRF, the NF.
[0096] At step 226-4, on detecting that the message match present in the
blacklist, rejecting, by the NRF, the authentication of the NF.
[0097] FIG. 3 illustrates an exemplary computer system (300) in which or
20 with which embodiments of the present disclosure may be implemented. As shown in FIG. 3, the computer system (300) may include an external storage device (310), a bus (320), a main memory (330), a read only memory (340), a mass storage device (350), a communication port (360), and a processor (370). A person skilled in the art will appreciate that the computer system (300) may include more than one
25 processor (370) and communication ports (360). Processor (370) may include
various modules associated with embodiments of the present disclosure.
[0098] In an embodiment, the communication port (360) may be any of an
RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or
30 other existing or future ports. The communication port (360) may be chosen
25

depending on a network, such a Local Area Network (LAN), Wide Area Network
(WAN), or any network to which the computer system (300) connects.
[0099] In an embodiment, the memory (330) may be Random Access
Memory (RAM), or any other dynamic storage device commonly known in the art.
5 Read-only memory (340) may be any static storage device(s) e.g., but not limited
to, a Programmable Read Only Memory (PROM) chips for storing static
information e.g., start-up or Basic Input/Output System (BIOS) instructions for the
processor (370).
[00100] In an embodiment, the mass storage (350) may be any current or
10 future mass storage solution, which may be used to store information and/or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), one
15 or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g., an array of disks (e.g., SATA arrays).
[00101] In an embodiment, the bus (320) communicatively couples the
processor(s) (370) with the other memory, storage and communication blocks. The bus (320) may be, e.g., a Peripheral Component Interconnect (PCI)/PCI Extended
20 (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB)
or the like, for connecting expansion cards, drives and other subsystems as well as
other buses, such a front side bus (FSB), which connects the processor (370) to the
computer system (300).
[00102] Optionally, operator and administrative interfaces, e.g., a display,
25 keyboard, joystick, and a cursor control device, may also be coupled to the bus (320) to support direct operator interaction with the computer system (300). Other operator and administrative interfaces may be provided through network connections connected through the communication port (360). Components described above are meant only to exemplify various possibilities. In no way should
30 the aforementioned exemplary computer system (300) limit the scope of the present disclosure.
26

[00103] While the foregoing describes various embodiments of the present
disclosure, other and further embodiments of the present disclosure may be devised without departing from the basic scope thereof. The scope of the present disclosure is determined by the claims that follow. The present disclosure is not limited to the 5 described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the present disclosure when combined with information and knowledge available to the person having ordinary skill in the art.
10 ADVANTAGES OF THE PRESENT DISCLOSURE
[00104] The present disclosure provides a system for Network Function (NF)
whitelisting in a communication network.
[00105] The present disclosure supports authentication based on Client
Credentials Assertion (CCA).
15 [00106] The present disclosure supports authentication based on whitelisting
conditions/list with ability to enable or disable the feature.
[00107] The present disclosure supports authorization for own services
(Management and Discovery) based on Open Authorization (OAuth) Token.
[00108] The present disclosure provides support for counters and logs for
20 authentication and authorization.
27

We claim:
1. A method for performing authentication of a plurality of network functions
(NFs) in a network (106), the method comprising:
receiving, by a network repository function (NRF), a message from one of the plurality of NFs; and
authenticating, by the NRF, the NF based on a whitelisting authentication, wherein the whitelisting authentication comprises of:
checking, by the NRF, whether a runtime user configurable flag is enabled;
on detecting that the runtime user configurable flag is enabled, performing, by the NRF, authentication of the message by checking whether the message match present in a whitelist and missing in a blacklist; and
on detecting that the message match present in the whitelist and missing in the blacklist, authenticating, by the NRF, the NF.
2. The method as claimed in claim 1, wherein the message comprises a registration request or an access request.
3. The method as claimed in claim 1 further comprising:
on detecting that the message match is present in the blacklist, rejecting, by the NRF, the authentication of the NF.
4. The method as claimed in claim 1, wherein the whitelist and the blacklist
comprise a combination of an NF instance identifier (ID) and an NF type or
a combination of an internet protocol (IP) subnet and the NF type, wherein
the NRF is configured to enable or disable the whitelisting authentication.

5. The method as claimed in claim 4, wherein the combination of NF instance ID and the NF type comprises a NF instance ID range, the NF type and a public land mobile network (PLMN), wherein the combination of the IP subnet and the NF type comprises an IP range, the NF type and the PLMN.
6. The method as claimed in claim 1, wherein the NRF is configured to create counters for authentication and authorization, wherein the NRF is configured to generate a log for failed authentication attempts.
7. The method as claimed in claim 1, wherein the NRF is configured to support authorization by providing an open authorization token for NRF services and management and discovery services.
8. The method as claimed in claim 1, wherein the NRF is configured to perform one or more authentication techniques, wherein the authentication techniques comprise a hypertext transfer protocol secure (HTTPS), a client credentials assertion (CCA) and the whitelisting authentication, wherein performing authentication in order of the HTTPS, the CCA and the whitelisting authentication.
9. The method as claimed in claim 1 further comprising:
authenticating a first message received from a direct peer node and allowing subsequent messages from the direct peer node, wherein the first message is a NF register message.
10. A system (108) for performing authentication of a plurality of network
functions (NFs) in a network (106), by a network repository function (NRF),
wherein the NRF comprising:
a receiving unit (220) configured to receive a message from one of the plurality of NFs; and

an authentication unit (214) configured to authenticate the NF based on a whitelisting authentication, wherein the whitelisting authentication comprises of:
a processing unit (208) configured to check whether a runtime user configurable flag is enabled;
on detecting that the runtime user configurable flag is enabled, the authentication unit (214) is configured to perform authentication of the message by checking whether the message match present in a whitelist and missing in a blacklist; and
on detecting that the message match present in the whitelist and missing in the blacklist, the authentication unit (214) is configured to authenticate the NF.
11. The system (108) as claimed in claim 10, wherein on detecting that the message match present in the blacklist, the authentication unit (214) configured to reject the authentication of the NF.
12. The system (108) as claimed in claim 10, wherein the message comprises a registration request or an access request.
13. The system (108) as claimed in claim 10, wherein the whitelist and the blacklist comprise a combination of an NF instance identifier (ID) and an NF type and a combination of an internet protocol (IP) subnet and the NF type, wherein the NRF is configured to enable or disable the whitelisting authentication.
14. The system (108) as claimed in claim 13, wherein the combination of NF instance identifier (ID) and the NF type comprises a NF instance ID range, the NF type and a public land mobile network (PLMN), wherein the combination of the IP subnet and the NF type comprises an IP range, the NF type and the PLMN.

15. The system (108) as claimed in claim 10, wherein the NRF is configured to create counters for authentication and authorization, wherein the NRF is configured to generate a log for failed authentication attempts.
16. The system (108) as claimed in claim 10, wherein the NRF is configured to support authorization by providing an open authorization token for NRF services and management and discovery services.
17. The system (108) as claimed in claim 10, wherein the NRF is configured to perform one or more authentication techniques, wherein the authentication techniques comprise a hypertext transfer protocol secure (HTTPS), a client credentials assertion (CCA) and the whitelisting authentication, wherein performing authentication in order of the https, the CCA and the whitelisting authentication.
18. The system (108) as claimed in claim 10, wherein the NRF is configured to authenticate a first message received from a direct peer node and not authenticating for subsequent messages from the direct peer node, wherein the first message is a NF register message.
19. A user equipment (UE) communicatively coupled with a system (108), the coupling comprises steps of:
receiving, by the system, a connection request;
sending an acknowledgment of the connection request to the UE; and
transmitting a plurality of signals in response to the connection request to the system (108), wherein the system (108) configured for performing authentication of a plurality of network functions (NFs) in a network, by a network repository function (NRF) as claimed in claim 10.