WO2021165194A1 - Gestion de clé - Google Patents

Gestion de clé Download PDF

Info

Publication number
WO2021165194A1
WO2021165194A1 PCT/EP2021/053622 EP2021053622W WO2021165194A1 WO 2021165194 A1 WO2021165194 A1 WO 2021165194A1 EP 2021053622 W EP2021053622 W EP 2021053622W WO 2021165194 A1 WO2021165194 A1 WO 2021165194A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
network
service
public key
function
Prior art date
Application number
PCT/EP2021/053622
Other languages
English (en)
Inventor
Nagendra Bykampadi
Silke Holtmanns
Jani Ekman
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 WO2021165194A1 publication Critical patent/WO2021165194A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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
    • 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/604—Tools and structures for managing or administering access control systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • 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
    • 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
    • H04L9/3268—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 using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity

Definitions

  • the present disclosure relates to communication between network functions and network support functions.
  • Core network, CN entities may seek to discover a set of one or more NF instances and NF service instances for a specific NF service or an NF type.
  • CN entities include NFs and Service Communication Proxies, SCPs.
  • NF instances to be discovered include application functions, gateways and subscriber repositories, and also application related functions e.g. for vertical industry support, or entertainment. Further examples include a (radio) access or resource control or management function, a session management or control function, an interworking, data management or storage function, an authentication function or a combination of one or more of these functions.
  • NF service instances, known also as NF services include individual services provided by an NF.
  • One NF may be configured to provide more than one service, wherein each of the more than one service may be reachable using a different approach, such as a different port or communication protocol.
  • NF service discovery may be enabled via a NF discovery procedure, as specified for wireless communication networks in technical specifications established by the third generation partnership project, 3 GPP, or GSMA, GSM association, for example.
  • 3 GPP third generation partnership project
  • GSMA GSM association
  • technology disclosed herein has relevance also to wire-line communication networks, such as internet protocol, IP, based networking, or a combination thereof.
  • an apparatus comprising a memory configured to store a token received in the apparatus from a network function requesting a service, and at least one processing core configured to cause transmission, from the apparatus to a network support function, of a request message concerning the token, the token relating to the service, and to process a response message from the network support function, the response message comprising information concerning a public key relating to the token.
  • an apparatus comprising a memory configured to store information concerning public keys of network support functions, and at least one processing core configured to receive, from a network function or a service communication proxy, a request message concerning a token, and to cause transmission, from the apparatus, of a response message, the response message comprising information concerning a public key relating to the token.
  • a method comprising storing a token received in an apparatus performing the method from a network function requesting a service, and causing transmission, from the apparatus to a network support function, of a request message concerning the token, the token relating to the service, and processing a response message from the network support function, the response message comprising information concerning a public key relating to the token.
  • a method comprising storing information concerning public keys of network support functions, and receiving, from a network function or a service communication proxy, a request message concerning a token, and to cause transmission, from an apparatus performing the method, of a response message, the response message comprising information concerning a public key relating to the token.
  • an apparatus comprising means for storing a token received in the apparatus performing the method from a network function requesting a service, and causing transmission, from the apparatus to a network support function, of a request message concerning the token, the token relating to the service, and processing a response message from the network support function, the response message comprising information concerning a public key relating to the token.
  • an apparatus comprising means for storing information concerning public keys of network support functions, and receiving, from a network function or a service communication proxy, a request message concerning a token, and to cause transmission, from the apparatus, of a response message, the response message comprising information concerning a public key relating to the token.
  • a 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 storing a token received in the apparatus from a network function requesting a service, and causing transmission, from the apparatus to a network support function, of a request message concerning the token, the token relating to the service, and processing a response message from the network support function, the response message comprising information concerning a public key relating to the token.
  • a 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 storing information concerning public keys of network support functions, and receiving, from a network function or a service communication proxy, a request message concerning a token, and to cause transmission, from the apparatus, of a response message, the response message comprising information concerning a public key relating to the token.
  • a computer program configured to cause, when executed, an apparatus to perform at least the following: storing a token received in the apparatus from a network function requesting a service, and causing transmission, from the apparatus to a network support function, of a request message concerning the token, the token relating to the service, and processing a response message from the network support function, the response message comprising information concerning a public key relating to the token.
  • a computer program configured to cause, when executed, an apparatus to perform at least the following: storing information concerning public keys of network support functions, and receiving, from a network function or a service communication proxy, a request message concerning a token, and to cause transmission, from the apparatus, of a response message, the response message comprising information concerning a public key relating to the token.
  • FIGURE 1 illustrates an example system in accordance with at least some embodiments of the present invention
  • FIGURE 2A illustrates hierarchical NRFs relevant to the present disclosure
  • FIGURE 2B illustrates messaging in hierarchical NRFs which causes the
  • FIGURE 3 illustrates an example apparatus capable of supporting at least some embodiments of the present invention
  • FIGURE 4A illustrates signalling in accordance with at least some embodiments of the present invention
  • FIGURE 4B illustrates signalling in accordance with at least some embodiments of the present invention
  • FIGURE 4C illustrates signalling in accordance with at least some embodiments of the present invention
  • FIGURE 5 is a flow graph of a method in accordance with at least some embodiments of the present invention.
  • a network support function architecture may be enhanced to enable provision of public keys to network functions, NFs, which provide services, such that these network functions are then able to verify that cryptographic tokens provided to them from NFs which request the services are valid.
  • a public key may be used for encryption and/or signature verification.
  • An example network support function is a network repository function, NRE.
  • An NF which provides a service may be referred to as a NF producer, NFp.
  • An NF which requests a service may be referred to as a NF consumer, NFc.
  • a network function e.g.
  • NFp, NFc or an NRE may query, by sending a request message, from a network support function, such as an NRE, for the public key or a location from where it may be obtained.
  • the NRE may respond to the request message by obtaining the public key, or its location, from a data repository of the NRE, or by obtaining it from another NRE, and returning the thus obtained public key, or its location, to the querying NFp.
  • the public key or its location is information concerning the public key.
  • An NFp may be run in a user equipment, or in another network node, for example.
  • the fetching mechanism may also be deployed for a system, where a set of NFs is equipped with a master key and the NF fetches its own shared key, which is secured with the master key.
  • the NF uses the same provisioning mechanism, only the shared key is secured with the master key.
  • the master key might be part of the initial NF settings.
  • FIGURE 1 illustrates an example system 100 in accordance with at least some embodiments of the present invention.
  • the system comprises two public land mobile networks, PLMNs, 110, 112, each equipped with a network function, NF, 120, 122.
  • a network function may refer to an operational and/or a physical entity.
  • a network function 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 virtualized 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, a network repository function, NRF, a unified data management, UDM, an authentication server function, AUSF, a policy control function, PCF, and an application function, AF.
  • a further example is a user plane function, UPF, wherein an NRF may be used for dynamic registration of UPF services to NRF.
  • the PLMNs each may further comprise a security edge protection proxy, SEPP, 130, 132 configured to operate as a security edge node or gateway.
  • the NFs may communicate with each other using representational state transfer application programming interfaces. These may be known as Restful APIs. Further examples of NFs include NFs related to gaming, streaming or industrial process control.
  • the system may compromise also out of 3G or 4G nodes e.g. HSS Home Subscriber Service and a suitable interworking function for protocol translations between e.g. diameter and REST API Json.
  • the SEPP 130, 132 is a network node at the boundary of an operator's network that may be configured to receive a message, such as an HTTP request or HTTP response from the NF, apply protection for sending, and forward 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.
  • the SEPP may make additional security validations.
  • an inter-PLMN interconnect allows secure communication between a service-consuming NF and a service-producing NF, henceforth referred to as cNF 120 and pNF 122. They may also be referred to as NF service consumer and NF service producer, respectively.
  • a service communication proxy, SCP, 150 may be deployed for indirect communication between network functions, NFs.
  • An SCP is an intermediate function/element to assist in routing messages, such as, for example, control plane messages between NFs.
  • Direct communication may be applied between NFc 120 and NFc 122 for an NF service, or NF service communication may be performed indirectly via SCP(s) 150.
  • the NFc 120 performs discovery of the target NFp 122 by local configuration or via local NRF, cNRF 140.
  • the NFc 120 may delegate the discovery of the target NFp 122 to the SCP 150 used for indirect communication.
  • the SCP uses the parameters provided by NFc 120 to perform discovery and/or selection of the target NF service producer, for example with reference to one or more NRF. These parameters may include an identity or address of an NRF to contact first.
  • the SCP address(es) for one or more SCP nodes may be locally configured in NFc 120, for example. Where multiple SCP nodes are used, they may serve redundancy and/or load sharing purposes, for example.
  • 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 NFc or SCP, to discover a set of NF instance(s) and NF service instance(s) for a specific NF service or an NF type.
  • the network repository function, NRF may comprise 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 NFc or SCP.
  • 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, for example, run in a same computing substrate.
  • NRF may be in a physically distinct node than an SCP or even hosted by a service provider.
  • the NFc 120 or SCP 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 NFc 120 or SCP 150 may also provide other service parameters, such as information relating to network slicing.
  • the SCP 150 may request service discovery from a NRF in its PLMN 110, that is, 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 SCP via the cNRF 140 in the PLMN 110 of the NFc.
  • the SCP 150 may trigger service requests for the NFp 122 via the cSEPP 130 and the pSEPP 132.
  • an NFc may provide the SCP an address or name of an NRF which may be used by the SCP.
  • An NF can communicate with a PLMN-level NRF by constructing an address for the NRF based on a predetermined process.
  • the PLMN-level NRF address may be pre-configured in the NF in connection with initialization of the NF, or subsequently.
  • a home network domain name of the PLMN may be prefixed by the letters “nrf ⁇ The IP address may then be fetched from domain name server, DNS, for example.
  • an address, or name, of an NSSF for example an NSSF of a different PLMN, may be self-constructed by an NF.
  • a PLMN-level NRF may be configured hierarchically above other NRFs in that PLMN.
  • a PLMN-level NRF may have authority over other NRFs in that PLMN.
  • An authority NRF may be referred to as a master NRF.
  • a system implementing an embodiment of the present disclosure comprises both fourth generation, 4G, and fifth generation, 5G, parts.
  • OAuth based service authorization and token exchange is applied between the mobile networks.
  • the second network entity such as the pNRF
  • the NFc may be an OAuth client and the NFp may operate as OAuth resource server, and they may be configured to support OAuth authorization framework as defined in RFC 6749.
  • a network support function such as an NRF may further be configured to act as an authorization server, which may advise an NFc concerning a suitable NFp, and provide the NFc with a cryptographic token authorizing the NFc to use the service provided by the NFp.
  • the NRF may act as an OAuth 2.0 authentication server.
  • the token may comprise e.g. identifiers of the NFc, NRF and NFp, a timestamp and/or an identifier of the specific service which is authorised for the NFc with the token.
  • the token may be cryptographically signed using a private key of the NRF.
  • a validity of such a cryptographic signature may be verified using the corresponding public key of the NRF, which the NFp may obtain in connection with registering with the NRF the service(s) it offers.
  • a TLS handshake between the NFp and the NRF may comprise that the NRF provides its public key to the NFp.
  • the NFc contacts the NFp it may present the authorizing token, which the NFp may then verify using its copy of the public key of the NRF.
  • Suitable public-key cryptosystems include the Rivest-Shamir- Adleman, RSA, and ElGamal cryptosystems.
  • the elliptic curve digital signature algorithm, ECDSA may be used in generating cryptographic signatures using public key cryptography.
  • the NFp may not have a copy of the public key that is needed to verify the validity of the token. Consequently, the NFp needs a method to obtain the correct public key in order for the authorization action performed by the NRF the NFc used to be meaningful.
  • the NFp when the NFp receives a service request from the NFc which comprises the token, it may realize it doesn’t have the public key, and request it from an NRF.
  • the public key may be referred to as a public key for the sake of brevity.
  • the NRF may have a copy of the public key or it may have information concerning a location from where the NFp may fetch the public key, and the NRF may provide to the NFp the public key, or the location.
  • the NRF may request it from another NRF, for example a PLMN-level NRF or another NRF higher in an NRF hierarchy than the requesting NRF, and provide the information to the NFp once it obtains it from the other NRF.
  • the NRFs of one PLMN may be configured to provide public keys, or their locations, of NRFs in the same PLMN to requesting NFs.
  • the NRFs may expose an API for NFs to use when they want to avail this new service in NRF.
  • a new operation in an NRF’s existing AccessToken service may be used.
  • a new API may be created for this purpose.
  • an existing API may be extended with new end points. For example “(nrfApiRoot ⁇ /oauth2/token” is currently specified for access token API service. “ ⁇ nrfApiRoot ⁇ /oauth2/keys” may be used for a public key retrieval service.
  • the new service or the new operation proposed herein may be centralized in a PLMN-level NRF or be available in all NRFs, including the NRF that the NFp has registered its service(s) with. In the latter case, the NFp may only need to be configured with the address of one NRF.
  • a response from the NRF may contain an URL from which the public key for the NRF which issued the token can be obtained, or the response may comprise the public key itself.
  • FIGURE 2A illustrates hierarchical NRFs relevant to the present disclosure.
  • NFc/SCP-c may contact NRF2a or NRF2b, based on a pre-configured or automatically generated address or domain name, to request information of PLMN-level NRF3.
  • the requested information may comprise contact information, such as an address or domain name, of NRF3.
  • NFc/SCP-c may then use NRF3 to discover NFp.
  • FIGURE 2B illustrates messaging in hierarchical NRFs which causes the
  • NFp to not have the correct public key.
  • time advances from the top toward the bottom.
  • the vertical axes correspond to, from the left to the right, the NF consumer NFc, four NRFs labelled NRF 1, NRF2, NRF3 and NRF4, and finally the NF producer NFp on the right.
  • the NFp may lack the public key it needs. It may be beneficial to use different sub-certificate authority for this purpose, for example from a network slicing point of view if an S-NSSAI specific NRF is only allowed to sign the access tokens for a specific network slice. This may require specific handling if the signing certificates are revoked.
  • phase 210 the NFp registers its service with NRF4, for example by using a PUT NFProfile operation toward NRF4, which responds with an OK message.
  • NFp may also have a copy of the public key of NRF4.
  • phase 220 NFc requests for a service matching the one registered in phase 210, from NRF1.
  • NRF1 doesn’t have information concerning it, however it will query NRF2 for such information, phase 230, and NRF2 responds it doesn’t know of such a service, phase 240.
  • NRFl will query NRF3 for the service, and NRF3 will in phase 260 respond that NFp has the service, and further in phase 260, NRF3 will also issue a token authorizing NFc to access the service. NRF1 will pass the token to NFc in phase 270. NRF3 may have received information concerning the service from NRF4 via intra-NRF signalling, for example.
  • the NFc will request the service from NFp, wherein NFc provides the token, which comprises a signature performed using the private key of NRF3.
  • the NFp has registered with NRF4 and it as a result does not have the public key of NRF3 which would be needed to verify the token has a correct signature.
  • Tokens may contain a replay protection feature, such as, for example, a timer, a one-time number or a similar element.
  • FIGURE 2B While the signalling of FIGURE 2B is one way in which an NFp or NFc doesn’t have the correct public key, other events may lead to the same situation.
  • an SCP or a service communication proxy, SeCoP, are between NFc and NFp instances.
  • TLS connections between NFc and NFp may take place hop by hop, that is, without end to end TLS between NFp and NFc.
  • the NF consumer may lack the public key of an NRF.
  • NRFs may be enhanced by configuring them to provide a service to distribute public keys, such a service may be called Nnrf PublicKey, for example.
  • the new service may allow NF producers to obtain the public key of an OAuth server, such as the NRF, that issued the access token to an NF consumer.
  • FIGURE 3 illustrates an example apparatus capable of supporting at least some embodiments of the present invention.
  • device 300 which may comprise, for example, a node running an NF, NRF or SCP as herein described.
  • 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.
  • a processing core may comprise, for example, a Cortex- A8 processing core manufactured by ARM Holdings or a Steamroller processing core designed by Advanced Micro Devices Corporation.
  • Processor 310 may comprise at least one AMD EPYC and/or Intel Xeon processor. 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 be means for performing method steps in device 300, such as storing, 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, 360.
  • UI 360 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 360, 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.
  • Processor 310, memory 320, transmitter 330, receiver 340 and/or UI 360 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 4A illustrates signalling in accordance with at least some example embodiments of the present invention.
  • NF service producer NFp or an SCP On the vertical axes are disposed, on the left, NF service producer NFp or an SCP, and on the right, a PLMN-level NRF which is an example of a network support function. Time advances from the top toward the bottom. While discussed herein as a PLMN-level NRF, in general this node may be an NRF or other node which is tasked with assisting NF producers in obtaining public keys.
  • the NF producer NFp transmits to the PLMN-level NRF a request message concerning a token the NFp has received from an NFc, for example in a service request.
  • the token may be cryptographically signed, and the NFp may lack the correct public key to verify whether the signature is valid.
  • the request message may comprise the token, or information concerning the token enabling the NRF to identify which public key, or a node whose public key, is needed to validate the cryptographic signature of the token.
  • the request message may comprise at least one of the following parameters relating to the token: an identity of an issuer of the token, a subject of the token, an audience of the token, and a network slice identifier of the token.
  • the NFp may be pre-configured with an address or fully qualified domain name of a PLMN-level NRF, for example.
  • the request message may comprise an Nnrf NRFPublicKey Request message.
  • This message may be sent over a secure TLS connection between the NF Producer and the NRF, or via an SCP using hop-by-hop security.
  • the PLMN-level NRF obtains either the public key needed to validate the token, or a location from where this public key may be obtained. For example, the NRF may look at an issuer field in the token to discover, which NRF or authentication server has issued the token.
  • the PLMN-level NRF may be configured with public keys or address information of NRFs under its authority, for example, or it may dynamically request such information as a response to the request message of phase 410.
  • the PLMN-level NRF may respond with a response message, the response message comprising information concerning the public key relating to the token.
  • the information in the response message may comprise the public key itself, or a location or address from where it may be obtained.
  • the location or address may be a network address, expressed as an internet protocol address or an URL or URI, for example.
  • the URL may reference a JSON metadata document that contains a "jwks uri" value that is an "https" URL from which the issuer's keys are retrieved as a JWK Set.
  • a URL provided in phase 430 may directly refer to a NRF’s JWK Set document which contains the signing key the NF producer uses to validate the signature.
  • the response message of phase 430 may comprise a Nnrf NFPublicKey Response.
  • a JWK RCC 7517
  • the members of the object represent properties of the key, including its value.
  • JWK includes parameters on whether the key is an Elliptic curve-based key or an RSA key, whether the key is used for encryption or signature.
  • a JWK Set includes one or more JWKs. This is useful if for some reason more than one cryptographic key is used for the said purpose.
  • the NFp may use the public key in case it was provided in phase 430, or retrieve the public key using the location or address, in case the location or address was provided in phase 430.
  • Processing the response message may comprise retrieving the public key or the location or address from the response message.
  • an SCP may be employed, which may be configured to perform in the process of FIGURE 4 A as the NFp described above, on behalf of the NFp.
  • Public key retrieval may be performed over TLS across all hops, hop-to-hop, to avoid man-in-the-middle, MITM, attacks and similar threats.
  • FIGURE 4B illustrates signalling in accordance with at least some example embodiments of the present invention.
  • NF service producer NFp or an SCP acting on the behalf of NFp
  • NRF-1 and a PLMN-level NRF.
  • the PLMN-level NRF may have authority over NRF-1. Time advances from the top toward the bottom.
  • the NFp sends a request message, as described above e.g. in connection with FIGURE 4A, phase 410, to NRF-1.
  • NRF-1 responsively requests, phase 450, the PLMN-level NRF for the information concerning the public key needed to validate the token referred to in the request message of phase 440.
  • the PLMN-level NRF obtains the information concerning the public key, and returns it to NRF-1 in phase 470.
  • NRF-1 in turn provides the information concerning the public key to NFp in phase 480.
  • the PLMN-level NRF may comprise an authority NRF assigned to a PLMN, such that it may at least in part control other NRFs in the PLMN.
  • the messages of phases 440 and/or 450 may comprise a Nnrf_NFPublicKey_Request, while the messages of phases 470 and/or 480 may comprise a Nnrf_NFPublicKey_Response.
  • the NRF-1 transmits to the PLMN-level NRF a request message, which is in this embodiment a subscription request based on the Nnrf_NFManagement service.
  • the PLMN-level NRF authorizes the subscription request and selects NRFs meeting criteria defined in the subscription request.
  • subscription data of the selected NRFs is returned to the NF service consumer, and in phase 480 notification data is provided, for example concerning updates to the information of phase 470.
  • FIGURE 4C illustrates signalling in accordance with at least some example embodiments of the present invention.
  • FIGURE 4C illustrates an access token service enhanced to offer public keys of an issuer of a token.
  • a public key request operation is defined, wherein the message of phase 490 comprises a public key request, for example a POST /oauth2/token (PublicKeyReq).
  • PublicKeyReq a public key request for example a POST /oauth2/token
  • the NF service producer may use an existing token endpoint in an NRF as
  • OAuth2.0 Authorization Server for example as identified by a URI “(nrfApiRoot ⁇ /oauth2/token” to request OAuth Server’s public key information.
  • a specific data type may be used in the public key request of phase 490.
  • the specific data type may comprise, at the minimum, one of the following: the token, selected token claims such as the issuer, audience and subject.
  • the specific data type may comprise a validity time of the token.
  • the NF producer may send the complete token or include relevant parameters such as the issuer, subject and audience, and optionally S- NSSAI for network slice specific access tokens.
  • NFs may be pre-configured with details of the PLMN-level NRF or other NRFs to enable the sending of the message of phase 490.
  • the response message of phase 4100 comprises the information concerning the public key described above.
  • the message of phase 4100 may comprise a 200 OK (PublicKeyResp) message.
  • the NFp may then obtain the public key, either from the response message or by using address or location information in the response message.
  • a URL in the response message references a JSON metadata document that contains a "jwks uri” value that is an "https" URL from which the issuer's public keys are retrieved as a JWK Set.
  • the URL obtained from the response message directly refers to NRF’s JWK Set document which contains the signing key the NF producer uses to validate the signature of the token.
  • FIGURE 5 is a flow graph of a method in accordance with at least some example embodiments of the present invention. The phases of the illustrated method may be performed in an apparatus such as a NFp or SCP acting on behalf of an NFp.
  • the apparatus may comprise a single physical node or an arrangement of plural physical nodes together configured to run the NFp or SCP.
  • the method of FIGURE 5 is performed by a user equipment.
  • a user equipment may be configured to perform the role of an NFp.
  • Phase 510 comprises storing a token received in an apparatus performing the method from a network function requesting a service.
  • Phase 520 comprises causing transmission, from the apparatus to a network support function, of a request message concerning the token, the token relating to the service.
  • phase 530 comprises processing in the apparatus, a response message from the network support function, the response message comprising information concerning a public key relating to the token.
  • Processing the response message may comprise, for example, extracting from the response message the public key, or the location of the public key.
  • the public key relating to the token may comprise the public key corresponding to the signature included as one of the token’s parameters.
  • a user equipment apparatus such as a cell phone or tablet computer or laptop computer or desktop computer or mobile internet of things, IOT, device or fixed IOT device.
  • This user equipment apparatus can, for example, be furnished with corresponding capabilities as described in connection with the fixed and/or the wireless network node(s), as appropriate.
  • the user equipment apparatus may be the user equipment and/or or a control device, such as a chipset or processor, configured to control the user equipment when installed therein.
  • Examples of such functionalities include an NFp and/or an SCP, which may be implemented in the user equipment apparatus by providing the user equipment apparatus with software configured to cause the user equipment apparatus to perform from the point of view of these functions/nodes.
  • At least some embodiments of the present invention find industrial application in enhancing reliability in communication networks.

Landscapes

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

Abstract

Selon un aspect donné à titre d'exemple, la présente invention concerne un appareil comprenant une mémoire configurée pour stocker un jeton reçu dans l'appareil en provenance d'une fonction de réseau demandant un service, et au moins un noyau de traitement conçu pour provoquer la transmission, de l'appareil à une fonction de support de réseau, d'un message de demande concernant le jeton, le jeton se rapportant au service, et pour traiter un message de réponse en provenance de la fonction de support de réseau, le message de réponse comprenant des informations concernant une clé publique relative au jeton. L'appareil peut comprendre un nœud de réseau ou un équipement utilisateur, par exemple.
PCT/EP2021/053622 2020-02-19 2021-02-15 Gestion de clé WO2021165194A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN202041007132 2020-02-19
IN202041007132 2020-02-19

Publications (1)

Publication Number Publication Date
WO2021165194A1 true WO2021165194A1 (fr) 2021-08-26

Family

ID=74661390

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/053622 WO2021165194A1 (fr) 2020-02-19 2021-02-15 Gestion de clé

Country Status (1)

Country Link
WO (1) WO2021165194A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113825134A (zh) * 2021-09-29 2021-12-21 新华三技术有限公司 一种网络服务授权方法、装置及设备
WO2024046592A1 (fr) * 2022-09-02 2024-03-07 Telefonaktiebolaget Lm Ericsson (Publ) Hiérarchie de référentiel de réseau

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190251241A1 (en) * 2018-02-15 2019-08-15 Nokia Technologies Oy Security management for service authorization in communication systems with service-based architecture
WO2020030852A1 (fr) * 2018-08-10 2020-02-13 Nokia Technologies Oy Authentification de fonction de réseau basée sur une liaison de clé publique dans un jeton d'accès dans un système de communication

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190251241A1 (en) * 2018-02-15 2019-08-15 Nokia Technologies Oy Security management for service authorization in communication systems with service-based architecture
WO2020030852A1 (fr) * 2018-08-10 2020-02-13 Nokia Technologies Oy Authentification de fonction de réseau basée sur une liaison de clé publique dans un jeton d'accès dans un système de communication

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
HUAWEI ET AL: "Adding OAuth related authorization services for SBA security", vol. SA WG3, no. Dalian (China); 20180820 - 20180824, 13 August 2018 (2018-08-13), XP051541540, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg%5Fsa/WG3%5FSecurity/TSGS3%5F92%5FDalian/Docs/S3%2D182453%2Ezip> [retrieved on 20180813] *
HUAWEI ET AL: "Authorization of NF service access", vol. SA WG3, no. Reno (US); 20171127 - 20171201, 20 November 2017 (2017-11-20), XP051380509, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg%5Fsa/WG3%5FSecurity/TSGS3%5F89%5FReno/Docs/> [retrieved on 20171120] *
ZHANG SHUNLIANG ET AL: "Towards secure 5G networks: A Survey", COMPUTER NETWORKS, ELSEVIER, AMSTERDAM, NL, vol. 162, 31 July 2019 (2019-07-31), XP085848265, ISSN: 1389-1286, [retrieved on 20190731], DOI: 10.1016/J.COMNET.2019.106871 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113825134A (zh) * 2021-09-29 2021-12-21 新华三技术有限公司 一种网络服务授权方法、装置及设备
WO2024046592A1 (fr) * 2022-09-02 2024-03-07 Telefonaktiebolaget Lm Ericsson (Publ) Hiérarchie de référentiel de réseau

Similar Documents

Publication Publication Date Title
EP4002760A1 (fr) Procédure de sécurité
CN113661696B (zh) 用于处理可伸缩fqdn的系统和方法
US11737011B2 (en) Management of access tokens in communication networks
KR102084104B1 (ko) 종단간 m2m 서비스 계층 세션
US11425636B1 (en) Network function service subscription control
US20220191028A1 (en) Authorization of network request
EP3886390A1 (fr) Gestion de jeton
US20210120416A1 (en) Secure inter-mobile network communication
CN114503644B (zh) 支持具有tls的间接通信
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
WO2021165194A1 (fr) Gestion de clé
WO2021140051A1 (fr) Requêtes dans un réseau
WO2021094349A1 (fr) Autorisation de services en plusieurs étapes pour la communication indirecte dans un système de communication
WO2020025128A1 (fr) Gestion de certificat
WO2021165925A1 (fr) Gestion de clé
WO2021099675A1 (fr) Gestion de sécurité de service de réseau mobile
WO2021240055A1 (fr) Autorisation améliorée dans des réseaux de communication
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
EP4092982A1 (fr) Authentification d&#39;une demande de réseau
US20220217127A1 (en) Authentication of network request
EP4181465A1 (fr) Sécurité de réseau
US20220132369A1 (en) Payload compression
US12034733B2 (en) Authorization in communication networks
CN113676903B (zh) 切片认证授权管理方法、装置和系统

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

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

Country of ref document: EP

Kind code of ref document: A1