WO2021165925A1 - Key management - Google Patents

Key management Download PDF

Info

Publication number
WO2021165925A1
WO2021165925A1 PCT/IB2021/051452 IB2021051452W WO2021165925A1 WO 2021165925 A1 WO2021165925 A1 WO 2021165925A1 IB 2021051452 W IB2021051452 W IB 2021051452W WO 2021165925 A1 WO2021165925 A1 WO 2021165925A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
public key
network function
function
request message
Prior art date
Application number
PCT/IB2021/051452
Other languages
French (fr)
Inventor
Silke Holtmanns
Nagendra Bykampadi
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 WO2021165925A1 publication Critical patent/WO2021165925A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1063Application servers providing network services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1016IP multimedia subsystem [IMS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/321Cryptographic 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/3213Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3247Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources

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, 3GPP, for example.
  • 3GPP third generation partnership project
  • 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 public key cryptography key pair comprising a public key and a private key, and at least one processing core configured to run a network function, to cause transmission, from the apparatus to a network support function, via at least one service communication proxy, of a request message, the request message comprising an authorization code signed with a cryptographic signature generated using the private key, and to at least one of the following: cause transmission to the network support node of provisioning information concerning the public key, and configure a storage distinct from the apparatus to provide a copy of the public key responsive to a request which comprises a specific network address relating to the public key.
  • an apparatus comprising a memory configured to store public keys of network functions, and at least one processing core configured to receive, from a service communication proxy, a request message requesting a token relating to a service to be provided to a network function, the request message comprising an authorization code signed digitally with a cryptographic signature, verify the cryptographic signature using a public key of the network function and to obtain the public key of the network function by at least one of the following: retrieving the public key of the network function from a network function profile of the network function, and retrieving the public key of the network function from a storage using a specific network address relating to the network function.
  • a method comprising storing a public key cryptography key pair comprising a public key and a private key, running a network function, and causing transmission, from an apparatus performing the method to a network support function, via at least one service communication proxy, of a request message, the request message comprising an authorization code signed with a cryptographic signature generated using the private key, and at least one of the following: causing transmission to the network support node of provisioning information concerning the public key, and configuring a storage distinct from the apparatus to provide a copy of the public key responsive to a request which comprises a specific network address relating to the public key.
  • a method comprising receiving, from a service communication proxy, a request message requesting a token relating to a service to be provided to a network function, the request message comprising an authorization code signed digitally with a cryptographic signature, verifying the cryptographic signature using a public key of the network function and obtaining the public key of the network function by at least one of the following: retrieving the public key of the network function from a network function profile of the network function, and retrieving the public key of the network function from a storage using a specific network address relating to the network function.
  • an apparatus comprising means for storing a public key cryptography key pair comprising a public key and a private key, running a network function, and causing transmission, from an apparatus performing the method to a network support function, via at least one service communication proxy, of a request message, the request message comprising an authorization code signed with a cryptographic signature generated using the private key, and at least one of the following: causing transmission to the network support node of provisioning information concerning the public key, and configuring a storage distinct from the apparatus to provide a copy of the public key responsive to a request which comprises a specific network address relating to the public key.
  • an apparatus comprising means for receiving, from a service communication proxy, a request message requesting a token relating to a service to be provided to a network function, the request message comprising an authorization code signed digitally with a cryptographic signature, verifying the cryptographic signature using a public key of the network function and obtaining the public key of the network function by at least one of the following: retrieving the public key of the network function from a network function profile of the network function, and retrieving the public key of the network function from a storage using a specific network address relating to the network function.
  • 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 perform at least storing a public key cryptography key pair comprising a public key and a private key, running a network function, and causing transmission, from an apparatus performing the method to a network support function, via at least one service communication proxy, of a request message, the request message comprising an authorization code signed with a cryptographic signature generated using the private key, and at least one of the following: causing transmission to the network support node of provisioning information concerning the public key, and configuring a storage distinct from the apparatus to provide a copy of the public key responsive to a request which comprises a specific network address relating to the public key
  • 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 perform at least receiving, from a service communication proxy, a request message requesting a token relating to a service to be provided to a network function, the request message comprising an authorization code signed digitally with a cryptographic signature, verifying the cryptographic signature using a public key of the network function and obtaining the public key of the network function by at least one of the following: retrieving the public key of the network function from a network function profile of the network function, and retrieving the public key of the network function from a storage using a specific network address relating to the network function.
  • a computer program configured to cause, when executed, an apparatus to perform at least the following: storing a public key cryptography key pair comprising a public key and a private key, running a network function, and causing transmission, from an apparatus performing the method to a network support function, via at least one service communication proxy, of a request message, the request message comprising an authorization code signed with a cryptographic signature generated using the private key, and at least one of the following: causing transmission to the network support node of provisioning information concerning the public key, and configuring a storage distinct from the apparatus to provide a copy of the public key responsive to a request which comprises a specific network address relating to the public key.
  • a computer program configured to cause, when executed, an apparatus to perform at least the following: receiving, from a service communication proxy, a request message requesting a token relating to a service to be provided to a network function, the request message comprising an authorization code signed digitally with aa cryptographic signature, verifying the cryptographic signature using a public key of the network function and obtaining the public key of the network function by at least one of the following: retrieving the public key of the network function from a network function profile of the network function, and retrieving the public key of the network function from a storage using a specific network address relating to the network function.
  • 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 an example authorization code in accordance with at least some embodiments
  • FIGURE 3 illustrates an example apparatus capable of supporting at least some embodiments of the present invention
  • FIGURE 4 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 may be enhanced to enable provision of public keys to network support functions which authorize access to services, such that these network support functions are then able to verify that cryptographic signatures provided to them by network functions, NFs, are valid.
  • An example network support function is a network repository function, NRF, but the network support function may also or alternatively comprise an authorization server.
  • 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.
  • NFc nodes may request tokens granting access to services of NFp nodes from network support functions, such as NRFs.
  • FIGURE 1 illustrates an example system 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.
  • a user equipment may perform the role of an NF.
  • 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 perform additional security validations.
  • an inter-PLMN interconnect allows secure communication between a service-consuming NF and a service-producing NF, henceforth referred to as NFc 120 and NFp 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 When using indirect communication, an NFc may provide the SCP an address or name of an NRF which may be used by the SCP. In indirect communication, security may be ensured using hop-by-hop secure connections, such as TLS connections such that an NFc forms a secure connection with an SCP, and the SCP forms a separate secure connection with an NRF.
  • hop-by-hop secure connections such as TLS connections
  • An NF can communicate with a PFMN-level NRF by constructing an address for the NRF based on a predetermined process.
  • the PFMN-level NRF address may be pre-configured in the NF in connection with initialization of the NF, or subsequently. For example, to obtain a fully qualified domain name of an authority NRF of a specific PFMN, a home network domain name of the PFMN 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 PFMN, may be self-constructed by an NF.
  • a PFMN-level NRF may be configured hierarchically above other NRFs in that PFMN.
  • a PFMN-level NRF may have authority over other NRFs in that PFMN.
  • 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 this NFp.
  • the NFc may transmit a request message to the NRF to request the token.
  • the request message may comprise a cryptographic signature generated using the private key of the NFc.
  • 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.
  • Suitable public -key cryptosystems include the Rivest- Shamir-Adleman, RSA, and ElGamal cryptosystems. Also suitable may be the elliptic curve digital signature algorithm, ECDSA.
  • the authorizing network support element may verify the request message originates in the correct requesting node.
  • a maliciously acting node may attempt to present itself as a legitimate NFc in a counterfeit request message.
  • the request message may comprise a cryptographic signature of the NFc.
  • the signature may be generated using a private key of the NFc.
  • the signature may be over the entire request message or over an authentication code comprised in the request message, for example.
  • the public key corresponding to the private key is needed.
  • the NFc or other requesting node, does not directly connect with the network support node, such as NRF, there may be no protocol handshake where the public key would be exchanged.
  • the network support node such as NRF
  • the hop-by- hop model may generate a level of transitive trust, but the public key of the NFc itself is not necessarily communicated in the hop-by-hop process. In such a case, there is no direct end-to- end connection with the NFc and NRF as endpoints of the end-to-end connection.
  • the SCP may issue token requests for any NF consumers, existing or non-existing, and there may be no way for the NRF, or other network support function, to determine the authenticity of the access token request messages.
  • the requesting node such as NFc
  • the requesting node generates a cryptographic signature it with its own private key, and includes this signature in a request message where it seeks access to a service.
  • the question then is how does the NFc share the public key with the NRF or how does the NRF obtain the NFc’s public key that it needs to verify the signature in the request message.
  • the NFc’s public key is stored in the NF profile.
  • NFc provides this profile during NRF registration, or more generally when registering with a network support function providing authorization service.
  • the public key may then also be available to an intermediate NRF or SCP nodes for later use.
  • the NRF thus knows how to get the NFc’s public key.
  • an NFRegister request to NRF can be used to update the public key for future use.
  • registering with the NRF may be made mandatory for NFc nodes. It is also possible that NRF may store the key separately in a secure store, for example one for each NF that registers with it. In general terms, provisioning information concerning the public key may be provided from the NFc to the NRF.
  • the provisioning information may comprise the public key, for example in case the provisioning information is the NF profile which comprises the public key. Additionally or alternatively, the provisioning information may comprise a specific network address using which the public key may be retrieved.
  • the NF profile may be provided in a registration request, for example.
  • the NFc’ s public key is stored in a location distinct from the network support node, such as the NRF, and referenced through a specific network address, such as a unique URI or URL.
  • HTTPS may be used in retrieving the public key using the specific network address.
  • This option may avoid using the NF profile to store the NF’s public key, or may be used in conjunction with the NF profile option.
  • the specific network address may be shared in the authorization code itself, where the authorization code is a JSON Web Token, or can be part of the NF profile that is registered with the network support function, such as NRF.
  • the public key may be updated directly to the location referred to by the specific network address.
  • the NFc may configure the storage to store the public key and to provide a copy of the public key responsive to a request which comprises a specific network address relating to the NFc, in particular, to the public key of the NFc.
  • FIGURE 2A illustrates hierarchical NRFs relevant to the present disclosure.
  • FIGURE 2A an intra-PLMN, intra-domain SBA inter-SCP scenario is illustrated.
  • the NFc may contact NRF2a or NRF2b via SCP-c, based on a pre-configured or automatically generated address or domain name, to request information of PLMN-level NRF3 and/or the NFp.
  • the requested information may comprise contact information, such as an address or domain name, of NRF3 or the NFp.
  • SCP-c may then use NRF3 to discover NFp.
  • the NFc contacts the NRF indirectly, in a hop-by-hop manner.
  • FIGURE 2B illustrates an example authorization code in accordance with at least some example embodiments.
  • the illustrated authorization code is a JSON Web Token, JWT, data structure.
  • an NFc may supply this data structure to the NRF, or other network support function.
  • the specific network address from where the public key needed to verify the signature of the request message is included in this data structure as a URI, although a URL or other suitable address may be used in other embodiments.
  • the network support function such as NRF, may use a HTTPS or another secure method to obtain the public key from the location referred to by the specific network address.
  • the authorization code may be included in the request message, and the signature to be verified may be applied over the entire request message or over just the authorization code, for example.
  • the authorization code is a JWT data structure which is different from the one illustrated in FIGURE 2B.
  • the authorization code may comprise the specific network address.
  • the public key When stored in a storage, the public key may be stored in a JSON Web Key,
  • JWK JavaScript Object Notation
  • JSON JavaScript Object Notation
  • 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.
  • the URL may directly refer to NF consumer JWK Set JSON document which contains the signing key the NRF uses to validate the signature.
  • a public key may be updated in both of the options described above, in detail, when the public key is stored in a NF profile, a normal or partial NF registering request to the NRF may be used to update the key. When the public key is in the storage distinct from the NRF, it may be updated directly by the NFc.
  • the NRF or other network support function is configured to construct the specific network address based on a network function identity of the network function, in accordance with a pre-configured network address construction mechanism.
  • the specific network address may be a concatenation including the NF instance identifier, a PLMN identifier of a PLMN where the NFc is located, and a string indicating the specific network address relates to a public key.
  • the NRF may have the pre-configured construction mechanism configured therein from communication standards, for example.
  • the following table discloses an example of a network function profile, where the specific network address where the public key may be retrieved from is included as a publickeyURI variable.
  • the NF profile may comprise an NF type, a NF instance identifier and an NF status, for example, in addition to the public key or address of the public key.
  • 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 or NRF 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, causing transmitting and configuring.
  • 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
  • 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.
  • Such 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.
  • 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 4 illustrates signalling in accordance with at least some embodiments of the present invention.
  • the NFc On the vertical axes are disposed, from the left to the right, the NFc, the SCP, an NRF and a storage STR, distinct from the NRF, the NFc and the SCP. Time advances from the top to the bottom.
  • the NFc In phase 410, the NFc generates a key pair comprising a public key and a private key. The keys may be used such that a cryptographic signature generated using the private key may be verified using the public key, for example.
  • the NFc configures the storage STR with the new public key generated in phase 410. STR may be remote from NFc in that it is not in the same physical computing substrate, for example. The NFc may store the key pair in a memory comprised in the physical node or nodes that run the NFc.
  • phase 430 the NFc registers with the NRF, providing to the NRF the NF profile of the NFc, this profile comprising a specific network address of the public key in storage STR.
  • the specific network address may take the form of a URI or URL, for example.
  • Phase 430 may take place using direct messaging, as illustrated, or indirectly via an SCP, for example.
  • the NFc triggers the SCP with a service request message to request an access token from the NRF for the NFc, the access token relating to a service the NFc wishes to access. The token authorizes the NFc to access the service in an NFp.
  • the SCP acts on behalf of the NFc in phase 450, requesting the token from the NRF.
  • the request messages of phases 440 and 450 comprise the authorization code and cryptographic digital signature for the authorization code or the whole message that the NFc has created using its private key, which was generated in phase 410. This signature has been described herein above.
  • An example authorization code, suitable for use in the process of FIGURE 4, is illustrated in FIGURE 2B.
  • the NRF retrieves the specific network address from the NF profile it has or from the URI stored in the authorization code, and in phase 470 it requests the public key from STR using the specific network address.
  • the STR responds in phase 480 by providing the requested public key of NFc.
  • the NRF verifies whether the signature in the request message it received in phase 450 is valid. In case it is valid, the NRF may authorize the NFc to use the requested service by generating the access token, in case the NFc fulfils admissibility criteria, which may be defined by the NFp providing the service, for example. Thus merely having a valid signature is not necessarily sufficient to access the service, as the validity of the signature only proves the NFc has created the signature itself.
  • the NRF may also verify location information in the authorization code, in embodiments which use the authorization code. In the event the NRF chooses to authorize the NFc to use the service, it responds, phase 4100, with a response message which may comprise the requested access token relating to the service..
  • the SCP may include the access token in the service request message and send the service request message to the NFp, for example.
  • FIGURE 5 is a flow graph of a method in accordance with at least some embodiments of the present invention.
  • the phases of the illustrated method may be performed in an apparatus such as a NFc, for example.
  • the apparatus like other apparatuses running NFs, may comprise a single physical node or an arrangement of plural physical nodes together configured to run the NFp or SCP.
  • the apparatus may in some embodiments comprise a user equipment
  • Phase 510 comprises storing a public key cryptography key pair comprising a public key and a private key.
  • Phase 520 comprises running a network function, and causing transmission, from an apparatus performing the method to a network support function, via at least one service communication proxy, of a request message requesting a token relating to a service, the request message comprising a cryptographic signature generated using the private key, and at least one phase 530 and phase 540.
  • Phase 530 comprises causing transmission to the network support node of provisioning information concerning the public key.
  • Phase 540 comprises configuring a storage distinct from the apparatus to provide a copy of the public key responsive to a request which comprises a specific network address relating to the public key.
  • the storage may be distinct from both the network function, such as the NFc, and from the network support function, such as the NRF. Distinct in this context may comprise that the storage is physically in a separate node, and/or that the storage is in another logical network domain or entity.
  • the provisioning information may comprise, for example, the public key.
  • the provisioning information may comprise a NF profile of the NFc, the NF profile comprising the public key.
  • provisioning information is information which conveys information for the network support node.
  • 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)
  • Multimedia (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

According to an example aspect of the present invention, there is provided an apparatus comprising a memory configured to store a public key cryptography key pair comprising a public key and a private key, and at least one processing core configured to run a network function, to cause transmission, from the apparatus to a network support function, via at least one service communication proxy, of a request message, the request message comprising an authorization code signed with a cryptographic signature generated using the private key, and to at least one of the following: cause transmission to the network support node of provisioning information concerning the public key, and configure a storage distinct from the apparatus to provide a copy of the public key responsive to a request which comprises a specific network address relating to the public key. The apparatus may comprise a user equipment, for example.

Description

KEY MANAGEMENT
FIELD
[0001] The present disclosure relates to communication between network functions and network support functions.
BACKGROUND
[0002] In networks supporting wireless or wire-based communication, discovering
Network Functions, NFs, and network function services is of interest as many instances are virtualized and are of dynamic nature. 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. Examples of such CN entities include NFs and Service Communication Proxies, SCPs. Examples of 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.
[0003] 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, 3GPP, for example. However, technology disclosed herein has relevance also to wire-line communication networks, such as internet protocol, IP, based networking, or a combination thereof. SUMMARY
[0004] According to some aspects, there is provided the subject-matter of the independent claims. Some embodiments are defined in the dependent claims. The scope of protection sought for various embodiments of the invention is set out by the independent claims. The embodiments, examples and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments of the invention.
[0005] According to a first aspect of the present disclosure, there is provided an apparatus comprising a memory configured to store a public key cryptography key pair comprising a public key and a private key, and at least one processing core configured to run a network function, to cause transmission, from the apparatus to a network support function, via at least one service communication proxy, of a request message, the request message comprising an authorization code signed with a cryptographic signature generated using the private key, and to at least one of the following: cause transmission to the network support node of provisioning information concerning the public key, and configure a storage distinct from the apparatus to provide a copy of the public key responsive to a request which comprises a specific network address relating to the public key.
[0006] According to a second aspect of the present disclosure, there is provided an apparatus comprising a memory configured to store public keys of network functions, and at least one processing core configured to receive, from a service communication proxy, a request message requesting a token relating to a service to be provided to a network function, the request message comprising an authorization code signed digitally with a cryptographic signature, verify the cryptographic signature using a public key of the network function and to obtain the public key of the network function by at least one of the following: retrieving the public key of the network function from a network function profile of the network function, and retrieving the public key of the network function from a storage using a specific network address relating to the network function.
[0007] According to a third aspect of the present disclosure, there is provided a method comprising storing a public key cryptography key pair comprising a public key and a private key, running a network function, and causing transmission, from an apparatus performing the method to a network support function, via at least one service communication proxy, of a request message, the request message comprising an authorization code signed with a cryptographic signature generated using the private key, and at least one of the following: causing transmission to the network support node of provisioning information concerning the public key, and configuring a storage distinct from the apparatus to provide a copy of the public key responsive to a request which comprises a specific network address relating to the public key.
[0008] According to a fourth aspect of the present disclosure, there is provided a method comprising receiving, from a service communication proxy, a request message requesting a token relating to a service to be provided to a network function, the request message comprising an authorization code signed digitally with a cryptographic signature, verifying the cryptographic signature using a public key of the network function and obtaining the public key of the network function by at least one of the following: retrieving the public key of the network function from a network function profile of the network function, and retrieving the public key of the network function from a storage using a specific network address relating to the network function.
[0009] According to a fifth aspect of the present disclosure, there is provided an apparatus comprising means for storing a public key cryptography key pair comprising a public key and a private key, running a network function, and causing transmission, from an apparatus performing the method to a network support function, via at least one service communication proxy, of a request message, the request message comprising an authorization code signed with a cryptographic signature generated using the private key, and at least one of the following: causing transmission to the network support node of provisioning information concerning the public key, and configuring a storage distinct from the apparatus to provide a copy of the public key responsive to a request which comprises a specific network address relating to the public key.
[0010] According to a sixth aspect of the present disclosure, there is provided an apparatus comprising means for receiving, from a service communication proxy, a request message requesting a token relating to a service to be provided to a network function, the request message comprising an authorization code signed digitally with a cryptographic signature, verifying the cryptographic signature using a public key of the network function and obtaining the public key of the network function by at least one of the following: retrieving the public key of the network function from a network function profile of the network function, and retrieving the public key of the network function from a storage using a specific network address relating to the network function.
[0011] According to a seventh aspect of the present disclosure, there is provided 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 perform at least storing a public key cryptography key pair comprising a public key and a private key, running a network function, and causing transmission, from an apparatus performing the method to a network support function, via at least one service communication proxy, of a request message, the request message comprising an authorization code signed with a cryptographic signature generated using the private key, and at least one of the following: causing transmission to the network support node of provisioning information concerning the public key, and configuring a storage distinct from the apparatus to provide a copy of the public key responsive to a request which comprises a specific network address relating to the public key
[0012] According to an eighth aspect of the present disclosure, there is provided 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 perform at least receiving, from a service communication proxy, a request message requesting a token relating to a service to be provided to a network function, the request message comprising an authorization code signed digitally with a cryptographic signature, verifying the cryptographic signature using a public key of the network function and obtaining the public key of the network function by at least one of the following: retrieving the public key of the network function from a network function profile of the network function, and retrieving the public key of the network function from a storage using a specific network address relating to the network function.
[0013] According to a ninth aspect of the present disclosure, there is provided a computer program configured to cause, when executed, an apparatus to perform at least the following: storing a public key cryptography key pair comprising a public key and a private key, running a network function, and causing transmission, from an apparatus performing the method to a network support function, via at least one service communication proxy, of a request message, the request message comprising an authorization code signed with a cryptographic signature generated using the private key, and at least one of the following: causing transmission to the network support node of provisioning information concerning the public key, and configuring a storage distinct from the apparatus to provide a copy of the public key responsive to a request which comprises a specific network address relating to the public key.
[0014] According to a tenth aspect of the present disclosure, there is provided a computer program configured to cause, when executed, an apparatus to perform at least the following: receiving, from a service communication proxy, a request message requesting a token relating to a service to be provided to a network function, the request message comprising an authorization code signed digitally with aa cryptographic signature, verifying the cryptographic signature using a public key of the network function and obtaining the public key of the network function by at least one of the following: retrieving the public key of the network function from a network function profile of the network function, and retrieving the public key of the network function from a storage using a specific network address relating to the network function. BRIEF DESCRIPTION OF THE DRAWINGS
[0015] FIGURE 1 illustrates an example system in accordance with at least some embodiments of the present invention;
[0016] FIGURE 2A illustrates hierarchical NRFs relevant to the present disclosure; [0017] FIGURE 2B illustrates an example authorization code in accordance with at least some embodiments;
[0018] FIGURE 3 illustrates an example apparatus capable of supporting at least some embodiments of the present invention;
[0019] FIGURE 4 illustrates signalling in accordance with at least some embodiments of the present invention, and
[0020] FIGURE 5 is a flow graph of a method in accordance with at least some embodiments of the present invention.
EMBODIMENTS
[0021] As disclosed herein below, a network may be enhanced to enable provision of public keys to network support functions which authorize access to services, such that these network support functions are then able to verify that cryptographic signatures provided to them by network functions, NFs, are valid. An example network support function is a network repository function, NRF, but the network support function may also or alternatively comprise an authorization server. 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. NFc nodes may request tokens granting access to services of NFp nodes from network support functions, such as NRFs. Such token request messages, or request messages in general, may comprise cryptographic signatures of the NFc nodes, or in general cryptographic signatures of the requesting node. To verify the signature, the network support node, such as an NRF, needs a copy of the public key of the requesting node. The network support node may retrieve this public key from an NF profile of the requesting node, or from a remote storage, as will be described herein below. [0022] FIGURE 1 illustrates an example system 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. In some embodiments, a user equipment may perform the role of an NF.
[0023] In case of a third generation partnership project, 3GPP, 5G system service based architecture, SBA, core network, 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.
[0024] 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 perform additional security validations.
[0025] In the example of FIGURE 1, an inter-PLMN interconnect allows secure communication between a service-consuming NF and a service-producing NF, henceforth referred to as NFc 120 and NFp 122. They may also be referred to as NF service consumer and NF service producer, respectively.
[0026] 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. [0027] 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. In direct communication, 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. In the latter case, 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. In general, 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.
[0028] 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. Unless the expected NF and/or NF service information is locally configured on the requester NF, such as when the expected NF service or NF is in the same PLMN as the requester NF, 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. Alternatively NRF may be in a physically distinct node than an SCP or even hosted by a service provider.
[0029] In order for the NFc 120 or SCP 150 to obtain information about the NF and/or
NF service(s) registered or configured in a PLMN/slice, 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.
[0030] In case of indirect communication, during an NF service discovery in inter-PLMN
(roaming) communication, the SCP 150, on behalf of the NFc 120, 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. Then the SCP 150 may trigger service requests for the NFp 122 via the cSEPP 130 and the pSEPP 132. When using indirect communication, an NFc may provide the SCP an address or name of an NRF which may be used by the SCP. In indirect communication, security may be ensured using hop-by-hop secure connections, such as TLS connections such that an NFc forms a secure connection with an SCP, and the SCP forms a separate secure connection with an NRF.
[0031] An NF can communicate with a PFMN-level NRF by constructing an address for the NRF based on a predetermined process. Alternatively, the PFMN-level NRF address may be pre-configured in the NF in connection with initialization of the NF, or subsequently. For example, to obtain a fully qualified domain name of an authority NRF of a specific PFMN, a home network domain name of the PFMN may be prefixed by the letters “nrf ’. The IP address may then be fetched from domain name server, DNS, for example. Similarly, an address, or name, of an NSSF, for example an NSSF of a different PFMN, may be self-constructed by an NF. A PFMN-level NRF may be configured hierarchically above other NRFs in that PFMN. A PFMN-level NRF may have authority over other NRFs in that PFMN.
[0032] It is to be noted that at least some of the entities or nodes 120, 122, 130, 132, 140,
142 and 150 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 present examples in delivery of a particular message is identified by use of the prefix/suffix “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. In some embodiments, a system implementing an embodiment of the present disclosure comprises both fourth generation, 4G, and fifth generation, 5G, parts.
[0033] In some embodiments OAuth based service authorization and token exchange is applied between the mobile networks. Thus, the second network entity, such as the pNRF, may be or perform as an OAuth authorization server, AS. 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.
[0034] In general, 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 this NFp. The NFc may transmit a request message to the NRF to request the token. The request message may comprise a cryptographic signature generated using the private key of the NFc. For example, 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. Suitable public -key cryptosystems include the Rivest- Shamir-Adleman, RSA, and ElGamal cryptosystems. Also suitable may be the elliptic curve digital signature algorithm, ECDSA.
[0035] Before providing the NFc the token authorizing access to a service, such as one provided by an NFp, the authorizing network support element, such as NRF, may verify the request message originates in the correct requesting node. In a spoofing attack, a maliciously acting node may attempt to present itself as a legitimate NFc in a counterfeit request message. To guard against such attempts, the request message may comprise a cryptographic signature of the NFc. The signature may be generated using a private key of the NFc. The signature may be over the entire request message or over an authentication code comprised in the request message, for example. To verify the signature, the public key corresponding to the private key is needed. In case the NFc, or other requesting node, does not directly connect with the network support node, such as NRF, there may be no protocol handshake where the public key would be exchanged. Such is the case where an SCP and hop-by-hop connections are used, for example. The hop-by- hop model may generate a level of transitive trust, but the public key of the NFc itself is not necessarily communicated in the hop-by-hop process. In such a case, there is no direct end-to- end connection with the NFc and NRF as endpoints of the end-to-end connection.
[0036] In case a fully authenticated SCP is compromised by an attacker, the SCP may issue token requests for any NF consumers, existing or non-existing, and there may be no way for the NRF, or other network support function, to determine the authenticity of the access token request messages.
[0037] In accordance with methods disclosed herein, the requesting node, such as NFc, generates a cryptographic signature it with its own private key, and includes this signature in a request message where it seeks access to a service. The question then is how does the NFc share the public key with the NRF or how does the NRF obtain the NFc’s public key that it needs to verify the signature in the request message.
[0038] According to a first option, the NFc’s public key is stored in the NF profile. The
NFc provides this profile during NRF registration, or more generally when registering with a network support function providing authorization service. Thus the public key may then also be available to an intermediate NRF or SCP nodes for later use. The NRF thus knows how to get the NFc’s public key. In case the NFc’s private/public key pair needs to be updated, for example due to expiry, then an NFRegister request to NRF can be used to update the public key for future use. In the first option, registering with the NRF may be made mandatory for NFc nodes. It is also possible that NRF may store the key separately in a secure store, for example one for each NF that registers with it. In general terms, provisioning information concerning the public key may be provided from the NFc to the NRF. The provisioning information may comprise the public key, for example in case the provisioning information is the NF profile which comprises the public key. Additionally or alternatively, the provisioning information may comprise a specific network address using which the public key may be retrieved. The NF profile may be provided in a registration request, for example.
[0039] According to a second option, the NFc’ s public key is stored in a location distinct from the network support node, such as the NRF, and referenced through a specific network address, such as a unique URI or URL. HTTPS may be used in retrieving the public key using the specific network address. This option may avoid using the NF profile to store the NF’s public key, or may be used in conjunction with the NF profile option. The specific network address may be shared in the authorization code itself, where the authorization code is a JSON Web Token, or can be part of the NF profile that is registered with the network support function, such as NRF. In case the NFc’s private/public key pair needs to be updated, then the public key may be updated directly to the location referred to by the specific network address. The NFc may configure the storage to store the public key and to provide a copy of the public key responsive to a request which comprises a specific network address relating to the NFc, in particular, to the public key of the NFc.
[0040] FIGURE 2A illustrates hierarchical NRFs relevant to the present disclosure. In
FIGURE 2A, an intra-PLMN, intra-domain SBA inter-SCP scenario is illustrated. The NFc may contact NRF2a or NRF2b via SCP-c, based on a pre-configured or automatically generated address or domain name, to request information of PLMN-level NRF3 and/or the NFp. The requested information may comprise contact information, such as an address or domain name, of NRF3 or the NFp. SCP-c may then use NRF3 to discover NFp. As the communication goes via SCP-c, the NFc contacts the NRF indirectly, in a hop-by-hop manner.
[0041] FIGURE 2B illustrates an example authorization code in accordance with at least some example embodiments. The illustrated authorization code is a JSON Web Token, JWT, data structure. In this case, an NFc may supply this data structure to the NRF, or other network support function. The specific network address from where the public key needed to verify the signature of the request message is included in this data structure as a URI, although a URL or other suitable address may be used in other embodiments. The network support function, such as NRF, may use a HTTPS or another secure method to obtain the public key from the location referred to by the specific network address. The authorization code may be included in the request message, and the signature to be verified may be applied over the entire request message or over just the authorization code, for example. In some embodiments, the authorization code is a JWT data structure which is different from the one illustrated in FIGURE 2B. In general, the authorization code may comprise the specific network address.
[0042] When stored in a storage, the public key may be stored in a JSON Web Key,
JWK, format. A JWK, as defined in IETF RFC 7517, is a JavaScript Object Notation, JSON, data structure that represents a cryptographic key. When JWK format is used for the key and the key is available remotely on a server, the HTTPS URI may be used to obtain the JSON document that has the required key. 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. In another embodiment, the URL may directly refer to NF consumer JWK Set JSON document which contains the signing key the NRF uses to validate the signature.
[0043] A public key may be updated in both of the options described above, in detail, when the public key is stored in a NF profile, a normal or partial NF registering request to the NRF may be used to update the key. When the public key is in the storage distinct from the NRF, it may be updated directly by the NFc.
[0044] In some embodiments, the NRF or other network support function is configured to construct the specific network address based on a network function identity of the network function, in accordance with a pre-configured network address construction mechanism. For example, the specific network address may be a concatenation including the NF instance identifier, a PLMN identifier of a PLMN where the NFc is located, and a string indicating the specific network address relates to a public key. The NRF may have the pre-configured construction mechanism configured therein from communication standards, for example.
[0045] The following table discloses an example of a network function profile, where the specific network address where the public key may be retrieved from is included as a publickeyURI variable. The NF profile may comprise an NF type, a NF instance identifier and an NF status, for example, in addition to the public key or address of the public key.
Figure imgf000013_0001
Figure imgf000014_0001
Figure imgf000015_0001
[0046] FIGURE 3 illustrates an example apparatus capable of supporting at least some embodiments of the present invention. Illustrated is device 300, which may comprise, for example, a node running an NF or NRF as herein described. Comprised in device 300 is 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, causing transmitting and configuring. Processor 310 may be configured, at least in part by computer instructions, to perform actions. [0047] 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. As used in this application, the term “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.
[0048] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term 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. The term 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.
[0049] 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.
[0050] 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.
[0051] 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. [0052] 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. Such 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. Alternatively to a serial bus, the transmitter may comprise a parallel bus transmitter. Likewise 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. Alternatively to a serial bus, the receiver may comprise a parallel bus receiver.
[0053] Device 300 may comprise further devices not illustrated in FIGURE 3. In some embodiments, device 300 lacks at least one device described above.
[0054] 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. For example, 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. However, as the skilled person will appreciate, 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.
[0055] FIGURE 4 illustrates signalling in accordance with at least some embodiments of the present invention. On the vertical axes are disposed, from the left to the right, the NFc, the SCP, an NRF and a storage STR, distinct from the NRF, the NFc and the SCP. Time advances from the top to the bottom.
[0056] In phase 410, the NFc generates a key pair comprising a public key and a private key. The keys may be used such that a cryptographic signature generated using the private key may be verified using the public key, for example. In phase 420, the NFc configures the storage STR with the new public key generated in phase 410. STR may be remote from NFc in that it is not in the same physical computing substrate, for example. The NFc may store the key pair in a memory comprised in the physical node or nodes that run the NFc.
[0057] In phase 430, the NFc registers with the NRF, providing to the NRF the NF profile of the NFc, this profile comprising a specific network address of the public key in storage STR. As described above, the specific network address may take the form of a URI or URL, for example. Phase 430 may take place using direct messaging, as illustrated, or indirectly via an SCP, for example. [0058] In phase 440, the NFc triggers the SCP with a service request message to request an access token from the NRF for the NFc, the access token relating to a service the NFc wishes to access. The token authorizes the NFc to access the service in an NFp. The SCP acts on behalf of the NFc in phase 450, requesting the token from the NRF. The request messages of phases 440 and 450 comprise the authorization code and cryptographic digital signature for the authorization code or the whole message that the NFc has created using its private key, which was generated in phase 410. This signature has been described herein above. An example authorization code, suitable for use in the process of FIGURE 4, is illustrated in FIGURE 2B.
[0059] In phase 460, the NRF retrieves the specific network address from the NF profile it has or from the URI stored in the authorization code, and in phase 470 it requests the public key from STR using the specific network address. The STR responds in phase 480 by providing the requested public key of NFc.
[0060] In phase 490, the NRF verifies whether the signature in the request message it received in phase 450 is valid. In case it is valid, the NRF may authorize the NFc to use the requested service by generating the access token, in case the NFc fulfils admissibility criteria, which may be defined by the NFp providing the service, for example. Thus merely having a valid signature is not necessarily sufficient to access the service, as the validity of the signature only proves the NFc has created the signature itself. The NRF may also verify location information in the authorization code, in embodiments which use the authorization code. In the event the NRF chooses to authorize the NFc to use the service, it responds, phase 4100, with a response message which may comprise the requested access token relating to the service.. The SCP may include the access token in the service request message and send the service request message to the NFp, for example.
[0061] FIGURE 5 is a flow graph of a method in accordance with at least some embodiments of the present invention. The phases of the illustrated method may be performed in an apparatus such as a NFc, for example. The apparatus, like other apparatuses running NFs, may comprise a single physical node or an arrangement of plural physical nodes together configured to run the NFp or SCP. In particular, the apparatus may in some embodiments comprise a user equipment
[0062] Phase 510 comprises storing a public key cryptography key pair comprising a public key and a private key. Phase 520 comprises running a network function, and causing transmission, from an apparatus performing the method to a network support function, via at least one service communication proxy, of a request message requesting a token relating to a service, the request message comprising a cryptographic signature generated using the private key, and at least one phase 530 and phase 540. [0063] Phase 530 comprises causing transmission to the network support node of provisioning information concerning the public key. Phase 540 comprises configuring a storage distinct from the apparatus to provide a copy of the public key responsive to a request which comprises a specific network address relating to the public key. The storage may be distinct from both the network function, such as the NFc, and from the network support function, such as the NRF. Distinct in this context may comprise that the storage is physically in a separate node, and/or that the storage is in another logical network domain or entity. As noted above, the provisioning information may comprise, for example, the public key. The provisioning information may comprise a NF profile of the NFc, the NF profile comprising the public key. In general, provisioning information is information which conveys information for the network support node.
[0064] It is to be understood that the embodiments of the invention disclosed are not limited to the particular structures, process steps, or materials disclosed herein, but are extended to equivalents thereof as would be recognized by those ordinarily skilled in the relevant arts. It should also be understood that terminology employed herein is used for the purpose of describing particular embodiments only and is not intended to be limiting.
[0065] Reference throughout this specification to one embodiment or an embodiment means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Where reference is made to a numerical value using a term such as, for example, about or substantially, the exact numerical value is also disclosed.
[0066] As used herein, a plurality of items, structural elements, compositional elements, and/or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, no individual member of such list should be construed as a de facto equivalent of any other member of the same list solely based on their presentation in a common group without indications to the contrary. In addition, various embodiments and example of the present invention may be referred to herein along with alternatives for the various components thereof. It is understood that such embodiments, examples, and alternatives are not to be construed as de facto equivalents of one another, but are to be considered as separate and autonomous representations of the present invention.
[0067] Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the preceding description, numerous specific details are provided, such as examples of lengths, widths, shapes, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well- known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
[0068] While the forgoing examples are illustrative of the principles of the present invention in one or more particular applications, it will be apparent to those of ordinary skill in the art that numerous modifications in form, usage and details of implementation can be made without the exercise of inventive faculty, and without departing from the principles and concepts of the invention. Accordingly, it is not intended that the invention be limited, except as by the claims set forth below.
[0069] The verbs “to comprise” and “to include” are used in this document as open limitations that neither exclude nor require the existence of also un-recited features. The features recited in depending claims are mutually freely combinable unless otherwise explicitly stated. Furthermore, it is to be understood that the use of "a" or "an", that is, a singular form, throughout this document does not exclude a plurality.
INDUSTRIAL APPLICABILITY
[0070] At least some embodiments of the present invention find industrial application in enhancing reliability in communication networks.
ACRONYMS LIST
3GPP third generation partnership project
5G fifth generation
5GC 5G core network AF application function
AMF access and mobility function
API application programming interface
AUSF authentication server function
CN core network DNS domain name server
DRA diameter routing agent
HTTP hypertext transfer protocol
HTTPS hypertext transfer protocol secure
FQDN fully qualified domain name IP Internet protocol
IPX IP exchange JSON javascript object notation NEF network exposure function NF network function NRF network repository function NSI network slice instance NSSF network slice selection function PCF policy control function PFMN public land mobile network SBA service based architecture SEPP security edge protection proxy SCP service communication proxy SMF session management function TCP transmission control protocol TFS transport layer security UDM unified data management URF uniform resource locator URI uniform resource identifier VNF virtualized network function

Claims

CLAIMS:
1. An apparatus comprising: a memory configured to store a public key cryptography key pair comprising a public key and a private key, and at least one processing core configured to run a network function, to cause transmission, from the apparatus to a network support function, via at least one service communication proxy, of a request message, the request message comprising an authorization code signed with a cryptographic signature generated using the private key, and at least one of the following: cause transmission to the network support node of provisioning information concerning the public key, and configure a storage distinct from the apparatus to provide a copy of the public key responsive to a request which comprises a specific network address relating to the public key.
2. An apparatus comprising: a memory configured to store public keys of network functions, and at least one processing core configured to receive, from a service communication proxy, a request message requesting a token relating to a service to be provided to a network function, the request message comprising an authorization code signed digitally with a cryptographic signature, verify the cryptographic signature using a public key of the network function and to obtain the public key of the network function by at least one of the following: retrieving the public key of the network function from a network function profile of the network function, and retrieving the public key of the network function from a storage using a specific network address relating to the network function.
3. The apparatus according to claim 1, wherein the provisioning information comprises a network function profile of the network function, the network function profile comprising the public key or the specific network address.
4. The apparatus according to any of claims 1 - 3, wherein the network support function comprises a network repository function configured to perform network function discovery and/or network function service discovery.
5. The apparatus according to claim 4, wherein the network function profile comprises a network function type, a network function instance identifier and a network function status.
6. The apparatus according to any of claims 2 - 5, wherein the token authorizes the network function to access the service.
7. The apparatus according to claim 6, wherein the token comprises a cryptographic signature of the network support function.
8. The apparatus according to any of claims 1 - 7, wherein the specific network address comprises a universal resource locator, URL, or a universal resource identifier, URI.
9. The apparatus according to any of claims 1 - 8, wherein the specific network address is comprised in the network function profile and optionally in the authorization code included in the request message.
10. The apparatus according to any of claim 1 - 9, wherein the apparatus is configured to construct the specific network address based on a network function identity of the network function, in accordance with a pre- configured network address construction mechanism.
11. The apparatus according to any of claims 1 - 10, wherein the apparatus is a user equipment.
12. A method comprising: storing a public key cryptography key pair comprising a public key and a private key; running a network function, and causing transmission, from an apparatus performing the method to a network support function, via at least one service communication proxy, of a request message, the request message comprising an authorization code signed with a cryptographic signature generated using the private key, and at least one of the following: causing transmission to the network support node of provisioning information concerning the public key, and configuring a storage distinct from the apparatus to provide a copy of the public key responsive to a request which comprises a specific network address relating to the public key.
13. A method comprising: receiving, from a service communication proxy, a request message requesting a token relating to a service to be provided to a network function, the request message comprising an authorization code signed digitally with a cryptographic signature, verifying the cryptographic signature using a public key of the network function and obtaining the public key of the network function by at least one of the following: retrieving the public key of the network function from a network function profile of the network function, and retrieving the public key of the network function from a storage using a specific network address relating to the network function.
14. The method according to claim 12, wherein the provisioning information comprises a network function profile of the network function, the network function profile comprising the public key or the specific network address
15. The method according to any of claims 12 or 14, wherein the network support function comprises a network repository function configured to perform network function discovery and/or network function service discovery.
16. The method according to claim 15, wherein the network function profile comprises a network function type, a network function instance identifier and a network function status.
17. The method according to any of claims 13 - 16, wherein the token authorizes the network function to access the service.
18. The method according to claim 17, wherein the token comprises a cryptographic signature of the network support function.
19. The method according to any of claims 12 - 18, wherein the specific network address comprises a universal resource locator, URL, or a universal resource identifier, URI.
20. The method according to any of claims 12 - 19, wherein the specific network address is comprised in the network function profile and optionally in the authorization code included in the request message.
21. The method according to any of claim 12 - 20, further comprising constructing the specific network address based on a network function identity of the network function, in accordance with a pre-configured network address construction mechanism.
22. An apparatus comprising means for: storing a public key cryptography key pair comprising a public key and a private key; running a network function, and causing transmission, from an apparatus performing the method to a network support function, via at least one service communication proxy, of a request message, the request message comprising an authorization code signed with a cryptographic signature generated using the private key, and at least one of the following: causing transmission to the network support node of provisioning information concerning the public key, and configuring a storage distinct from the apparatus to provide a copy of the public key responsive to a request which comprises a specific network address relating to the public key.
23. An apparatus comprising means for: receiving, from a service communication proxy, a request message requesting a token relating to a service to be provided to a network function, the request message comprising an authorization code signed digitally with a cryptographic signature, verifying the cryptographic signature using a public key of the network function and obtaining the public key of the network function by at least one of the following: retrieving the public key of the network function from a network function profile of the network function, and retrieving the public key of the network function from a storage using a specific network address relating to the network function.
24. 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 perform at least: storing a public key cryptography key pair comprising a public key and a private key; running a network function, and causing transmission, from an apparatus performing the method to a network support function, via at least one service communication proxy, of a request message, the request message comprising an authorization code signed with a cryptographic signature generated using the private key, and at least one of the following: causing transmission to the network support node of provisioning information concerning the public key, and configuring a storage distinct from the apparatus to provide a copy of the public key responsive to a request which comprises a specific network address relating to the public key
25. 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 perform at least: receiving, from a service communication proxy, a request message requesting a token relating to a service to be provided to a network function, the request message comprising an authorization code signed digitally with a cryptographic signature, verifying the cryptographic signature using a public key of the network function and obtaining the public key of the network function by at least one of the following: retrieving the public key of the network function from a network function profile of the network function, and retrieving the public key of the network function from a storage using a specific network address relating to the network function.
PCT/IB2021/051452 2020-02-20 2021-02-19 Key management WO2021165925A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN202041007345 2020-02-20
IN202041007345 2020-02-20

Publications (1)

Publication Number Publication Date
WO2021165925A1 true WO2021165925A1 (en) 2021-08-26

Family

ID=74844943

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2021/051452 WO2021165925A1 (en) 2020-02-20 2021-02-19 Key management

Country Status (1)

Country Link
WO (1) WO2021165925A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113825134A (en) * 2021-09-29 2021-12-21 新华三技术有限公司 Network service authorization method, device and equipment
WO2023198733A1 (en) * 2022-04-13 2023-10-19 Telefonaktiebolaget Lm Ericsson (Publ) Efficient determination of user subscription information in a multi-domain network

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190253894A1 (en) * 2018-02-15 2019-08-15 Nokia Technologies Oy Security management for roaming service authorization in communication systems with service-based architecture
US20190251241A1 (en) * 2018-02-15 2019-08-15 Nokia Technologies Oy Security management for 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
US20190253894A1 (en) * 2018-02-15 2019-08-15 Nokia Technologies Oy Security management for roaming service authorization in communication systems with service-based architecture
US20190251241A1 (en) * 2018-02-15 2019-08-15 Nokia Technologies Oy Security management for service authorization in communication systems with service-based architecture

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113825134A (en) * 2021-09-29 2021-12-21 新华三技术有限公司 Network service authorization method, device and equipment
WO2023051316A1 (en) * 2021-09-29 2023-04-06 新华三技术有限公司 Network service authorization method and apparatus, and electronic device
WO2023198733A1 (en) * 2022-04-13 2023-10-19 Telefonaktiebolaget Lm Ericsson (Publ) Efficient determination of user subscription information in a multi-domain network

Similar Documents

Publication Publication Date Title
EP4002760A1 (en) Security procedure
JP7421591B2 (en) Network-assisted bootstrapping for machine-to-machine communication
JP6715976B2 (en) End-to-end authentication at service layer using public key mechanism
KR102084104B1 (en) End-to-end m2m service layer sessions
CN113661696B (en) System and method for handling scalable FQDN
US11737011B2 (en) Management of access tokens in communication networks
US11425636B1 (en) Network function service subscription control
US20220191028A1 (en) Authorization of network request
US20210120416A1 (en) Secure inter-mobile network communication
EP3886390A1 (en) Token management
WO2021140272A1 (en) Verification of access tokens with network repository functions in core networks
WO2020025128A1 (en) Certificate management
WO2021165925A1 (en) Key management
WO2021165194A1 (en) Key management
WO2021140051A1 (en) Queries in a network
WO2021099675A1 (en) Mobile network service security management
WO2021224545A1 (en) Enhanced registration in communication networks
EP4125241A1 (en) Secure provision of network services
WO2021240055A1 (en) Enhanced authorization in communication networks
EP3605992B1 (en) Remotely configuring a customer premise equipment
US20220217127A1 (en) Authentication of network request
EP4092982A1 (en) Authentication of network request
US20230155832A1 (en) Network security
WO2016205673A1 (en) Enhanced address registration in constrained networks
EP3852339B1 (en) Enabling quality of service for trusted 3rd party network functions in core networks

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

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

Country of ref document: EP

Kind code of ref document: A1