WO2021240055A1 - Autorisation améliorée dans des réseaux de communication - Google Patents

Autorisation améliorée dans des réseaux de communication Download PDF

Info

Publication number
WO2021240055A1
WO2021240055A1 PCT/FI2021/050368 FI2021050368W WO2021240055A1 WO 2021240055 A1 WO2021240055 A1 WO 2021240055A1 FI 2021050368 W FI2021050368 W FI 2021050368W WO 2021240055 A1 WO2021240055 A1 WO 2021240055A1
Authority
WO
WIPO (PCT)
Prior art keywords
access control
control list
network
request
list
Prior art date
Application number
PCT/FI2021/050368
Other languages
English (en)
Inventor
Pradyumna Ram PRASAD
Krishnamurthy MAHADEVAIAH
Muthuswamy SOMASKANDAN
Nagendra Bykampadi
Harish MURALIDHARA
Original Assignee
Nokia Technologies Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Technologies Oy filed Critical Nokia Technologies Oy
Publication of WO2021240055A1 publication Critical patent/WO2021240055A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/562—Brokering proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/084—Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices

Definitions

  • Various example embodiments relate in general to communication networks, such as core networks of cellular communication systems, and more specifically, to enhancing authorization in such networks.
  • an apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to perform transmit a request about an access control list to a network repository function, wherein the request concerns accessing services of a network function producer, receive, in response to the request, an access control list response from the network repository function, the access control list response comprising an access control list, wherein the access control list is a list of network functions that are allowed to access services of the network function producer and validate a service request when a sender of the service request is in the access control list.
  • Embodiments of the first aspect may comprise at least one feature from the following bulleted list or any combination of the following features:
  • the request comprises an identifier of a network wherein the apparatus is located and an identifier of a network wherein the network function producer is located;
  • the access control list response comprises a list of network function instance identities of the network functions that are allowed to access services of the network function producer;
  • the at least one memory and the computer program code are configured to, with the at least one processing core, further cause the apparatus to perform determine, based on the received access control list response, that the apparatus has been subscribed to receive notifications about changes in the list;
  • the at least one memory and the computer program code are configured to, with the at least one processing core, further cause the apparatus to perform, receive an updated access control list from the network repository function and transmit, responsive to receiving the updated access control list, a confirmation to the network repository function, the confirmation indicating that the access control list has been successfully updated;
  • the apparatus is a service communication proxy and the at least one memory and the computer program code are configured to, with the at least one processing core, further cause the apparatus to perform, check, upon receiving the service request, that an instance identity in the service request is in the access control list and transmit another service request, said another service request comprising an instance identity of the apparatus;
  • the apparatus is a service communication proxy and the at least one memory and the computer program code are configured to, with the at least one processing core, further cause the apparatus to perform, transmit said another service request to the network function producer, receive, when an instance identity of the apparatus is in the access control list, a service response from the network function producer, the service response indicating that access to services of the network function producer is allowed for the sender of the service request and transmit the service response to the sender of the service request, wherein the sender is a network function consumer;
  • the apparatus is a first service communication proxy and the at least one memory and the computer program code are configured to, with the at least one processing core, further cause the apparatus to perform, transmit said another service request to a second service communication proxy and receive, when an instance identity of the apparatus and an instance identity of the second service communication proxy are in the access control list, a service response from the network function provider, the service response indicating that access to services of the network function producer is allowed for the sender of the service request and transmit the service response to the sender of the service request, wherein the sender is a network function consumer;
  • the apparatus is a network function producer and the at least one memory and the computer program code are configured to, with the at least one processing core, further cause the apparatus to perform, receive a service request from a service communication proxy, the service request comprising an instance identity of the service communication proxy, check, upon receiving the service request, that the instance identity of the service communication proxy in the service request is in the access control list and transmit, when the instance identity of the service communication proxy is in the access control list, a service response to the service communication proxy, the service response indicating that access to services of the apparatus is allowed.
  • an apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to perform, receive a request about an access control list from a requesting network function, wherein the request concerns accessing services of a network function producer, determine an access control list, wherein the access control list is a list of network functions that are allowed to access services of the network function producer and transmit an access control list response to the requesting network function, the access control list response comprising the list of network functions.
  • Embodiments of the second aspect may comprise at least one feature from the following bulleted list or any combination of the following features: ⁇ the request comprises an identifier of a network wherein the requesting network function is located and an identifier of a network wherein the network function producer is located;
  • the access control list response comprises a list of network function instance identities of the network functions that are allowed to access services of the network function producer;
  • the at least one memory and the computer program code are configured to, with the at least one processing core, further cause the apparatus to perform, determine, based on the received request, that the requesting network function is to be subscribed to receive notifications concerning changes in the list of network functions and transmit an updated access control list to the network function upon detecting a change in the list of network functions.
  • Example embodiments of the first or the second may comprise at least one feature from the following bulleted list:
  • the at least one memory and the computer program code are configured to, with the at least one processing core, further cause the apparatus to operate according to at least one standard specification defined by a 3 rd Generation Partnership Project, 3GPP; and
  • the at least one standard specification is a 5G standard.
  • a first method comprising transmitting a request about an access control list to a network repository function, wherein the request concerns accessing services of a network function producer, receiving, in response to the request, an access control list response from the network repository function, the access control list response comprising an access control list, wherein the access control list is a list of network functions that are allowed to access services of the network function producer and validating a service request when a sender of the service request is in the access control list.
  • a second method comprising, receiving a request about an access control list from a requesting network function, wherein the request concerns accessing services of a network function producer, determining an access control list, wherein the access control list is a list of network functions that are allowed to access services of the network function producer and transmitting an access control list response to the requesting network function, the access control list response comprising the list of network functions.
  • an apparatus comprising means for transmitting a request about an access control list to a network repository function, wherein the request concerns accessing services of a network function producer, means for receiving, in response to the request, an access control list response from the network repository function, the access control list response comprising an access control list, wherein the access control list is a list of network functions that are allowed to access services of the network function producer and means for validating a service request when a sender of the service request is in the access control list.
  • an apparatus comprising means for receiving a request about an access control list from a requesting network function, wherein the request concerns accessing services of a network function producer, means for determining an access control list, wherein the access control list is a list of network functions that are allowed to access services of the network function producer and means for transmitting an access control list response to the requesting network function, the access control list response comprising the list of network functions.
  • non- transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least perform the first method.
  • non-transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least perform the second method.
  • a computer program configured to perform the first method.
  • a computer program configured to perform the second method.
  • FIGURE 1 illustrates an exemplary system in accordance with at least some example embodiments
  • FIGURE 2 illustrates a first signalling example in accordance with at least some example embodiments
  • FIGURE 3 illustrates a second signalling example in accordance with at least some example embodiments
  • FIGURE 4 illustrates a third signalling example in accordance with at least some example embodiments
  • FIGURE 5 illustrates a fourth signalling example in accordance with at least some example embodiments
  • FIGURE 6 illustrates a fifth signalling example in accordance with at least some example embodiments
  • FIGURE 7 illustrates a sixth signalling example in accordance with at least some example embodiments
  • FIGURE 8 illustrates an example apparatus capable of supporting at least some example embodiments
  • FIGURE 9 illustrates a flow graph of a first method in accordance with at least some example embodiments
  • FIGURE 10 illustrates a flow graph of a second method in accordance with at least some example embodiments.
  • Authorization may be improved by the procedures described herein for example by enabling authorization of intermediate Network Functions, NFs, such as a Service Communication Proxy, SCP, by a Network Function Producer, NFP.
  • NFs such as a Service Communication Proxy, SCP
  • NFP Network Function Producer
  • the SCP and/or the NFP may request an access control list, which defines NFs that are allowed to access services of the NFP, from a Network Repository Function, NRF.
  • NRF Network Repository Function
  • the SCP and/or the NFP may use the access control list to validate a sender of a service request when the sender is in the access control list. For instance, the SCP may receive the service request from a Network Function Consumer, NFC, and validate the service request if the NFC is in the access control list.
  • the SCP may then transmit another service request to the NFP, said another service request comprising an instance identity of the SCP.
  • the NFP may also validate a sender of said another service request, i.e., the SCP, and if the SCP is in the access control list, the NFP may transmit a service response indicating that access to services of the NFP is allowed for the NFC.
  • it may be also required that the standard OAuth based authorization passes for the NFC at the NFP before the service response indicating that access to services of the NFP is allowed for the NFC can be transmitted.
  • FIGURE 1 illustrates an exemplary system in accordance with at least some example embodiments of the present invention.
  • the exemplary system of FIGURE 1 comprises two Public Land Mobile Networks, PLMNs, 110 and 112, each equipped with at least one NF, 120 and 122, respectively.
  • AnNF may refer to an operational and/or a physical entity.
  • An NF may be a specific network node or element, or a specific function or set of functions carried out by one or more entities, such as Virtual Network Functions, VNFs.
  • At least some example embodiments of the present invention may be applied in containerized deployments as well.
  • One physical node may be configured to perform plural NFs.
  • NFs include a (radio) access or resource control or management function, session management or control function, interworking, data management or storage function, authentication function or a combination of one or more of these functions.
  • NFs may comprise at least some of an Access and Mobility Function, AMF, a Session Management Function, SMF, a Network Slice Selection Function, NSSF, a Network Exposure Function, NEF, an NRF, an Unified Data Management, UDM, an User Data Repository, UDR, an Unstructured Data Storage Function, UDSF, an Authentication Server Function, AUSF, a Policy Control Function, PCF, an Application Function, AF, Operations Administration and Maintenance, OAM, and Network Data Analysis Function, NWDAF.
  • AMF Access and Mobility Function
  • SMF Session Management Function
  • NSSF Network Slice Selection Function
  • NEF Network Exposure Function
  • NRF Network Exposure Function
  • UDM Unified Data Management
  • UDR User Data Repository
  • UDR Unstructured Data Storage Function
  • UDSF an Authentic
  • the PLMNs 110 and 112 may further comprise a Security Edge Protection Proxy, SEPP, 130 and 132, respectively.
  • SEPPs 130 and 132 may be configured to operate as a security edge node or gateway.
  • the NFs may communicate with each other using representational state transfer Application Programming Interfaces, APIs. These may be known as Restful APIs.
  • An inter-PLMN interconnection allows secure communication between a service-consuming NF and a service-producing NF, referred to as a NFC 120 and a NFP 122 in FIGURE 1, respectively.
  • Service Communication Proxies, SCPs, 150 and 152 may be deployed for indirect communication between network functions.
  • the SCPs 150 and 152 may be intermediate functions/elements for assisting in routing of messages, such as control plane messages like Diameter Routing Agent, DRA, messages between NFs.
  • NF discovery and NF service discovery enable core network entities, such as the NFC 120 or the SCP 150, to discover a set of NF instance(s) and NF service instance(s) for a specific NF service or an NF type.
  • the NRF 140, 142 is a function that is used to support the functionality of NFs and NF service discovery and status notification.
  • the NRF 140, 142 may maintain an NF profile of available NF instances and their supported services.
  • the NRFs may notify about newly registered, updated, or deregistered NF instances along with its NF services to subscribed NFCs and/or SCPs.
  • the NF and NF service discovery may be implemented via the NRF 140, 142.
  • the NRFs 140, 142 may be logical functions.
  • the NRF 140, 142 may also support status notification.
  • the NRF 140 may be co-located together with the SCP 150 for example.
  • the NFC 120 or the SCPc 150 may initiate, based on local configuration, a discovery procedure with the NRFc 140.
  • the discovery procedure may be initiated by providing the type of the NF and optionally a list of the specific service(s) it is attempting to discover.
  • the NFC 120 or the SCPc 150 may also provide other service parameters, such as slicing related information.
  • the entities or nodes 120, 122, 130, 132, 140, 142, 150, 152 may act in both service-consuming and service-providing roles and that their structure may also be similar or identical, even though their role in the example of FIGURE 1 in delivery of a particular message is identified by use of the prefix “c” or “p” indicating whether they are acting for the service-consuming or service-producing NF. It is to be noted that instead of “c” and “p”, “v” for visited and “h” for home may be used to refer to at least some respective entities in the visited and home PLMNs.
  • OAuth based authorization and token exchange may be applied between the mobile networks.
  • the NFC 120 may be an OAuth client and the NRFp 142 may operate as OAuth resource server, and both may be configured to support OAuth authorization framework as defined in RFC 6749.
  • Embodiments of the present invention address various challenges related to authorization. For instance, some embodiments enable authorization of the NFC 120 by intermediate network elements, such as the SCPc 150 and/or the SCPp 152. Moreover, some embodiments enable authorization of a first intermediary in a call path, such as the SPCc 150, by a second intermediary in the call path, such as the SPCp 152. Some embodiments enable authorization of said intermediate network elements by the NFP 122. Authorization of the NFC 120 and/or SCPc 150 by the SEPPp 132 in a visited PFMN for roaming cases or by the SEPPc 130 in home PFMN may also be enabled.
  • 3GPP standard specification TS 33.501 (sections 13.3.3, 13.3.5 and 13.3.6) do not currently define a procedure for authorization but only define a solution for authentication.
  • Authorization header defined in RFC 7230, in section 3.2.2, may be used between the NFC 120 and the NFP 122, but at all intermediate NFs in the path between the NFC 120 and the NFP 122 cannot be authorized with current solutions.
  • all NFCs, NFPs and intermediate NFs such as SCPs and SEPPs, may operate as Transport Layer Security, TLS, Servers. These TLS servers may be grouped logically to provide a service.
  • a set of TLS servers can be dedicated to a network slice to provide a required QoS, to a group based on location or be domain specific.
  • a set of NLs may comprise for example one NEC, one NLP, one SCP and one SEPP.
  • the set of NLs may be a part of a network slice and only the NLs in the set may be allowed to communicate with each other, i.e., other NLs should not be authorized to reach this group.
  • the challenge thus is how to enable authorization for a set of NLs, i.e., for a part of a network slice.
  • NEC 120 would use an authorization header to pass a token to be used at the NLP 122.
  • an intermediate SCP 150 can authorize the NEC 120 using local policy only.
  • the NLP 122 can authorize the intermediate SCP 150, 152 based on local policy only.
  • the inter-PLMN cases would be problematic as well, because the authorization header in a request from the NEC 120 is for the NLP 122 to consume.
  • the intermediate SEPP 132 can authorize the NEC 120 using local policy only.
  • the NLP 122 can authorize the SEPP 130 only based on local policy as well. Consequently, proper authorization is not possible for a set of NLs in intra-PLMN and inter-PLMN cases.
  • an access control list is provided at an NRL, such as the NRLc 140 or the NRLp 142.
  • the access control list may comprise a list of NLs that can access, or are allowed to access, services of a given NL, such as the NLP 122.
  • the NRL may provide access control service so that other NLs may retrieve, or request, the access control list from the NRL.
  • the access control list may be configured by an administrator for example. Thus, authorization may be enhanced at NLs to include verification/validation of the access control list.
  • all NLs, SCPs and SEPPs may implicitly subscribe with the NRL to receive notifications about changes in the access control list.
  • the subscription may be done when an NL requests the access control list for example.
  • all NFs, SCPs and SEPPs may then authorize the NFs, from which they receive a request, against the access control list received from the NRF.
  • a 3GPP forwarder header may be added to a service request to specify an instance identity of the NF that sent the service request, so that the receiving NF may easily get to know the NF that sent the service request.
  • the receiving NF may thus verify/validate the NF that sent the service request by comparing the instance identity of the NF that sent the service request to the list of NFs that are allowed to access the given NF.
  • the instance identity may be a variable ⁇ nflnstancelD ⁇ and represent an identifier that is globally unique inside the PFMN of the NRF where the NF is being registered.
  • the instance identity may be a Universally Unique Identifier, UUID, for example.
  • access control information may be handled at a transport interface of an application.
  • a Subject Alternate Name, SAN, or a CN in a TFS certificate may be used to validate against the access control list before accepting a connection.
  • FIGURE 2 illustrates a first signalling example in accordance with at least some example embodiments.
  • NRF 202 On the vertical axes are disposed, from the left to the right, NRF 202 and NF 208. Time advances from the top towards the bottom.
  • NRF 202 may for example be NRFc 140 and/or NRFp 142 of FIGURE 1.
  • NF 208 may for example be NFP 122, SCPc 150 or SCPp 152 of FIGURE 1.
  • NF 208 may be referred to as a requesting NF.
  • FIGURE 2 illustrates an example about NF 208 accessing services of NRF 200 and fetching an access control list.
  • an access control list may be configured as a part of NRF 202.
  • the access control list may be updated dynamically, e.g., when a new NF (not shown in FIGURE 1) is added to a network.
  • the new NF may provide its own information when it registers with NRF 202.
  • the provided information may contain a list of network slices the new NF belongs to and possibly location information of the new, registering NF as well.
  • NRF 202 may then use the provided information to build the access control list dynamically.
  • NF 208 may transmit a request about an access control list to NRF 202, to request an access control list of NFs that can, i.e., are allowed to, access services of a target NF, such as an NFP. That is to say, the request may concern accessing services of the NFP.
  • NF 208 may thus be a requesting NF.
  • the request may be referred to as an access control list request.
  • the request may be in the following form: “Nnrf AccessControl (GET... /accessControlList/ ⁇ nflnstanceId ⁇ (AccessControlListReq(requester PLMN, target PLMN, callbackUri))).
  • the request may comprise an identifier of a network wherein the NF 208 is located (requester PLMN) and an identifier of a network wherein the NFP is located (target PLMN), to make it easier for NRL 202 to find the NLP.
  • the authorization process may be improved by using the identifiers of the network(s).
  • NRL 202 and NL 208 may determine that NL 208 has been subscribed to changes in the access control list. Lor instance, NRL 208 may determine implicitly based on the access control list request that NL 208 should be subscribed to changes in the access control list.
  • NRL 202 may transmit, in response to receiving the access control list request, an access control list response to NL 208.
  • the access control list response may comprise a list of network functions that can, and are allowed to, access services of the target NL, such as the NLP.
  • the access control list response may be in the following form: “200 Ok (AccessControlList(NfInstanceList, validityPeriod))”. That is to say, the access control list response may comprise a list of NL instance identities that are allowed to access services of the NLP.
  • NL 208 may locally cache the access control list. NL 208 may for example store the access control list to a memory of NL 208 or to an external memory.
  • the access control list may be a list of sets of NTs (NfSets), wherein one set of NTs is a set of NTs grouped logically based on some criteria.
  • the NL sets may be defined in 3GPP standard specifications for example.
  • PIGURE 3 illustrates a second signalling example in accordance with at least some example embodiments. On the vertical axes are again disposed, from the left to the right, NRL 202 and NL 208. Time advances from the top towards the bottom. PIGURE 3 illustrates an example about updating the access control list. Lor example, relevant NPs, SCPs and SEPPs may be informed whenever there are changes in the access control list at NRL 202.
  • NRL 202 may detect a change in the access control list. NRL 202 may detect a change for example when a new NL is added to the access control list or if an old NF is removed from the list. NRF 202 may update the access control list by adding the new NF to, or by removing the old NF from, the access control list in such cases.
  • NRF 202 may transmit, upon detecting a change in the access control list, an updated access control list to NF 208 in another message.
  • Said another message may be in the following form: “Nnrf AccessControl (PUT callbackURI(AccessControlList(NflnstanceList)).
  • NF 208 may locally cache the updated access control list. NF 208 may for example store the updated access control list to a memory of NF 208 or to an external memory and delete the old access control list. [0053] At 340, NF 208 may transmit, responsive to receiving and successfully caching the updated access control list, a confirmation to NRF 202. The confirmation may indicate that the access control list has been successfully updated. The confirmation may be in the following form: “200 Ok”.
  • FIGURE 4 illustrates a third signalling example in accordance with at least some example embodiments.
  • NRF 202, SCP 204, NFC 206 and NFP 208 may be the same as in FIGURES 2 and 3.
  • SCP 204 may be SCPc 150 or SCPp 152 of FIGURE 1 while NFC 206 may be NFc 120 of FIGURE 1.
  • FIGURE 4 illustrates an example with one intermediate SCP.
  • SCP 204 may request the access control list from NRF 202 and
  • NRF 202 may respond accordingly by transmitting the access control list to SCP 204.
  • NFP 208 may request, at step 420, the access control list from NRF 202 and NRF 202 may respond accordingly by transmitting the access control list to NFP 208.
  • Steps 410 and steps 420 may comprise all the steps shown in FIGURE 2 for example. SCP 204 and NFP 208 may thus be requesting NFs.
  • NFC 206 may transmit a service request to SCP 204.
  • the service request may be transmitted via a Service Based Interface, SBI, for example, i.e., it may be a SBI Request.
  • SBI Service Based Interface
  • NFC 206 may thus be a sender of the service request.
  • SCP 204 may check upon receiving the service request that an instance identity in the service request can be found from the cached access control list. That is to say, SCP 204 may check that an instance identity of NFC 206, received in the service request, is in the access control list, i.e., validate NFC 206 against the access control list. SCP 204 may thus validate the service request when the sender of the service request (NFC 206) is in the access control list.
  • SCP 204 may, when the instance identity in the service request is in the cached access control list (i.e., an instance identity of NFC 206 is in the access control list), transmit another service request to NFP 208.
  • Said another service request may be transmitted via the SBI as well, i.e., it may be a SBI Request.
  • Said another service request may be transmitted on behalf of NFC 206. So at step 440 the sender of said another service request may be SCP 204.
  • Said another service request may comprise an instance identity of SCP 204, which is particularly beneficial because authorization is enhanced by indicating that SCP 204 has validated the service request.
  • said another service request may comprise a 3GPP forwarder header indicating the instance identity of SCP 204.
  • Information about NFC 206 may be again finally checked by NFP 208 using existing oAuth mechanisms as well.
  • NFP 208 may check, upon receiving said another service request, that an instance identity in said another service request can be found from the cached access control list. That is to say, NFP 208 may check that an instance identity of SCP 204, received in said another service request, is in the access control list, i.e., validate SCP 204 against the access control list. NFP 208 may thus validate the service request when the sender of said another service request (SCP 204) is in the access control list. Consequently, the service request of NFC 206 would be validated at the same time as well because service requests of both, SCP 204 and NFC 206, can be validated.
  • NFP 208 may, when the instance identity in said another service request is in the cached access control list (i.e., an instance identity of SCP 204 is in the access control list), transmit a service response to SCP 204.
  • the service response may be transmitted via the SBI as well, i.e., it may be a SBI Response.
  • SCP 204 may forward the service response to NFC 206 at step 460.
  • the service response may indicate that access to services of NFP 208 is allowed for the sender of the service request, i.e., NFC 206.
  • FIGURE 5 illustrates a fourth signalling example in accordance with at least some example embodiments.
  • NRF 202, 1 st SCP 204, 2 nd SCP 205, NFC 206 and NFP 208 may be the same as in FIGURES 4 and 2 nd SCP 204 may be SCPc 150 or SCPp 152 of FIGURE 1 as well.
  • FIGURE 5 illustrates an example with two intermediate SCP.
  • NRF 202 may build the access control list, i.e., the list of NFs that are allowed to access services of the target NF, such as NF 208, for example either after OAM at NRF 202 and/or registration by all NFs (NRF 202, 1 st SCP 204, 2 nd SCP 205, NFC 206 and NF 208 in FIGURE 5) with NRF 202.
  • the access control list may allow 1 st SCP 204 to receive and validate messages from NFC 208, 2 nd SCP 205 to receive and validate messages from 1 st SCP 204 and NF 208 to receive and validate messages from 2 nd SCP 205 and NFC 206.
  • 1 st SCP 204, 2 nd SCP 205 and NFP 208 may request and receive the access control list similarly as at steps 410 - 420 of FIGURE 4.
  • 1 st SCP 204, 2 nd SCP 205 and NFP 208 may be requesting NFs.
  • Steps 540 and 545 may correspond to steps 430 and 435 of FIGURE 4, respectively.
  • NFC 206 may for example initiate a HTTP request to NF 208, but as a first hop forward the service request to 1 st SCP 204 by setting a 3GPP forward header to its own instance identity, i.e., NFC instance identity.
  • 1 st SCP 204 may, when the instance identity in the service request is in the cached access control list (i.e., an instance identity of NFC 206 is in the access control list), transmit another service request to 2 nd SCP 205 instead of NFP 208.
  • Said another service request may be transmitted via the SBI as well, i.e., it may be a SBI Request.
  • Said another service request may be transmitted on behalf of NFC 206.
  • Said another service request may comprise an instance identity of SCP 204.
  • said another service request may comprise a 3 GPP forwarder header indicating the instance identity of SCP 204.
  • 1 st SCP 204 may receive the service request from NFC 206 and determine whether to forward the service request to 2 nd SCP 205. Before forwarding the service request 1 st SCP 204 may check if it is authorized to receive the service request from NFC 206 using the access control list as received from NRF 202. 1 st SCP 204 may get an instance identity of NFC 206 from either the 3GPP forwarder header in the service request or from the transport level TLS communication with NFC 206. After successful authorization, 1 st SCP 204 may replace the instance identity of NFC 206 with an instance identity of 1 st SCP 204 in the service request, to generate another service request.
  • 1 st SCP 204 may replace the instance identity of NFC 206 with an instance identity of 1 st SCP 204 in the 3 GPP forwarder header in the service request. If the 3 GPP forwarder header is not already present, 1 st SCP 204 may add the header with its own instance identity.
  • 2 nd SCP 205 may check, at step 555, that an instance identity in said another service request can be found from the cached access control list, similarly as NFP 208 checked at step 445.
  • 2 nd SCP 205 may, when the instance identity in said another service request is in the cached access control list, transmit an additional service request to NFP 208.
  • Said additional service request may be transmitted via the SBI as well, i.e., it may be a SBI Request.
  • Said additional service request may be transmitted on behalf of NFC 206 as well.
  • Said additional service request may comprise an instance identity of 2 nd SCP 205, which is particularly beneficial because authorization is enhanced by indicating that 2 nd SCP 205 has validated the service request.
  • said another service request may comprise a 3 GPP forwarder header indicating the instance identity of 2 nd SCP 205.
  • 2 nd SCP 205 may thus be a sender of a service request as well.
  • NFP 208 may check, upon receiving said additional service request, that an instance identity in said another service request can be found from the cached access control list. That is to say, NFP 208 may check that an instance identity of 2 nd SCP 205, received in said additional service request, is in the access control list, i.e., validate 2 nd SCP 205 against the access control list. NFP 208 may thus validate the service request when the sender of said additional service request (2 nd SCP 205) is in the access control list. NFP 208 may perform the following authorization: Authorization header to validate the service request from NFC 206 and authorize that the service request from 2 nd SCP 205 by validating against the access control list.
  • Steps 570 and 580 may correspond to steps 450 and 460 of FIGURE 4, but at step 570 the service response may be transmitted to 2 nd SCP 205 and 2 nd SCP 205 may forward the service response to 1 st SCP 204.
  • FIGURE 6 illustrates a fifth signalling example in accordance with at least some example embodiments.
  • FIGURE 6 demonstrates an example which is otherwise the same as the example of FIGURE 4, but a listening entity (not shown in FIGURE 6) is related to the process at steps 615, 625, 635 and 645.
  • the listening entity may refer to connection management. Every TLS server may have connection management and the listening entity of each TLS server may be responsible to listen on a certain ip and port, and also accept new connections from peers. If the listening entity is provided in the access control list, connection parameters of a peer can be checked before handing over a request to an application, to check for oAuth or process any application logic.
  • SCP 204 may provide the access control list to the listening entity and/or NFP 208 may provide the access control list to the listening entity at step 625.
  • the listening entity may validate TLS properties against the access control list. Said TLS properties may include for example SAN or a CN in the certificate. For this, SCP 204 may forward the service request to the listening entity when NFC 206 is in the access control list. Alternatively, or in addition, the listening entity may validate TLS properties against the access control list at step 645. In such a case, NFP 208 may forward the service request to the application layer when SCP 204 is in the access control list.
  • FIGURE 7 illustrates a sixth signalling example in accordance with at least some example embodiments.
  • FIGURE 7 demonstrates an example which is otherwise the same as the example of FIGURE 5, but a listening entity (not shown in FIGURE 7) is related to the process.
  • the received access control list may be provided to the listening entity.
  • the listening entity may validate TLS properties against the access control list similarly as in case of FIGURE 6 and 1 st SCP 204, 2 nd SCP 205 and NFP 208 may forward the service request to the listening entity, respectively.
  • FIGURE 8 illustrates an example apparatus capable of supporting at least some example embodiments. Illustrated is device 800, which may comprise, for example, an NFc, NFp or authorization server, or a device controlling functioning thereof.
  • processor 810 which may comprise, for example, a single- or multi-core processor wherein a single-core processor comprises one processing core and a multi-core processor comprises more than one processing core.
  • Processor 810 may comprise, in general, a control device.
  • Processor 810 may comprise more than one processor.
  • Processor 810 may be a control device.
  • Processor 810 may comprise at least one Application-Specific Integrated Circuit, ASIC.
  • Processor 810 may comprise at least one Field-Programmable Gate Array, FPGA.
  • Processor 810 may comprise an Intel Xeon processor for example. Processor 810 may be means for performing method steps in device 800, such as determining, causing transmitting and causing receiving. Processor 810 may be configured, at least in part by computer instructions, to perform actions.
  • a processor may comprise circuitry, or be constituted as circuitry or circuitries, the circuitry or circuitries being configured to perform phases of methods in accordance with example embodiments described herein.
  • circuitry may refer to one or more or all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of hardware circuits and software, such as, as applicable: (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a network function, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.
  • firmware firmware
  • circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware.
  • circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.
  • Device 800 may comprise memory 820.
  • Memory 820 may comprise random- access memory and/or permanent memory.
  • Memory 820 may comprise at least one RAM chip.
  • Memory 820 may comprise solid-state, magnetic, optical and/or holographic memory, for example. Memory 820 may be at least in part accessible to processor 810. Memory 820 may be at least in part comprised in processor 810. Memory 820 may be means for storing information. Memory 820 may comprise computer instructions that processor 810 is configured to execute. When computer instructions configured to cause processor 810 to perform certain actions are stored in memory 820, and device 800 overall is configured to run under the direction of processor 810 using computer instructions from memory 820, processor 810 and/or its at least one processing core may be considered to be configured to perform said certain actions. Memory 820 may be at least in part comprised in processor 810. Memory 820 may be at least in part external to device 800 but accessible to device 800.
  • Device 800 may comprise a transmitter 830.
  • Device 800 may comprise a receiver 840.
  • Transmitter 830 and receiver 840 may be configured to transmit and receive, respectively, information in accordance with at least one cellular standard, such as a standard defined by the 3GPP.
  • Transmiter 830 may comprise more than one transmitter.
  • Receiver 840 may comprise more than one receiver.
  • Transmiter 830 and/or receiver 840 may be configured to operate in accordance with a suitable communication standard.
  • Device 800 may comprise User Interface, UI, 850.
  • UI 850 may comprise at least one of a display, a keyboard, a touchscreen, a vibrator arranged to signal to a user by causing device 800 to vibrate, a speaker and a microphone.
  • a user may be able to operate device 800 via UI 850, for example to configure device 800 and/or functions it runs.
  • Processor 810 may be furnished with a transmiter arranged to output information from processor 810, via electrical leads internal to device 800, to other devices comprised in device 800.
  • a transmitter may comprise a serial bus transmitter arranged to, for example, output information via at least one electrical lead to memory 820 for storage therein.
  • the transmiter may comprise a parallel bus transmitter.
  • processor 810 may comprise a receiver arranged to receive information in processor 810, via electrical leads internal to device 800, from other devices comprised in device 800.
  • Such a receiver may comprise a serial bus receiver arranged to, for example, receive information via at least one electrical lead from receiver 840 for processing in processor 810.
  • the receiver may comprise a parallel bus receiver.
  • Device 800 may comprise further devices not illustrated in FIGURE 8. In some example embodiments, device 800 lacks at least one device described above. For example, device 800 may not have UI 850.
  • Processor 810, memory 820, transmitter 830, receiver 840 and/or UI 850 may be interconnected by electrical leads internal to device 800 in a multitude of different ways.
  • each of the aforementioned devices may be separately connected to a master bus internal to device 800, to allow for the devices to exchange information.
  • this is only one example and depending on the example embodiment various ways of interconnecting at least two of the aforementioned devices may be selected without departing from the scope of the present invention.
  • FIGURE 9 is a flow graph of a first method in accordance with at least some example embodiments.
  • the phases of the illustrated first method may be performed by an NF, such as SCP 204 or NFP 208, or by a control device configured to control the functioning thereof, possibly when installed therein.
  • the first method may comprise, at step 910, transmitting a request about an access control list to a network repository function, wherein the request concerns accessing services of a network function producer.
  • the first method may also comprise, at step 920, receiving, in response to the request, an access control list response from the network repository function, the access control list response comprising an access control list, wherein the access control list is a list of network functions that are allowed to access services of the network function producer.
  • the first method may comprise, at step 930, validating a service request when a sender of the service request is in the access control list.
  • FIGURE 10 is a flow graph of a second method in accordance with at least some example embodiments.
  • the phases of the illustrated second method may be performed by NRF 202, or by a control device configured to control the functioning thereof, possibly when installed therein.
  • the second method may comprise, at step 1010, receiving a request about an access control list from a requesting network function, wherein the request concerns accessing services of a network function producer.
  • the second method may also comprise, at step 1020, determining an access control list, wherein the access control list is a list of network functions that are allowed to access services of the network function producer.
  • the second method may comprise, at step 1020, transmitting an access control list response to the requesting network function, the access control list response comprising the list of network functions.
  • Embodiments of the present invention may be exploited, e.g., in 3GPP standards.
  • a new 3GPP header “3gpp-forwarder” may be introduced in 3GPP standard specification TS 29.500, in section 5.2.3 “HTTP custom headers”.
  • a new entry may be to Table 5.2.7.1-1 “NF services provided by the NRF” in 3GPP standard specification TS 23.502, such as “Service Name: Nnrf_AccessControl”, “Service Operations: Get”, “Operation Semantics: Request/Response”, “Example Consumer(s): AMF, SMF, PCF, NEF, NSSF, SMSF, AUSF, UDM, NWDAF, I-CSCF, S- CSCF, IMS-AS, HSS, SCP, SEPP“.
  • a new service “AccessControlFist” may be added to 3GPP standard specification TS 29.510 as well.
  • an apparatus such as, for example, NRF 202, SCP 204 or NFP 208, or a device controlling functioning thereof, may comprise means for carrying out the example embodiments described above and any combination thereof.
  • a computer program may be configured to cause a method in accordance with the example embodiments described above and any combination thereof.
  • a computer program product embodied on a non-transitory computer readable medium, may be configured to control a processor to perform a process comprising the example embodiments described above and any combination thereof.
  • an apparatus such as, for example, NRF 202, SCP 204 or NFP 208, or a device controlling functioning thereof, may comprise at least one processor, and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to perform the example embodiments described above and any combination thereof.
  • At least some example embodiments find industrial application at least in 5G core networks, wherein it is desirable to authorize subscription requests, and possibly in other core networks in the future as well.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Selon un aspect donné à titre d'exemple, la présente invention concerne un procédé consistant à transmettre une demande concernant une liste de commande d'accès à une fonction de référentiel de réseau, la demande concernant l'accès à des services d'un producteur de fonction de réseau, à recevoir, en réponse à la demande, une réponse de liste de commande d'accès en provenance de la fonction de référentiel de réseau, la réponse de liste de commande d'accès comprenant une liste de commande d'accès et la liste de commande d'accès étant une liste de fonctions de réseau qui sont autorisées à accéder à des services du producteur de fonction de réseau, et à valider une demande de service lorsqu'un expéditeur de la demande de service est dans la liste de commande d'accès.
PCT/FI2021/050368 2020-05-25 2021-05-21 Autorisation améliorée dans des réseaux de communication WO2021240055A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN202041021832 2020-05-25
IN202041021832 2020-05-25

Publications (1)

Publication Number Publication Date
WO2021240055A1 true WO2021240055A1 (fr) 2021-12-02

Family

ID=78744146

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2021/050368 WO2021240055A1 (fr) 2020-05-25 2021-05-21 Autorisation améliorée dans des réseaux de communication

Country Status (1)

Country Link
WO (1) WO2021240055A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114301662A (zh) * 2021-12-27 2022-04-08 中国电信股份有限公司 请求生产者网络功能服务的方法及装置、设备及介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110620822A (zh) * 2019-09-27 2019-12-27 腾讯科技（深圳）有限公司 一种网元确定方法和装置
WO2020002764A1 (fr) * 2018-06-29 2020-01-02 Nokia Technologies Oy Gestion de sécurité pour un accès à un service dans un système de communication
US10609530B1 (en) * 2019-03-27 2020-03-31 Verizon Patent And Licensing Inc. Rolling out updated network functions and services to a subset of network users

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020002764A1 (fr) * 2018-06-29 2020-01-02 Nokia Technologies Oy Gestion de sécurité pour un accès à un service dans un système de communication
US10609530B1 (en) * 2019-03-27 2020-03-31 Verizon Patent And Licensing Inc. Rolling out updated network functions and services to a subset of network users
CN110620822A (zh) * 2019-09-27 2019-12-27 腾讯科技（深圳）有限公司 一种网元确定方法和装置

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 16", 3GPP TS 29.510, 30 March 2020 (2020-03-30), XP055877722, Retrieved from the Internet <URL:https://www.3gpp.org/ftp/Specs/archive/29_series/29.510/29510-g30.zip> [retrieved on 20210916] *
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS", 3GPP TS 23.502, 27 March 2020 (2020-03-27), Retrieved from the Internet <URL:https://www.3gpp.org/ftp/Specs/archive/23_series/23.502/23502-g40.zip> [retrieved on 20210916] *
ORACLE CORPORATION, VERIZON UK LTD: "Enablers for multiple SCPs (23.502)", 3GPP DRAFT; S2-2003193, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG2, no. Online Meeting ;20200420 - 20200423, 10 April 2020 (2020-04-10), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051874689 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114301662A (zh) * 2021-12-27 2022-04-08 中国电信股份有限公司 请求生产者网络功能服务的方法及装置、设备及介质
CN114301662B (zh) * 2021-12-27 2024-02-23 中国电信股份有限公司 请求生产者网络功能服务的方法及装置、设备及介质

Similar Documents

Publication Publication Date Title
US12063312B2 (en) Security procedure for cryptographic signature verification based on a trust relationship between edge nodes connecting home and visited networks
CN113661696B (zh) 用于处理可伸缩fqdn的系统和方法
US10728315B2 (en) Method and apparatus for distributing content using a mobile device
US11737011B2 (en) Management of access tokens in communication networks
US11425636B1 (en) Network function service subscription control
US20220191028A1 (en) Authorization of network request
EP4030685A1 (fr) Traitement des erreurs de demande de fonction réseau
EP3886390A1 (fr) Gestion de jeton
JP7404513B2 (ja) Ｔｌｓを用いる間接通信のサポート
WO2021140272A1 (fr) Vérification de jetons d&#39;accès avec des fonctions de référentiel de réseau dans des réseaux centraux
WO2021176131A1 (fr) Autorisation améliorée dans des réseaux de communication
WO2021094349A1 (fr) Autorisation de services en plusieurs étapes pour la communication indirecte dans un système de communication
WO2021140051A1 (fr) Requêtes dans un réseau
WO2021165194A1 (fr) Gestion de clé
WO2021165925A1 (fr) Gestion de clé
WO2021240055A1 (fr) Autorisation améliorée dans des réseaux de communication
US20230362209A1 (en) Systems and methods for facilitating provisioning of internet protocol multimedia subsystem services
US20230030315A1 (en) Network Security
US20230319569A1 (en) Enhanced interconnection between cellular communication networks
EP3852339B1 (fr) Activation de la qualité de service pour les fonctions de réseau de tiers fiables dans des réseaux principaux
WO2021198552A1 (fr) Autorisation améliorée dans des réseaux de communication
US11758368B2 (en) Methods, systems, and computer readable media for supporting mobile originated data multicasting in a communications network
EP4092982A1 (fr) Authentification d&#39;une demande de réseau
US20220217127A1 (en) Authentication of network request
EP4181465A1 (fr) Sécurité de réseau

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21814405

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21814405

Country of ref document: EP

Kind code of ref document: A1