Method, apparatus and computer program for authentication of a service request

Abstract

An apparatus comprising: means for receiving a service request comprising a first token signed by a Network Function service consumer, wherein the apparatus and the Network Function service consumer are in a first network; means for validating the first token using a public key of the Network Function service consumer; means for generating a second token based on content in the validated first token; means for signing the second token using a private key of the apparatus and providing a public key of the apparatus in the signed second token; means for sending a second service request comprising the signed second token to a network entity in a second network, the second network comprising a Network Function provider for the service request.

Description

[0001] METHOD, APPARATUS AND COMPUTER PROGRAM FOR AUTHENTICATION OF A SERVICE REQUEST

[0002] TECHNICAL FIELD

[0003] Various example embodiments of this disclosure relate to a method, apparatus, and computer program for a communications network. Some examples relate to a method, apparatus, and computer program for authenticating a service request.

[0004] BACKGROUND

[0005] A communication network can be seen as a facility that enables communications between two or more communication devices, or provides communication devices access to a data network. A mobile or wireless communication network is one example of a communication network. A communication device may be provided with a service by an application server.

[0006] Such communication networks operate in according with standards such as those provided by 3GPP (Third Generation Partnership Project) or ETSI (European Telecommunications Standards Institute). Examples of standards are the so-called 4G (4thGeneration), 5G (5th Generation) standards provided by 3GPP.

[0007] SUMMARY

[0008] Some example embodiments of this disclosure will be described with respect to certain aspects. These aspects are not intended to indicate key or essential features of the embodiments of this disclosure, nor are they intended to be used to limit the scope of thereof. Other features, aspects, and elements will be readily apparent to a person skilled in the art in view of this disclosure.

[0009] An apparatus comprising: means for receiving a service request comprising a first token signed by a Network Function service consumer, wherein the apparatus and the Network Function service consumer are in a first network; means for validating the first token using a public key of the Network Function service consumer; means for generating a second token based on content in the validated first token; means for signing the second token using a private key of the apparatus and providing a public key of the apparatus in the signed second token; means for sending a second service request comprising the signed second token to a network entity in a second network, the second network comprising a Network Function provider for the service request. According to some examples, the apparatus comprises a Security Edge Protection Proxy, SEPP or a Service Communication Proxy, SCP.

[0010] According to some examples, the network entity in the second network comprises a Security Edge Protection Proxy, SEPP or a Service Communication Proxy, SCP.

[0011] According to some examples, the token signed by the Network Function service consumer comprises at least one of: a Network Function instance identifier of the Network Function service consumer; a timestamp; an expiration time; a Network Function type of the expected target of the service request.

[0012] According to some examples, the signed second token comprises at least one of: a Network Function instance identifier of the Network Function service consumer; a timestamp; an expiration time; a Network Function type of the expected target of the service request; a Network Function type of the Network Function service consumer; an instance identifier of the apparatus.

[0013] According to some examples, the first network is a visited Public Land Mobile Network or a Non-Public Network, and wherein the second network comprises a home Public Land Mobile Network or Non-Public Network.

[0014] According to some examples, the network entity in the second network is configured to: validate the signed second token using the public key of the apparatus; and then generate a third token based on content in the signed second token; and sign the third token using a private key of the network entity and provide a public key of the network entity in the signed third token; send a third service request comprising the signed third token to the Network Function provider.

[0015] According to some examples, the Network Function provider is configured to: authenticate the third service request for the Network Function service consumer by validating the signed third token using the public key of the network entity in the second network; and in response to authenticating the third service request, provide a service to the Network Function service consumer. According to some examples, the third service request comprises the first token, the second signed token and the third signed token.

[0016] According to some examples, at least one of the first token, the second signed token and the third signed token comprise Client Credentials Assertion, CCA.

[0017] According to some examples, the first token is provided in a custom http header of the service request; the second signed token is provided in a custom http header of the second service request; and / or the third signed token is provided in a custom http header of the third service request.

[0018] According to an aspect, there is provided an apparatus comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform: receiving a service request comprising a first token signed by a Network Function service consumer, wherein the Network Function service consumer is in a first network; validating the first token using a public key of the Network Function service consumer; generating a second token based on content in the validated first token; signing the second token using a private key of an apparatus and providing a public key of the apparatus in the signed second token; sending a second service request comprising the signed second token to a network entity in a second network, the second network comprising a Network Function provider for the service request.

[0019] According to some examples, the apparatus comprises a Security Edge Protection Proxy, SEPP or a Service Communication Proxy, SCP.

[0020] According to some examples, the network entity in the second network comprises a Security Edge Protection Proxy, SEPP or a Service Communication Proxy, SCP.

[0021] According to some examples, the token signed by the Network Function service consumer comprises at least one of: a Network Function instance identifier of the Network Function service consumer; a timestamp; an expiration time; a Network Function type of the expected target of the service request.

[0022] According to some examples, the signed second token comprises at least one of: a Network Function instance identifier of the Network Function service consumer; a timestamp; an expiration time; a Network Function type of the expected target of the service request; a Network Function type of the Network Function service consumer; an instance identifier of the apparatus.

[0023] According to some examples, the first network is a visited Public Land Mobile Network or a Non-Public Network, and wherein the second network comprises a home Public Land Mobile Network or Non-Public Network.

[0024] According to some examples, the network entity in the second network is configured to: validate the signed second token using the public key of the apparatus; and then generate a third token based on content in the signed second token; and sign the third token using a private key of the network entity and provide a public key of the network entity in the signed third token; send a third service request comprising the signed third token to the Network Function provider.

[0025] According to some examples, the Network Function provider is configured to: authenticate the third service request for the Network Function service consumer by validating the signed third token using the public key of the network entity in the second network; and in response to authenticating the third service request, provide a service to the Network Function service consumer.

[0026] According to some examples, the third service request comprises the first token, the second signed token and the third signed token.

[0027] According to some examples, at least one of the first token, the second signed token and the third signed token comprise Client Credentials Assertion, CCA.

[0028] According to some examples, the first token is provided in a custom http header of the service request; the second signed token is provided in a custom http header of the second service request; and / or the third signed token is provided in a custom http header of the third service request.

[0029] According to an aspect, there is provided a method comprising: receiving a service request comprising a first token signed by a Network Function service consumer, wherein the Network Function service consumer is in a first network; validating the first token using a public key of the Network Function service consumer; generating a second token based on content in the validated first token; signing the second token using a private key of an apparatus and providing a public key of the apparatus in the signed second token; sending a second service request comprising the signed second token to a network entity in a second network, the second network comprising a Network Function provider for the service request.

[0030] According to some examples, the method is performed by a Security Edge Protection Proxy, SEPP or a Service Communication Proxy, SCP.

[0031] According to some examples, the network entity in the second network comprises a Security Edge Protection Proxy, SEPP or a Service Communication Proxy, SCP.

[0032] According to some examples, the token signed by the Network Function service consumer comprises at least one of: a Network Function instance identifier of the Network Function service consumer; a timestamp; an expiration time; a Network Function type of the expected target of the service request.

[0033] According to some examples, the signed second token comprises at least one of: a Network Function instance identifier of the Network Function service consumer; a timestamp; an expiration time; a Network Function type of the expected target of the service request; a Network Function type of the Network Function service consumer; an instance identifier of the apparatus.

[0034] According to some examples, the first network is a visited Public Land Mobile Network or a Non-Public Network, and wherein the second network comprises a home Public Land Mobile Network or Non-Public Network.

[0035] According to some examples, the network entity in the second network is configured to: validate the signed second token using the public key of the apparatus; and then generate a third token based on content in the signed second token; and sign the third token using a private key of the network entity and provide a public key of the network entity in the signed third token; send a third service request comprising the signed third token to the Network Function provider.

[0036] According to some examples, the Network Function provider is configured to: authenticate the third service request for the Network Function service consumer by validating the signed third token using the public key of the network entity in the second network; and in response to authenticating the third service request, provide a service to the Network Function service consumer. According to some examples, the third service request comprises the first token, the second signed token and the third signed token.

[0037] According to some examples, at least one of the first token, the second signed token and the third signed token comprise Client Credentials Assertion, CCA.

[0038] According to some examples, the first token is provided in a custom http header of the service request; the second signed token is provided in a custom http header of the second service request; and / or the third signed token is provided in a custom http header of the third service request.

[0039] According to an aspect, there is provided a computer program comprising instructions stored thereon for performing at least the following: receiving a service request comprising a first token signed by a Network Function service consumer, wherein the Network Function service consumer is in a first network; validating the first token using a public key of the Network Function service consumer; generating a second token based on content in the validated first token; signing the second token using a private key of an apparatus and providing a public key of the apparatus in the signed second token; sending a second service request comprising the signed second token to a network entity in a second network, the second network comprising a Network Function provider for the service request.

[0040] According to an aspect, there is provided an apparatus comprising: means for receiving a second service request from a network entity in a first network, the second service request comprising a second token signed by the network entity in the first network, wherein the second token is generated based on content in a first token signed by a Network Function consumer in the first network and included in a first service request from the Network Function consumer in the first network; means for validating the signed second token using the public key of the network entity in the first network; means for generating a third token based on content in the signed second token; means for signing the third token using a private key of the apparatus; means for providing a public key of the apparatus in the signed third token; means for sending a third service request comprising the signed third token to the Network Function provider, wherein the apparatus and the Network Function provider are in a second network.

[0041] According to some examples, the Network Function provider is configured to: authenticate the third service request for the Network Function service consumer by validating the signed third token using the public key of the apparatus; and in response to authenticating the third service request, provide a service to the Network Function service consumer.

[0042] According to some examples, the apparatus comprises a Security Edge Protection Proxy, SEPP or a Service Communication Proxy, SCP.

[0043] According to some examples, the network entity in the first network comprises a Security Edge Protection Proxy, SEPP or a Service Communication Proxy, SCP.

[0044] According to some examples, the token signed by the Network Function service consumer comprises at least one of: a Network Function instance identifier of the Network Function service consumer; a timestamp; an expiration time; a Network Function type of the expected target of the service request.

[0045] According to some examples, the signed second token comprises at least one of: a Network Function instance identifier of the Network Function service consumer; a timestamp; an expiration time; a Network Function type of the expected target of the service request; a Network Function type of the Network Function service consumer; an instance identifier of the apparatus.

[0046] According to some examples, the first network is a virtual Public Land Mobile Network or a Non-Public Network, and wherein the second network comprises a home Public Land Mobile Network.

[0047] According to some examples, the third service request comprises the first token, the second signed token and the third signed token.

[0048] According to some examples, at least one of the first token, the second signed token and the third signed token comprise Client Credentials Assertion, CCA.

[0049] According to some examples, the first token is provided in a custom http header of the service request; the second signed token is provided in a custom http header of the second service request; and / or the third signed token is provided in a custom http header of the third service request. According to an aspect, there is provided an apparatus comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform: receiving a second service request from a network entity in a first network, the second service request comprising a second token signed by the network entity in the first network, wherein the second token is generated based on content in a first token signed by a Network Function consumer in the first network and included in a first service request from the Network Function consumer in the first network; validating the signed second token using the public key of the network entity in the first network; generating a third token based on content in the signed second token; signing the third token using a private key of an apparatus; providing a public key of the apparatus in the signed third token; sending a third service request comprising the signed third token to the Network Function provider, wherein the apparatus and the Network Function provider are in a second network.

[0050] According to some examples, the Network Function provider is configured to: authenticate the third service request for the Network Function service consumer by validating the signed third token using the public key of the apparatus; and in response to authenticating the third service request, provide a service to the Network Function service consumer.

[0051] According to some examples, the apparatus comprises a Security Edge Protection Proxy, SEPP or a Service Communication Proxy, SCP.

[0052] According to some examples, the network entity in the first network comprises a Security Edge Protection Proxy, SEPP or a Service Communication Proxy, SCP.

[0053] According to some examples, the token signed by the Network Function service consumer comprises at least one of: a Network Function instance identifier of the Network Function service consumer; a timestamp; an expiration time; a Network Function type of the expected target of the service request.

[0054] According to some examples, the signed second token comprises at least one of: a Network Function instance identifier of the Network Function service consumer; a timestamp; an expiration time; a Network Function type of the expected target of the service request; a Network Function type of the Network Function service consumer; an instance identifier of the apparatus. According to some examples, the first network is a virtual Public Land Mobile Network or a Non-Public Network, and wherein the second network comprises a home Public Land Mobile Network.

[0055] According to some examples, the third service request comprises the first token, the second signed token and the third signed token.

[0056] According to some examples, at least one of the first token, the second signed token and the third signed token comprise Client Credentials Assertion, CCA.

[0057] According to some examples, the first token is provided in a custom http header of the service request; the second signed token is provided in a custom http header of the second service request; and / or the third signed token is provided in a custom http header of the third service request.

[0058] According to an aspect there is provided a method comprising: receiving a second service request from a network entity in a first network, the second service request comprising a second token signed by the network entity in the first network, wherein the second token is generated based on content in a first token signed by a Network Function consumer in the first network and included in a first service request from the Network Function consumer in the first network; validating the signed second token using the public key of the network entity in the first network; generating a third token based on content in the signed second token; signing the third token using a private key of an apparatus; providing a public key of the apparatus in the signed third token; sending a third service request comprising the signed third token to the Network Function provider, wherein the apparatus and the Network Function provider are in a second network.

[0059] According to some examples, the Network Function provider is configured to: authenticate the third service request for the Network Function service consumer by validating the signed third token using the public key of the apparatus; and in response to authenticating the third service request, provide a service to the Network Function service consumer.

[0060] According to some examples, the method is performed by a Security Edge Protection Proxy, SEPP or a Service Communication Proxy, SCP.

[0061] According to some examples, the network entity in the first network comprises a Security Edge Protection Proxy, SEPP or a Service Communication Proxy, SCP. According to some examples, the token signed by the Network Function service consumer comprises at least one of: a Network Function instance identifier of the Network Function service consumer; a timestamp; an expiration time; a Network Function type of the expected target of the service request.

[0062] According to some examples, the signed second token comprises at least one of: a Network Function instance identifier of the Network Function service consumer; a timestamp; an expiration time; a Network Function type of the expected target of the service request; a Network Function type of the Network Function service consumer; an instance identifier of the apparatus.

[0063] According to some examples, the first network is a virtual Public Land Mobile Network or a Non-Public Network, and wherein the second network comprises a home Public Land Mobile Network.

[0064] According to some examples, the third service request comprises the first token, the second signed token and the third signed token.

[0065] According to some examples, at least one of the first token, the second signed token and the third signed token comprise Client Credentials Assertion, CCA.

[0066] According to some examples, the first token is provided in a custom http header of the service request; the second signed token is provided in a custom http header of the second service request; and / or the third signed token is provided in a custom http header of the third service request.

[0067] According to an aspect, there is provided a computer program comprising instructions stored thereon for performing at least the following: receiving a second service request from a network entity in a first network, the second service request comprising a second token signed by the network entity in the first network, wherein the second token is generated based on content in a first token signed by a Network Function consumer in the first network and included in a first service request from the Network Function consumer in the first network; validating the signed second token using the public key of the network entity in the first network; generating a third token based on content in the signed second token; signing the third token using a private key of an apparatus; providing a public key of the apparatus in the signed third token; sending a third service request comprising the signed third token to the Network Function provider, wherein the apparatus and the Network Function provider are in a second network.

[0068] According to an aspect, there is provided a non-transitory computer readable medium comprising program instructions that, when executed by an apparatus, cause the apparatus to perform at least the method according to any of the preceding aspects.

[0069] In the above, many different embodiments have been described. It should be appreciated that further embodiments may be provided by the combination of any two or more of the embodiments described above.

[0070] DESCRIPTION OF FIGURES

[0071] Some example embodiments will now be described, by way of non-limiting and illustrative example only, with reference to the accompanying Figures in which:

[0072] FIG. 1 shows a representation of a communication network comprising a 5thgeneration communication network;

[0073] FIG. 2 shows an example method flow;

[0074] FIG. 3 shows an example method performed by a first network entity;

[0075] FIG. 4 shows an example method performed by a second network entity;

[0076] FIG. 5 shows a representation of an apparatus for the communication system of FIG. 1 according to some example embodiments;

[0077] FIG. 6 shows a representation of an apparatus according to some example embodiments; and FIG. 7 shows a schematic representation of a non-volatile memory medium storing instructions which when executed by a processor allow a processor to perform one or more of the steps of the methods disclosed herein.

[0078] DETAILED DESCRIPTION

[0079] A token signed by a network entity (e.g., a Network Function (NF), Security Edge Protection Proxy (SEPP), Service Communication Proxy (SCP)) can be used by the signing network entity to authenticate itself. An example of such a token is a JavaScript Object Notation (JSON) Web Token (JWT).

[0080] 3GPP TS 33.501 describes an example JWT, the Client Credentials Assertion (CCA), that can be used by a network entity to authenticate towards a receiving end point (e.g., Network Repository Function, NRF, Network Function service provider, NFp), by including the signed token in a service request. A CCA may include the includes the NF Service Consumer’s NF Instance ID that can be checked against the certificate by the NF Service Producer. The CCA may include at least one of the following:

[0081] • the NF instance ID of the NF Service Consumer (subject);

[0082] • a timestamp (iat) and an expiration time (exp), and

[0083] • an NF type of the expected audience (audience), i.e. the type "NRF" and / or the NF type of the NF Service Producer.

[0084] A CCA can be used in indirect communication scenarios, where there is no end to end (i.e., NF consumer (NFc) to NFp mutual Transport Layer Security (TLS) authentication, but the mutual authentication is performed between the NFs and Security Communication Proxy (SCP) as TLS proxy (intermediary).

[0085] In the case of inter Public Land Mobile Network (PLMN) communication, since there is a lack of global root Certification Authority (CA) operating across multiple operators, a CCA signed by NFc present in a visited PLMN (vPLMN), cannot be verified by the NRF or NFp present in the home PLMN, hPLMN, unless cross-certification process is established between the two PLMNs. Cross-certification can be a complex process to run between different operator entities, and therefore is often not activated in real deployments. Operators typically use different CAs for the certificates used in internal Service-Based Interface (SBI) communication and for the ones used in external Security Edge Protection Proxy (SEPP) interfaces for the communication with other roaming partners or IP exchange (IPX). Configuring trust anchors among all interconnected operators is also problematic from an operational viewpoint.

[0086] Without the verification, the entities providing the service request to a particular NFc in a different PLMN cannot verify the authenticity of that NFc, leading to a lack of trust.

[0087] Some examples described herein provide a mechanism for providing trust between an entity providing an inter-PLMN service request to an NFc without the complexity of implementing cross-certification.

[0088] Some examples provide a first network entity (e.g., a SEPP or SCP) in a first network (e.g., vPLMN or a Non-Public Network (NPN)) that can validate a first token (e.g., a CCA certificate: “CCA1”) used to verify the authenticity of a digital signature (e.g., JWS and / or a CCA digital signature) of a NFp. A first network entity in the first network may then include a new, second token (e.g., a new CCA certificate: “CCA2”) signed by the first network entity in the service request. The second token may be a new token comprising the same original token information from the first token but with a new digital signature (e.g., JWS) created with the private key of the first network entity. The second token can be verified by a second network entity (e.g., a SEPP or SCP) in a second network (e.g., hPLMN or an NPN) that has a trust relationship with the first network entity in the first network. For example, a consumer SEPP (cSEPP) in the first network would have a previous trust relationship with a producer SEPP (pSEPP) in the second network to establish an N32 interface. After validation of a second token, the second network entity creates a new, third token (e.g., a new CCA certificate: “CCA3”) comprising the same content as the first token and the second token, but signed with the private key of the second network entity. The second network entity may include its own instance identifier in the third token. An NFp within the same operator domain as the second network entity can validate the third token and consequently the original content of the first token and the second token, therefore authenticating the NFc from which the initial first token was sent from (e.g., in a message such as a service request).

[0089] In some examples, all 3 tokens may be sent to the NFp from the second network entity. In other examples, only the third token is sent to the NFp from the second network entity.

[0090] In some examples, at least one of the first token, the second token and the third token may be included in a custom http header of a service request.

[0091] In some examples, a similar mechanism is provided for tokens originating from an NFp sent towards an NFc.

[0092] In the following various example embodiments are explained with reference to communication devices (e.g., UEs) that are capable of communication with a communications network. Before explaining in detail the embodiments of the methods and apparatuses of the present disclosure, a communications network comprising a 5thgeneration communication system (5GS), a radio access network and a core network (5GC) thereof, are briefly explained with reference to FIG. 1.

[0093] FIG. 1 shows a schematic representation of a communications network comprising a cellular or mobile communication system (e.g., a 5G communication system (5GS), and data network. The 5GS may comprise a radio access network such as a 5G radio access network (5G-RAN) or next generation radio access network (NG-RAN), a 5G core network (5GC). An application function may be deployed in the 5GS as trusted application function or may be deployed or hosted on one or more application servers of the data network. Such application functions are untrusted application functions. The 5GS connects a UE to a data network via the access network and the 5GC (e.g., a II PF of the 5GC).

[0094] The 5GC may comprise the following network functions: Network Slice Selection Function (NSSF); Network Exposure Function; Network Repository Function (NRF); Policy Control Function (PCF); UDM; Application Function (AF); Authentication Server Function (ALISF); an AMF; and Session Management Function (SMF), and a user plane function (UPF). FIG. 1 also shows the various interfaces (N1 , N2 etc.) that may be implemented between the various elements of the system.

[0095] FIG. 2 shows an example message flow between an NF service consumer 202 (NFc), an intermediary NF 204 (e.g., an NRF), a first network entity 206 (e.g., cSEPP, SCP), a second network entity 208 (e.g., pSEPP, SCP) and a destination NF 210 (e.g., an NRF or NFp).

[0096] NFc 202, intermediary NF 204 and first network entity 206 are in a first network. The first network may comprise a vPLMN or an NPN. A second network entity 208 and a destination NF 210 are in a second network. The second network may comprise a hPLMN or NPN.

[0097] At 201 , NFc 202 may register with intermediary NF 204.

[0098] At 203, NFc 202 sends a service request towards destination NF (e.g., NRF or NFp) in the second network. The request is sent via intermediary NF 204. The request may comprise a first token generated by NFc 202. The first token is signed by NFc 202 using the private key of NFc 202, such that the public key of NFc 202 is included in the signature of the signed first token or is included in the first token (e.g., as part of a CCA). The first token may comprise a CCA. According to some examples, the first token may comprise at least one of the following:

[0099] • the NF instance ID of the NFc 202 (subject);

[0100] • a timestamp (iat) and an expiration time (exp) for the validity of the first token; and

[0101] • an NF type of the expected audience (audience), i.e. the type "NRF" and / or the NF type of NFp 210.

[0102] At 205, intermediary NF 204 authenticates the first token and validates NFc 202 based on a public key of NFc 202 (e.g., a CCA “CCA1”) in the first token. At 207, intermediary NF 204 sends the service request including the first token signed by NFc 202 to first network entity 206. At 209, the first network entity 206 validates the contents of the first token using the public key of NFc 202 in the signed first token (e.g., in the x5u or x5c fields of a CCA). This may comprise performing at least one of:

[0103] • Validating the signature (e.g., of NFc 202) of the signed first token (for example using the method for JWS described in Internet Engineering Task Force (IETF), RFC 7515 for JWS;

[0104] • Checking that the NF instance ID of NFc 202 in the first token corresponds to the NF instance ID in the public key certificate used for signing the first token;

[0105] • Validating the timestamp (iat) and / or the expiration time of the first token (this can be performed, for example, as specified in Internet Engineering Task Force (IETF), RFC 7519);

[0106] • Verifying the NF type of the expected audience for the destination NF 210 of the first token by checking that the type indicated in the first token is correct (e.g., checking if the type is NRF and / or checking the NF type of the NFp).

[0107] After successful validation, first network entity 206 generates a new, second token based on the content of the first token. The second token may comprise the contents of the first token and additional information from the first network entity 206. For example, the second token may comprise at least one of:

[0108] • the NF instance ID of NFc 202 (subject);

[0109] • a timestamp (iat) and an expiration time (exp) for the validity of the second token;

[0110] • an NF type of the expected audience (audience), i.e. the type "NRF" and / or the NF type of NFp 210;

[0111] • the NF type of NFc 202;

[0112] • the Instance ID of the first network entity 206.

[0113] The first network entity 206 may then sign the second token using its own private key. The public key of first network entity 206 is then included in the signed second token (either in the signature or in the second token) for verification of the second token. At 211 , first network entity 206 then forwards the service request along with the signed second token to second network entity 208 in the second network. According to some examples, the signed second token may be included in a custom http header of the service request.

[0114] At 213, second network entity 208 validates the signed second token using a public key of first network entity 206. This may comprise at least one of:

[0115] • Validating the signature (e.g., of network entity 206) of the signed second token (for example using the method for JWS described in Internet Engineering Task Force (IETF), RFC 7515 for JWS;

[0116] • Checking that the instance ID of first network entity 206 in the second token corresponds to the instance ID in the public key certificate used for signing the second token;

[0117] • Validating the timestamp (iat) and / or the expiration time of the second token (this can be performed, for example, as specified in Internet Engineering Task Force (IETF), RFC 7519);

[0118] • Verifying the NF type of the expected audience for the destination NF 210 of the second token by checking that the type indicated in the second token is correct (e.g., checking if the type is NRF and / or checking the NF type of the NFp).

[0119] After successful validation, second network entity 208 generates a new, third token based on the content of the second token. The third token may comprise the contents of the second token and additional information from the second network entity 208. For example, the second token may comprise at least one of:

[0120] • the NF instance ID of NFc 202 (subject);

[0121] • a timestamp (iat) and an expiration time (exp) for the validity of the third token;

[0122] • an NF type of the expected audience (audience), i.e. the type "NRF" and / or the NF type of NFp 210;

[0123] • the NF type of NFc 202;

[0124] • the Instance ID of the second network entity 208.

[0125] The second network entity 208 may then sign the second token using its own private key. The public key of second network entity 208 is then included in the signed third token (either in the signature or in the second token) for verification of the third token. At 215, second network entity 208 forwards the service request along with the signed third token to destination NF 210 in the second network. According to some examples, the signed third token may be included in a custom http header of the service request.

[0126] At 217, destination NF 210 verifies the signed third token using a public key of second network entity 208. This may comprise at least one of:

[0127] • Validating the signature (e.g., of network entity 208) of the signed third token (for example using the method for JWS described in Internet Engineering Task Force (IETF), RFC 7515 for JWS;

[0128] • Checking that the instance ID of the second network entity 208 in the second token corresponds to the instance ID in the public key certificate used for signing the second token;

[0129] • Validating the timestamp (iat) and / or the expiration time of the third token (this can be performed, for example, as specified in Internet Engineering Task Force (IETF), RFC 7519);

[0130] • Verifying the NF type of the expected audience for the destination NF 210 of the third token by checking that the type indicated in the third token is correct (e.g., checking if the type is NRF and / or checking the NF type of the NFp).

[0131] Upon successful verification of the signed third token, destination NF 210 authenticates NFc 202 and sends a response accordingly (e.g., sends an acknowledgement or begins providing the requested service to NFc 202). If verification is not successful, an error message is returned to NFc.

[0132] FIG. 3 shows an example method flow. The method may be performed by an apparatus, such as network entity 206, for example. The method may be performed by a cSEPP or an SCP, for example.

[0133] At 300, the method comprises a service request comprising a first token signed by a Network Function service consumer, wherein the Network Function service consumer is in a first network. The first token may comprise a CCA.

[0134] At 302, the method comprises validating the first token using a public key of the Network Function service consumer. At 304, the method comprises generating a second token based on content in the validated first token. The second token may comprise a CCA.

[0135] At 306, the method comprises signing the second token using a private key of an apparatus and providing a public key of the apparatus in the signed second token

[0136] At 308, the method comprises sending a second service request comprising the signed second token to a network entity in a second network, the second network comprising a Network Function provider for the service request.

[0137] FIG. 4 shows an example method flow. The method may be performed by an apparatus, such as network entity 206, for example. The method may be performed by a pSEPP or an SCP, for example.

[0138] At 400, the method comprises receiving a second service request from a network entity in a first network, the second service request comprising a second token signed by the network entity in the first network, wherein the second token is generated based on content in a first token signed by a Network Function consumer in the first network and included in a first service request from the Network Function consumer in the first network. The second token may comprise a CCA. The first token may comprise a CCA.

[0139] At 402, the method comprises validating the signed second token using the public key of the network entity in the first network.

[0140] At 404, the method comprises generating a third token based on content in the signed second token.

[0141] At 406, the method comprises signing the third token using a private key of an apparatus.

[0142] At 408, the method comprises providing a public key of the apparatus in the signed third token.

[0143] At 410, the method comprises sending a third service request comprising the signed third token to the Network Function provider, wherein the apparatus and the Network Function provider are in a second network.

[0144] FIG. 5 illustrates an example of an apparatus 500 implementing or comprising at least the session management of the core network of the communication network illustrated on FIG. 1. The apparatus 500 may comprise at least one random access memory (RAM) 511a, at least on read only memory (ROM) 511 b, at least one processor 512, 513 and a network interface 514. The at least one processor 512, 513 may be coupled to the RAM 511a and the ROM 511 b. The at least one processor 512, 513 may be configured to execute an appropriate software code 515 of the network entities described herein. Execution of the software code 515 of the network entities described herein (or execution of instructions of the software code 515 of the network entities described herein) may for example may cause the apparatus to perform method shown in FIG. 3 or 4. The software code 515 may be stored in the ROM 511 b. The apparatus 500 may be interconnected with another apparatus 500 for controlling other network functions of 5GC. In some embodiments, one or more network functions of the 5GC is deployed or hosted on an apparatus 500. In alternative embodiments, the apparatus may include software code of additional network functions of the core network of the communication network. The apparatus 500 may comprise a computing device (e.g., a server), a computing system, such as a distributed computing system, or a virtual machine provided by a cloud computing system. In some examples, the apparatus 500 may comprise a cloud computing system (e.g., a cloud core network) that comprises the session management function, and other network functions of the core network shown in FIG. 1.

[0145] FIG. 6 illustrates an example of a communication device 600, such as the terminal illustrated on FIG. 1 . The communication device 600 may be provided by any device capable of sending and receiving radio signals. Non-limiting examples of a communication device 600 comprise a user equipment, a mobile station (MS) or mobile device such as a mobile phone or what is known as a ’smart phone’, a computer provided with a wireless interface card or other wireless interface facility (e.g., USB dongle), a personal data assistant (PDA) or a tablet provided with wireless communication capabilities, a machine-type communications (MTC) device, an Internet of things (loT) type communication device or any combinations of these or the like. The communication device 600 may comprise a transceiver for transmitting and / or receiving, for example, wireless signals carrying communications, for example radio signals. The communications may be one or more of voice, electronic mail (email), text messages, multimedia data, machine data and so on.

[0146] The communication device 600 may receive wireless signals (e.g., radio signals) over an air or radio interface 607 via appropriate apparatus for receiving and may transmit wireless signals via appropriate apparatus for transmitting radio signals. In FIG. 6 transceiver is designated schematically by block 606. The transceiver 606 may comprise, for example, a radio part and associated antenna arrangement. The antenna arrangement may be arranged internally or externally to the mobile device and may comprise one or more antenna elements. The antenna arrangement may be a multi-input multi output (MIMO) antenna.

[0147] The communication device 600 may be provided with at least one processor 601 , at least one memory ROM 602a, at least one RAM 602b and other possible components 603 for use in software and hardware aided execution of tasks it is configured to perform, including control of access to and communications with radio access networks (e.g., the 5G-RAN or NG-RAN illustrated in FIG. 1) and other communication devices. The at least one processor 601 is coupled to the RAM 602b and the ROM 602a. The at least one processor 601 may be configured to execute an appropriate software code 608 (e.g., the at least one processor may execute instructions of the software code 608). The execution of the software code 608 may for example allow the communication device to perform one or more operations, including the operations described herein. The software code 608 may be stored in the ROM 602a.

[0148] The processor, the ROM, and the RAM, the transceiver and other circuitry of the communication device (e.g., a modem) can be provided on a circuit board, in chipsets, or in a system on chip. The circuit board, chipsets or system on chip is denoted by reference 704. The communication device 700 may optionally have a user interface such as key pad 705, touch sensitive screen or pad, combinations thereof or the like. Optionally one or more of a display, a speaker and a microphone may be provided depending on the type of communication device.

[0149] FIG. 7 shows a schematic representation of non-volatile memory media 700a (e.g. computer disc (CD) or digital versatile disc (DVD)) and 700b (e.g. universal serial bus (USB) memory stick) storing instructions and / or parameters 702 which when executed by a processor allow the processor to perform one or more of the steps of any method flow described herein.

[0150] It is understood that references in the above to various network functions (e.g., to an AMF, an AF, a PCF etc.) may comprise apparatus that perform at least some of the functionality associated with those network functions. Further, an apparatus comprising a network function may comprise a virtual network function instance of that network function.

[0151] It should be understood that the apparatuses may comprise or be coupled to other units or modules etc., such as radio parts or radio heads, used in or for transmission and / or reception. Although the apparatuses have been described as one entity, different modules and memory may be implemented in one or more physical or logical entities. It is noted that whilst some embodiments have been described in relation to 5G networks, similar principles can be applied in relation to other networks and communication systems. Therefore, although certain embodiments were described above by way of example with reference to certain example architectures for wireless networks, technologies and standards, embodiments may be applied to any other suitable forms of communication systems than those illustrated and described herein.

[0152] It is also noted herein that while the above describes example embodiments, there are several variations and modifications which may be made to the disclosed solution without departing from the scope of the present invention.

[0153] As used herein, “at least one of the following: ” and “at least one of ” and similar wording, where the list of two or more elements are joined by “and” or “or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0154] In general, the various embodiments may be implemented in hardware or special purpose circuitry, software, logic or any combination thereof. Some aspects of the disclosure may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the disclosure is not limited thereto. While various aspects of the disclosure may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0155] As used herein, the term “circuitry” may refer to one or more or all of the following:

[0156] (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry) and

[0157] (b) combinations of hardware circuits and software, such as (as applicable):

[0158] (i) a combination of analog and / or digital hardware circuit(s) with software / firmware and

[0159] (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.”

[0160] This definition of circuitry applies to all uses of the term “means” herein, including in any claims. As a further example, as used herein, 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.

[0161] The embodiments of this disclosure may be implemented by computer software executable by a data processor of the mobile device, such as in the processor entity, or by hardware, or by a combination of software and hardware. Computer software or program, also called program product, including software routines, applets and / or macros, may be stored in any apparatus-readable data storage medium and they comprise program instructions to perform particular tasks. A computer program product may comprise one or more computerexecutable components which, when the program is run, are configured to carry out embodiments. The one or more computer-executable components may be at least one software code or portions of it.

[0162] Further in this regard it should be noted that any blocks of the logic flow as in the Figures may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on such physical media as memory chips, or memory blocks implemented within the processor, magnetic media such as hard disk or floppy disks, and optical media such as for example DVD and the data variants thereof, CD. The physical media is a non-transitory media.

[0163] The term “non-transitory,” as used herein, is a limitation of the medium itself (i.e. , tangible, not a signal ) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM).

[0164] The memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The data processors may be of any type suitable to the local technical environment, and may comprise one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASIC), FPGA, gate level circuits and processors based on multi core processor architecture, as non-limiting examples.

[0165] Various example embodiments of the disclosure may be practiced in various components such as integrated circuit modules. The design of integrated circuits is by and large a highly automated process. Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

[0166] The scope of protection sought for various example embodiments of the disclosure is set out by the independent claims. The example embodiments and features thereof, if any, described in this disclosure that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various example embodiments of the disclosure.

[0167] The foregoing description has provided, by way of non-limiting and illustrative examples, a full and informative description of the various example embodiments of this disclosure. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the claims. However, all such and similar modifications of the teachings will still fall within the various example embodiments of the disclosure as set forth in the claims. By way of non-limiting and illustrative example, there is a further example embodiment comprising a combination of one or more example embodiments with any of the other example embodiments previously discussed.

Claims

Claims:

1. An apparatus comprising: means for receiving a service request comprising a first token signed by a Network Function service consumer, wherein the apparatus and the Network Function service consumer are in a first network; means for validating the first token using a public key of the Network Function service consumer; means for generating a second token based on content in the validated first token; means for signing the second token using a private key of the apparatus and providing a public key of the apparatus in the signed second token; means for sending a second service request comprising the signed second token to a network entity in a second network, the second network comprising a Network Function provider for the service request.

2. The apparatus according to claim 1 , wherein the apparatus comprises a Security Edge Protection Proxy, SEPP or a Service Communication Proxy, SCP.

3. The apparatus according to claim 1 or claim 2, wherein the network entity in the second network comprises a Security Edge Protection Proxy, SEPP or a Service Communication Proxy, SCP.

4. The apparatus according to any preceding claim, wherein the token signed by the Network Function service consumer comprises at least one of: a Network Function instance identifier of the Network Function service consumer; a timestamp; an expiration time; a Network Function type of the expected target of the service request.

5. The apparatus according to any preceding claim, wherein the signed second token comprises at least one of: a Network Function instance identifier of the Network Function service consumer; a timestamp; an expiration time; a Network Function type of the expected target of the service request; a Network Function type of the Network Function service consumer; an instance identifier of the apparatus.

6. The apparatus according to any preceding claim, wherein the first network is a visited Public Land Mobile Network or a Non-Public Network, and wherein the second network comprises a home Public Land Mobile Network or Non-Public Network.

7. The apparatus according to any preceding claim, wherein the network entity in the second network is configured to: validate the signed second token using the public key of the apparatus; and then generate a third token based on content in the signed second token; and sign the third token using a private key of the network entity and provide a public key of the network entity in the signed third token; send a third service request comprising the signed third token to the Network Function provider.

8. The apparatus according to claim 7, wherein the Network Function provider is configured to: authenticate the third service request for the Network Function service consumer by validating the signed third token using the public key of the network entity in the second network; and in response to authenticating the third service request, provide a service to the Network Function service consumer.

9. The apparatus according to claim 7 or claim 8, wherein the third service request comprises the first token, the second signed token and the third signed token.

10. The apparatus according to any of claims 7 to 9, wherein at least one of the first token, the second signed token and the third signed token comprise Client Credentials Assertion, CCA.11 . The apparatus according to any of claims 7 to 10, wherein: the first token is provided in a custom http header of the service request; the second signed token is provided in a custom http header of the second service request; and / or the third signed token is provided in a custom http header of the third service request.

12. A method comprising: receiving a service request comprising a first token signed by a Network Function service consumer, wherein the Network Function service consumer is in a first network; validating the first token using a public key of the Network Function service consumer; generating a second token based on content in the validated first token; signing the second token using a private key of an apparatus and providing a public key of the apparatus in the signed second token;sending a second service request comprising the signed second token to a network entity in a second network, the second network comprising a Network Function provider for the service request.

13. A computer program comprising instructions stored thereon for performing at least the following: receiving a service request comprising a first token signed by a Network Function service consumer, wherein the Network Function service consumer is in a first network; validating the first token using a public key of the Network Function service consumer; generating a second token based on content in the validated first token; signing the second token using a private key of an apparatus and providing a public key of the apparatus in the signed second token; sending a second service request comprising the signed second token to a network entity in a second network, the second network comprising a Network Function provider for the service request.

14. An apparatus comprising: means for receiving a second service request from a network entity in a first network, the second service request comprising a second token signed by the network entity in the first network, wherein the second token is generated based on content in a first token signed by a Network Function consumer in the first network and included in a first service request from the Network Function consumer in the first network; means for validating the signed second token using the public key of the network entity in the first network; means for generating a third token based on content in the signed second token; means for signing the third token using a private key of the apparatus; means for providing a public key of the apparatus in the signed third token; means for sending a third service request comprising the signed third token to the Network Function provider, wherein the apparatus and the Network Function provider are in a second network.

15. The apparatus according to claim 14, wherein the Network Function provider is configured to: authenticate the third service request for the Network Function service consumer by validating the signed third token using the public key of the apparatus; andin response to authenticating the third service request, provide a service to the Network Function service consumer.

16. The apparatus according to claim 14 or claim 15, wherein the apparatus comprises a Security Edge Protection Proxy, SEPP or a Service Communication Proxy, SCP.

17. The apparatus according to any of claims 14 to 16, wherein the network entity in the first network comprises a Security Edge Protection Proxy, SEPP or a Service Communication Proxy, SCP.

18. The apparatus according to any of claims 14 to 17, wherein the token signed by the Network Function service consumer comprises at least one of: a Network Function instance identifier of the Network Function service consumer; a timestamp; an expiration time; a Network Function type of the expected target of the service request.

19. The apparatus according to any of claims 14 to 18, wherein the signed second token comprises at least one of: a Network Function instance identifier of the Network Function service consumer; a timestamp; an expiration time; a Network Function type of the expected target of the service request; a Network Function type of the Network Function service consumer; an instance identifier of the apparatus.

20. The apparatus according to any of claims 14 to 19, wherein the first network is a virtual Public Land Mobile Network or a Non-Public Network, and wherein the second network comprises a home Public Land Mobile Network.

21. The apparatus according to claim 19 or claim 20, wherein the third service request comprises the first token, the second signed token and the third signed token.

22. The apparatus according to any of claims 14 to 21 , wherein at least one of the first token, the second signed token and the third signed token comprise Client Credentials Assertion, CCA.

23. The apparatus according to any of claims 14 to 22, wherein: the first token is provided in a custom http header of the service request; the second signed token is provided in a custom http header of the second service request; and / or the third signed token is provided in a custom http header of the third service request.

24. A method comprising: receiving a second service request from a network entity in a first network, the second service request comprising a second token signed by the network entity in the first network, wherein the second token is generated based on content in a first token signed by a Network Function consumer in the first network and included in a first service request from the Network Function consumer in the first network; validating the signed second token using the public key of the network entity in the first network; generating a third token based on content in the signed second token; signing the third token using a private key of an apparatus; providing a public key of the apparatus in the signed third token; sending a third service request comprising the signed third token to the Network Function provider, wherein the apparatus and the Network Function provider are in a second network.

25. A computer program comprising instructions stored thereon for performing at least the following: receiving a second service request from a network entity in a first network, the second service request comprising a second token signed by the network entity in the first network, wherein the second token is generated based on content in a first token signed by a Network Function consumer in the first network and included in a first service request from the Network Function consumer in the first network; validating the signed second token using the public key of the network entity in the first network; generating a third token based on content in the signed second token; signing the third token using a private key of an apparatus; providing a public key of the apparatus in the signed third token; sending a third service request comprising the signed third token to the Network Function provider, wherein the apparatus and the Network Function provider are in a second network.

Images