Mitigating access token theft attacks in direct and indirect communications in SBA

Abstract

Examples of the various embodiments described herein relate to methods and apparatus for mitigating access token theft attacks in direct and indirect communications in SBA. One such example of an embodiment relates to a method comprising obtaining a first access token request from a network function service consumer (NFC), the first access token request comprising an authentication code of the NFc; authenticating a Network Function Consumer (NFC) based on a check of whether the authentication code is signed by the NFc; issuing a second access token request to a network authorization entity or function, where the second access token request includes an authentication code of the NFc, and the second access token request further includes a public key of the NFc or a hash of the public key of the NFc; receiving an access token from the network authorization entity or function based on the above, wherein the access token includes a public key of the NFc or a hash of a public key of the NFc; and issuing a service request to a network function service provider NFp, wherein the service request comprises the access token and the authentication code of the NFc.

Description

Technical Field

[0001] Examples of various embodiments described herein relate to methods and apparatus for mitigating access token theft attacks in direct and indirect communications in a service-based architecture. Background Art

[0002] With the passage of time, communication networks are expanding more and more all over the world. Various organizations such as European Telecommunications Standards Institute (ETSI), 3rd Generation Partnership Project (3GPP), Telecom and Internet Converged Services and Advanced Networking Protocol (TISPAN), International Telecommunication Union (ITU), 3rd Generation Partnership Project 2 (3GPP2), Internet Engineering Task Force (IETF), IEEE (Institute of Electrical and Electronics Engineers), WiMAX Forum, etc. are working on standards or specifications for telecommunication networks and access environments.

[0003] In one of these developments, a service-based architecture is being developed, and in this document, examples of the embodiments described relate to such a service-based architecture, such as the service-based architecture SBA discussed in 3GPP for, for example, the fifth generation 5G network. Nevertheless, the examples of the embodiments described herein may be applicable to other scenarios than 5G SBA, such as those developed within other standardization bodies, or future network generations such as 5.25G or 6G.

[0004] For example, in such a network architecture and / or service-based architecture SBA, 3GPP defines a 5G core network function (NF) interface and related application programming interface (API) for each NF to communicate between NFs. Summary of the invention

[0005] The examples of various embodiments described in the subject disclosure provide certain advantages, such as in the form of one or more improvements explicitly described herein or apparent to those skilled in the art from the subject disclosure. Therefore, the examples of at least some embodiments of the subject disclosure are intended to provide (or otherwise facilitate) at least a portion of the above advantages and improvements.

[0006] Various aspects of examples of embodiments of the subject disclosure are set out in the claims and relate to methods, apparatus, and computer program products in the context of mitigating access token theft attacks in direct and indirect communications in SBAs.

[0007] At least some of the above advantages and improvements may be achieved by the method, apparatus and non-transitory storage medium specified in the claims. Further advantages and improvements may be achieved by the method, apparatus and non-transitory storage medium set out in the respective dependent claims.

[0008] So far, according to examples of various embodiments, a device may include: at least one processor; and at least one memory storing instructions, which instructions, when executed by the at least one processor, may cause the device to at least: obtain a first access token request from a network function service consumer NFc, the first access token request including an authentication code of NFc; authenticate NFc based on a check of whether the authentication code is signed by the network function service consumer NFc; issue a second access token request to a network authorization entity or function, wherein the second access token request includes an authentication code of NFc, and the second access token request also includes a public key of NFc or a hash of the public key of NFc; receive an access token from the network authorization entity or function based on the above, wherein the access token includes the public key of NFc or a hash of the public key of NFc; and issue a service request to a network function service provider NFp, wherein the service request includes the access token and the authentication code of NFc.

[0009] According to examples of various embodiments, the device may also be caused to: receive a service request including an authentication code from the NFc, and obtain a first access token request by generating a first access token request based on the received service request; or obtain a first access token request by receiving the first access token request from the NFc.

[0010] According to examples of various embodiments, the device that is caused to be authenticated may also include the device being caused to: compare a public key included in the authentication code with a public key present in a Transport Layer Security (TLS) connection between the device and the NFc; and / or compare the NF instance ID included in the authentication code with the NF instance ID present in TLS credential information associated with the TLS connection; and / or wherein the authentication code is signed based on the TLS credential or via an OAuth signing private key of the NFc.

[0011] According to examples of various embodiments, the device enabled to issue a second access token request may also include the device enabled to: add a signature authentication code of the device to the second access token request; and / or issue a second access token request to a network authorization entity or function via at least one service communication agent SCP.

[0012] According to an example of at least some embodiments, a device may include at least one processor; and at least one memory storing instructions, which, when executed by the at least one processor, may cause the device to at least: receive an access token request, the access token request including an authentication code of a network function service consumer NFc, and also including a public key of NFc or a hash of the public key of NFc; authenticate NFc based on the authentication code of NFc; verify whether the public key included in the authentication code corresponds to the public key of NFc; if it is verified that the public keys are the same, generate an access token including the public key of NFc or a hash of the public key of NFc; and issue the access token to NFc and / or a service communication agent SCP.

[0013] According to examples of at least some embodiments, the apparatus being caused to authenticate may include the apparatus being caused to compare a public key included in the authentication code with a public key registered at a network authorization entity or function associated with the NFc.

[0014] According to examples of at least some embodiments, the received access request may further include an authentication code from a serving communication proxy SCP; and the device being caused to authenticate may further include the device being caused to authenticate the authentication code from the SCP.

[0015] According to examples of at least some embodiments, the means caused to generate the access token uses a public key of the NFc or a hash of the public key of the NFc stored in the NRF or received in the access token request.

[0016] According to an example of at least some embodiments, a device may include: at least one processor; and at least one memory storing instructions, which when executed by the at least one processor may cause the device to at least: receive a service request from a service communication agent SCP or from a network function service consumer NFc, the service request including an access token and an authentication code of NFc, the access token also including a public key of NFc or a hash of the public key of NFc; verify whether the public key included in the access token is the same as the public key included in the authentication code of NFc; and if it is verified that the public keys are the same, issue a service response to NFc.

[0017] In addition, according to examples of various embodiments, a device may include a component for obtaining a first access token request from a network function service consumer NFc, the first access token request including an authentication code of NFc; a component for authenticating whether the authentication code is signed by NFc; a component for issuing a second access token request to a network authorization entity or function, wherein the second access token request includes the authentication code of NFc, and the second access token request also includes the public key of NFc or the hash of the public key of NFc; a component for receiving an access token from the network authorization entity or function based on the above, wherein the access token includes the public key of NFc or the hash of the public key of NFc; and a component for issuing a service request to a network function service provider NFp, wherein the service request includes the access token and the authentication code of NFc.

[0018] According to examples of various embodiments, the device may also include a component for receiving a service request including an authentication code from NFc and obtaining a first access token request by generating a first access token request based on the received service request; or a component for obtaining a first access token request by receiving the first access token request from NFc.

[0019] According to examples of various embodiments, the device may also include a component for authentication, including a component for comparing a public key included in the authentication code with a public key present in a TLS connection between the device and the NFc; and / or a component for comparing the NF instance ID included in the authentication code with the NF instance ID present in TLS credential information associated with the TLS connection; and / or wherein the authentication code is signed based on the TLS credential or via an OAuth signing private key of the NFc.

[0020] According to examples of various embodiments, the device may also include a component for adding a signature authentication code of the device to a second access token request; and / or a component for issuing a second access token request to a network authorization entity or function via at least one service communication proxy SCP.

[0021] According to an example of at least some embodiments, an apparatus may include a component for receiving an access token request, the access token request including an authentication code of a network function service consumer NFc, and also including a public key of the NFc or a hash of the public key of the NFc; a component for authenticating the NFc based on the authentication code of the NFc; a component for verifying whether the public key included in the authentication code corresponds to the public key of the NFc; a component for generating an access token including the public key of the NFc or a hash of the public key of the NFc if the public keys are verified to be the same; and a component for issuing the access token to the NFc and / or a service communication agent SCP.

[0022] According to examples of at least some embodiments, the apparatus may further include means for comparing a public key included in the authentication code with a public key registered at a network authorization entity or function associated with the NFc.

[0023] According to examples of at least some embodiments, the received access request may further include an authentication code from a serving communication proxy SCP; and the apparatus may further include means for verifying the authentication code from the SCP.

[0024] According to an example of at least some embodiments, the apparatus may include means for generating the access token using a public key of the NFc or a hash of the public key of the NFc stored in the NRF or received in the access token request.

[0025] According to an example of at least some embodiments, an apparatus may include a component for receiving a service request from a service communication proxy SCP or from a network function service consumer NFc, the service request including an access token and an authentication code of the NFc, the access token also including a public key of the NFc or a hash of the public key of the NFc; a component for verifying whether the public key included in the access token is the same as the public key included in the authentication code of the NFc; and a component for issuing a service response to the NFc if the public keys are verified to be the same.

[0026] It should be understood that any of the above-mentioned apparatuses including “means for performing a process” may likewise be understood to correspond to apparatuses including “means configured to perform such a process”.

[0027] According to an example of at least some embodiments, a method includes: obtaining a first access token request from a network function service consumer NFc, the first access token request including an authentication code of the NFc; authenticating whether the authentication code is signed by the NFc; issuing a second access token request to a network authorization entity or function, wherein the second access token request includes the authentication code of the NFc, and the second access token request also includes a public key of the NFc or a hash of the public key of the NFc; based on the above, receiving an access token from the network authorization entity or function, wherein the access token includes the public key of the NFc or a hash of the public key of the NFc; and issuing a service request to a network function service provider NFp, wherein the service request includes the access token and the authentication code of the NFc.

[0028] In addition, according to examples of at least some embodiments, the method may also include: receiving a service request including an authentication code from the NFc, and obtaining a first access token request by generating a first access token request based on the received service request; or obtaining the first access token request by receiving the first access token request from the NFc.

[0029] In addition, according to examples of at least some embodiments, the method may include: authentication, including comparing a public key included in the authentication code with a public key present in the TLS connection between the service communication agent SCP and the NFc; and / or comparing the NF instance ID included in the authentication code with the NF instance ID present in the TLS credential information associated with the TLS connection; and / or wherein the authentication code is signed based on the TLS credential or via an OAuth signing private key of the NFc.

[0030] In addition, according to examples of at least some embodiments, the method may include: issuing a second access token request includes adding a signature authentication code of the SCP to the second access token request; and / or issuing the second access token request to a network authorization entity or function via at least one additional SCP.

[0031] According to an example of at least some embodiments, a method includes: receiving an access token request, the access token request including an authentication code of a network function service consumer NFc, and also including a public key of the NFc or a hash of the public key of the NFc; authenticating the NFc based on the authentication code of the NFc; verifying whether the public key included in the authentication code corresponds to the public key of the NFc; if it is verified that the public keys are the same, generating an access token including the public key of the NFc or a hash of the public key of the NFc; and issuing the access token to the NFc and / or a service communication agent SCP.

[0032] Furthermore, according to examples of at least some embodiments, the method may include: verifying, including comparing a public key included in the authentication code with a public key registered at a network authorization entity or function associated with the NFc.

[0033] Furthermore, according to examples of at least some embodiments, the received access request may further include an authentication code from a serving communication proxy SCP; and the verifying may further include verifying the authentication code from the SCP.

[0034] Furthermore, according to examples of at least some embodiments, generating the access token includes using a public key of the NFc or a hash of the public key of the NFc stored in the NRF or received in the access token request.

[0035] According to an example of at least some embodiments, a method includes: receiving a service request from a service communication proxy SCP or from a network function service consumer NFc, the service request including an access token and an authentication code of the NFc, the access token also including a public key of the NFc or a hash of the public key of the NFc; verifying whether the public key included in the access token is the same as the public key included in the authentication code of the NFc; and if it is verified that the public keys are the same, issuing a service response to the NFc.

[0036] According to examples of at least some embodiments, the authentication code may be a Client Certificate Assertion CCA.

[0037] Furthermore, according to examples of various embodiments, there may be provided a computer program product for a computer, the computer program product comprising software code portions for performing the steps of any of the above outlined methods when the above product is run on a computer.

[0038] According to examples of at least some embodiments, a computer program product may include a computer-readable medium having the software code portion stored thereon, and / or the computer program product may be directly loadable into an internal memory of a computer and / or transmittable via a network by means of at least one of an upload process, a download process, and a push process.

[0039] Any of the various aspects recited in the claims facilitates mitigation of access token theft attacks in direct and indirect communications in SBA, thereby providing at least some of the advantages and improvements described above.

[0040] In more detail, the subject disclosure describes mitigating access token theft attacks in direct and indirect communications in SBA, which, according to examples of some embodiments, may prove superior to proprietary solutions for at least the following reasons.

[0041] Other advantages may become apparent to those skilled in the art from the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Examples of some embodiments of the subject disclosure are described below, by way of example only, with reference to the accompanying drawings, in which:

[0043] FIG. 1 (comprising Part 1 of 2 and Part 2 of 2) illustrates a signaling flow associated with mitigating access token theft attacks in direct and indirect communications in SBA according to an example of various embodiments of the subject disclosure;

[0044] FIG. 2 (comprising Part 1 of 2 and Part 2 of 2) illustrates a signaling flow associated with mitigating access token theft attacks in direct and indirect communications in an SBA according to an example of various embodiments of the subject disclosure;

[0045] Figure 3 A flowchart illustrating steps corresponding to an example method according to an example of various embodiments of the subject disclosure is shown;

[0046] Figure 4 A flowchart illustrating steps corresponding to an example method according to an example of various embodiments of the subject disclosure is shown;

[0047] Figure 5 A flowchart illustrating steps corresponding to an example method according to an example of various embodiments of the subject disclosure is shown;

[0048] Figure 6 shows a block diagram illustrating an example apparatus according to an example of various embodiments of the subject disclosure;

[0049] Figure 7 shows a block diagram illustrating an example apparatus according to an example of various embodiments of the subject disclosure; and

[0050] Figure 8 Shown is a block diagram illustrating an example apparatus according to an example of various embodiments of the subject disclosure. DETAILED DESCRIPTION

[0051] In general, two or more endpoints involved in the communication between endpoints may be implemented as a specific type of endpoint (e.g., a communication station or entity or function, such as a terminal device, user equipment (UE) or other communication network element, database, server, host, etc.), or implemented as one or more network elements or functions (e.g., virtualized network functions), such as communication network control elements or functions, such as access network elements (such as access points (APs), radio base stations (BSs), relay stations, eNBs, gNBs, etc.); and core network elements or functions, such as control nodes, support nodes, service nodes, gateways, user plane functions, access and mobility functions, etc. These endpoints may belong to a single communication network system, different communication network systems, or a combination of at least one same communication network system and at least one different communication network system.

[0052] In the following, examples of various embodiments will be described using a communication network architecture based on 3GPP standards such as 5G / NR as an example of a communication network to which the examples of the embodiments may be applied, without limiting the examples of the embodiments to such an architecture. However, it is clear to those skilled in the art that the examples of the embodiments may also be applied to other kinds of communication networks, such as 4G and / or LTE (even 6G and higher), in which mobile communication principles such as Wi-Fi, Worldwide Interoperability for Microwave Access (WiMAX), Personal Communications Service (PCS), Wideband Code Division Multiple Access (WCDMA), systems using ultra-wideband (UWB) technology, mobile ad hoc networks (MANET), wired access, etc. In addition, without loss of generality, the description of examples of some embodiments is related to mobile communication networks, but the subject disclosure can be extended and applied to any other type of communication network, such as a wired communication network or a data center network.

[0053] The examples of the following embodiments are to be understood as illustrative in nature only. Although portions of the subject disclosure may refer to "one", "an" or "some" examples of (multiple) embodiments in several specific locations, this does not necessarily mean that each such reference is related to the same (multiple) examples of (multiple) embodiments, or that the features described apply only to a single example of an embodiment. Individual features from examples of different embodiments may also be combined to provide examples of other embodiments. In addition, terms such as "including" and "comprising" should be understood as not limiting the examples of the described embodiments to only those features that have been mentioned; such examples of embodiments may also include features, structures, units, modules, etc. that are not specifically mentioned.

[0054] A simplified system architecture of a (telecommunication) communication network including a mobile communication system (in which examples of some embodiments are applicable) may include the architecture of one or more communication networks. The one or more communication networks may include (multiple) radio access network subsystems and (multiple) core networks. Such an architecture may include one or more communication network control elements or functions, access network elements, radio access network elements, access service network gateways or base transceiver stations, such as base stations (BS), access points (APs), node Bs (NBs), evolved node Bs (eNBs) or next generation node Bs (gNBs), distributed or centralized units (CUs), which control (multiple) corresponding coverage areas or cells and with which one or more communication stations may communicate via one or more channels via one or more communication beams for sending several types of data in multiple access domains, such as communication elements or functions, such as user equipment (e.g., customer equipment), mobile devices or terminal devices, such as UEs, or another device with similar functionality, such as modem chipsets, chips, modules, etc., which may also be part of a station, element, function or application configured to communicate, such as a UE, an entity or function that can be used in a machine-to-machine communication architecture, or attached as a separate element to an element, function or application configured to communicate, etc. In addition, it may include (core) network elements or network functions ((core) network control elements or network functions, (core) network management elements or network functions), such as gateway network elements / functions, mobility management entities, mobile switching centers, servers, databases, etc.

[0055] The functionality and interconnection of the described elements and functions (which also depends on the actual network type) are obvious to a person skilled in the art and can be described in the corresponding specification, so their description is omitted in this document. However, it should be noted that in addition to those described in detail below, several additional network elements and signaling links may be used to communicate to or from elements, functions or applications, such as communication endpoints, communication network control elements (such as servers, gateways, radio network controllers) and other elements of the same or other communication networks.

[0056] It should be understood that according to some examples of embodiments, a so-called "fluid" or flexible network concept can be implemented, in which the operations and functions of a network element, a network function or another entity of the network can be performed in a flexible manner in different entities or functions (such as in a node, a host or a server). Therefore, the "division of labor" between the network elements, functions or entities involved can vary from case to case.

[0057] In some examples of embodiments, the subject disclosure relates to mitigating access token theft attacks in direct and indirect communications in an SBA.

[0058] TS 33.501 clause 13 discloses SBA authorization using OAuth 2.0.

[0059] IETF RFC 8705 addresses the issue of binding OAuth 2.0 access tokens to TLS credentials. For the purpose of issuing restricted access tokens, the client identifies itself to the resource server by the fingerprint of its public key. During the processing of the access token request, the authorization server obtains the client's public key from the TLS stack and associates its fingerprint with the corresponding access token. The resource server obtains the public key from the TLS stack in the same way and compares its fingerprint with the fingerprint associated with the access token.

[0060] Although the above RFC only addresses direct communication because it relies on mTLS, it does not address all indirect communication cases in 3GPP (ie, Models C and D).

[0061] In current 3GPP specifications, in particular in the OAuth 2.0 framework for SBA, access tokens are used for authorization, and EE TLS credentials are used for authentication. Therefore, if an access token that grants a first network function NF1 to consume services of a second network function acting as a producer NF2 is leaked to a third network function NF3 with valid credentials, this NF3 can consume services of NF2 even though it is not authorized to do so. 3GPP's current approach to this problem is to rely on "good" implementations that do not allow access tokens to be leaked, and prevent the problem named "token answering".

[0062] The currently specified RFC 8705 does not address the issues in 5G SBA for several reasons:

[0063] Indirect communication was introduced in Rel 16. The communication between (consumer) NFc and (producer) NFp is done via SCP (Service Communication Proxy). Therefore, TLS (Transport Layer Security) mutual authentication is performed between NF and SCP.

[0064] · CCA (Client Certificate Assertion) specified by 3GPP to enable client authentication in indirect communication based deployments. RFC8705 does not include this feature.

[0065] 5G SBA uses HTTP / 2, and according to RFC 9113, 'TLS1.3 post-handshake authentication' will be avoided.

[0066] Currently, in the case of authorization using OAuth 2.0, there is no provision to prevent access token theft / abuse type attacks in the case of indirect communication such as 5G SBA. It should be noted that CCA itself is only standardized and used for authentication, so it does not solve the token theft problem. In other words, in the case of indirect communication, NRF and NFp currently have no means to verify which NF is the initiator of the access token / service request and whether a malicious or infiltrated SCP or NF is performing a token theft attack.

[0067] Therefore, the problem remains unsolved, and the proposed solution according to the examples of various embodiments of the subject disclosure also solves the same problem.Therefore, the examples of various embodiments of the subject disclosure are advantageous because they enable solving at least part of the problem.

[0068] By solving such (multiple) problems, at least one or more examples of the embodiments can advantageously deploy at least one of the following features:

[0069] - Use binding between access tokens for authorization and credentials for authentication;

[0070] - Perform mutual authentication between network functions NFs, even in deployments based on indirect communication;

[0072] -Allows CCA to be used for authorization in addition to authentication.

[0073] The current problem is solved in a single PLMN non-roaming scenario, where the public key of the NF service consumer can be obtained via the CCA used in indirect communication.

[0074] The NRF verifies the CCA using the public key provided by the NF and also verifies if the public key in the CCA is present in the previously registered NF profile (it should be noted that according to various examples of embodiments, it can be assumed that all NFs (whether consumers or producers) must be registered with the NRF or any other repository). This information (public key) is available during NF registration (currently NF registration is only via direct communication, i.e. using mutual TLS in principle) or this information can be obtained from the OAM using the NF instance ID present in the CCA.

[0075] Once verified, the NRF adds the NFc's public key (or a hash of the public key or a credential fingerprint) to the generated access token and binds the access token in such a way that only the NFc that provides proof of handling of the corresponding private key can use the access token.

[0076] During a service request, when NFc makes a request to NFp (along with CCA), NFp verifies whether the public key present in the access token matches the public key present in CCA. In case of successful verification, i.e., verifying the public key present in the access token against CCA, NFp provides the service.

[0077] Furthermore, in cases where it may be necessary to protect the complete path (and authenticate / authorize) all SCPs in the path for access token requests from NFc to NRF and service requests from NFc to NFp, according to examples of various embodiments, it is suggested to enhance the access token to include intermediate SCPs.

[0078] According to examples of at least some embodiments of the present disclosure, different variations may be envisioned to address the above-mentioned issues.

[0079] Variant I: Solution based on RFC8705. To adopt RFC, at least the following changes need to be made to the signaling:

[0080] NFc public key is bound to the access token; and / or

[0081] NFp verifies the access token (NFc public key) against the CCA and then it provides the service; and / or

[0082] By validating the access token, it can be ensured that it has not been stolen or misused and therefore is intended for the authentic NF consumer making the request.

[0083] Referring now to FIG. 1 (which consists of Part 1 of 2 and Part 2 of 2; connected at A'-A" and B'-B"), operation for Model D is shown, which also applies to Model C.

[0084] Here, network entities are denoted by numerals 110, 120, 130 and 140. Signaling (i.e., messages) exchanged between them are represented by arrows, and processing at the entities is represented by "boxes" shown below the respective entities. Network functions NF are shown as consumer NFc1 and producer NFp, service control points are denoted SCP, and authoritative servers are denoted hNRF (e.g., home network repository function).

[0085] A. NF (Consumer and Producer) Profile Registration (not shown in Figure 1)

[0086] The NFc 110 also registers its public key (or a hash or fingerprint of the public key) during profile registration at the NRF 140 (or OAM). Since profile registration should happen via mTLS (not mandatory), the NRF 140 may have the public key from the corresponding TLS credential. If the key used for access token signing is different from the key present in mTLS, this may also be updated at the NRF 140 as part of NF profile registration.

[0087] If this information is not available at the NRF 140, it may request corresponding information from the OAM using the NFc instance ID information.

[0088] It should be noted that according to examples of various embodiments, it may be assumed that all NFs (both consumers and producers) are registered with the NRF in the future.

[0089] B. NFc / SCP requests access token from NRF

[0090] As shown in B1, NFc 110 also sends its CCA along with the service request. In the case of both Model C and Model D, the service request contains the CCA.

[0091] Even though the CCA is only valid for a short period of time (its validity period may expire after a period of time), the following process still works in the event that it can be assumed that the CCA has been stolen:

[0092] As shown in B2, when SCP 120 receives an access token request from NFc 110 (in model C), or when it receives a service request and then generates an access token request accordingly (in model D), it first verifies whether the CCA is indeed signed and belongs to the NFc 110 that issued the message.

[0093] Since SCP 120 has direct mTLS with NFc 110, it can verify whether the public key present in the TLS connection is the same as the public key present in CCA. In the case of using different keys for TLS and CCA signatures, SCP 120 verifies whether the NF instance ID present in the TLS credential information is the same as the NF instance ID present in CCA. Only after successful verification, SCP 120 forwards the access token request (indicated by B1) to NRF 140 (Model C), or generates an access token request (Model D) and sends it to NRF 140, including the information of the public key of NFc 110 in the access token request.

[0094] C. Access token generation and process verification proof via NRF 140

[0095] As shown in C1, when the NRF 140 receives the access token request together with the CCA of the NFc 110, after performing the verification specified in, for example, Section 13.3.8 of TS33.501, it verifies that the public key present in the CCA is indeed the public key belonging to the NFc 110 (the instance ID of the NFc 110 is present in the access token request) (using the NF profile registration information), and appends the public key present in the CCA to the access token. Alternatively, the NRF 140 can also add the signature HASH of the public key or the NFc credential fingerprint in the access token.

[0096] It should be noted that in the case where the NF service consumer (NFc 110) is not registered at the NRF 140, even so, the CCA generated by the NFc 110 will serve as proof of possession of the private key and the corresponding public key will be added to the access token.

[0097] D. Issue a service request to the NF service producer (NFp 130)

[0098] As shown in the second part of FIG. 1 , the NF service producer (NFp 130), upon receiving the request (denoted by D1) together with the CCA (consumer NFC, denoted by 110) of NFc1, can verify whether the public key present in the access token (in the second part of FIG. 1 , denoted as AT in D2 in general) is the same as the public key in the CCA. If the verification is successful, the service is provided.

[0099] Variant II: Binding the access token to the full path / intermediate SCP by appending / modifying the access token request issued to the NRF

[0100] Referring now to FIG. 2 (consisting of Part 1 of 2 and Part 2 of 2; connected at A'-A" and B'-B"), therein is shown a signaling flow associated with mitigating access token theft attacks in direct and indirect communications in an SBA according to an example of various embodiments disclosed herein.

[0101] Here, network entities are denoted by numerals 210, 220, 230 and 240, and signaling (i.e., messages) exchanged between them are denoted by (numbered) arrows. Network functions NF are shown as consumer NF (210), producer NF (240), service control point is SCP, denoted by 220, and authorization server is NRF (e.g., network repository function), denoted by 230.

[0102] Not shown in Figure 2 is "Step 0". Here, it is assumed that NF registration (and SCP registration) at the NRF occurs via direct communication or OAM, so that the NRF already has TLS credentials or public key pairs corresponding to the OAuth signing keys of the NF and SCP.

[0103] As shown in step 1: NF service consumer 210, when issuing an access token request to NRF 230 (optionally, directly or (as shown in Figure 2) via SCP 220), it also includes its certificates, such as NF instance ID, NF type, slice ID, PLMNID, etc. The corresponding certificates have been considered as part of the client's TLS credentials (e.g., part of specification TS 33.310). Once these certificates are added to the access token request, the NF service consumer 210 signs the corresponding information element(s) using its TLS credentials or via its OAuth signing private key. Once signed, the public key or information on how to access the public key is also added to the access token request to verify the information. This information can be added as a complete key or in the form of a URI to obtain the key.

[0104] As shown in step 2: In the case of indirect communication, that is, if SCP 220 is between them and receives the access token request, SCP 220 also adds its own certificate information (such as SCP ID, PLMN information, etc.) as a separate information element (IE) on top of the existing access token request and signs it using its own TLS certificate or OAuth private key. Subsequently, SCP 220 also adds information on how to access the key used (or optionally the key itself) to verify the signed certificate.

[0105] It should be noted that in the case of Model D, where the SCP 220 itself generates the access token request, the NF service consumer 210 can issue its details and sign them, and then provide them to the SCP 220, which can then append this information in the access token request generated by the SCP 220.

[0106] It should be noted that in the case where there are multiple SCPs in a hop (not shown in Figure 2), each SCP adds its details to the access token request received from the previous entity, signs it, and then forwards it to the next entity in the communication chain.

[0107] As shown in step 3: upon receiving the final access token request (from / via NFc and / or one or more SCPs), the NRF 230, in addition to performing the general verification defined in TS 33.501 clause 13, verifies the certificates of one (or more) SCPs 220 and NFc 210 using the (multiple) corresponding public keys provided by NFc 210 and SCP (or multiple SCPs) 220, and verifies the same information (i.e., certificates, (multiple) credentials, keys) based on the registration information provided in step 0.

[0108] As shown in step 4: If the verification is successful, the NRF 230 generates an access token such that the full path information (including the authorized NFc 210, the (one or more) SCPs 220 and their (corresponding) public keys for the NFp 240 to verify the same details, and the full path information) is added to the access token.

[0109] As shown in step 5: NRF 230 issues an enhanced access token with additional information back to SCP 220 (or NFc 210) based on and / or dependent on the communication model used. Part 1 of FIG. 2 shows that the signaling in S5 is sent from NRF 230 back to NFc 210 via SCP 220.

[0110] As shown in step 6: NFc 210 (or SCP 220 as shown in part 2 of FIG. 2 ) issues a service request with an enhanced access token to NF service producer NFp 240 .

[0111] As shown in step 7: NFp 240 ensures that both SCP 220 and NFc 210 have been authenticated and authorized by NRF 230, and directly uses the public key information present in the certificate and access token to verify their details.

[0112] As shown in step 8: if the verification is successful, NFp 240 sends a service response to NFc 210, otherwise it sends an error code.

[0113] In the following, examples of further embodiments are described with respect to the above-mentioned methods and / or apparatuses.

[0114] Reference now Figure 3 , in which a flowchart illustrating steps corresponding to an example method according to an example of various embodiments of the present subject disclosure is shown.

[0115] Specifically, according to Figure 3 In S310, the method includes obtaining a first access token request from a network function service consumer NFc, where the first access token request includes an authentication code of the NFc.

[0116] Furthermore, in S320, the method includes authenticating whether the authentication code is signed by the NFc.

[0117] In addition, if the authentication code is signed by NFc ("Yes" in S320), then in S330, the method includes issuing a second access token request to a network authorization entity or function, wherein the second access token request includes the authentication code of NFc, and the second access token request also includes the public key of NFc or the hash of the public key of NFc.

[0118] Furthermore, in S340, the method comprises receiving an access token from a network authorization entity or function, wherein the access token comprises a public key of the NFc or a hash of a public key of the NFc.

[0119] Furthermore, in S350, the method includes issuing a service request to the network function service provider NFp, wherein the service request includes an access token and an authentication code of the NFc.

[0120] In addition, according to examples of at least some embodiments, the method may also include: receiving a service request including an authentication code from the NFc, and obtaining a first access token request by generating a first access token request based on the received service request; or obtaining the first access token request by receiving the first access token request from the NFc.

[0121] In addition, according to examples of various embodiments, the method may include: verification, including comparing a public key included in the authentication code with a public key present in the TLS connection between the service communication agent SCP and the NFc; and / or comparing the NF instance ID included in the authentication code with the NF instance ID present in the TLS credential information associated with the TLS connection; and / or wherein the authentication code is signed based on the TLS credential or via an OAuth signing private key of the NFc.

[0122] In addition, according to examples of at least some embodiments, the method may include: issuing a second access token request includes adding a signature authentication code of the SCP to the second access token request; and / or issuing the second access token request to a network authorization entity or function via at least one additional SCP.

[0123] Reference now Figure 4 , Figure 4 A flowchart illustrating steps corresponding to an example method according to an example of various embodiments of the subject disclosure is shown.

[0124] Specifically, according to Figure 4 In S410, the method includes receiving an access token request, the access token request includes an authentication code of a network function service consumer NFc, and also includes a public key of the NFc or a hash of the public key of the NFc.

[0125] Furthermore, in S420, the method includes authenticating the NFc based on the authentication code of the NFc.

[0126] Furthermore, in S430, the method includes verifying whether the public key included in the authentication code corresponds to the NFc.

[0127] Furthermore, if it is verified that the public keys are identical ("Yes" in S430), then in S440, the method includes generating an access token including the public key of the NFc or a hash of the public key of the NFc.

[0128] Furthermore, in S450, the method includes issuing an access token to the NFc and / or the serving communication proxy SCP.

[0129] Furthermore, according to examples of at least some embodiments, the verification may include comparing a public key included in the authentication code with a public key registered at a network authorization entity or function associated with the NFc.

[0130] Furthermore, according to examples of at least some embodiments, the received access request may further include an authentication code from a serving communication proxy SCP; and the verifying may further include verifying the authentication code from the SCP.

[0131] Reference now Figure 5 , Figure 5 A flowchart illustrating steps corresponding to an example method according to an example of various embodiments of the subject disclosure is shown.

[0132] Specifically, according to Figure 5 In S510, the method includes receiving a service request from a service communication proxy SCP or from a network function service consumer NFc, the service request includes an access token and an authentication code of the NFc, and the access token also includes a public key of the NFc or a hash of the public key of the NFc.

[0133] Furthermore, in S520, the method includes verifying whether a public key included in the access token is identical to a public key included in the authentication code of the NFc.

[0134] Furthermore, if it is verified that the public keys are identical ("Yes" in S520), then in S530, the method includes issuing a service response to the NFc.

[0135] In addition, according to reference Figures 3 to 5 In examples of various embodiments, the authentication code may be a client certificate assertion CCA.

[0136] Reference now Figure 6 , Figure 6 Shown is a block diagram illustrating an example apparatus according to an example of various embodiments of the subject disclosure.

[0137] Specifically, Figure 6A block diagram illustrating an apparatus 600 of an example according to various embodiments is shown, which may represent a service communication agent (e.g., SCP 120, 220) as outlined above with reference to FIG. 1 and FIG. 2, which may participate in mitigating access token theft attacks in direct and indirect communications in an SBA. In addition, even though reference is made to a service communication agent, the service communication agent may be another device or function with similar tasks, such as a chipset, chip, module, application, etc., which may also be part of a network element or attached to a network element as a separate element, etc. It should be understood that each block and any combination thereof may be implemented by various components or combinations thereof, such as hardware, software, firmware, one or more processors, and / or circuit systems.

[0138] Figure 6 The device 600 shown may include a processing circuit system, a processing function, a control unit or a processor 610, such as a CPU, etc., which is suitable for enabling mitigation of access token theft attacks in direct and indirect communications in SBA. The processor 610 may include one or more processing parts or functions dedicated to a specific process as described below, or the process may be run in a single processor or processing function. The portion for performing such a specific process may also be provided as a discrete element, or provided in one or more additional processors, processing functions or processing parts, such as in a physical processor (such as a CPU) or in one or more physical or virtual entities. Reference numerals 631 and 632 represent input / output (I / O) units or functions (interfaces) connected to the processor or processing function 610. The I / O units 631 and 632 may be combined units including communication devices toward several entities / elements, or may include a distributed structure with multiple different interfaces for different entities / elements. Reference numeral 620 represents a memory, which may be used, for example, to store data and programs / instructions to be executed by the processor or processing function 610 and / or used as working storage for the processor or processing function 610. It should be noted that memory 620 may be implemented using one or more memory portions of the same or different types of memory, but may also represent external memory, such as an external database provided on a cloud server.

[0139] The processor or processing function 610 is configured to perform processing related to the above-mentioned processing. In particular, the processor or processing circuit system or function 610 includes one or more of the following sub-parts. Sub-part 611 is an acquisition part, which can be used as a part for acquiring a first access token request from a network function service consumer. Part 611 can be configured to perform according to Figure 3 In addition, sub-section 612 is an authentication section, which can be used as a section for authenticating whether the authentication code is signed by NFc. Section 612 can be configured to perform Figure 3In addition, sub-section 613 is an issuing section, which can be used as a section for issuing a second access token request. Section 613 can be configured to execute according to Figure 3 In addition, sub-section 614 is a receiving section, which can be used as a section for receiving an access token. Section 614 can be configured to perform according to Figure 3 In addition, sub-section 615 is an issuing section, which can be used as a section for issuing a service request. Section 615 can be configured to execute according to Figure 3 The S350's handling.

[0140] Reference now Figure 7 , Figure 7 Shown is a block diagram illustrating an example apparatus according to an example of various embodiments of the subject disclosure.

[0141] Specifically, Figure 7 A block diagram of an apparatus 700 illustrating an example according to various embodiments is shown, which may represent a network authorization entity or function (e.g., NRF 140, 230) as outlined above with reference to FIG. 1 and FIG. 2, which may participate in mitigating access token theft attacks in direct and indirect communications in SBA. In addition, even though reference is made to a network authorization entity or function, the network authorization entity or function may be another device or function with similar tasks, such as a chipset, chip, module, application, etc., which may also be part of a network element or attached to a network element as a separate element, etc. It should be understood that each box and any combination thereof may be implemented by various components or combinations thereof, such as hardware, software, firmware, one or more processors and / or circuit systems.

[0142] Figure 7The device 700 shown may include a processing circuit system, a processing function, a control unit or a processor 710, such as a CPU, etc., which is suitable for enabling mitigation of access token theft attacks in direct and indirect communications in SBA. The processor 710 may include one or more processing parts or functions dedicated to a specific process as described below, or the process may be run in a single processor or processing function. The portion for performing such a specific process may also be provided as a discrete element, or provided in one or more additional processors, processing functions or processing parts, such as in a physical processor (such as a CPU) or in one or more physical or virtual entities. Reference numerals 731 and 732 represent input / output (I / O) units or functions (interfaces) connected to the processor or processing function 710. The I / O units 731 and 732 may be combined units including communication devices toward several entities / elements, or may include a distributed structure with multiple different interfaces for different entities / elements. Reference numeral 720 represents a memory, which may be used, for example, to store data and programs / instructions to be executed by the processor or processing function 710 and / or used as working storage for the processor or processing function 710. It should be noted that the memory 720 may be implemented using one or more memory portions of the same or different types of memory, but may also represent external memory, such as an external database provided on a cloud server.

[0143] The processor or processing function 710 is configured to perform processing related to the above-mentioned processing. In particular, the processor or processing circuit system or function 710 includes one or more of the following sub-parts. Sub-part 711 is a receiving part, which can be used as a part for receiving an access token request. Part 711 can be configured to perform according to Figure 4 In addition, sub-section 712 is an authentication section, which can be used as a section for authenticating NFc. Section 712 can be configured to perform according to Figure 4 In addition, sub-section 713 is a verification section, which can be used as a section for verifying the public key. Section 713 can be configured to perform according to Figure 4 In addition, sub-section 714 is a generating section, which can be used as a section for generating an access token. Section 714 can be configured to perform according to Figure 4 In addition, sub-section 715 is an issuing section, which can be used as a section for issuing an access token. Section 715 can be configured to perform according to Figure 4 The S450's handling.

[0144] Reference now Figure 8 , Figure 8 Shown is a block diagram illustrating an example apparatus according to an example of various embodiments of the subject disclosure.

[0145] Specifically, Figure 8 A block diagram illustrating an apparatus 800 of an example according to various embodiments is shown, which may represent a NFp (e.g., NFp 130, 240) as outlined above with reference to FIG. 1 and FIG. 2, which may participate in mitigating access token theft attacks in direct and indirect communications in SBA. Furthermore, even though reference is made to a NFp, the NFp may be another device or function with similar tasks, such as a chipset, chip, module, application, etc., which may also be part of a network element or attached to a network element as a separate element, etc. It should be understood that each block and any combination thereof may be implemented by various components or combinations thereof, such as hardware, software, firmware, one or more processors, and / or circuit systems.

[0146] Figure 8 The device 800 shown may include a processing circuit system, a processing function, a control unit or a processor 810, such as a CPU, etc., which is suitable for enabling mitigation of access token theft attacks in direct and indirect communications in SBA. The processor 810 may include one or more processing parts or functions dedicated to a specific process as described below, or the process may be run in a single processor or processing function. The portion for performing such a specific process may also be provided as a discrete element, or provided in one or more additional processors, processing functions or processing parts, such as in a physical processor (such as a CPU) or in one or more physical or virtual entities. Reference numerals 831 and 832 represent input / output (I / O) units or functions (interfaces) connected to the processor or processing function 810. The I / O units 831 and 832 may be combined units including communication devices toward several entities / elements, or may include a distributed structure with multiple different interfaces for different entities / elements. Reference numeral 820 represents a memory, which may be used, for example, to store data and programs / instructions to be executed by the processor or processing function 810 and / or used as working storage for the processor or processing function 810. It should be noted that the memory 820 may be implemented using one or more memory portions of the same or different types of memory, but may also represent external memory, such as an external database provided on a cloud server.

[0147] The processor or processing function 810 is configured to perform processing related to the above-mentioned processing. In particular, the processor or processing circuit system or function 810 includes one or more of the following sub-parts. Sub-part 811 is a receiving part, which can be used as a part for receiving service requests. Part 811 can be configured to perform according to Figure 5 In addition, sub-section 812 is a verification section, which can be used as a section for verifying the public key. Section 812 can be configured to perform according to Figure 5 In addition, sub-section 813 is an issuing section, which can be used as a section for issuing a service response. Section 813 can be configured to execute according to Figure 5 The S530 is processed.

[0148] It should be noted that, as mentioned above Figure 6 , Figure 7 and Figure 8 The apparatuses 600, 700 and 800 as outlined may include additional / additional sub-parts that may allow the apparatuses 600, 700 and 800 to perform the above-referenced Figure 3 , Figure 4 and Figure 5 Outline the approach / methodological steps.

[0149] In addition, according to examples of various embodiments, a device may include a component for obtaining a first access token request from a network function service consumer NFc, the first access token request including an authentication code of NFc; a component for authenticating whether the authentication code is signed by NFc; a component for issuing a second access token request to a network authorization entity or function, wherein the second access token request includes the authentication code of NFc and also includes a public key of NFc or a hash of the public key of NFc; a component for receiving an access token from the network authorization entity or function based on the above, wherein the access token includes the public key of NFc or a hash of the public key of NFc; and a component for issuing a service request to a network function service provider NFp, wherein the service request includes the access token and the authentication code of NFc.

[0150] According to examples of various embodiments, the device may also include a component for receiving a service request including an authentication code from NFc and obtaining a first access token request by generating a first access token request based on the received service request; or a component for obtaining a first access token request by receiving the first access token request from NFc.

[0151] According to examples of various embodiments, the device may also include a component for comparing a public key included in the authentication code with a public key present in a TLS connection between the device and the NFc; and / or a component for comparing the NF instance ID included in the authentication code with the NF instance ID present in TLS credential information associated with the TLS connection; and / or wherein the authentication code is signed based on the TLS credential or via an OAuth signing private key of the NFc.

[0152] According to examples of various embodiments, the device may also include a component for adding a signature authentication code of the device to a second access token request; and / or a component for issuing a second access token request to a network authorization entity or function via at least one service communication proxy SCP.

[0153] According to an example of at least some embodiments, an apparatus may include a component for receiving an access token request, the access token request including an authentication code of a network function service consumer NFc, and also including a public key of the NFc or a hash of the public key of the NFc; a component for authenticating the NFc based on the authentication code of the NFc; a component for verifying whether the public key included in the authentication code corresponds to the NFc; a component for generating an access token including the public key of the NFc or a hash of the public key of the NFc if the public keys are verified to be the same; and a component for issuing the access token to the NFc and / or a service communication agent SCP.

[0154] According to examples of at least some embodiments, the apparatus may further include means for comparing a public key included in the authentication code with a public key registered at a network authorization entity or function associated with the NFc.

[0155] According to examples of at least some embodiments, the received access request may further include an authentication code from a serving communication proxy SCP; and the apparatus may further include means for verifying the authentication code from the SCP.

[0156] According to an example of at least some embodiments, an apparatus may include a component for receiving a service request from a service communication proxy SCP or from a network function service consumer NFc, the service request including an access token, the access token including an authentication code of the NFc and also including a public key of the NFc or a hash of the public key of the NFc; a component for verifying whether the public key included in the access token is the same as the public key included in the authentication code of the NFc; and a component for issuing a service response to the NFc if the public keys are verified to be the same.

[0157] Furthermore, according to examples of various embodiments, a computer program product for a computer may be provided, the computer program product comprising software code portions for performing the steps of any of the above-outlined methods when the above-mentioned product is run on a computer.

[0158] According to examples of at least some embodiments, a computer program product may include a computer-readable medium having the above-mentioned software code portion stored thereon, and / or the computer program product may be directly loadable into the internal memory of a computer and / or may be sendable via a network by means of at least one of an upload process, a download process, and a push process.

[0159] It should be understood

[0160] -The access technology through which services are transferred to and / or from entities in a communication network can be any suitable current or future technology, and technologies such as WLAN (Wireless Local Access Network), WiMAX (Worldwide Interoperability for Microwave Access), LTE, LTE-A, 5G, 6G, Bluetooth, infrared, etc. can be used; in addition, examples of embodiments can also apply wired technologies, such as IP-based access technologies, such as wired networks or fixed lines.

[0161] -Examples of embodiments suitable for being implemented as software code or portions thereof and running using a processor or processing functionality are independent of software code and may be specified using any known or future developed programming language, such as a high-level programming language, such as object-oriented C, C, C++, C#, Java, Python, Javascript, other scripting languages, etc., or a low-level programming language, such as machine language or assembler.

[0162] -The implementation of the examples of the embodiments is hardware independent and can be implemented using any known or future developed hardware technology or any mixture of these technologies, such as a microprocessor or CPU (Central Processing Unit), MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic) and / or TTL (Transistor-Transistor Logic).

[0163] -Examples of the embodiments may be implemented as separate devices, apparatuses, units, means or functions, or in a distributed manner, for example, one or more processors or processing functions may be used or shared in a process, or one or more processing segments or processing portions may be used and shared in a process, where one physical processor or more than one physical processor may be used to implement one or more processing portions dedicated to a particular process being described,

[0164] - the device may be implemented by a semiconductor chip, a chipset, or a (hardware) module including such a chip or chipset;

[0165] -Examples of embodiments may also be implemented as any combination of hardware and software, such as ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field Programmable Gate Array) or CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components.

[0166] - The examples of the embodiments may also be implemented as a computer program product, including a computer usable medium having computer readable program code embodied therein, the computer readable program code being adapted to execute the processes as described in the embodiments, wherein the computer usable medium may be a non-transitory medium.

[0167] The term "circuitry" may refer to one or more or all of the following examples of embodiments:

[0168] (a) Hardware circuit implementation only (such as implementation in analog and / or digital circuitry only)

[0169] as well as

[0170] (b) a combination of hardware circuitry and software such as (where applicable):

[0171] (i) a combination of analog and / or digital hardware circuits and software / firmware, and

[0172] (ii) any portion of hardware processor(s) (including digital signal processor(s)) with software, software and memory(s) that work together to enable a device such as a mobile phone or server to perform various functions), and

[0173] Hardware circuit(s) and / or processor(s), such as microprocessor(s) or portion(s) of microprocessor(s), that require software (e.g., firmware) to operate, but in which the software may not be present when not required for operation.

[0174] This definition of circuitry applies to all uses of the term herein, including in any claims. As another example, as used herein, the term circuitry also covers an implementation of only a hardware circuit or processor (or multiple processors) or a portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. For example, the term circuitry also covers a baseband integrated circuit or processor integrated circuit for a mobile device, or a similar integrated circuit in a server, cellular network device, or other computing or network device, if applicable to the particular claim element.

[0175] The term "non-transitory" as used herein is a limitation on the medium itself (eg, tangible, rather than a signal), rather than a limitation on the persistence of data storage (eg, RAM versus ROM).

[0176] As used herein, “at least one of the following:” and “at least one of…” and similar expressions (wherein a list of two or more elements is connected by “and” or “or”) refer to at least any one of these elements, or at least any two or more of these elements, or at least all of these elements.

[0177] Although the subject disclosure has been described herein before with reference to examples of various embodiments thereof, the subject disclosure is not limited thereto and various modifications may be made to the subject disclosure as will be apparent to those skilled in the art.

[0178] The abbreviations used in this article have the following meanings:

[0179] 3GPP: Third Generation Partnership Project

[0180] 3GGP2: 3rd Generation Partnership Project 2

[0181] 4G: Fourth Generation

[0182] 5G: Fifth Generation

[0183] 5GC: 5G Core Network

[0184] 6G: Sixth Generation

[0185] AP: Access Point

[0186] AT: Access Token

[0187] API: Application Programming Interface

[0188] BS: Base Station

[0189] CCA: Client Certificate Assertion

[0190] CDMA: Code Division Multiple Access

[0191] EE: End-to-end (encryption)

[0192] eNB: Evolved Node B

[0193] ETSI: European Telecommunications Standards Institute

[0194] gNB: Next Generation Node B

[0195] IEEE: Institute of Electrical and Electronics Engineers

[0196] ITU: International Telecommunication Union

[0197] LTE: Long Term Evolution

[0198] LTE-A: Long Term Evolution Advanced

[0199] MAC: Medium Access Control

[0200] MANETs: Mobile Ad Hoc Networks

[0201] NB: Node B

[0202] NF: Network Function

[0203] NG-RAN: Next Generation Radio Access Network

[0204] NR: New Radio

[0205] NRF: Network Repository Function

[0206] NW: Network

[0207] OAM: Operations, Administration, and Maintenance

[0208] PLMN: Public Land Mobile Network

[0209] RAM: Random Access Memory

[0210] RAN: Radio Access Network

[0211] Rel: version

[0212] ROM: Read Only Memory

[0213] RRC: Radio Resource Control

[0214] SBA: Service Based Architecture

[0215] SCP: Service Communication Proxy

[0216] TISPAN: Telecom and Internet Convergence Services and Advanced Network Protocols

[0217] TLS: Transport Layer Security

[0218] UE: User Equipment

[0219] URI: Uniform Resource Identifier

[0220] UWB: Ultra Wideband

[0221] WCDMA: Wideband Code Division Multiple Access

[0222] WiMAX: Worldwide Interoperability for Microwave Access

[0223] WLAN: Wireless Local Area Network

Claims

1. A method for communication, comprising: Obtaining a first access token request from a network function service consumer NFc, wherein the first access token request includes an authentication code of the NFc; authenticating the NFc by checking whether the authentication code is signed by the network function service consumer NFc; issuing a second access token request to a network authorization entity or function, wherein the second access token request includes the authentication code of the NFc, and the second access token request also includes a public key of the NFc, or a hash of the public key of the NFc; Based on the above, receiving an access token from the network authorization entity or function, wherein the access token includes the public key of the NFc, or a hash of the public key of the NFc; as well as A service request is issued to a network function service provider NFp, wherein the service request includes the access token and the authentication code of the NFc.

2. The method according to claim 1, further comprising: receiving a service request including the authentication code from the NFc, and acquiring the first access token request by generating the first access token request based on the received service request; or The first access token request is obtained by receiving the first access token request from the NFc.

3. The method according to claim 1 or 2, wherein the authentication comprises: comparing the public key included in the authentication code with the public key present in the TLS connection between the serving communication proxy SCP and the NFc; and / or comparing the NF instance ID included in the authentication code with the NF instance ID present in the TLS credential information associated with the TLS connection; and / or The authentication code is signed based on the TLS certificate or via the OAuth signature private key of the NFc.

4. The method according to any one of claims 1 to 3, wherein the issuing of the second access token request comprises: adding the signature authentication code of the SCP to the second access token request; and / or The second access token request is issued to the network authorization entity or function via at least one further SCP.

5. A method for communication, comprising: receiving an access token request, the access token request including an authentication code of a network function service consumer NFc, and also including a public key of the NFc, or a hash of the public key of the NFc; authenticating the NFc based on the authentication code of the NFc; Verifying whether the public key included in the authentication code corresponds to the NFc; If it is verified that the public keys are identical, generating an access token including the public key of the NFc or a hash of the public key of the NFc; as well as The access token is issued to the NFc and / or service communication proxy SCP.

6. The method of claim 5, wherein the verification comprises: The public key included in the authentication code is compared with a public key registered at a network authorization entity or function associated with the NFc.

7. The method according to claim 5 or 6, wherein The received access request also includes an authentication code from a serving communication proxy SCP; and The verification also includes: The authentication code from the SCP is verified.

8. The method according to claim 5, wherein Generating the access token comprises: Using the public key of the NFc stored in the NRF or received in the access token request, or a hash of the public key of the NFc.

9. A method for communication, comprising: receiving a service request from a service communication proxy SCP or from a network function service consumer NFc, wherein the service request includes an access token and an authentication code of the NFc, and the access token also includes a public key of the NFc or a hash of the public key of the NFc; verifying whether the public key included in the access token is identical to the public key included in the authentication code of the NFc; and If it is verified that the public keys are identical, a service response is sent to the NFc.

10. The method according to any one of claims 1 to 4, 5 to 8 or 9, wherein the authentication code is a Client Certificate Assertion (CCA).

11. An apparatus for communication, comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: Obtaining a first access token request from a network function service consumer NFc, wherein the first access token request includes an authentication code of the NFc; authenticating the NFc based on a check whether the authentication code is signed by the network function consumer NFc; issuing a second access token request to a network authorization entity or function, wherein the second access token request includes the authentication code of the NFc, and the second access token request also includes a public key of the NFc, or a hash of the public key of the NFc; Based on the above, receiving an access token from the network authorization entity or function, wherein the access token includes the public key of the NFc, or a hash of the public key of the NFc; as well as A service request is issued to a network function service provider NFp, wherein the service request includes the access token and the authentication code of the NFc.

12. The apparatus of claim 11, wherein the apparatus is further configured to: receiving a service request including the authentication code from the NFc, and acquiring the first access token request by generating the first access token request based on the received service request; or The first access token request is obtained by receiving the first access token request from the NFc.

13. The apparatus according to claim 11 or 12, wherein the apparatus being caused to authenticate further comprises: The device is configured to: comparing the public key included in the authentication code with the public key present in the TLS connection between the device and the NFc; and / or comparing the NF instance ID included in the authentication code with the NF instance ID present in the TLS credential information associated with the TLS connection; and / or The authentication code is signed based on the TLS certificate or via the OAuth signature private key of the NFc.

14. The apparatus according to any one of claims 11 to 13, wherein the apparatus being caused to issue the second access token request further comprises: The device is configured to: adding a signature authentication code of the device to the second access token request; and / or The second access token request is issued to the network authorization entity or function via at least one serving communication proxy SCP.

15. An apparatus for communication, comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: receiving an access token request, the access token request including an authentication code of a network function service consumer NFc, and also including a public key of the NFc, or a hash of the public key of the NFc; authenticating the NFc based on the authentication code of the NFc; Verifying whether the public key included in the authentication code corresponds to the NFc; If it is verified that the public keys are identical, generating an access token including the public key of the NFc or a hash of the public key of the NFc; as well as The access token is issued to the NFc and / or service communication proxy SCP.

16. The apparatus of claim 15, wherein the apparatus is caused to verify that: The device is configured to: The public key included in the authentication code is compared with a public key registered at a network authorization entity or function associated with the NFc.

17. The device according to claim 15 or 16, wherein The received access request also includes an authentication code from a serving communication agent SCP; and The device is caused to verify that: The device is caused to verify the authentication code from the SCP.

18. The apparatus of claim 15, wherein the apparatus being caused to generate the access token comprises: Using the public key of the NFc stored in the NRF or received in the access token request, or a hash of the public key of the NFc.

19. An apparatus for communication, comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: receiving a service request from a service communication proxy SCP or from a network function service consumer NFc, wherein the service request includes an access token and an authentication code of the NFc, and the access token also includes a public key of the NFc or a hash of the public key of the NFc; verifying whether the public key included in the access token is identical to the public key included in the authentication code of the NFc; and If it is verified that the public keys are identical, a service response is sent to the NFc.

20. An apparatus according to any one of claims 11 to 14, 15 to 18 or 19, wherein the authentication code is a Client Certificate Assertion (CCA).

21. A computer program product for a computer, comprising software code portions for performing the steps of any one of claims 1 to 4, 5 to 8 or 9 when the product is run on the computer.

22. The computer program product of claim 21, wherein The computer program product comprises a computer readable medium on which the software code portions are stored, and / or The computer program product is directly loadable into the internal memory of the computer and / or transmittable via a network by means of at least one of an upload process, a download process and a push process.

Images