WO2020174121A1 - Autorisation de communication de réseau inter-mobile - Google Patents

Autorisation de communication de réseau inter-mobile Download PDF

Info

Publication number
WO2020174121A1
WO2020174121A1 PCT/FI2019/050161 FI2019050161W WO2020174121A1 WO 2020174121 A1 WO2020174121 A1 WO 2020174121A1 FI 2019050161 W FI2019050161 W FI 2019050161W WO 2020174121 A1 WO2020174121 A1 WO 2020174121A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
network
message
request
authorization
Prior art date
Application number
PCT/FI2019/050161
Other languages
English (en)
Inventor
Silke Holtmanns
Gabriela LIMONTA
Nagendra S BYKAMPADI
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
Priority to PCT/FI2019/050161 priority Critical patent/WO2020174121A1/fr
Publication of WO2020174121A1 publication Critical patent/WO2020174121A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G06F21/335—User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272—Virtual private networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/108—Source integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/02—Inter-networking arrangements

Definitions

  • the present invention relates to inter-mobile network communications authorization, and in particular authorization of requests to a resource of a network function.
  • Network elements or functions located in different Public Land Mobile Networks may need to communicate for roaming mobile devices.
  • PLMNs Public Land Mobile Networks
  • Specific edge security network entities such as security proxies, may be arranged at the perimeter of a PLMN network to protect the PLMN from outside messages (inbound) and provide additional security services for the inter-PLMN communication between the network elements or functions at the different PLMNs.
  • Web-based communication such as Hypertext Transfer Protocol Secure (HTTP(S)
  • HTTP(S) Hypertext Transfer Protocol Secure
  • Security of the messages needs to be ensured for various inter-PLMN service scenarios.
  • Network function service logic may perform authorization of a resource request from another PLMN.
  • a method comprising: receiving, by a resource request authorization service, a protected first message from a service-consuming second network entity in a second mobile network for a service providing first network entity in a first mobile network, the first message comprising a request for a resource of the first network entity, extracting the first message, performing an authorization procedure comprising verification of authority of the service-consuming second network entity identified in the first message to obtain requested service indicated by the request, and generating a signed second message comprising the request for the first network entity in response to the authorization procedure being successfully performed.
  • an apparatus comprising at least one processor, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processor, cause the apparatus at least to: receive, by a resource request authorization service, an protected first message from a service-consuming second network entity in a second mobile network for a service-providing first network entity in a first mobile network, the first message comprising a request for a resource of the first network entity, extract the first message, perform an authorization procedure comprising verification of authority of the service-consuming second network entity identified in the first message to obtain requested service indicated by the request, and generate a signed second message comprising the request for the first network entity in response to the authorization procedure being successfully performed.
  • a computer program product a computer readable medium, or a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform the method according to any one of the above aspects or embodiments thereof.
  • FIGURE 1 illustrates an example system capable of supporting at least some embodiments of the present invention
  • FIGURE 2 illustrates a method in accordance with at least some embodiments
  • FIGURES 3 to 5 illustrate example system configurations in accordance with at least some embodiments
  • FIGURE 6 illustrates signalling in accordance with some embodiments
  • FIGURE 7 illustrates arrangement of inter-PLMN service flows in accordance with some embodiments; and [0012] FIGURE 8 illustrates an apparatus in accordance with at least some embodiments.
  • FIGURE 1 illustrates a system 100 of an example embodiment.
  • the system comprises two PLMNs 110, 112 equipped with a Network Function (NF) 120, 150.
  • 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), Unified Data Management (UDM), Authentication Server Function (AUSF), Policy Control Function (PCF), and Application Function (AF).
  • the PFMNs each further comprise a Security Edge Protection Proxy (SEPP) 130, 132 configured to operate as a security edge node or gateway.
  • SEPP Security Edge Protection Proxy
  • the SEPP 130, 132 is a network node at the boundary of an operator's network that receives a message, such as an HTTP request or HTTP response from the NF, applies protection for sending, and forwards the reformatted message through a chain of intermediate nodes, such as IP exchanges (IPX) 140 towards a receiving SEPP.
  • IPX IP exchanges
  • 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 message can alternatively be sent towards any other network function of the second network.
  • the two SEPPs 130, 132 may also communicate with each other, e.g., regarding their mutual connections.
  • the SEPP 130, 132 may be configured to act as a non-transparent proxy node.
  • the SEPP may be configured to protect application layer control plane messages between the NFs 120, 150 belonging to the different PFMNs and use the N32 interface to communicate with each other.
  • the SEPP is configured to perform mutual authentication and negotiation of cipher suites with the SEPP in the roaming network.
  • the SEPP is configured to handle key management aspects that involve setting up the required cryptographic keys needed for securing messages on the N32 interface between two SEPPs.
  • the internetwork interconnect allows secure communication between a service-consuming NF e.g. in a visited PLMN and a service-producing NF e.g. in a home PLMN, henceforth referred to as cNF and pNF, respectively.
  • Security is enabled by the Security Edge Protection Proxies of both networks, henceforth referred to as cSEPP and pSEPP, respectively.
  • SEPPs 130, 132 may simultaneously act in both 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“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 respective entities in the visited and home PLMNs.
  • An N32-c connection is a TLS based connection that may be established between the pSEPP and the cSEPP.
  • the N32-c connection may be applied between the SEPPs for management of the N32 interface, such as cipher suite and protection policy exchange, and error notifications.
  • An N32-f connection is a logical connection that exists between the pSEPP and the cSEPP for exchange of protected HTTP messages.
  • the application layer security employs JSON Web Encryption, JWE.
  • JOSE JSON Object Signing and Encryption
  • the cNF 120 may request service discovery from a Network Repository Function (NRF) in its PLMN 110.
  • the NRF may send a discovery request to an NRF in another PLMN 112, e.g. the home PLMN.
  • the NRF in the other network 112 may respond with a discovery response which is forwarded to the cNF via the NRF in the PLMN 110 of the cNF.
  • the cNF may trigger service requests to the pNF via the cSEPP 130 and the pSEPP 132.
  • the cNF sends a request for the pNF.
  • the cSEPP receives the message and applies symmetric key based application layer protocol, such as the JWE.
  • the resulting JWE object is forwarded to intermediaries.
  • the pIPX and cIPX can offer services that require modifications of the messages transported over the interconnect (N32) interface. These modifications are appended to the message as digitally signed JWS objects which contain the desired changes.
  • the pSEPP which receives the message from pIPX, validates the JWE object, extracts the original message sent by the NF, validates the signature in the JWS object and applies patches corresponding to the modifications by intermediaries. The pSEPP then forwards the message to the destination NF.
  • the NFs 120, 150 may be configured to support TLS, both server-side and client-side certificates.
  • the connection between the SEPPs 130, 132 and the respective NFs 120, 150 may be protected by TLS.
  • the NFs may be configured to use HTTPS to send HTTP based messages to the remote NF in the other PLMN.
  • HTTPS uses TLS to securely transmit HTTP messages between the NF and the SEPP.
  • the messages may comprise HTTP Representational State Transfer (REST) Application Programming Interface (API) requests to an NF resource.
  • the pSEPP 132 channels the HTTP REST API messages to the corresponding pNF 150. While the pSEPP takes care that the N32 (control) interface is properly secure it does not care of the actual authorization of a resource request coming in from the roaming network.
  • the SEPP only sets up a secure N32 tunnel with the other end-point.
  • a specific filtering service is established to perform authorization and validation of such resource requests between mobile networks, such as 5G PLMNs, and pass only successfully authorized resource request passing for a service-providing network entity.
  • the filtering service may be configured to perform filtering on behalf of a large range of nodes/NFs belonging to a network, and potentially multiple networks.
  • Such filtering service may, and is below, referred to a resource request authorization service (RAS).
  • RAS resource request authorization service
  • FIGURE 2 illustrates a method according to some embodiments.
  • the method may be implemented in an apparatus configured to perform the RAS, such as the pSEPP 132 or another network node in the service-producing network or a further network, or a controller thereof.
  • the method comprises receiving 200, by a resource request authorization service, a protected first message from a service-consuming second network entity in a second mobile network for a service-providing first network entity in a first mobile network.
  • the first message comprises a request for a resource of the first network entity, such as an API request to a service-providing network function.
  • the term resource refers generally to a resource in the first mobile network, identified by a resource identifier and to which the second network entity may initiate a connection by the request in the first message, such as by an API call comprising a URI to an API of the service-providing second network entity.
  • the service-providing first network entity may operate as a server for the service-consuming second network entity acting as a client.
  • the request is a REST API call from the cNF 120 to an API of the pNF 150.
  • the first message is extracted 210.
  • the extraction generally involves releasing at least some of the protection applied for the protected first message, to have access to relevant identification information required for performing the authorization.
  • the first message may be integrity-protected by a digital signature and/or enciphered (partially or entirely), for example.
  • block 210 may involve validation of the digital signature and/or deciphering of at least some of the ciphered portions of the received first message, for example.
  • the apparatus carrying out the method of Figure 2 is provided with access to relevant credentials for terminating application layer security (ALS) level connection, such as TLS or an IP Security (IPsec) based connection, in a further embodiment between the cSEPP and the pSEPP.
  • ALS application layer security
  • IPsec IP Security
  • An authorization procedure is performed 220 for the first message.
  • the authorization procedure comprises verification of authority of the service-consuming second network entity identified in the first message to obtain requested service identified in the request.
  • the authorization procedure may comprise a set of checks, or sub procedures, to be performed, according to authorization policy and parameters configured for the service. If one of the checks or sub-procedures fails, the authorization procedure fails, and the resource request may be filtered out, i.e. not sent to the first network entity.
  • a signed second message is generated 230, comprising the request for the first network entity in response to the authorization procedure being successfully performed.
  • the message may comprise a cryptographic signature of the request authorization service or a network node performing the request authorization service.
  • other protection measures may be applied for the second message, which may correspond to those applied for the protected first (and removed in connection with block 210).
  • the apparatus carrying out block 230 may thus have access to relevant credentials for (re-)establishing ALS level connection, such as TLS or an IP Security (IPsec) based connection to the first mobile network for the second message.
  • IPsec IP Security
  • the signed second message may be sent to the first network entity after block 230, directly or indirectly depending on the applied implementation and system location of the apparatus performing the method of Figure 2.
  • the first network entity can confirm that authorization procedure has been performed for the request by the signing party.
  • the first network entity or in some embodiments further the first mobile network, thus does not have be configured to perform authorization procedure of the service requests received from roaming partner networks in accordance with roaming contracts. Instead, the authorization procedure may be outsourced.
  • the authorization procedure implementation is (more) centralized instead of being spread as responsibility of entities with various levels of data security means and skills, security risks are better in control and may be reduced. For example, it is much easier to keep the authorization procedures updated for numerous new and updated roaming agreements, as well as security procedures updated against new types of security risks and attacks.
  • the signed second message may be generated 230 to comprise an indication of the performed authorization procedure, by the signing or another information element in the message.
  • the signed second message may comprise an information element comprising result and/or further information related to the authorization procedure. For example, associated network slice information, sub-operator and security class information may be included in the message and also signed.
  • the request may define one or more operations requested by the service consuming service function.
  • the authorization procedure 220 may comprise operations to validate the request.
  • the authorization procedure may comprise verifying authority of the service-consuming network function to the requested operations.
  • the authorization policy may comprise (roaming) network and/or network entity identifiers allowed to access a given API of the first network entity.
  • the policy may further identify available resources, allowed actions, and further scope of access restrictions or permissions, for example.
  • the apparatus performing the method of Figure 2 may be configured to perform one or more further security sub-procedures before passing the request for the service-providing network function, some examples being illustrated below.
  • the authorization procedure 220 may comprise determining service consumer type of the second network entity on the basis of the first message and performing the verification on the basis of the determined service consumer type.
  • information may be prestored for the RAS on NF types and their permitted actions (i.e. scope) and actors. Whenever an incoming message is received by the RAS, it checks whether the consumer NF type is one of the permitted types to obtain service in the first network.
  • the network entity from which the protected first message is received 200 may be authenticated as part of, or prior to, the authorization procedure 220, e.g. in connection with block 210.
  • the authorization procedure 220 may comprise verifying if requested service operation(s) indicated by the request are authorized in a service or roaming resource access policy of the second mobile network and/or the second network entity.
  • resource access policy refers generally to a policy for controlling inter-mobile network resource access, in some embodiments for mobile subscriber or service roaming purposes.
  • the RAS may comprise telco logic to verify if the request matches with predefined contractual roaming or service agreement. For example, if no location based service roaming agreement is provided for the first network 112, such location based request to the pNF 150 is not allowed.
  • GET operation may be the only HTTP operation allowed for a given API.
  • the authorization procedure 220 comprises performing further security measures regarding the source of the protected first message, such as an integrity verification procedure
  • the RAS or the procedure 220 thereof may comprise additional security checks, e.g. for malware, ransomware and other unwanted elements. It also may include rules dependent on source of the request, such as special rules for requests coming from legacy nodes via an interworking function.
  • the RAS may comprise Denial of Service (DoS) protection functions, such perform a set of DoS modes.
  • DoS Denial of Service
  • a security edge node is configured to perform the RAS, and hence the method of Figure 2, and filter out a non-authorized request for the resource of the first network entity.
  • the security edge node may be a gateway or proxy device at the border of a mobile network, some example network configurations being illustrated below.
  • a proxy device or node is configured to perform the RAS.
  • the proxy may intercept the first message being transferred between security edge nodes in the first mobile network and the second mobile network, perform resource authorization on the basis of the request, and send the signed second message to the security edge node in the second mobile network after block 230.
  • the first network entity is a service-producing network function, such as the pNF 150
  • the second network entity is a service-consuming network function, such as the cNF 120
  • the security edge node is a security edge protection proxy, such as the pSEPP 132.
  • the proxy may be provided in a network node 160 of a third network 114, such as a PLMN of a further network operator.
  • a network node 160 of a third network 114 such as a PLMN of a further network operator.
  • Such RAS proxy node 160 may perform the method of Figure 2 and send the signed second message after block 230 to the pSEPP 132.
  • the pSEPP may operate as normal security edge node and send the resource request to the target pNF 150.
  • the proxy node 160 is a SEPP located in a third PLMN 114.
  • SEPP could be referred to as aSEPP, and may directly or indirectly (upon request of the pSEPP 132) perform the RAS for service requests to one or more network functions 150 of the first network 112.
  • the pSEPP 132 may comprise the RAS and send the signed second message to the pNF 150 after block 230.
  • the RAS is implemented in a further network entity in the first network, such as a proxy in the PLMN 112 between the cSEPP 130 and he pSEPP 132 or between the pSEPP 132 and the pNF 150.
  • Figure 6 illustrates an example signalling scenario in a case for applying an aSEPP indirectly in the embodiment of Figure 4.
  • the cSEPP sends the protected resource request message 602 to the pSEPP.
  • the authorization of at least some inter-PLMN API requests is delegated to the aSEPP in the third PLMN 114, so the pSEPP is configured to forward the protected API request message 604 to the aSEPP.
  • the aSEPP processes 606 the received message by performing the blocks of Figure 2.
  • the aSEPP sends signed API request 608 to the pSEPP, which forwards it 610 to the pNF.
  • the aSEPP is configured to intercept the resource request before arriving to the pSEPP and/or send the signed resource request directly to the pNF.
  • Figure 7 illustrates inter-PLMN service flows in a 5G SBA system between some vNFs and hNFs.
  • the aSEPP or the hSEPP (or pSEPP) is configured to perform the RAS and carry out least some of presently disclosed embodiments.
  • the authorization service may be configured to provide an authorization as a service (AaS) for all or a set of network functions of the first (service-producing or home) mobile network, such as the PLMN 112, for one or more network slices of the first mobile network, and/or one or more security zones of the first mobile network.
  • a virtual filtering domain may be established, which may perform the RAS based on API authorization rules that are applied to a group of core network nodes. Within this group there may also be subgroups e.g. for slices of networks or mobile virtual network operators (MVNOs).
  • MVNOs mobile virtual network operators
  • virtual NF frontends may thus be provided for NFs connected to the SBA. That means that such virtual NF frontend, implemented e.g. by the aSEPP, may break the ALS level inter-PLMN tunnel, extract the first message, validate the request(s) in the first message against the virtual NF frontends policies, and reassemble the message for forwarding to the final or“real” NF, e.g. the pNF 150.
  • the final or“real” NF e.g. the pNF 150.
  • the RAS e.g. as a virtual NF frontend, may be assigned e.g. one or more of:
  • the virtual NF frontend may be configured to provide AaS to all network functions within an operator.
  • an operator has outsourced service access authorization to the virtual NF frontend.
  • the virtual NF frontend provides the AaS to specific slices within the operator network.
  • Some slices may require a higher level of assurance based on geographical location.
  • the virtual NF frontend provides the AaS to a set of network functions within the security zone.
  • a virtual PCF frontend may be configured with a list of resources which the PCF offers and associated specific policies for each partner (or groups of partners), for a specific slice, a sub-operator and/or a specific security zone. Even if called PCF frontend, the virtual PCF frontend does not have to comprise any actual PCF functionality, but merely perform the AaS for the PCF.
  • service access authorization is based on virtual frontend NF in the SEPP, which may comprise information of all or some of network functions in the operator network and their profiles comprising information on authorized service consumer NF types, potential resources, and allowed actions.
  • service access authorization is based on access tokens of an authorization protocol, such as OAuth protocol, e.g. OAuth version 2.0.
  • OAuth protocol e.g. OAuth version 2.0.
  • the network entity comprising the RAS is provisioned with appropriate public key of the issuer (such as the NRF in 5G SB A) to verify the signature in the access token and validate the embedded request(s) or claims.
  • validity of the request(s) may be based on a locally stored profile database comprising information on valid service consumers, scope of their access, etc.
  • the first message and the second message are or are carried by TLS protocol messages and the RAS is configured to terminate a first transport layer security session, in some embodiments the TLS session from the cSEPP 130.
  • Another TLS session may be established after block 230 between the entity performing the RAS and the first network entity, to transfer the authorized request.
  • a TLS session is established between the aSEPP comprising the RAS ( Figure 4) and the pSEPP 132 for the pNF 150 to which the request is addressed (for message 608 of the example of Figure 6).
  • the pSEPP 132 comprising the RAS may establish the TLS session for transmitting the authorized request.
  • TLS is just one example of available transfer options for securing the transmission of the inter-PLMN messages.
  • VPN virtual private network
  • VPN virtual private network
  • trusted platform module (TPM) operations may be carried out between at least some of the above- illustrated network entities to further increase the security level. TPM operations may be carried out as part of the authorization procedure 220 by the RAS.
  • guarantees about integrity and identity based on TPM capabilities are provided as part of or in connection with authentication between the entity performing the RAS and the entity sending the resource request (as the protected first message), such as between the cSEPP and aSEPP/pSEPP.
  • the TPM may be applied for protecting initial set-up and key exchange for enabling the RAS, i.e. before and for enabling to perform the method of Figure 2.
  • TPM based authentication illustrated below may be applied for other inter-PLMN communication, even if the above-illustrated RAS related features are not implemented.
  • some or all of the TPM based features illustrated below may be applied between SEPPs as an add-on to existing (e.g. TLS) authentication.
  • a TPM includes two unique keypairs that can only be used by the TPM: the Endorsement Key (EK) and Attestation Key (AK). Private parts of these keypairs cannot be read, only used to encrypt/sign through the TPM.
  • EK Endorsement Key
  • AK Attestation Key
  • the TPM and its keys may be applied to encrypt a secret, so that only the correct SEPP can decrypt the secret.
  • cSEPP can encrypt a secret for the initial tunnel set-up with the TPM keys of aSEPP. Then, only aSEPP will be able to decrypt this secret by using its TPM.
  • aSEPP can send any secret encrypted with cSEPP’ s TPM keys. This way, they can share the initial secrets securely and guarantee that only the correct SEPP has access to it.
  • An attestation server is an entity in charge of obtaining information about the hardware, firmware and software status of a set of monitored platforms (e.g. SEPPs with a TPM) in the form of cryptographic measurements.
  • the respective entity needs to have access to this attestation server in order to get the integrity information.
  • locaFglobal attestation servers maintained by an appropriate authority.
  • TPM measurements can be compared to reference values to determine if the evaluated entity is in an appropriate status, e.g.“initial/known” status, or if its integrity has been compromised.
  • the RAS performing entity is able to check not only the identity of the other entity it communicates with, but also that the other entity’s platform is in an appropriate state (has not been tampered with).
  • An operator may have a TPM for each of its customer networks (e.g. virtual operators) or a root certificate and then sub-certificates for each customer.
  • a network entity such as the aSEPP or pSEPP, may comprise a TPM which binds it to the PLMN and the operator (optionally also sub-operator and slice).
  • the AK of this TPM is used to sign the second message 230, which allows the receiving pNF to be sure that the received message is legitimate, i.e. not coming e.g. as an insider attack from another network node. If the pNF has the public part of the AK of the RAS-performing entity, it can verify the signature. Since only the TPM has access to the private part of the AK, any message signed with the AK could have only been signed on that platform by its TPM.
  • network functions or nodes illustrated above may be shared between two physically separate devices forming one operational entity.
  • virtual networking may involve a process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network.
  • Network virtualization may involve platform virtualization, often combined with resource virtualization.
  • Network virtualization may be categorized as external virtual networking which combines many networks, or parts of networks, into the server computer or the host computer. External network virtualization is targeted to optimized network sharing. Another category is internal virtual networking which provides network-like functionality to software containers on a single system.
  • instances of the 5G network functions can be instantiated as virtual network functions (VNFs) in network function virtualization (NFV) architecture.
  • VNFs virtual network functions
  • NFV network function virtualization
  • An electronic device comprising electronic circuitries may be an apparatus for realizing at least some embodiments of the present invention.
  • the apparatus may be or may be comprised in a computer, a server, a proxy device, a network function hosting device, a network access device, network management device or another appropriately configured communications apparatus.
  • the apparatus carrying out the above-described functionalities is comprised in such a device, e.g. the apparatus may comprise a circuitry, such as a chip, a chipset, a microcontroller, or a combination of such circuitries configured to perform at least some of the above illustrated features.
  • the term“circuitry” may refer to one or more or all of the following:
  • 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.
  • FIGURE 8 illustrates an example apparatus capable of supporting at least some embodiments of the present invention. Illustrated is a device 800, which may be arranged to carry out at least some of the embodiments related to arranging inter-PLMN communication as illustrated above.
  • the device may include one or more controllers configured to carry out operations in accordance with at least some of the embodiments illustrated above, such as some or more of the features illustrated above in connection with Figures 2 to 7.
  • the device may operate as the apparatus performing the RAS and the method of Figure 2, such as the proxy network node 160, the aSEPP or pSEPP 132, for example.
  • a processor 802 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.
  • the processor 802 may comprise more than one processor.
  • the processor may comprise at least one application- specific integrated circuit, ASIC.
  • the processor may comprise at least one field-programmable gate array, FPGA.
  • the processor may be means for performing method steps in the device.
  • the processor may be configured, at least in part by computer instructions, to perform actions.
  • the device 800 may comprise memory 804.
  • the memory may comprise random-access memory and/or permanent memory.
  • the memory may comprise at least one RAM chip.
  • the memory may comprise solid-state, magnetic, optical and/or holographic memory, for example.
  • the memory may be at least in part accessible to the processor 802.
  • the memory may be at least in part comprised in the processor 802.
  • the memory 804 may be means for storing information.
  • the memory may comprise computer instructions that the processor is configured to execute. When computer instructions configured to cause the processor to perform certain actions are stored in the memory, and the device in overall is configured to run under the direction of the processor using computer instructions from the memory, the processor and/or its at least one processing core may be considered to be configured to perform said certain actions.
  • the memory may be at least in part comprised in the processor.
  • the memory may be at least in part external to the device 800 but accessible to the device.
  • control parameters affecting operations related to the credentials management and associated information may be stored in one or more portions of the memory and used to control operation of the apparatus.
  • the memory may comprise device-specific cryptographic information, such as secret and public key of the device 800.
  • the device 800 may comprise a transmitter 806.
  • the device may comprise a receiver 808.
  • the transmitter and the receiver may be configured to transmit and receive, respectively, information in accordance with at least one wired or wireless, cellular or non- cellular standard.
  • the transmitter may comprise more than one transmitter.
  • the receiver may comprise more than one receiver.
  • the transmitter and/or receiver may be configured to operate in accordance with global system for mobile communication, GSM, wideband code division multiple access, WCDMA, LTE, 5G, wireless local area network, WLAN, and/or Ethernet, for example.
  • the device 800 may comprise a near-field communication, NFC, transceiver 810.
  • the device 800 may comprise user interface, UI, 812.
  • the UI may comprise at least one of a display, a keyboard, a touchscreen, a vibrator arranged to signal to a user by causing the device to vibrate, a speaker and a microphone.
  • a user may be able to operate the device via the UI, for example to cause the device to perform at least some functions illustrated above, configure the RAS, and/or to manage digital files stored in the memory 804 or on a cloud accessible via the transmitter 806 and the receiver 808, or via the NFC transceiver 810.
  • the device 800 may comprise or be arranged to accept a user identity module or other type of memory module 814.
  • the user identity module may comprise, for example, a personal identification IC card installable in the device 800.
  • the processor 802 may be furnished with a transmitter arranged to output information from the processor, via electrical leads internal to the device 800, to other devices comprised in the device.
  • a transmitter may comprise a serial bus transmitter arranged to, for example, output information via at least one electrical lead to memory 804 for storage therein.
  • the transmitter may comprise a parallel bus transmitter.
  • the processor may comprise a receiver arranged to receive information in the processor, via electrical leads internal to the device 800, from other devices comprised in the device 800.
  • Such a receiver may comprise a serial bus receiver arranged to, for example, receive information via at least one electrical lead from the receiver 808 for processing in the processor.
  • the receiver may comprise a parallel bus receiver.
  • the device 800 may comprise further devices not illustrated in Figure 8. For example, some devices may lack the NFC transceiver 810 and/or the user identity module 814.
  • the processor 802, the memory 804, the transmitter 806, the receiver 808, the NFC transceiver 810, the UI 812 and/or the user identity module 814 may be interconnected by electrical leads internal to the device 800 in a multitude of different ways.
  • each of the aforementioned devices may be separately connected to a master bus internal to the device, 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.
  • references 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.
  • 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.
  • the skilled person will appreciate that above-illustrated embodiments may be combined in various ways. Embodiments illustrated in connection with Figures 2 to 8 may be taken in isolation or further combined together.

Landscapes

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

Abstract

Un exemple d'aspect de la présente invention concerne un procédé, comprenant : la réception, par un service d'autorisation de demande de ressource, d'un premier message protégé en provenance d'une deuxième entité de réseau de consommation de service dans un deuxième réseau mobile pour une première entité de réseau de fourniture de service dans un premier réseau mobile, le premier message comprenant une demande de ressource de la première entité de réseau, l'exécution d'une procédure d'autorisation comprenant la vérification de l'autorité de la deuxième entité de réseau de consommation de service identifiée dans le premier message pour obtenir un service demandé indiqué par la demande, et la création d'un deuxième message signé comprenant la demande pour la première entité de réseau en réponse à la procédure d'autorisation exécutée avec succès.
PCT/FI2019/050161 2019-02-28 2019-02-28 Autorisation de communication de réseau inter-mobile WO2020174121A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/FI2019/050161 WO2020174121A1 (fr) 2019-02-28 2019-02-28 Autorisation de communication de réseau inter-mobile

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/FI2019/050161 WO2020174121A1 (fr) 2019-02-28 2019-02-28 Autorisation de communication de réseau inter-mobile

Publications (1)

Publication Number Publication Date
WO2020174121A1 true WO2020174121A1 (fr) 2020-09-03

Family

ID=72240198

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2019/050161 WO2020174121A1 (fr) 2019-02-28 2019-02-28 Autorisation de communication de réseau inter-mobile

Country Status (1)

Country Link
WO (1) WO2020174121A1 (fr)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113992381A (zh) * 2021-10-22 2022-01-28 北京天融信网络安全技术有限公司 授权方法、装置、授权平台及存储介质
CN114268943A (zh) * 2020-09-16 2022-04-01 华为技术有限公司 授权方法及装置
US20220191694A1 (en) * 2020-12-15 2022-06-16 Oracle International Corporation Methods, systems, and computer readable media for message validation in fifth generation (5g) communications networks
EP4075722A1 (fr) * 2021-04-16 2022-10-19 Nokia Technologies Oy Amélioration de la sécurité sur une communication inter-réseau
US11622255B2 (en) 2020-10-21 2023-04-04 Oracle International Corporation Methods, systems, and computer readable media for validating a session management function (SMF) registration request
CN116325829A (zh) * 2020-10-09 2023-06-23 上海诺基亚贝尔股份有限公司 用于动态授权的机制
US11689912B2 (en) 2021-05-12 2023-06-27 Oracle International Corporation Methods, systems, and computer readable media for conducting a velocity check for outbound subscribers roaming to neighboring countries
US11700510B2 (en) 2021-02-12 2023-07-11 Oracle International Corporation Methods, systems, and computer readable media for short message delivery status report validation
US11751056B2 (en) 2020-08-31 2023-09-05 Oracle International Corporation Methods, systems, and computer readable media for 5G user equipment (UE) historical mobility tracking and security screening using mobility patterns
US11770694B2 (en) 2020-11-16 2023-09-26 Oracle International Corporation Methods, systems, and computer readable media for validating location update messages
US11812271B2 (en) 2020-12-17 2023-11-07 Oracle International Corporation Methods, systems, and computer readable media for mitigating 5G roaming attacks for internet of things (IoT) devices based on expected user equipment (UE) behavior patterns
US11825310B2 (en) 2020-09-25 2023-11-21 Oracle International Corporation Methods, systems, and computer readable media for mitigating 5G roaming spoofing attacks
US11832172B2 (en) 2020-09-25 2023-11-28 Oracle International Corporation Methods, systems, and computer readable media for mitigating spoofing attacks on security edge protection proxy (SEPP) inter-public land mobile network (inter-PLMN) forwarding interface
US20240073103A1 (en) * 2022-08-26 2024-02-29 T-Mobile Usa, Inc. Dynamic configuration and discovery of security edge protection proxy
US11974134B2 (en) 2022-01-28 2024-04-30 Oracle International Corporation Methods, systems, and computer readable media for validating subscriber entities against spoofing attacks in a communications network

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120110637A1 (en) * 2009-05-01 2012-05-03 Nokia Corporation Systems, Methods, and Apparatuses for Facilitating Authorization of a Roaming Mobile Terminal
US20140098671A1 (en) * 2009-01-28 2014-04-10 Headwater Partners I Llc Intermediate Networking Devices
US20170142096A1 (en) * 2015-11-16 2017-05-18 Cisco Technology, Inc. Endpoint privacy preservation with cloud conferencing
WO2018013925A1 (fr) * 2016-07-15 2018-01-18 Idac Holdings, Inc. Structure d'autorisation adaptative pour réseaux de communication
US20190045421A1 (en) * 2018-06-22 2019-02-07 Intel Corporation Receive-side scaling for wireless communication devices

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140098671A1 (en) * 2009-01-28 2014-04-10 Headwater Partners I Llc Intermediate Networking Devices
US20120110637A1 (en) * 2009-05-01 2012-05-03 Nokia Corporation Systems, Methods, and Apparatuses for Facilitating Authorization of a Roaming Mobile Terminal
US20170142096A1 (en) * 2015-11-16 2017-05-18 Cisco Technology, Inc. Endpoint privacy preservation with cloud conferencing
WO2018013925A1 (fr) * 2016-07-15 2018-01-18 Idac Holdings, Inc. Structure d'autorisation adaptative pour réseaux de communication
US20190045421A1 (en) * 2018-06-22 2019-02-07 Intel Corporation Receive-side scaling for wireless communication devices

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security architecture and procedures for 5G system (Release 15", 3GPP TS 33.501 V15.3.1 ( 2018-12, 26 December 2018 (2018-12-26), Retrieved from the Internet <URL:<https://www.3gpp.org/ftp/specs/archive/33_series/33.501/33501-f31.zip>> [retrieved on 20190510] *
HUAWEI ET AL.: "S 3-190440 . Clarification on service authorization and token verification", 3GPP TSG SA WG3 (SECURITY) MEETING #94, 1 February 2019 (2019-02-01) - 1 February 2019 (2019-02-01), XP051595865, Retrieved from the Internet <URL:<https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_94_Kochi/Docs/S3-190440.zip>> [retrieved on 20190516] *
NOKIA ET AL.: "S 3-183689 . Editorial corrections in clauses in 13.2", 3GPP TSG SA WG3 (SECURITY) MEETING #93, 16 November 2018 (2018-11-16), Spokane (US, XP051499858, Retrieved from the Internet <URL:<https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_93_Spokane/Docs/S3-183689.zip>> [retrieved on 20190516] *

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11751056B2 (en) 2020-08-31 2023-09-05 Oracle International Corporation Methods, systems, and computer readable media for 5G user equipment (UE) historical mobility tracking and security screening using mobility patterns
CN114268943A (zh) * 2020-09-16 2022-04-01 华为技术有限公司 授权方法及装置
US11832172B2 (en) 2020-09-25 2023-11-28 Oracle International Corporation Methods, systems, and computer readable media for mitigating spoofing attacks on security edge protection proxy (SEPP) inter-public land mobile network (inter-PLMN) forwarding interface
US11825310B2 (en) 2020-09-25 2023-11-21 Oracle International Corporation Methods, systems, and computer readable media for mitigating 5G roaming spoofing attacks
CN116325829A (zh) * 2020-10-09 2023-06-23 上海诺基亚贝尔股份有限公司 用于动态授权的机制
US11622255B2 (en) 2020-10-21 2023-04-04 Oracle International Corporation Methods, systems, and computer readable media for validating a session management function (SMF) registration request
US11770694B2 (en) 2020-11-16 2023-09-26 Oracle International Corporation Methods, systems, and computer readable media for validating location update messages
US11818570B2 (en) * 2020-12-15 2023-11-14 Oracle International Corporation Methods, systems, and computer readable media for message validation in fifth generation (5G) communications networks
US20220191694A1 (en) * 2020-12-15 2022-06-16 Oracle International Corporation Methods, systems, and computer readable media for message validation in fifth generation (5g) communications networks
US11812271B2 (en) 2020-12-17 2023-11-07 Oracle International Corporation Methods, systems, and computer readable media for mitigating 5G roaming attacks for internet of things (IoT) devices based on expected user equipment (UE) behavior patterns
US11700510B2 (en) 2021-02-12 2023-07-11 Oracle International Corporation Methods, systems, and computer readable media for short message delivery status report validation
US11818102B2 (en) 2021-04-16 2023-11-14 Nokia Technologies Oy Security enhancement on inter-network communication
EP4075722A1 (fr) * 2021-04-16 2022-10-19 Nokia Technologies Oy Amélioration de la sécurité sur une communication inter-réseau
US11689912B2 (en) 2021-05-12 2023-06-27 Oracle International Corporation Methods, systems, and computer readable media for conducting a velocity check for outbound subscribers roaming to neighboring countries
CN113992381A (zh) * 2021-10-22 2022-01-28 北京天融信网络安全技术有限公司 授权方法、装置、授权平台及存储介质
US11974134B2 (en) 2022-01-28 2024-04-30 Oracle International Corporation Methods, systems, and computer readable media for validating subscriber entities against spoofing attacks in a communications network
US20240073103A1 (en) * 2022-08-26 2024-02-29 T-Mobile Usa, Inc. Dynamic configuration and discovery of security edge protection proxy

Similar Documents

Publication Publication Date Title
WO2020174121A1 (fr) Autorisation de communication de réseau inter-mobile
TWI514896B (zh) 可信賴聯合身份方法及裝置
Prasad et al. 3GPP 5G security
US8627064B2 (en) Flexible system and method to manage digital certificates in a wireless network
JP5390619B2 (ja) Ｈｏｍｅｎｏｄｅ−ｂ装置およびセキュリティプロトコル
KR101202671B1 (ko) 사용자가 가입자 단말에서 단말 장치에 원격으로 접속할 수있게 하기 위한 원격 접속 시스템 및 방법
Hojjati et al. A blockchain-based authentication and key agreement (AKA) protocol for 5G networks
US20210120416A1 (en) Secure inter-mobile network communication
CN110808830A (zh) 一种基于5G网络切片的IoT安全验证框架及其服务方法
JP2022043175A (ja) コアネットワークへの非３ｇｐｐ装置アクセス
CN112602344A (zh) 漫游5g-nr通信的端到端安全性
US11316670B2 (en) Secure communications using network access identity
Shokoor et al. Overview of 5G & beyond security
Marques et al. EAP-SH: an EAP authentication protocol to integrate captive portals in the 802.1 X security architecture
WO2021099675A1 (fr) Gestion de sécurité de service de réseau mobile
WO2021079023A1 (fr) Sécurité de communication de réseau inter-mobile
US20220353263A1 (en) Systems and methods for securing network function subscribe notification process
Moroz et al. Methods for ensuring data security in mobile standards
Marques et al. Integration of the Captive Portal paradigm with the 802.1 X architecture
Aiash et al. Introducing a novel authentication protocol for secure services in heterogeneous environments using Casper/FDR
Lei et al. 5G security system design for all ages
Southern et al. Wireless security: securing mobile UMTS communications from interoperation of GSM
Santos et al. A federated lightweight authentication protocol for the internet of things
RU2779029C1 (ru) Доступ не отвечающего спецификациям 3gpp устройства к базовой сети
CN117678255A (zh) 边缘启用器客户端标识认证过程

Legal Events

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

Ref document number: 19917352

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

Country of ref document: EP

Kind code of ref document: A1