WO2021140272A1 - Vérification de jetons d'accès avec des fonctions de référentiel de réseau dans des réseaux centraux - Google Patents

Vérification de jetons d'accès avec des fonctions de référentiel de réseau dans des réseaux centraux Download PDF

Info

Publication number
WO2021140272A1
WO2021140272A1 PCT/FI2020/050873 FI2020050873W WO2021140272A1 WO 2021140272 A1 WO2021140272 A1 WO 2021140272A1 FI 2020050873 W FI2020050873 W FI 2020050873W WO 2021140272 A1 WO2021140272 A1 WO 2021140272A1
Authority
WO
WIPO (PCT)
Prior art keywords
public key
request
network
function
network repository
Prior art date
Application number
PCT/FI2020/050873
Other languages
English (en)
Inventor
Pradyumna Ram PRASAD
Nagendra S BYKAMPADI
Ananth-Rama RAO
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 WO2021140272A1 publication Critical patent/WO2021140272A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • 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
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/108—Source integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices

Definitions

  • FIELD [0001] Various example embodiments relate in general to core networks, such as 5G core networks, and more specifically, to verification of access tokens with network repository functions in such networks.
  • access tokens may be used in a communication network to provide a secure way for authorized parties to access services. Access tokens may be exploited for example in core networks, such as in 5G core networks developed by 3rd Generation Partnership Project, 3GPP.
  • core networks such as in 5G core networks developed by 3rd Generation Partnership Project, 3GPP.
  • Network Function, NF, Service Producers need to be able to verify NF service requests and access tokens associated with the service requests, to provide service to authorized consumers.
  • 3GPP still develops 5G core networks and there is a need to provide improved methods, apparatuses and computer programs for verification of NF service requests and access tokens in 5G core networks, and possibly in other core networks in the future as well.
  • a method for a network repository function comprising receiving a request for a public key from a network function service producer, wherein the request for the public key is associated with an access token issued by the network repository function for a specific network function service consumer, retrieving the public key upon receiving the request for the public key of the network repository function and transmitting a public key response to the network function service producer, wherein the public key response is associated with the public key.
  • Embodiments of the first aspect may comprise at least one feature from the following bulleted list:
  • the public key response comprises the public key of the network repository function
  • the public key response comprises a certificate and the certificate further comprises the public key
  • the request for the public key comprises at least an issuer field of the access token, the issuer field identifying the network repository function that issued the access token.
  • a method for a network function service producer comprising transmitting a request for a public key to a network repository function, wherein the request for the public key is associated with the network repository function that issued an access token to a specific network function service consumer, receiving a public key response from the network repository function, wherein the public key response is associated with the public key of the network repository function and verifying a digital signature in the access token using the public key.
  • Embodiments of the second aspect may comprise at least one feature from the following bulleted list:
  • the public key response comprises the public key of the network repository function
  • the public key response comprises a certificate and the certificate further comprises the public key
  • the request for the public key comprises at least an issuer field of the access token, the issuer field identifying the network repository function that issued the access token.
  • an apparatus such as a network repository function, comprising one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to receive a request for a public key from a network function service producer, wherein the request for the public key is associated with an access token issued by the network repository function for a specific network function service consumer, retrieve the public key upon receiving the request for the public key of the network repository function and transmit a public key response to the network function service producer, wherein the public key response is associated with the public key.
  • the at least one memory and the computer program code may be further configured to, with the at least one processing core, cause the apparatus at least to perform the method according to the first aspect.
  • the apparatus may be a network repository function or control device configured to control the functioning thereof, possibly when installed therein.
  • an apparatus such as a network function service producer, comprising one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to transmit a request for a public key to a network repository function, wherein the request for the public key is associated with the network repository function that issued an access token to a specific network function service consumer, receive a public key response from the network repository function, wherein the public key response is associated with the public key of the network repository function and verify a digital signature in the access token using the public key.
  • the at least one memory and the computer program code may be further configured to, with the at least one processing core, cause the apparatus at least to perform the method according to the second aspect.
  • the apparatus may be a network function service producer or control device configured to control the functioning thereof, possibly when installed therein.
  • an apparatus such as a network repository function, comprising means for receiving a request for a public key from a network function service producer, wherein the request for the public key is associated with an access token issued by the network repository function for a specific network function service consumer, means for retrieving the public key upon receiving the request for the public key of the network repository function and means for transmitting a public key response to the network function service producer, wherein the public key response is associated with the public key.
  • the apparatus may comprise means for performing the method according to the first aspect.
  • the apparatus may be a network repository function or control device configured to control the functioning thereof, possibly when installed therein.
  • an apparatus such as a network function service producer, comprising means for transmitting a request for a public key to a network repository function, wherein the request for the public key is associated with the network repository function that issued an access token to a specific network function service consumer, means for receiving a public key response from the network repository function, wherein the public key response is associated with the public key of the network repository function and means for verifying a digital signature in the access token using the public key.
  • the apparatus may comprise means for performing the method according to the second aspect.
  • the apparatus may be a network function service producer or control device configured to control the functioning thereof, possibly when installed therein.
  • 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 method of the first aspect.
  • 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 method of the second aspect.
  • a computer program configured to perform the method of the first aspect.
  • a computer program configured to perform the method of the second aspect.
  • FIGURE 1 illustrates an exemplary system in accordance with at least some embodiments
  • FIGURE 2 illustrates service registration in accordance with at least some embodiments
  • FIGURE 3 illustrates an example apparatus capable of supporting at least some embodiments
  • FIGURE 4 illustrates a first signalling example in accordance with at least some embodiments
  • FIGURE 5 illustrates a second signalling example in accordance with at least some embodiments
  • FIGURE 6 illustrates a third signalling example in accordance with at least some embodiments
  • FIGURE 7 illustrates a fourth signalling example in accordance with at least some embodiments
  • FIGURE 8 illustrates a fifth signalling example in accordance with at least some embodiments
  • FIGURE 9 illustrates a sixth signalling example in accordance with at least some embodiments.
  • FIGURE 10 illustrates a flow graph of a first method in accordance with at least some embodiments.
  • FIGURE 11 illustrates a flow graph of a second method in accordance with at least some embodiments.
  • Verification of access tokens in core networks may be improved by the procedures described herein.
  • the network may comprise aNetwork Function, NF, Service Producer, a NF Service Consumer and more than one Network Repository Function, NRF.
  • the NF Service Producer may be registered with one NRF but receive an NF service request comprising an access token from an NF Service Consumer which is registered with another NRF.
  • Embodiments of the present invention may be used to address various challenges that may occur in such scenarios by making it possible for the NF Service Producer to request for a public key associated with the access token issued by the NRF for a specific NF Service Consumer, thereby enabling secure and functional verification of the NF service request and the access token regardless of the network topology.
  • the public key may be a public key of a NRF.
  • FIGURE 1 illustrates an exemplary system in accordance with at least some embodiments of the present invention.
  • the exemplary system of FIGURE 1 comprises two Public Land Mobile Networks, PLMNs, 110 and 112, each equipped with an NF, 120 and 122, respectively.
  • An NF 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 Elements, VNFs.
  • One physical node may be configured to perform plural NFs. Examples of such network functions 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, a Unified Data Management, UDM, an Authentication Server Function, AUSF, a Policy Control Function, PCF, and an Application Function, AF.
  • 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.
  • the SEPP 130, 132 is a network node at the boundary of an operator's network that receives a message, such as an HTTP request or HTTP response from the NF, applies protection for sending, and forwards the reformatted message through a chain of intermediate nodes, such as IP exchanges, IPX, towards a receiving SEPP.
  • the receiving SEPP receives a message sent by the sending SEPP and forwards the message towards an NF within its operator’s network, e.g. the AUSF.
  • An inter-PLMN interconnection allows secure communication between a service-consuming NF and a service-producing NF, referred to as cNF 120 and pNF 122 in FIGURE 1.
  • cNF 120 may be referred to as an NF Service Consumer
  • pNF 122 may be referred to as an NF Service Producer.
  • a Service Communication Proxy, SCP, 150 may be deployed for indirect communication between network functions.
  • the SCP 150 is an intermediate function/element to assist in routing of messages, such as control plane messages such as Diameter Routing Agent, DRA, messages between NFs.
  • Direct communication may be applied between cNF 120 and pNF 122 for an NF service, or NF service communication may be performed indirectly via SCP(s) 150.
  • the cNF 120 may perform discovery of the target pNF 122 by local configuration or via local NRF, cNRF 140.
  • the cNF 120 may delegate the discovery of the target pNF 122 to the pSCP 150 used for indirect communication.
  • the pSCP uses the parameters provided by cNF 120 to perform discovery and/or selection of the target NF Service Producer.
  • the pSCP address may be locally configured in cNF 120.
  • an SCP is an intermediate function covering delegated NF discovery to help resolving the target NF producer instances and delegated routing to help route control plane messages between two NFs.
  • NF discovery and NF service discovery enable core network entities, such as cNF 140 or 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 is a function that is used to support the functionality of NF and NF service discovery and status notification.
  • the NRF may maintain an NF profile of available NF instances and their supported services.
  • the NRF may notify about newly registered, updated, or deregistered NF instances along with its NF services to a subscribed cNF 120 or cSCP 150.
  • the NF and NF service discovery may be implemented via the NRF.
  • the NRF is a logical function that is used to support the functionality of NF and NF service discovery.
  • the NRF may also support status notification.
  • An NRF may be co-located together with an SCP.
  • the cNF 120 or cSCP 150 may initiate, based on local configuration, a discovery procedure with the cNRF 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 cNF 120 or cSCP 150 may also provide other service parameters, such as slicing related information.
  • the cSCP 150 may request service discovery from an NRF in its PLMN 110, i.e., the cNRF 140.
  • the cNRF may send a discovery request to an NRF, referred herein as pNRF 142, in another PLMN 112, e.g. the home PLMN.
  • the pNRF 142 in the other network 112 may respond with a discovery response which may be forwarded to the cSCP via the cNRF 140 in the PLMN 110 of the cNF 120.
  • the cSCP may trigger service requests for the pNF via the cSEPP 130 and the pSEPP 132.
  • a cNF 120 may provide the SCP an address or name of the NRF which may be used by the SCP.
  • 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, while 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 can be used to refer to at least some respective entities in the visited and home PFMNs.
  • OAuth based authorization and token exchange may be applied between the mobile networks.
  • the second network entity such as the pNRF 142
  • the cNF 120 may be an OAuth client and the pNF 122 may operate as OAuth resource server, and both may be configured to support OAuth authorization framework as defined in RFC 6749.
  • An NF such as pNF 122, may register its services with an NRF.
  • a public key used by the NF in question is needed for verifying an NF service request, i.e., an access token, of the NF.
  • the public key of the NF is the public key of the NRF to which the NF is registered.
  • a public key of an NRF is made available to the NF’s services through TFS connections as part of the handshake.
  • FIGURE 2 illustrates service registration in accordance with at least some embodiments. More specifically, FIGURE 2 illustrates service registration of an NF Service Consumer, such as cNF 120 of FIGURE 1, withNRF-3.
  • an NF for example the NF Service Consumer of FIGURE 2 or NF Service Producer (not shown in FIGURE 2), registers to an NRF, there may be no defined hierarchy.
  • the NF Service Producer such as pNF 122 of FIGURE 1
  • the NRF -4 As part of a TLS handshake the NF Service Producer may receive a public key of the NRF -4 to be used later for verification of tokens. So if there is an NF Service Consumer, registered with the NRF-1, which tries to discover the NF Service Producer, the process would follow the service registration demonstrated in FIGURE 2.
  • the NRF-1, NRF -2 and NRF-3 of FIGURE 2 may be in the same serving PLMN, but the NRF- 4 may be in a different PLMN.
  • the NF Service Consumer may transmit an access token request (AccessTokenReq) to the NRF-1.
  • the NRF-1 may forward the access token request to the NRF -2 at step 220.
  • the NRF -2 may respond to the access token request by transmitting a redirect message (307 Temporary Redirect, 404 Not Found) at step 230. Consequently, the NRF-1 may also forward the access token request to the NRF-3 at step 240.
  • the NRF-3 may respond to the access token request by transmitting an access token response (200 OK (AccessTokenRsp, 400 Bad Request (AccessTokenErr)) at step 250. So the NRF-3 may return an access token in the access token response for accessing the NF Services Producer’s services.
  • the NRF-1 may forward the access token to the NF Service Consumer at step 260.
  • the access token response may contain the access token (AccessTokenClaim) returned and signed by the NRF-3 and a MAC calculation used for digital signature for validation of the access token would be the private key of the NRF-3. So if the NF Service Consumer uses the access token to access the NF Services Producer’s services, the NF Service Producer would not be able to verify the access token, because the NF Services Producer has the public key of the NRF-4 but the NF Services Producer does not have the public key of the NRF-3 required for verification of the access token of the NF Service Consumer in question.
  • Another challenge may be related to interaction through an SCP and registration of the NF Service Producer with the NRF-1.
  • the NF Service Producer may register with the NRF-1 via the SCP.
  • a connection may be created with the SCP and the NF Service Producer would have the TLS certificate of the direct peer, i.e., the SCP.
  • the NF Service Producer would have the public key of the SCP and hence an OAuth verification failure may occur.
  • the NF Service Consumer may get the access token from the NRF-1, wherein the access token is signed by the private key of the NRF-1.
  • the public key of the NRF-1 would be thus required by the NF Service Producer to verify the access token of the NF Service Consumer in question.
  • verification of a service request, transmitted from the NF Service Consumer to the NF Service Producer would fail as the NF Service Producer has the public key of the SCP but not the public key of the NRF-1.
  • challenges may occur also when an OAuth NRF, i.e., an NRF offering OAuth services, is different from the NRF the NF Service Producer is registered with. Registration of the NF Service Producer with the NRF-1 may be performed through direct registration and the NF Producer may get the public key of the NRF-1 from the TLS handshake.
  • OAuth NRF i.e., an NRF offering OAuth services
  • the OAuth verification may fail though, because if the NF Service Consumer gets the access token from the NRF-2, the access token may be signed by the private key of the NRF-2. The public key of the NRF-2 would be thus required by the NF Service Producer to verify the access token. However, verification of the access token, transmitted from the NF Service Consumer to the NF Service Producer would fail as the NF Service Producer would have the public key of the NRF-1 but not the public key of the NRF-2.
  • Embodiments of the present invention there provide a dynamic solution which makes it possible to query and obtain the required key by the NF Service Producer to verify a digital signature in the NF service request, i.e., the digital signature in the access token, received from the NF Service Consumer.
  • signalling burden may be minimized compared to provisioning of all of the keys.
  • FIGURE 3 illustrates an example apparatus capable of supporting at least some embodiments. Illustrated is device 300, which may comprise, for example, anNRF or anNF Service Producer, or a device controlling functioning thereof.
  • processor 310 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 310 may comprise, in general, a control device.
  • Processor 310 may comprise more than one processor.
  • Processor 310 may be a control device.
  • Processor 310 may comprise at least one Application-Specific Integrated Circuit, ASIC.
  • Processor 310 may comprise at least one Field-Programmable Gate Array, FPGA.
  • Processor 310 may comprise an Intel Xeon processor for example.
  • Processor 310 may be means for performing method steps in device 300, such as retrieving, transmitting and receiving.
  • Processor 310 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 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 300 may comprise memory 320.
  • Memory 320 may comprise random- access memory and/or permanent memory.
  • Memory 320 may comprise at least one RAM chip.
  • Memory 320 may comprise solid-state, magnetic, optical and/or holographic memory, for example.
  • Memory 320 may be at least in part accessible to processor 310.
  • Memory 320 may be at least in part comprised in processor 310.
  • Memory 320 may be means for storing information.
  • Memory 320 may comprise computer instructions that processor 310 is configured to execute. When computer instructions configured to cause processor 310 to perform certain actions are stored in memory 320, and device 300 overall is configured to run under the direction of processor 310 using computer instructions from memory 320, processor 310 and/or its at least one processing core may be considered to be configured to perform said certain actions.
  • Memory 320 may be at least in part comprised in processor 310.
  • Memory 320 may be at least in part external to device 300 but accessible to device 300.
  • Device 300 may comprise a transmitter 330.
  • Device 300 may comprise a receiver 340.
  • Transmitter 330 and receiver 340 may be configured to transmit and receive, respectively, information in accordance with at least one cellular or non-cellular standard.
  • Transmitter 330 may comprise more than one transmitter.
  • Receiver 340 may comprise more than one receiver.
  • Transmitter 330 and/or receiver 340 may be configured to operate in accordance with a suitable communication standard.
  • Device 300 may comprise User Interface, UI, 350.
  • UI 350 may comprise at least one of a display, a keyboard, a touchscreen, a vibrator arranged to signal to a user by causing device 300 to vibrate, a speaker and a microphone.
  • a user may be able to operate device 300 via UI 350, for example to configure device 300 and/or functions it runs.
  • Processor 310 may be furnished with a transmitter arranged to output information from processor 310, via electrical leads internal to device 300, to other devices comprised in device 300.
  • a transmitter may comprise a serial bus transmitter arranged to, for example, output information via at least one electrical lead to memory 320 for storage therein.
  • the transmitter may comprise a parallel bus transmitter.
  • processor 310 may comprise a receiver arranged to receive information in processor 310, via electrical leads internal to device 300, from other devices comprised in device 300.
  • Such a receiver may comprise a serial bus receiver arranged to, for example, receive information via at least one electrical lead from receiver 340 for processing in processor 310.
  • the receiver may comprise a parallel bus receiver.
  • Device 300 may comprise further devices not illustrated in FIGURE 3. In some embodiments, device 300 lacks at least one device described above. For example, device 300 may not have UI 350.
  • Processor 310, memory 320, transmitter 330, receiver 340 and/or UI 350 may be interconnected by electrical leads internal to device 300 in a multitude of different ways.
  • each of the aforementioned devices may be separately connected to a master bus internal to device 300, to allow for the devices to exchange information.
  • this is only one example and depending on the 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 4 illustrates a first signalling example in accordance with at least some embodiments.
  • the NF Service Producer may transmit a request for a public key (AccessTokenClaims) to the NRF-4.
  • the NRF-4 may forward the request to the NRF-2 at step 420.
  • the NRF-2 may respond to the request for the public key by transmitting a redirect message (307 Temporary Redirect, 404 Not Found) at step 430. Consequently, the NRF-4 may also forward the request to the NRF- 3 at step 440.
  • the NRF-3 may respond to the access token request by transmitting a public key response (200 OK (PublicKeyRsp, 400 Bad Request (PublicKeyErr)) at step 450.
  • a public key response 200 OK (PublicKeyRsp, 400 Bad Request (PublicKeyErr)
  • the public key response may be associated with the public key of the NRF-3.
  • the public key response may comprise the public key as it is, i.e., directly in the response.
  • the public key response may comprise a certificate and the certificate may further comprise the public key.
  • the request for the public key may be associated with the access token issued by the NRF, such as the NRF-3, for a specific NF Service Consumer.
  • the NRF-3 may return the public key in the public key response for verifying the NF Services Consumer’s service request, i.e., the access token.
  • the NRF- 4 may forward the access token to the NF Service Producer at step 460.
  • the NF Service Producer may verify the NF service request of the NF Service Consumer using the public key. That is to say, the NF Service Producer may verify the access token, i.e., the digital signature in the access token, of the NF Services Consumer using the public key received from the NRF-3, if the NF Service Consumer is registered with the NRF-3.
  • the NRF-2 and NRF-3 of FIGURE 2 may be in the same serving PLMN of the NF Service Consumer, but the NRF -4 may be in a different PLMN.
  • the NF Service Producer may be registered with the NRF-4.
  • verification of the access token i.e., the digital signature in the access token, is enabled even though the NF Service Producer and the NF Service Consumer would be registered with different NRFs, and possibly located even in different PLMNs.
  • the NRF-4 may detect that the NF Service Consumer is registered to a different NRF than the NF Service Producer based on an issuer field of the access token, received in the request for the access key, and responsive to said detection the NRF-4 may transmit the request for the public key to another NFRs, such as NRF-2 and NRF-3.
  • the issuer field may identify the NRF that issued the access token to the NF Service Consumer.
  • FIGURE 5 illustrates a second signalling example in accordance with at least some embodiments.
  • the NF Service Producer may receive an NF service request from an NF Service Consumer at step 510.
  • the NF service request may comprise an access token.
  • the NF Service Producer may try to retrieve the public key that is needed for verifying the NF service request, i.e., the digital signature in the access token.
  • the public key may be retrieved once per connection for a validity duration for example.
  • the NF Service Producer may first check if it already has the public key that corresponds to the NF service request and the access token therein, i.e., the public key of the NRF to which the NF Service Consumer is registered to.
  • the NF Service Producer may determine that it has the public key already and in such a case, the NF Service Producer may proceed with verification of the digital signature in the access token. In some embodiments, the NF Service Producer may determine that it does not have the public key and consequently, the NF Service Producer may, at step 520, transmit a request for the public key to the NRF.
  • the request for the public key may be referred to as a public key request as well.
  • the request for the public key may be associated with the NF service request of the NF Service Consumer.
  • the request for the public key may be a request for the public key of the NF Service Consumer, such as the public key needed for verifying that the NF service request is valid.
  • the request for the public key may be associated with the NF service request of the NF Service Consumer so that the request comprises at least a part of the access token of the NF Service Consumer, i.e., at least a part of the access token included in the NF service request of the NF Service Customer.
  • the request for the public key may comprise for example an issuer field of the access token.
  • the NF Service Producer may be registered with the NRF in question.
  • the request for the public key may be transmitted over a TLS connection.
  • the NF Service Producer may transmit a complete access token received from the NF Service Customer, i.e., the request for the public key may comprise the complete access token.
  • the NF Service Producer may transmit a part of the access token, i.e., the request for the public key may comprise the part of the access token, such as an issuer, a subject and an audience of the access token.
  • the NRF that receives the request for the public key may retrieve the public key upon receiving the request for the public key at step 530.
  • the NRF may for example determine whether it has the public key and retrieve the public key based on said determination. For the determination, the NRF may look at the issuer field and if the issuer field is the same as an identity of the NRF, the NRF may determine that it has the public key, i.e., the NF Service Consumer is registered to the NRF in question.
  • the NRF may either respond to the request or forward the request to the appropriate NRF depending on whether it has the public key or not.
  • the NRF may retrieve the public key from another NRF upon determining that the NRF does not have the public key, i.e., when the NF Service Customer is registered to another NRF. That is to say, the NRF may retrieve the public key from another NRF upon determining that the request is for said another NRF. So in such a case the NRF may forward the request for the public key to said another NRF and receive the public key from said another NRF.
  • the NRF may retrieve the public key from a memory of the NRF if it is determined that the NRF in question has the public key.
  • the NRF may transmit a public key response to the NF Service Producer at step 540.
  • the public key response may comprise the public key.
  • the public key response may be transmitted over the TLS connection.
  • the NRF may verify the NF service request, i.e., the digital signature in the access token, using the received public key.
  • the public key response may comprise a certificate and the certificate may further comprise the public key.
  • the certificate may be a X.509 certificate.
  • the NF Service Producer may validate the certificate and extract the public key from the certificate after the validation. For instance, the NF Service Producer may validate the certificate against a certificate revocation list, a root certificate and/or a certificate for expiry. Once the validation has been performed the public key may be extracted from the certificate. The above validation steps are not required / possible if the public key was sent without the certificate, but the use of the certificate may be used to further improve security.
  • the NF Service Producer may transmit an NF service response at step 560. Depending on the result of the verification of the access token, the NF Service Producer may decline or accept the NF service request.
  • the retrieval of the public key of a given NF service request may be performed over TLS across all hops, to avoid “man in the middle attacks”.
  • Embodiments of the present invention may be used in all cases, regardless of the hierarchy or the presence of any intermediaries like SCPs. Embodiments of the present invention may be exploited for example in standardization, by applying some changes to 3 GPP standard specification TS 33.501 and/or 29.510 for example.
  • FIGURE 6 illustrates a third signalling example in accordance with at least some embodiments.
  • the example of FIGURE 6 is similar compared to the example of FIGURE 5 in a sense that steps 610 - 660 of FIGURE 6 may correspond to steps 510 - 560 of FIGURE 5.
  • FIGURE 6 demonstrates roaming scenarios and may be applied for example in the 3GPP TS 33.501, Section 13.4.1.2.
  • FIGURE 6 shows the request for the public key across PLMNs towards the NRF. That is to say, the NF Service Consumer and the NF Service Producer may be located in different PFMNs.
  • the NF Service Producer may detect that the NF Service Consumer is in a different PFMN, e.g., based on an issuer field of the access token of the NF service request, and responsive to the detection, transmit the request for the public key.
  • reliable verification of the access token, i.e., the digital signature in the access token, of the NF Service Consumer is enabled, even if the NF Service Consumer and the NF Service Producer would be in different PFMNs.
  • FIGURE 7 illustrates a fourth signalling example in accordance with at least some embodiments.
  • FIGURE 7 demonstrates additional service operation to get the public key from the NRF, which may be applied for example in the 3GPP TS 29.510, Section
  • the NF Service Producer may, at step 710 transmit a request for a public key (AccessTokenClaims) to the NRF-4 and upon receiving the NF request, the NRF-4 may respond at step 720 by transmitting a public key response comprising the public key (200 OK (PublicKeyRsp), 400 Bad Request (PublicKeyErr)).
  • the NF Service Producer may be registered to NRF-4 in this example.
  • FIGURE 8 illustrates a fourth signalling example in accordance with at least some embodiments.
  • FIGURE 8 demonstrates additional service operation to get the public key from the NRF, which may be applied for example in the 3GPP TS 29.510, Section
  • the NF Service Producer may, at step 810, transmit a request for a public key (AccessTokenClaims) to the SCP and upon receiving the request for the public key, the SCP may forward the request to the NRF- 2 at step 820.
  • the NRF -2 may respond at step 830 by transmitting a public key response comprising the public key (200 OK (PublicKeyRsp), 400 Bad Request (PublicKeyErr)).
  • the SCP may then forward the public key response to the NF Service Producer at step 840.
  • the NF Service Producer may be registered with an NRF via the SCP.
  • the NF Service Producer may detect that it is registered via the SCP and responsive to said detection, transmit the request for the public key to the SCP right away. Efficient communication through the SCP is therefore enabled.
  • FIGURE 9 illustrates a fifth signalling example in accordance with at least some embodiments.
  • FIGURE 9 demonstrates additional service operation to get the public key from the NRF and may be applied for example in the 3GPP TS 29.510, Section 5.4.2.3.3 (Hierarchical NRF).
  • the NF Service Producer may, at step 910, transmit a request for a public key (AccessTokenClaims) to the NRF-1 and upon receiving the request for the public key, the NRF-1 may forward the request to the NRF -2 at step 920.
  • a public key AccessTokenClaims
  • the NRF -2 may respond at step 930 by transmitting a public key response comprising the public key (200 OK (PublicKeyRsp), 400 Bad Request (PublicKeyErr)).
  • the NRF-1 may then forward the response to the NF Service Producer at step 940.
  • the NF Service Producer may be registered with the NRF-1.
  • the NF Service Producer may detect that hierarchical NRFs are used and responsive to said detection, transmit the request for the public key to the NRF-1 right away. Efficient communication is therefore enabled in case of hierarchical NRFs.
  • Some embodiments of the present invention may thus provide efficient communication regardless of the network topology/configuration (regardless of whether direct communication, indirect communication through SCP or hierarchical NRFs is used), because the NF Service Producer may detect the network topology/configuration upon receiving the access token from the NF Service Consumer and responsive to said detection, transmit the request for the public key to the NRF of the NF Service Producer right away.
  • At least some embodiments of the present invention may be applied in TS 29.510 as API additions, e.g., as additions to an existing yaml “TS29510_Nnrf_AccessToken.yaml”, as follows:
  • PublicKeyErr type: object required:
  • FIGURE 10 is a flow graph of a first method in accordance with at least some embodiments.
  • the phases of the illustrated first method may be performed by an NRF, or by a control device configured to control the functioning thereof, possibly when installed therein.
  • the first method may comprise, at step 1010, receiving a request for a public key from a network function service producer, wherein the request for the public key is associated with an access token issued by the network repository function for a specific a network function service consumer.
  • the first method may also comprise, at step 1020, retrieving the public key upon receiving the request for the public key of the network repository function.
  • the first method may comprise, at step 1030, transmitting a public key response to the network function service producer, wherein the public key response is associated with the public key.
  • FIGURE 11 is a flow graph of a second method in accordance with at least some embodiments.
  • the phases of the illustrated second method may be performed by an NF Service Producer, or by a control device configured to control the functioning thereof, possibly when installed therein.
  • the second method may comprise, at step 1110, transmitting a request for a public key to a network repository function, wherein the request for the public key is associated with the network repository function that issued an access token to a specific network function service consumer.
  • the second method may also comprise, at step 1120, receiving a public key response from the network repository function, wherein the public key response is associated with the public key of the network repository function.
  • the second method may comprise, at step 1130, verifying a digital signature in the access token using the public key.
  • an apparatus such as, for example, an NRF or an NF Service Producer, may comprise means for carrying out the embodiments described above and any combination thereof.
  • a computer program may be configured to cause a method in accordance with the 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 embodiments described above and any combination thereof.
  • an apparatus such as, for example, an NRF or an NF Service Producer, 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 embodiments described above and any combination thereof.
  • At least some embodiments find industrial application in 5G core networks, wherein it is desirable to verify service requests and access tokens with NRFs.
  • NRF Network Repository Function NRF Network Repository Function
  • NSSF Network Slice Selection Function NRF Network Repository Function
  • PCF Policy Control Function PLMN Public Land Mobile Network
  • SBA Service-Based Architecture
  • SCP Service Communication Proxy
  • SEPP Security Edge Protection Proxy
  • SMF Session Management Function UDM Unified Data Management

Landscapes

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

Abstract

Selon un aspect donné à titre d'exemple, l'invention concerne un procédé consistant à : recevoir une demande de clé publique d'un producteur de service de fonction réseau, la demande de clé publique étant associée à un jeton d'accès émis par la fonction de référentiel réseau pour un consommateur de service de fonction réseau spécifique ; récupérer la clé publique lors de la réception de la demande de clé publique de la fonction de référentiel réseau ; et transmettre une réponse de clé publique au producteur de service de fonction réseau, la réponse de clé publique étant associée à la clé publique de la fonction de référentiel réseau.
PCT/FI2020/050873 2020-01-10 2020-12-30 Vérification de jetons d'accès avec des fonctions de référentiel de réseau dans des réseaux centraux WO2021140272A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN202041001213 2020-01-10
IN202041001213 2020-01-10

Publications (1)

Publication Number Publication Date
WO2021140272A1 true WO2021140272A1 (fr) 2021-07-15

Family

ID=76787762

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2020/050873 WO2021140272A1 (fr) 2020-01-10 2020-12-30 Vérification de jetons d'accès avec des fonctions de référentiel de réseau dans des réseaux centraux

Country Status (1)

Country Link
WO (1) WO2021140272A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023051316A1 (fr) * 2021-09-29 2023-04-06 新华三技术有限公司 Procédé et appareil d'autorisation de service de réseau et dispositif électronique
US20230171255A1 (en) * 2021-11-29 2023-06-01 Verizon Patent And Licensing Inc. Computerized system and method for enhanced authorization of network data
WO2024003827A1 (fr) * 2022-06-29 2024-01-04 Jio Platforms Limited Système et procédé de validation de jeton d'accès au niveau d'une fonction de référentiel réseau
WO2024125345A1 (fr) * 2022-12-14 2024-06-20 华为技术有限公司 Procédé et appareil de communication

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019041802A1 (fr) * 2017-08-31 2019-03-07 华为技术有限公司 Procédé et appareil de découverte basés sur une architecture orientée service
US20190253894A1 (en) * 2018-02-15 2019-08-15 Nokia Technologies Oy Security management for roaming service authorization in communication systems with service-based architecture

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019041802A1 (fr) * 2017-08-31 2019-03-07 华为技术有限公司 Procédé et appareil de découverte basés sur une architecture orientée service
US20190253894A1 (en) * 2018-02-15 2019-08-15 Nokia Technologies Oy Security management for roaming service authorization in communication systems with service-based architecture

Non-Patent Citations (4)

* 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 STANDARD; TECHNICAL SPECIFICATION; 3GPP TS 29.510, vol. CT WG4, no. V16.2.0, 20 December 2019 (2019-12-20), pages 1 - 167, XP051840882 *
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security architecture and procedures for 5G system (Release 16", 3GPP STANDARD; TECHNICAL SPECIFICATION; 3GPP TS 33.501, vol. SA WG3, no. V16.1.0, 31 December 2019 (2019-12-31), pages 1 - 202, XP051841018 *
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security Aspects; Study on security aspects of the 5G Service Based Architecture (SBA) (Release 16", 3GPP TR 33.855, no. V1.9.0, November 2019 (2019-11-01) *
"Network Functions Virtualisation (NFV) Release 2; Security; Access Token Specification for API Access", ETSI DRAFT; ETSI GS NFV-SEC 022, vol. ISG - NFV, no. V2.7.1, 29 January 2020 (2020-01-29), pages 1 - 49, XP014374302 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023051316A1 (fr) * 2021-09-29 2023-04-06 新华三技术有限公司 Procédé et appareil d'autorisation de service de réseau et dispositif électronique
US20230171255A1 (en) * 2021-11-29 2023-06-01 Verizon Patent And Licensing Inc. Computerized system and method for enhanced authorization of network data
WO2024003827A1 (fr) * 2022-06-29 2024-01-04 Jio Platforms Limited Système et procédé de validation de jeton d'accès au niveau d'une fonction de référentiel réseau
WO2024125345A1 (fr) * 2022-12-14 2024-06-20 华为技术有限公司 Procédé et appareil de communication

Similar Documents

Publication Publication Date Title
US20220158847A1 (en) Security procedure
WO2021140272A1 (fr) Vérification de jetons d'accès avec des fonctions de référentiel de réseau dans des réseaux centraux
US11737011B2 (en) Management of access tokens in communication networks
EP3120591B1 (fr) Dispositif sur la base d'un identifiant d'utilisateur, système de gestion d'identité et d'activité
US11425636B1 (en) Network function service subscription control
US20220191028A1 (en) Authorization of network request
US20220224589A1 (en) Network function request error handling
EP3886390A1 (fr) Gestion de jeton
US20220104162A1 (en) Authorization of network node
WO2021176131A1 (fr) Autorisation améliorée dans des réseaux de communication
WO2021165925A1 (fr) Gestion de clé
WO2021165194A1 (fr) Gestion de clé
WO2021224545A1 (fr) Enregistrement amélioré dans des réseaux de communication
US20230030315A1 (en) Network Security
WO2021099675A1 (fr) Gestion de sécurité de service de réseau mobile
US20230319569A1 (en) Enhanced interconnection between cellular communication networks
WO2021240055A1 (fr) Autorisation améliorée dans des réseaux de communication
US12004059B2 (en) Enhanced identification in communication networks
WO2021224544A1 (fr) Enregistrement dans des réseaux de communication
GB2498566A (en) Authenticating a user at a proxy using cookies
WO2021079023A1 (fr) Sécurité de communication de réseau inter-mobile
EP3852339B1 (fr) Activation de la qualité de service pour les fonctions de réseau de tiers fiables dans des réseaux principaux
EP4181465A1 (fr) Sécurité de réseau
US20220217127A1 (en) Authentication of network request
EP4092982A1 (fr) Authentification d'une demande 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: 20911982

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: 20911982

Country of ref document: EP

Kind code of ref document: A1