WO2020174121A1

WO2020174121A1 - Inter-mobile network communication authorization

Info

Publication number: WO2020174121A1
Application number: PCT/FI2019/050161
Authority: WO
Inventors: Silke Holtmanns; Gabriela LIMONTA; Nagendra S BYKAMPADI
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2019-02-28
Filing date: 2019-02-28
Publication date: 2020-09-03
Anticipated expiration: 2021-08-28

Abstract

According to an example aspect of the present invention, there is provided 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, 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.

Description

INTER-MOBILE NETWORK COMMUNICATION AUTHORIZATION

FIELD

[0001] The present invention relates to inter-mobile network communications authorization, and in particular authorization of requests to a resource of a network function.

BACKGROUND

[0002] Network elements or functions located in different Public Land Mobile Networks (PLMNs) may need to communicate for roaming mobile devices. There may be various actors in interconnection network trying to track users, listen to traffic, etc. 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)), may be applied between the network entities in the different PLMNs, as well as between the network functions and the edge security entities. 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.

SUMMARY

[0003] The invention is defined by the features of the independent claims. Some specific embodiments are defined in the dependent claims.

[0004] According to a first aspect, there is provided 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.

[0005] According to a second aspect, there is provided 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. [0006] According to a third aspect, there is provided 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.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] FIGURE 1 illustrates an example system capable of supporting at least some embodiments of the present invention;

[0008] FIGURE 2 illustrates a method in accordance with at least some embodiments; [0009] FIGURES 3 to 5 illustrate example system configurations in accordance with at least some embodiments;

[0010] FIGURE 6 illustrates signalling in accordance with some embodiments;

[0011] 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.

EMBODIMENTS

[0013] 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. In case of a Third Generation Partnership Project (3GPP) 5G system Service Based Architecture (SBA), 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.

[0014] 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. 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.

[0015] 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. [0016] 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.

[0017] It is to be noted that the 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.

[0018] If there are no IPX entities between the pSEPP 132 and the cSEPP 130, TLS is used between the SEPPs. If there are IPX entities between the pSEPP and the cSEPP, application layer security on the N32 interface between SEPPs is needed for protection between the pSEPP and the cSEPP. 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. In some embodiments, the application layer security employs JSON Web Encryption, JWE. Thus, a JSON Object Signing and Encryption (JOSE) header comprises parameters describing the cryptographic operations and parameters applied.

[0019] During an NF service discovery in inter-PLMN (roaming) communication, 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. Then the cNF may trigger service requests to the pNF via the cSEPP 130 and the pSEPP 132.

[0020] 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.

[0021] 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. Thus, 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.

[0022] There is a need to perform authorization of the API requests between mobile networks for mobile subscriber and/or service roaming purposes. Equipping each service providing network entity with such capability and various roaming contracts would be burdensome and complex task for network operators. Furthermore, especially for smaller standalone network operators or operator subsidiaries with very limited security expertise it may be difficult problem to implement adequate security infrastructure for authorizing (API) requests from roaming partner networks. The proof of identity needs to be strong to avoid impersonation of other roaming partners.

[0023] There are now provided methods and apparatuses facilitating addressing authorization of inter-PLMN resource requests, such as API requests, to service-providing network functions.

[0024] 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).

[0025] 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.

[0026] 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.

[0027] 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. In some embodiments, the request is a REST API call from the cNF 120 to an API of the pNF 150.

[0028] 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. Thus, 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. In some embodiments, 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. [0029] 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.

[0030] 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. However, it is to be appreciated that also 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.

[0031] 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. By verifying the signature, the first network entity can confirm that authorization procedure has been performed for the request by the signing party. It is to be appreciated that various modifications and additions may be implemented to the method of Figure 2 within the scope of the present claims. Some further example embodiments are illustrated below.

[0032] 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. When 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.

[0033] 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.

[0034] 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. For example, 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. There may be also further conditions for allowing the request to be provided for the service-providing network function. 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.

[0035] 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. In a further example embodiment, 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.

[0036] The network entity from which the protected first message is received 200, such as the cSEPP 130, may be authenticated as part of, or prior to, the authorization procedure 220, e.g. in connection with block 210.

[0037] 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. Such 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. Another example is that GET operation may be the only HTTP operation allowed for a given API.

[0038] In a still further embodiment, the authorization procedure 220 comprises performing further security measures regarding the source of the protected first message, such as an integrity verification procedure

[0039] 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.

[0040] In some embodiments, 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.

[0041] In some embodiments, 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.

[0042] In some embodiments, 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, and the security edge node is a security edge protection proxy, such as the pSEPP 132. Some further example embodiments are herewith illustrated with references to the 3GPP 5G system entities. However, it will be appreciated that at least some of the presently disclosed features may be applied for arranging secure communications between mobile networks in other systems, such as 6G or other/further future generation PLMNs.

[0043] With reference to the example configuration of Figure 3, the proxy may be provided in 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.

[0044] With reference to another example configuration of Figure 4, the proxy node 160 is a SEPP located in a third PLMN 114. Such 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.

[0045] With reference to the example configuration of Figure 5, the pSEPP 132 may comprise the RAS and send the signed second message to the pNF 150 after block 230. In a still further embodiment, 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.

[0046] Figure 6 illustrates an example signalling scenario in a case for applying an aSEPP indirectly in the embodiment of Figure 4. In response to receiving 600 an API resource request from the cNF, 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.

[0047] The aSEPP processes 606 the received message by performing the blocks of Figure 2. In response to successful authorization procedure, the aSEPP sends signed API request 608 to the pSEPP, which forwards it 610 to the pNF. It is to be noted that in an alternative embodiment, 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.

[0048] 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.

[0049] 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).

[0050] By applying the RAS and above-illustrated features, 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.

[0051] The RAS, e.g. as a virtual NF frontend, may be assigned e.g. one or more of:

Operator (for hosting or outsourcing scenarios)

o In this scenario, the virtual NF frontend may be configured to provide AaS to all network functions within an operator. In other words, an operator has outsourced service access authorization to the virtual NF frontend.

- Network slice (for network slicing scenarios)

o In this scenario, the virtual NF frontend provides the AaS to specific slices within the operator network.

o Some slices (e.g. for public safety or military) may require a higher level of assurance based on geographical location.

Security zone (roaming class)

o In this scenario, the virtual NF frontend provides the AaS to a set of network functions within the security zone.

[0052] For example, 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.

[0053] In one deployment scenario example, 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. [0054] In some embodiments, service access authorization is based on access tokens of an authorization protocol, such as OAuth protocol, e.g. OAuth version 2.0. Thus, 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. As in the above deployment scenario, 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.

[0055] In some embodiments, 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. In an embodiment, 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). In another embodiment, if TLS is applied within the first network 112, the pSEPP 132 comprising the RAS may establish the TLS session for transmitting the authorized request.

[0056] However, it is to be appreciated that TLS is just one example of available transfer options for securing the transmission of the inter-PLMN messages. For example, there may be a virtual private network (VPN) connection, such as IPsec based connection, or even a dedicated line, from the network entity comprising the RAS to the first network or the first network, such as between the SEPP 160 and the pSEPP 132.

[0057] In some embodiments, trusted platform module (TPM) operations, enabling to assure platform integrity, 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.

[0058] In an embodiment, 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. [0059] 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. However, it is to be noted that TPM based authentication illustrated below may be applied for other inter-PLMN communication, even if the above-illustrated RAS related features are not implemented. For example, 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.

[0060] 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.

[0061] In an example embodiment, when two SEPPs, e.g. cSEPP and aSEPP want to set-up a secure tunnel among themselves (e.g. to set-up the RAS), the TPM and its keys may be applied to encrypt a secret, so that only the correct SEPP can decrypt the secret. For example, 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. Similarly, 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.

[0062] In an embodiment, when establishing a link between the RAS performing entity and the entity sending of the resource request, they can verify the integrity of each other’s platform (hardware, firmware and software) by requesting their integrity status from an attestation server.

[0063] 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. For example, there could be locaFglobal attestation servers maintained by an appropriate authority.

[0064] Such 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. Thus, 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.

[0065] 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). In an embodiment, 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.

[0066] As already indicated above, at least some of the above illustrated inter-PLMN RAS related features may be applied in systems applying network virtualization. Hence, network functions or nodes illustrated above may be shared between two physically separate devices forming one operational entity. In general, 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. For example, instances of the 5G network functions can be instantiated as virtual network functions (VNFs) in network function virtualization (NFV) architecture.

[0067] 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. In another embodiment, 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. [0068] 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 mobile phone or server, 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.” 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.

[0069] 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. [0070] Comprised in the device 800 is 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.

[0071] 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. For example, 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. Further, the memory may comprise device-specific cryptographic information, such as secret and public key of the device 800.

[0072] 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.

[0073] 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.

[0074] 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.

[0075] 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. Such 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. Alternatively to a serial bus, the transmitter may comprise a parallel bus transmitter. Fikewise 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. Alternatively to a serial bus, the receiver may comprise a parallel bus receiver.

[0076] 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.

[0077] 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. For example, 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. 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.

[0078] 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.

[0079] 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. 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. 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.

[0080] Various embodiments and examples 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.

[0081] 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.

[0082] 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. [0083] 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.

Claims

CLAIMS:

1. An apparatus comprising means for performing:

- 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.

2. The apparatus of claim 1, wherein a security edge node is configured to perform the resource authorization service and filter out a non-authorized request for the resource of the first network entity.

3. The apparatus of claim 2, wherein the security edge node is located in the first mobile network and is configured to send the signed second message to the first network entity.

4. The apparatus of claim 1 or 2, wherein a proxy is configured to perform the resource authorization service, intercept the first message being transferred between security edge nodes in the first mobile network and the second mobile network, perform resource authorization for the request, and send the signed second message to the security edge node in the second mobile network.

5. The apparatus of claim 4, wherein a security edge node located in a third mobile network comprises the proxy.

6. The apparatus of any preceding claim, wherein the request is an application programming interface call.

7. The apparatus of any preceding claim, wherein the authorization procedure comprises verifying if requested service operations 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.

8. The apparatus of any preceding claim, wherein the authorization procedure comprises determining service consumer type of the second network entity on the basis of the extracted first message and performing the verification on the basis of the determined service consumer type.

9. The apparatus of any preceding claim, wherein the authorization procedure comprises verifying integrity of a security edge node of the first mobile network.

10. The apparatus of any preceding claim, wherein the second message comprises an information element comprising result and/or further information of the authorization procedure.

11. The apparatus of any preceding claim, wherein the second message comprises a cryptographic signature of the request authorization service or a network node performing the request authorization service.

12. The apparatus of any preceding claim, wherein the authorization service is configured to perform the authorization procedure as an authorization as a service for all or a set of network functions of the second mobile network, for one or more network slices of the second mobile network, and one or more security zones of the second mobile network.

13. The apparatus of any preceding claim, wherein the protected first message and the signed second message are transport layer security protocol messages and the authorization service is configured to terminate a first transport layer security session from the second network entity and establish a second transport layer security session to the first network entity for sending the request to the first network entity.

14. The apparatus of any preceding claim, wherein the first network entity is a service- producing network function, the second network entity is a service-consuming network function, and the security edge node is a security edge protection proxy.

15. The apparatus of any preceding claim, wherein the means comprises at least one processor; and at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performance of the apparatus.

16. A method, comprising:

- extracting the first message,

17. The method of claim 16, wherein a security edge node performs the resource authorization service and filters out a non-authorized request for the resource of the first network entity.

18. The method of claim 17, wherein the security edge node is located in the first mobile network and sends the signed second message to the first network entity.

19. The method of claim 16 or 17, wherein a proxy performs the resource authorization service, intercepts the first message being transferred between security edge nodes in the first mobile network and the second mobile network, performs resource authorization for the request, and sends the signed second message to the security edge node in the second mobile network.

20. The method of claim 19, wherein a security edge node located in a third mobile network comprises the proxy.

21. The method of any preceding claim 16 to 20, wherein the request is an application programming interface call.

22. The method of any preceding claim 16 to 21, wherein the authorization procedure comprises verifying if requested service operations 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.

23. The method of any preceding claim 16 to 22, wherein the authorization procedure comprises determining service consumer type of the second network entity on the basis of the extracted first message and performing the verification on the basis of the determined service consumer type.

24. The method of any preceding claim 16 to 23, wherein the authorization procedure comprises verifying integrity of a security edge node of the first mobile network.

25. The method of any preceding claim 16 to 24, wherein the second message comprises an information element comprising result and/or further information of the authorization procedure.

26. The method of any preceding claim 16 to 25, wherein the second message comprises a cryptographic signature of the request authorization service or a network node performing the request authorization service.

27. The method of any preceding claim 16 to 26, wherein the authorization service is configured to perform the authorization procedure as an authorization as a service for all or a set of network functions of the second mobile network, for one or more network slices of the second mobile network, and one or more security zones of the second mobile network.

28. The method of any preceding claim 16 to 27, wherein the protected first message and the signed second message are a transport layer security protocol messages and the authorization service is configured to terminate a first transport layer security session from the second network entity and establish a second transport layer security session to the first network entity for sending the request to the first network entity.

29. The method of any preceding claim 16 to 28, wherein the first network entity is a service-producing network function, the second network entity is a service consuming network function, and the security edge node is a security edge protection proxy.

30. A computer program, comprising instructions for causing an apparatus to perform the method of any one of claims 16 to 29.

31. A non-transitory computer readable medium comprising program instructions for causing an apparatus to perform the method of any one of claims 16 to 29.