Methods and entities for authenticating application program interface (API) callers

Abstract

A 5G or near-5G communication system is disclosed to support higher data transmission rates than systems following 4G communication systems such as LTE. Embodiments herein disclose a method and system for authenticating application interface (API) callers using the Common Application Interface Framework (CAPIF). The method includes: upon receiving a connection request from at least one API caller to access at least one service API on a CAPIF-2e interface, establishing a secure transport layer security (TLS) connection with the at least one API caller. Furthermore, the method includes: determining at least one security method by the CCF, which will be used by the at least one API caller for CAPIF-2e Interface Security (C2eIS) of the at least one API caller to access the at least one service API on the CAPIF-2e interface. The method also includes enabling C2eIS for the at least one API caller by the API Exposure Function (AEF) based on the determined at least one security method.

Description

[0001] This case is a divisional application of the invention patent application filed on November 16, 2018, with application number 201880074510.X. Technical Field

[0002] This disclosure relates to the field of cellular communications, and more specifically, to authenticating API invokers using the Universal Application Programming Interface Framework (CAPIF). Background Technology

[0003] To meet the increased demand for wireless data services following the commercialization of fourth-generation (4G) communication systems, efforts have been made to develop and improve fifth-generation (5G) communication systems or quasi-5G communication systems. Therefore, 5G or quasi-5G communication systems are referred to as post-4G network communication systems or post-LTE systems.

[0004] To achieve high data transmission rates, the implementation of 5G communication systems in millimeter-wave bands (e.g., the 60 GHz band) is being considered. In 5G communication systems, techniques such as beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive MIMO are discussed to mitigate propagation path loss and increase propagation distance in the millimeter-wave band.

[0005] In addition, technologies such as evolved small cells, advanced small cells, cloud radio access networks (cloud RAN), ultra-dense networks, device-to-device communication (D2D), wireless backhaul, mobile networks, cooperative communication, coordinated multipoint (CoMP), and interference cancellation have been developed to improve the system network in 5G communication systems.

[0006] In addition, 5G systems have developed advanced coding and modulation (ACM) schemes such as hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC), as well as advanced access technologies such as filter bank multicarrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA). Summary of the Invention

[0007] Technical issues

[0008] Currently, the security aspects and corresponding security information flows of the Universal Application Programming Interface (CAPIF) framework interfaces (CAPIF-1, CAPIF-1e, CAPIF-2, and CAPIF-2e) are open. Therefore, various security methods are needed to support more than one authentication method and secure interface establishment method / process, as CAPIF will support a large number of services with different architectures and performance requirements. Given the above issues, a system and method for authenticating API callers is needed.

[0009] Solution

[0010] Various embodiments provide a system and method for authenticating API callers using the Common Application Programming Interface Framework (CAPIF).

[0011] In addition, various embodiments provide a system and method for establishing a secure connection between the CAPIF Core Function (CCF) and at least one API caller via the CAPIF-1e interface when a connection request for accessing at least one service API on the CAPIF-2e interface is received from at least one API caller.

[0012] In addition, various embodiments provide a system and method for determining at least one security method by the CCF, which will be used by at least one API caller for CAPIF-2e interface security (C2eIS) of at least one API caller to access at least one service API on the CAPIF-2e interface.

[0013] In addition, various embodiments provide a system and method for enabling C2eIS for at least one API caller based on at least one determined security method.

[0014] Therefore, embodiments of this document provide a method and system for authenticating application interface (API) callers using the Universal Application Interface Framework (CAPIF). The method includes, upon receiving a connection request from at least one API caller to access at least one service API on a CAPIF-2e interface, establishing a secure connection between the CAPIF Core Function (CCF) and at least one API caller, wherein establishing the secure connection between the CCF and at least one API caller is based on mutual authentication between the CCF and at least one API caller via a CAPIF-1e interface. Furthermore, the method includes: determining at least one security method by the CCF, which will be used by at least one API caller for CAPIF-2e Interface Security (C2eIS) of the at least one API caller to access at least one service API on the CAPIF-2e interface, wherein the at least one security method includes at least one of Transport Layer Security-Pre-Shared Key (TLS-PSK), TLS-Public Key Infrastructure (TLS-PKI), Internet Key Exchange Version 2 (IKEv2), Internet Protocol Security (IPsec), and OAuth 2.0. The method also includes enabling C2eIS for at least one API caller by the API Exposure Function (AEF) based on at least one determined security method. C2eIS includes at least one of authentication, interface protection, and authorization.

[0015] In this embodiment, the CCF determines at least one security method based on at least one of the following: the type of service subscribed to by the API caller, the interface type between the AEF and the API caller, the required length of the secure TLS session, the access scenario, the capabilities of the API caller, the capabilities of the AEF, the preferences of the API caller, and at least one negotiation between the API caller and the CCF. The CCF then instructs the API caller on this at least one security method. In this embodiment, the CCF also instructs the AEF on the determined at least one security method, whether requested or unsolicited, to execute the determined security method on the CAPIF-2e interface.

[0016] In one embodiment, enabling C2eIS for at least one API caller by the AEF based on at least one determined security method includes: if the determined security method is TLS-PSK, establishing a secure transport layer security (TLS) connection with at least one API caller via a CAPIF-2e interface using a pre-shared key (PSK) received from the CCF, wherein the PSK is derived by at least one of the at least one API caller and the CCF after a secure TLS connection is established between the CCF and the at least one API caller via a CAPIF-1e interface. Furthermore, receiving authorization rights from the at least one API caller from the CCF via a CAPIF-3 interface. Additionally, based on the authorization rights received from the CCF, authorizing the at least one API caller to access at least one service API.

[0017] In one embodiment, enabling C2eIS for at least one API caller by the AEF based on at least one determined security method includes: if the determined security method is TLS-PKI, establishing a secure TLS connection with the at least one API caller via the CAPIF-2e interface using mutual authentication based on client and server certificates. Furthermore, receiving authorization rights from the at least one API caller from the CCF via the CAPIF-3 interface. Additionally, based on the authorization rights received from the CCF, authorizing the at least one API caller to access at least one service API.

[0018] In one embodiment, enabling C2eIS for at least one API caller by the AEF based on at least one determined security method includes: if the determined security method is OAuth (Open Authorization: Token-Based Authentication and Authorization), establishing a secure TLS connection with at least one API caller via the CAPIF-2e interface using certificate-based mutual authentication. Furthermore, receiving a service API access request and an access token from at least one API caller, wherein the access token is generated by the CCF upon receiving the OAuth-based access token request from at least one API caller after establishing a secure TLS connection between the CCF and at least one API caller via the CAPIF-1e interface. Additionally, based on the access token received from at least one API caller, authorizing at least one API caller to access at least one service API.

[0019] In one embodiment, enabling C2eIS for at least one API caller by the AEF based on at least one determined security method includes: if the determined security method is OAuth 2.0, establishing a secure TLS connection with the at least one API caller via the CAPIF-2e interface using server certificate-based authentication. Furthermore, receiving a service API access request and an access token from the at least one API caller, wherein the access token is generated by the CCF upon receiving the OAuth 2.0-based access token request from the at least one API caller after establishing a secure TLS connection between the CCF and the at least one API caller via the CAPIF-1e interface. Additionally, based on the access token received from the at least one API caller, authorizing the at least one API caller to access at least one service API.

[0020] Therefore, embodiments of this document provide a system for authenticating application interface (API) callers using the Common Application Interface Framework (CAPIF). The system includes: a CAPIF Core Function (CCF) configured to establish a secure connection with at least one API caller upon receiving a connection request from at least one API caller to access at least one service API on a CAPIF-2e interface, wherein establishing the secure connection between the CCF and the at least one API caller is based on mutual authentication between the CCF and the at least one API caller via a CAPIF-1e interface. Furthermore, the CCF is configured to: determine at least one security method to be used by the at least one API caller for its C2eIS to access at least one service API on the CAPIF-2e interface, wherein the at least one security method includes at least one of Transport Layer Security-Pre-Shared Key (TLS-PSK), TLS-Public Key Infrastructure (TLS-PKI), Internet Key Exchange Version 2 (IKEv2), Internet Protocol Security (IPsec), application layer protection, local authorization mechanisms, and OAuth 2.0. Furthermore, the system includes an API Exposure Function (AEF) configured to enable C2eIS for at least one API caller based on at least one determined security method. In an embodiment, the at least one security method is determined based on at least one of the following: the type of service subscribed to by the API caller, the interface details between the AEF and the API caller, the access scenario, the required length of the Secure Transport Layer Security (TLS) session, the capabilities of the API caller, the capabilities of the AEF, the preferences of the API caller, and the negotiation between at least one API caller and the CCF.

[0021] These and other aspects of the exemplary embodiments herein will be better appreciated and understood when considered in conjunction with the following description and accompanying drawings. However, it should be understood that while the following description indicates exemplary embodiments and their many specific details, it is given by way of illustration rather than limitation. Many changes and modifications may be made within the scope of the exemplary embodiments without departing from the spirit of the exemplary embodiments herein, and the exemplary embodiments herein include all such modifications.

[0022] The effects of this disclosure are not limited to those described above. Furthermore, the potential effects contemplated by the technical features of this disclosure can be clearly understood from the following description.

[0023] Before proceeding with the detailed description below, it may be advantageous to define certain words and phrases used throughout this patent document: the terms “comprising” and “including” and their derivatives mean including but not limiting; the term “or” is inclusive, meaning and / or; the phrases “associated with” and “associated with” and their derivatives may mean including, including within, interconnected with, containing, contained within, connected to or connected to, coupled to or coupled to, communicable with, cooperating with, interleaved, juxtaposed, proximate, combined with or combined with, having, having the properties of, etc.; and the term “controller” means any device, system or part thereof that controls at least one operation, such device may be implemented in hardware, firmware or software or some combination of at least two of them. It should be noted that the functionality associated with any particular controller may be centralized or distributed, whether local or remote.

[0024] Furthermore, the various functions described below can be implemented or supported by one or more computer programs, each of which is formed by computer-readable program code and embodied in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, programs, functions, objects, classes, instances, associated data, or portions thereof adapted to be implemented in suitable computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" includes any type of medium accessible by a computer, such as read-only memory (ROM), random access memory (RAM), hard disk drive, optical disc (CD), digital video disc (DVD), or any other type of memory. "Non-transitory" computer-readable medium excludes wired, wireless, optical, or other communication links that transmit transient electrical or other signals. Non-transitory computer-readable medium includes media in which data can be permanently stored and media in which data can be stored and later rewritten, such as rewritable optical discs or erasable memory devices.

[0025] Definitions of certain words and phrases are provided throughout this patent document. Those skilled in the art will understand that, in many instances, if not most, such definitions apply to both prior and future use of the words and phrases defined herein. Attached Figure Description

[0026] The embodiments herein are illustrated in the accompanying drawings, and similar reference numerals indicate corresponding portions throughout the drawings. The embodiments herein will be better understood from the following description with reference to the accompanying drawings, in which:

[0027] Figure 1 A system diagram is shown according to an embodiment disclosed herein, illustrating a functional safety mechanism of the Common Application Interface Framework (CAPIF) for authenticating and authorizing API callers;

[0028] Figure 2 A sequence diagram of an embodiment disclosed herein is shown, illustrating the establishment of a secure channel for authenticating and authorizing API callers using a pre-shared key (PSK) via CAPIF-1e, CAPIF-2e, and CAPIF-3 reference points;

[0029] Figure 3 A sequence diagram of an embodiment disclosed herein is shown, illustrating the establishment of a secure channel for authenticating and authorizing API callers using certificate-based mutual authentication via CAPIF-2e and CAPIF-3 reference points;

[0030] Figure 4 A sequence diagram of an embodiment disclosed herein is shown, illustrating the establishment of a secure channel for authenticating and authorizing API callers using OAuth-based access tokens via CAPIF-1e and CAPIF-2e reference points;

[0031] Figure 5 A sequence diagram of an embodiment disclosed herein is shown, illustrating the process flow for authentication between the API caller and the API Exposure Function (AEF) prior to a service API call;

[0032] Figure 6 A sequence diagram of an embodiment disclosed herein is shown, illustrating a non-CCF (third-party based) authentication process;

[0033] Figure 7 A sequence diagram of an embodiment disclosed herein is shown, illustrating a scenario in which the CCF determines the mechanisms for authentication and authorization of API callers by the AEF and for secure communication between them.

[0034] Figure 8 The diagram illustrates a sequence of embodiments disclosed herein, showing an API caller invoking a Northbound API / service API using a Transport Layer Security Pre-Shared Key (TLS-PSK) method determined and indicated by the CCF; and

[0035] Figure 9 A sequence diagram of an embodiment disclosed herein is shown, illustrating an API caller invoking a northbound API / service API using an access token method determined and indicated by the CCF. Detailed Implementation

[0036] Exemplary embodiments herein, along with their various features and advantageous details, will be explained more fully with reference to the non-limiting embodiments illustrated in the accompanying drawings and described in detail below. Descriptions of well-known components and processing techniques have been omitted to avoid unnecessarily obscuring the embodiments herein. The description herein is intended merely to aid in understanding how the exemplary embodiments herein can be practiced and further to enable those skilled in the art to practice the exemplary embodiments herein. Therefore, this disclosure should not be construed as limiting the scope of the exemplary embodiments herein. Those skilled in the art will understand that the principles of this disclosure can be implemented in any suitably arranged system or apparatus.

[0037] In the following description, various embodiments will be illustrated with reference to the accompanying drawings. However, it should be understood that this disclosure is not intended to be limited to the specific forms disclosed herein; rather, it should be construed as covering various modifications, equivalents, and / or substitutions of the embodiments. In describing the drawings, similar reference numerals may be used to denote similar constituent elements.

[0038] As used herein, the expressions “have,” “may have,” “include,” or “may include” mean that a corresponding feature (e.g., a number, function, operation, or constituent element (such as a component)) is present, and do not exclude one or more additional features.

[0039] In this disclosure, the expressions “A or B”, “at least one of A and / or B”, or “one or more of A and / or B” can include all possible combinations of the listed items. For example, the expressions “A or B”, “at least one of A and B”, or “at least one of A or B” can include (1) at least one A, (2) at least one B, or (3) both at least one A and at least one B.

[0040] The expressions “first,” “second,” “the first,” or “the second” used in various embodiments may modify various components regardless of their order and / or importance, but do not limit the corresponding components. For example, first user equipment and second user equipment refer to different user equipment, although they are both user equipment. For example, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element, without departing from the scope of this disclosure.

[0041] It should be understood that when an element (e.g., the first element) is referred to as being (operably or communicatively) "connected" or "coupled" to another element (e.g., the second element), it can be directly connected or directly coupled to the other element, or any other element (e.g., the third element) can be inserted between them. Conversely, it can be understood that when an element (e.g., the first element) is referred to as being "directly connected" or "directly coupled" to another element (the second element), no element (e.g., the third element) is inserted between them.

[0042] As used herein, the expression “configured to” may be used interchangeably with the expressions “suitable for,” “capable of,” “designed to,” “adapted to,” “manufactured as,” or “capable of.” The term “configured to” may not necessarily mean that the hardware is “specifically designed for.” Alternatively, in some cases, the expression “device configured to…” may mean that the device, together with other devices or components, is “capable of….” For example, the phrase “adapted to (or configured to) a processor performing A, B, and C” may mean a dedicated processor (e.g., an embedded processor) used only to perform the corresponding operations, or a general-purpose processor (e.g., a central processing unit (CPU) or application processor (AP) that can perform the corresponding operations by running one or more software programs stored in a memory device.

[0043] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the disclosure. Singular expressions may include plural expressions unless they are distinctly different in the context. Unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. Terms as defined in commonly used dictionaries may be interpreted as having a meaning equivalent to that in the context of the relevant technical field and will not be construed as having an ideal or overly formal meaning unless clearly defined in this disclosure. In some cases, even terms defined in this disclosure should not be construed as excluding embodiments.

[0044] The embodiments of this paper implement a method and system for authenticating application interface (API) callers using the Common Application Interface Framework (CAPIF). The method includes establishing a secure connection with at least one API caller by the CAPIF Core Function (CCF) upon receiving a connection request from at least one API caller to access at least one service API on a CAPIF-2e interface. The establishment of the secure connection between the CCF and the at least one API caller is based on mutual authentication between the CCF and the at least one API caller via a CAPIF-1e interface. Furthermore, the method includes the CCF determining and instructing at least one security method to be used by the at least one API caller for the at least one API caller's C2eIS (i.e., authentication, interface protection, and authorization) to access at least one service API on the CAPIF-2e interface. This at least one security method includes at least one of Transport Layers Security-Pre-Shared Key (TLS-PSK), TLS-Public Key Infrastructure (TLS-PKI), IKEv2, IPsec, and OAuth. The method also includes enabling C2eIS for at least one API caller by the API Exposure Function (AEF) based on at least one determined security method. Now refer to the accompanying drawings, and more specifically to... Figures 1 to 9 An exemplary embodiment is shown, wherein similar reference numerals throughout the figures consistently denote corresponding features.

[0045] Figure 1 A system 100 diagram according to an embodiment disclosed herein is shown, illustrating a CAPIF functional safety mechanism for authenticating, protecting interfaces, and authorizing API callers 102.

[0046] System 100 includes one or more API callers 102, 104, a CAPIF Core Functionality (CCF) 106, an Application Programming Interface Exposure Functionality (AEF) 108, an API publishing function 110, and an API management function 112. In embodiments, the one or more API callers 102, 104 may be at least one of, but are not limited to, computers, laptops, mobile phones, personal digital assistants (PADs), servers, or any other device attempting to access AEF 108 to obtain one or more service APIs. In embodiments, the one or more API callers may be configured to invoke one or more service APIs existing on a network. CCF 106 is a functional entity that can be configured to aggregate all common aspects of the service APIs. CCF 106 can be configured for authentication, monitoring, logging authorization, and discovery, which are common to all service APIs. AEF 108 is an entity that can be configured to expose one or more service APIs to API callers (i.e., 102 and 104). API caller 102 may have a direct connection to AEF 108 to invoke the service APIs. However, API caller 102 may not have a direct connection to API publishing function 110 and API management function 112. API publishing function 110 can be configured to publish a library of service APIs on CCF 106. Furthermore, API management function 112 can be configured to manage functions related to logging and auditing of logs stored in CCF 106.

[0047] In this embodiment, API caller 104, residing within the Public Land Mobile Network (PLMN) trust domain, is trusted by the operator, while API caller 102, residing outside the PLMN trust domain, may not be trusted by the operator. API caller 104, trusted by the operator, may not undergo any security checks. However, API caller 102, residing outside the PLMN trust domain, may undergo a higher level of security checks.

[0048] In addition, system 100 includes one or more interfaces / reference points. The one or more interfaces include CAPIF-1, CAPIF-1e, CAPIF-2, CAPIF-2e, CAPIF-3, CAPIF-4, and CAPIF-5 interfaces. These interfaces are defined in the 3GPP TS 23.222 standard, and the CAPIF functionality is also defined in the 3GPP TS 23.222 standard. The CAPIF-1, CAPIF-2, CAPIF-3, CAPIF-4, and CAPIF-5 interfaces reside within the Public Land Mobile Network (PLMN) trust domain, while the CAPIF-1e and CAPIF-2e interfaces reside between CCF 106 and API caller 102, and between the AEF 108 access point and API caller 102, which resides outside the PLMN trust domain. The CAPIF-1, CAPIF-2, CAPIF-3, CAPIF-4 and CAPIF-5 interfaces support Transport Layer Security (TLS), as defined in the 3GPP TS 23.222 standard.

[0049] Both API callers (i.e., 102 and 104) existing within and outside the PLMN trust domain require authentication and authorization. To authenticate and authorize API caller 102, which exists outside the PLMN trust domain, CCF 106 must collaborate with AEF 108 and utilize the CAPIF-1e, CAPIF-2e, and CAPIF-3 interfaces to perform authentication and authorization for API caller 102 before granting access to the CAPIF service / service API. When API caller 104 is within the PLMN trust domain, CCF 106, collaborating with AEF 108, can perform authentication and authorization for API caller 104 via the CAPIF-1, CAPIF-2, and CAPIF-3 interfaces before granting access to the CAPIF service.

[0050] CAPIF-1 / 1-e exists between API caller 102 and CCF 106. Furthermore, system 100 authenticates API caller 102 based on its identity and credentials or by presenting a valid security token. Mutual authentication exists between the API caller and the CCF. Additionally, system 100 authorizes the API caller before accessing one or more service APIs. For CAPIF-2 / 2e between API caller 102 and AEF 108, system 100 authenticates API caller 102 based on its identity and credentials or by presenting a valid security token (OAuth). Furthermore, system 100 authorizes API caller 102 before accessing the service API. Furthermore, authorization and verification of the API caller occur when accessing the service API. Additionally, system 100 controls service API access based on policies configured by the PLMN operator. CAPIF-1e and CAPIF-2e are reference points where API caller 102 is located outside the PLMN trust domain.

[0051] Embodiments herein provide a method and system 100 for authenticating API callers using CAPIF. The method includes establishing a secure connection between CCF 106 and at least one API caller 102 upon receiving a connection request from at least one API caller 102 to access at least one service API on a CAPIF-2e interface. The secure connection established between CCF 106 and at least one API caller 102 is based on mutual authentication between CCF 104 and at least one API caller 102 via a CAPIF-1e interface. Furthermore, the method includes CCF 106 determining at least one security method to be used by at least one API caller 102 for C2eIS (i.e., authentication, interface protection, and authorization) to access at least one service API on the CAPIF-2e interface. This at least one security method includes at least one of Transport Layer Security-Pre-Shared Key (TLS-PSK), TLS-Public Key Infrastructure (TLS-PKI), Internet Key Exchange version 2 (IKEv2), Internet Protocol Security (IPsec), application layer protection, local authorization mechanisms, and OAuth. Furthermore, the method includes AEF 108 enabling C2eIS for at least one API caller 102 based on at least one determined security method. In an embodiment, the at least one security method is determined based on at least one of the following: the service type subscribed to by API caller 102, the type interface between AEF 108 and API caller 102, the access scenario, the required length of the Secure Transport Layer Security (TLS) session, the capabilities of API caller 102, the capabilities of AEF 108, the preferences of API caller 102, and negotiation between at least one API caller 102 and CCF 106. In an embodiment, whether requested or unrequested, CCF 106 instructs AEF 108 to perform the determined security method on the CAPIF-2e interface.

[0052] In one embodiment, enabling C2eIS for at least one API caller 102 by AEF 108 based on at least one determined security method includes: if the determined security method is TLS-PSK, establishing a secure TLS connection between AEF 108 and at least one API caller 102 via a CAPIF-2e interface using a PSK received from CCF 106, wherein after establishing a secure TLS connection between CCF 106 and at least one API caller 102 via a CAPIF-1e interface, a PSK is derived by at least one of the at least one API caller 102 and CCF 106. Furthermore, receiving authorization rights from at least one API caller 102 via a CAPIF-3 interface. Additionally, based on the authorization rights received from at least one API caller 102 by CCF 106, authorizing at least one API caller 102 to access at least one service API.

[0053] In this embodiment, API caller 102 discovers / identifies and directly contacts AEF 108 to obtain the service API, and then API caller 102 directly initiates authentication with AEF 108. Mutual authentication based on client and server certificates is then performed between API caller 102 and AEF 108 to establish a secure TLS connection with the assistance of CCF 106. Here, API caller 102 is either pre-configured or provisioned by CCF 106 during service discovery and obtains the information required for the specific service API. It is assumed that the determined security method and associated valid security credentials for the service are available to API caller 102, requiring a direct request to AEF 108 without contacting CCF 106. Furthermore, AEF 108 can authenticate the API caller independently of CCF (e.g., if the root certificate 106 for authenticating API caller 102 is pre-provided / available to AEF 108). After a secure TLS connection is successfully established between API caller 102 and AEF 108 on CAPIF-2e... AEF 108 requests authorization rights from CCF 106 for API caller 102 via the CAPIF-3 reference point. Furthermore, CCF 106 responds with the authorization rights of API caller 102 via CAPIF-3. Additionally, when establishing a secure TLS connection via the CAPIF-2e interface, API caller 102 invokes the applicable 3GPP Northbound API / Service API. Furthermore, AEF 108 grants API calls based on the authorization rights of API caller 102.

[0054] In one embodiment, AEF 108 enables C2eIS for at least one API caller based on at least one determined security method, including: if the determined security method is TLS-PKI, establishing a secure TLS connection with at least one API caller 102 via the CAPIF-2e interface using mutual authentication based on client and server certificates. Furthermore, receiving authorization rights from at least one API caller 102 from CCF 106 via the CAPIF-3 interface. Additionally, based on the authorization rights received from CCF 106, authorizing at least one API caller 102 to access at least one service API.

[0055] In one embodiment, AEF 108 enables C2eIS for at least one API caller 102 based on at least one determined security method, including: if the determined security method is OAuth, establishing a secure TLS connection between AEF 108 and at least one API caller 102 via the CAPIF-2e interface using at least one of certificate-based mutual authentication and server-side certificate-based authentication. Furthermore, receiving a service API access request and an access token from at least one API caller 102, wherein the access token is generated by CCF 106 upon receiving an OAuth-based access token request from at least one API caller 102 after establishing a secure TLS connection between CCF 106 and at least one API caller 102 via the CAPIF-1e interface. Additionally, based on the access token received from at least one API caller 102, authorizing at least one API caller 102 to access at least one service API.

[0056] In the embodiments, the security aspects and related information flows proposed for CAPIF are applicable to other reference points, such as the T8 interface defined for machine-type communication and the service-based architecture defined for fifth-generation (5G) systems.

[0057] Figure 1 Exemplary units of system 100 are shown, but it should be understood that other embodiments are not limited thereto. In other embodiments, system 100 may include fewer or more units. Furthermore, the labels or names of units are for illustrative purposes only and do not limit the scope of the embodiments herein. One or more units may be combined to perform the same or substantially similar functions in system 100.

[0058] Figure 2 A sequence diagram of an embodiment disclosed herein is shown, illustrating the establishment of a secure channel for authenticating and authorizing API caller 102 using PSK via CAPIF-1e, CAPIF-2e, and CAPIF-3 reference points.

[0059] according to Figure 2 The embodiments described herein establish a dedicated secure connection / session for authenticating API caller 102. Two different methods, such as a PSK-based method and a certificate-based method, can be used to establish a dedicated secure connection between API caller 102 and AEF 108. The established dedicated secure session can be used for all API calls and responses. To establish a dedicated secure session, a PSK can be derived after successful mutual authentication between CCF 106 and API caller 102 via the CAPIF-1e interface. Furthermore, the PSK can be used to establish a secure connection (e.g., TLS or IPSec) between API caller 102 and AEF 108 via the CAPIF-2e interface. The CAPIF-1e security mechanism can be used to "bootstrap" the key used to authenticate a secure TLS connection for CAPIF-2e. Without a PSK, a secure TLS session can be established via the CAPIF-2e interface using certificate-based mutual authentication between API caller 102 and AEF 108.

[0060] Figure 2 The advanced security information flow between API caller 102, CCF 106, and AEF 108 for establishing a secure channel using PSK is illustrated (for an access scenario where API caller 102 accesses AEF 108 before making a service API call). Security information is exchanged via CAPIF-1e, CAPIF-2e, and CAPIF-3 reference points, as detailed below.

[0061] In step 1, the method includes establishing a secure TLS session / connection between API caller 102 and CCF 106 via the CAPIF-1e interface. This method allows API caller 102 and CCF 106 to establish a secure TLS session / connection via the CAPIF-1e interface. The secure TLS session can be established based on mutual authentication between API caller 102 and CCF 106. Mutual authentication can be certificate-based mutual authentication (i.e., mutual authentication based on the certificates of the client (i.e., API caller 102) and the server (i.e., CCF 106)).

[0062] In step 2, the method includes deriving the PSK via the CAPIF-1e interface. This method allows API caller 102 and CCF106 to derive the PSK. After a secure TLS session is successfully established, the PSK can be derived based on the TLS session master secret, AEF108-specific parameters, session parameters, and other possible parameters. In an embodiment, the PSK deriving at CCF106 can be delayed until a request for the PSK is received from AEF108. In an embodiment, the PSK is specific to a particular AEF108 (the PSK is bound to an AEF ID). The AEF ID is a unique identifier, at least within CAPIF. AEFPSK = KDF(TLS Session Master_Secret (session master secret), TLS session parameters, AEFID, <other potential parameters>). KDF is the key deriving function. The terms AEFPSK and PSK are used interchangeably in this document.

[0063] In step 3a, the method includes initiating a secure channel establishment (TLS-PSK) request with AEF 108. This method allows API caller 102 to initiate a TLS-PSK request with AEF 108. API caller 102 initiates a secure channel establishment request with AEF 108 when exporting the PSK. In this embodiment, API caller 102 can export the PSK at any time before a secure TLS connection is established between API caller 102 and AEF 108.

[0064] In step 3b, the method includes requesting a PSK exported from API caller 108 from CCF 106 via the CAPIF-3 reference point. This method allows AEF 108 to request a PSK exported from API caller 102 from CCF 106 via the CAPIF-3 reference point.

[0065] In step 3c, the method includes receiving a PSK from CCF 106 via a CAPIF-3 reference point. This method allows AEF 108 to receive a PSK from CCF 106 via a CAPIF-3 reference point. CCF 106 can be configured to respond with an exported PSK via a CAPIF-3 reference point upon receiving a request from AEF 108. In an embodiment, CCF 106 can export the PSK and send it to AEF 108 in a notification message without any solicitation from AEF 108. In this case, it can be omitted. Figure 2 Steps 3b and 3c are shown to reduce latency.

[0066] In step 3d, the method includes establishing a secure TLS connection between API caller 102 and AEF 108 using a PSK. This method allows AEF 108 to establish a secure TLS connection between API caller 102 and AEF 108 using a PSK. The secure TLS connection between API caller 102 and AEF 108 can be established via the CAPIF-2e interface.

[0067] In step 4, the method includes requesting authorization rights from API caller 102 from CCF 106 via the CAPIF-3 reference point. This method allows AEF 108 to request authorization rights from API caller 102 from CCF 106 via the CAPIF-3 reference point.

[0068] In step 5, the method includes receiving the authorization rights of API caller 102 from CCF 106 via CAPIF-3. This method allows AEF 108 to receive the authorization rights of API caller 102 from CCF 106 via the CAPIF-3 interface.

[0069] In step 6, the method includes API caller 102 using AEF to call the applicable 3GPP Northbound API / Service API through a secure CAPIF-2e interface.

[0070] In step 7, the method includes authorizing at least one API caller 102 to access at least one service API based on authorization rights received from at least one API caller 102 from CCF 106. This method allows AEF 108 to authorize at least one API caller 102 to access at least one service API based on authorization rights received from at least one API caller 102 from CCF 108. AEF 108 grants API calls based on the authorization rights of API caller 102.

[0071] Figure 3 A sequence diagram of an embodiment disclosed herein is shown, illustrating the establishment of a secure channel for authentication and authorization of API caller 102 using certificate-based mutual authentication via CAPIF-2e and CAPIF-3 reference points.

[0072] The embodiments described herein allow for the exchange of security information via CAPIF-2e and CAPIF-3 reference points.

[0073] In step 1a, API caller 102 discovers / identifies to directly contact AEF 108 to obtain the service API, and then API caller 102 directly initiates authentication with AEF 108. Furthermore, mutual authentication based on client and server certificates is performed between API caller 102 and AEF 108 to establish a secure TLS connection with the assistance of CCF 106 (step 1b). In this scenario, the API caller is either pre-configured or provided by CCF 106 or pre-configured during service discovery and obtains the information required for the specific service API. Here, API caller 102 can directly request a connection with AEF without contacting CCF 106 (or after contacting CCF 106). After a secure TLS connection is successfully established on CAPIF-2e (i.e., between API caller 102 and AEF 108), AEF 108 requests authorization rights from API caller 102 from CCF 106 via the CAPIF-3 reference point. Furthermore, CCF106 responds with the authorized rights of API caller 102 via the CAPIF-3 reference point. Additionally, when establishing a secure TLS connection via the CAPIF-2e interface, API caller 102 invokes the applicable 3GPP Northbound API / Service API. Furthermore, AEF 108 grants API calls based on the authorized rights of the API caller.

[0074] Figure 4 A sequence diagram according to an embodiment disclosed herein is shown, illustrating the establishment of a secure channel for authentication and authorization of API caller 102 using OAuth-based access tokens via CAPIF-1e and CAPIF-2e reference points. The embodiments herein establish a secure channel via the CAPIF-1e interface. The CAPIF-2e reference point uses the access token to authorize and grant service API calls to API caller 102 of AEF 108.

[0075] Figure 4The diagram illustrates the advanced security information flow between API caller 102, CCF 106, and AEF 108. Security information can be exchanged via CAPIF-1e, CAPIF-2e, and CAPIF-3 reference points. This method is based on the OAuth 2.0 authorization framework. Referring to OAuth 2.0, CCF 106 maps to the authorization and token protocol endpoints. Furthermore, API caller 102 maps to the resource owner, client, and redirection endpoints, and AEF 108 maps to the resource server. The illustration of authentication and authorization for API caller 102 using access tokens via CAPIF-1e and CAPIF-2e reference points is based on the assumptions that the client endpoint type is registered as confidential, the authorization grant type is client credentials, and the access token is a bearer type (RFC 6750) and based on JWT (JSON Web Token).

[0076] In step 1, the method includes establishing a secure TLS session by API caller 102 and CCF 108 through the CAPIF-1e interface based on certificate-based mutual authentication. This method allows API caller 102 and CCF 106 to establish a secure TLS session based on certificate-based mutual authentication.

[0077] In step 2, the method includes requesting an access token from CCF 106 using an HTTPS request. This method allows API caller 102 to request an access token from CCF 106 using an HTTPS request. After successfully establishing a secure TLS session via CAPIF-1e, API caller 102 requests an access token from CCF 106 using an HTTPS request. The HTTPS request includes the grant type "client_credentials", the scope (the requested set of permissions), the API caller client identifier, and the key generated and shared during registration with CCF 106.

[0078] In step 3, the method includes verifying the grant request from API caller 102 against valid credentials, request type, and requested scope. This method allows CCF 106 to verify the grant request from API caller 102 against valid credentials, request type, and requested scope.

[0079] In step 4, the method includes generating an access token. This method allows CCF 106 to generate an access token. An access token can be generated after successful authorization of the request by CCF 106. The generated access token can be encoded as a JSON Web Token as defined in IETF RFC 7519. The access token may include a JSON web digital signature profile as defined in IETF RFC 7515. Furthermore, the access token is shared via a redirected Uniform Resource Identifier (URI), where the URI is given by the API caller 102 during registration with CCF 106.

[0080] In step 5, the method includes establishing a secure TLS connection with AEF 108 via a one-way authentication of the AEF 108 endpoint using a server certificate through the CAPIF-2e interface. This method allows API caller 102 to establish a secure TLS connection with AEF 108 via a one-way authentication of the AEF 108 endpoint using a server certificate through the CAPIF-2e interface.

[0081] In step 6, the method includes sending an access request / invocation for the 3GPP Northbound API / Service API and an access token to AEF 108 via the CAPIF-2e interface (for the access scenario: API caller 102 accesses AEF 108 during a Service API call). This method allows API caller 102 to send an access request / invocation for the 3GPP Northbound API / Service API and an access token to AEF 108 via the CAPIF-2e interface. The access token received from CCF 106 can be sent along with the API call request. The token is placed as a "bearer" attribute value under the "Authorization" header of the HTTPS request (API call).

[0082] In step 7, the method includes verifying the access token based on a signature that is part of the access token. This method allows AEF 108 to verify the access token based on a valid signature, which validates the API caller's request against the authorization permissions in the access token.

[0083] In step 7, upon successful verification of the access token and the authorization rights of API caller 102, the requested service API is invoked, and the appropriate result is sent as a response to API caller 102.

[0084] In this embodiment, various factors and requirements can influence the suitability of appropriate security methods (i.e., PSK and OAuth.2.0). While business requirements are likely a common factor in selecting a security method, the following criteria can be used when deciding on a security method.

[0085] Selection criteria for Method 1 (based on PSK): This method allows the establishment of a dedicated secure session. Because a dedicated secure TLS session is established (authorization occurs during session initiation), it can be used for multiple API calls, avoiding authorization verification for each call request. This method can be selected based on the following criteria / scenarios:

[0086] 1. If a secure TLS channel session requires an activity duration of a certain length (e.g., 12 hours or longer), the API caller 102 will use these sessions for API calls for a period of time instead of establishing a secure TLS connection for each request.

[0087] 2. If a rapid burst of API calls is required within a short period of time (e.g., 500 calls within 5 minutes), API caller 102 can use this method to establish a dedicated secure TLS session with AEF 108 and avoid authorization verification for each call request.

[0088] 3. If API caller 102, the CAPIF-2e reference point, or AEF 108 has strict requirements, such as minimizing message exchange size or power consumption, then API caller 102 can choose this method.

[0089] Method 2 (i.e., OAuth) selection criteria: This method is based on OAuth 2.0 and provides a framework for secure asynchronous API call requests and responses. This method can be selected based on the following criteria / scenarios:

[0090] If API calls are sparse and the need for secure sessions is short-lived, then OAuth2.0 is a good option.

[0091] If the available resources on AEF 108 are insufficient to maintain a secure TLS session after authentication, for example, due to network load or because authentication and authorization functions are offloaded as separate network entities, then OAuth 2.0 can be chosen.

[0092] Security methods (such as PSK-based, OAuth-based, or PKI-based methods) can be determined and selected based on the access scenario, the characteristics of the requested service and the constraints on the requested service, interface details (such as IP address / port), the status of the reference point, and the capabilities of the entity.

[0093] Figure 5 A sequence diagram of an embodiment disclosed herein is shown, illustrating the authentication process between API caller 102 and AEF108 prior to a service API call.

[0094] The embodiments described herein allow API caller 102 to directly contact and authenticate with AEF 108 (without requiring the prerequisites performed with CCF 106). If service discovery has already been performed, API caller 102 requests CCF 106 to provide one or more root certificates of a root certificate authority (CA) to verify one or more AEF certificates of AEF 108 discovered by API caller 102 for subsequent API calls. The CA may be hosted by the operator or trusted by the operator. Alternatively, CCF 106 provides a list of one or more root certificates of a CA to verify with API caller 102, at service discovery, during authorization, during authentication, or as a standalone / exclusive message exchange (request-response), one or more AEF certificates with (subscribed) details corresponding to AEF 108.

[0095] In one embodiment, during the service discovery process, in response to a service discovery request from API caller 102, CCF 106 provides API caller 102 with details about AEF 108. Details of AEF 108 include security parameters (e.g., authentication method, root certificate of the CA used to verify the AEF certificate, token, lifetime of the security certificate (token)) and access methods (based on CAPIF (authenticated by CCF before the service request), using TLS-PSK or TLS-certificate or based on access token or TLS-public key encryption), based on a third-party token). In another embodiment, API caller 102 may include its preference for authentication methods (e.g., based on the predictable frequency of service requests) in the service discovery request. Upon receiving a request from API caller 102, CCF 106 considers API caller 102's preferences and other criteria to determine the authentication method. In response to this request, CCF 106 indicates the selected authentication method to API caller 102. In one embodiment, the indication (selected authentication method and reference point protection (interface security)) is included in the secure TLS connection request / protocol.

[0096] according to Figure 5 Before invoking the northbound API / service API, API caller 102 authenticates with AEF 108. In this scenario, either a security PSK-based or certificate-based secure connection establishment method can be used. The PSK-based or certificate-based methods illustrate the process for API caller 102 to authenticate with AEF 108 and establish a TLS session to protect subsequent API calls.

[0097] Figure 6A sequence diagram of an embodiment disclosed herein is shown, illustrating a non-CCF (third-party based) authentication process. The embodiments herein provide a non-CCF (third-party based) authentication process to secure the interface between API caller 102 and AEF 108. In this scenario, the API caller obtains the information required for a specific service API, either pre-configured or provided by CCF 106 or during service discovery. Furthermore, this request needs to be made directly to AEF 108 without contacting CCF 106 (or after contacting CCF 106).

[0098] Figure 7 A sequence diagram of an embodiment disclosed herein is shown, illustrating a scenario in which the CCF determines the mechanisms for authentication and authorization of API caller 102 for AEF108 and for secure communication between them.

[0099] In step 1, API caller 102 and CCF 106 establish a secure communication channel, such as TLS, using mutual authentication based on client and server certificates.

[0100] In step 2, API caller 102 sends a security method request to CCF 106. The request to CCF 106 includes the API caller ID, details of AEF 108 such as service details, interface details, northbound API details, and API caller 102's preferred security method.

[0101] In step 3, CCF 106 selects the security method to be used by AEF 108 to authenticate and authorize API caller 102. This selection takes into account the information received from API caller 102 in step 2.

[0102] In an embodiment, CCF 106 selects at least one of the following security methods for each requested interface of all requested AEFs: PSK-based, PKI-based, OAuth 2.0-based, IKEv2-based, IPsec-based, application-layer security-based, or similar.

[0103] In an embodiment, the authentication method may be determined based on at least one of the following parameters: the type of service subscribed to by API caller 102, interface details (such as IP address / port), the protocol between AEF 108 and API caller 102, when access to a specific service is requested (when multiple services are subscribed), based on a time-based scenario (subscribed API), based on the required duration of the TLS session, the capabilities of the API caller, the capabilities of AEF 108, based on requests from API caller 102 (based on user input, usage time, and the number of previously known requests), and the specific method is selected by CCF 106 (per AEF or per API caller) and instructed to API caller 102.

[0104] In this embodiment, the method by which AEF 108 performs secure communication, authentication, and authorization for API caller 102 is associated with the service API interface details of AEF 108. That is, if the service requires, the same service API hosted on two or more API interfaces of the same (or different) AEF 108 can have different security methods corresponding to each API interface. CCF 106 takes this information into account when determining the security method.

[0105] In step 4, CCF 106 sends a security method response to API caller 102, indicating the selected security method for each AEF 108 (or each service API interface of one or more AEFs), and any security information associated with the selected security method (e.g., pre-shared keys for establishing TLS and / or IPsec directly and / or IPsec via IKEv2, etc.). API caller 102 will use this selected security method in subsequent communication with one or more AEFs 108.

[0106] Figure 8 A sequence diagram of an embodiment disclosed herein is shown, illustrating an API caller 102 invoking a northbound API / service API using a TLS-PSK method determined and indicated by CCF 106.

[0107] CCF 106 can send an authentication response to API caller 102. Additionally, API caller 102 sends an authenticated service API call request to AEF 108. Furthermore, it obtains API caller 102 information for authentication. Furthermore, AEF performs verification and authentication based on the PSK. Finally, AEF provides a service API call response to API caller 102.

[0108] Figure 9A sequence diagram of an embodiment disclosed herein is shown, illustrating an API caller 102 invoking a northbound API / service API using an access token method determined and indicated by CCF 106.

[0109] according to Figure 9 The CCF 106 shares the authentication response with API caller 102 based on the authentication request from API caller 102. Furthermore, API caller 102 presents a service API call request with authentication information to AEF-2 108. AEF-2 108 can also be configured to receive API caller 102 information for authentication. AEF-2 108 performs authentication and verification based on the token presented by API caller 102 and establishes a secure TLS connection between API caller 102 and AEF 108. Based on the authentication and verification, AEF-2 108 provides the service API call response.

[0110] The embodiments disclosed herein can be implemented by at least one software program that runs on at least one hardware device and performs network management functions to control the element. Figure 1 The elements shown can be at least one of hardware devices or a combination of hardware devices and software modules. For example, the embodiments disclosed herein can be implemented in a network entity of the Management Network Exposure Function (NEF) in a 5G core network, and the network entity can be implemented as a server including a transceiver and a processor configured to process the disclosed NEF-related processes.

[0111] The foregoing description of the specific embodiments so fully reveals the general nature of the embodiments herein that others can readily modify and / or adapt such specific embodiments by applying present knowledge without departing from the general concept. Therefore, such adaptations and modifications should and are intended to be understood as being within the meaning and scope of equivalents of the disclosed embodiments. It should be understood that the wording or terminology used herein is for descriptive purposes and not for limitation. Thus, although embodiments herein have been described with reference to examples, those skilled in the art will recognize that the embodiments herein can be practiced with modifications within the spirit and scope of the embodiments described herein.

Claims

1. A method performed by a first entity that implements the Authentication Application Programming Interface (AEF) exposure functionality, the method comprising: Receive authentication request messages from the second entity that implements the API caller; Send a security information request for authentication between the first and second entities to a third entity that implements the core functionality of the Common Application Programming Interface Framework (CAPIF) CCF. Security information is received from a third entity in connection with a security method used for authentication between the first and second entities, wherein the security information includes a pre-shared key (PSK) bound to an identifier of the first entity; and Use PSK to establish a transport layer secure TLS session between the first and second entities. Specifically, PSK is exported after TLS is successfully established on the interface between the second and third entities.

2. The method as described in claim 1, wherein, This security method corresponds to the access scenarios and capabilities of the second entity, and The access scenario indicates whether the second entity accesses the first entity before the service API call.

3. The method as described in claim 1, wherein, This security method is used to provide authentication, integrity protection, and authorization for a second entity.

4. The method as described in claim 1, in, The authentication between the first entity and the second entity is performed using this PSK.

5. A method performed by a third entity that implements the core functionality of the Universal Application Programming Interface Framework (CAPIF) CCF, the method comprising: The first entity, which implements the Authentication Application Programming Interface (AEF) exposure function, receives a security information request for authentication between itself and a second entity that implements the API caller; and Send security information to the first entity that is associated with the security method used for authentication between the first entity and the second entity. in, This security information includes a pre-shared key (PSK) bound to the identifier of the first entity. Specifically, PSK is exported after TLS is successfully established on the interface between the second and third entities.

6. The method of claim 5, wherein, Receiving security information requests also includes identifying the security method based on the access scenario and capabilities of the second entity. The access scenario indicates whether the second entity accesses the first entity before the service API call.

7. The method of claim 5, wherein, This security method is used to provide authentication, integrity protection, and authorization for a second entity.

8. A first entity that implements the Authentication Application Programming Interface (AEF) exposure function, the first entity comprising: transceiver; as well as The controller, coupled to the transceiver, is configured to: Receive authentication request messages from the second entity that implements the API caller. Send a security information request for authentication between the first and second entities to a third entity that implements the core functionality of the CAPIF (Common Application Programming Interface) framework (CCF). Security information is received from a third entity in connection with a security method for authentication between the first and second entities, wherein the security information includes a pre-shared key (PSK) bound to an identifier of the first entity; and Use PSK to establish a transport layer secure TLS session between the first and second entities. Specifically, PSK is exported after TLS is successfully established on the interface between the second and third entities.

9. The first entity as claimed in claim 8, wherein, This security method corresponds to the access scenarios and capabilities of the second entity, and The access scenario indicates whether the second entity accesses the first entity before the service API call.

10. The first entity as claimed in claim 8, wherein, This security method is used to provide authentication, integrity protection, and authorization for a second entity.

11. The first entity as described in claim 8, in, The authentication between the first entity and the second entity is performed using this PSK.

12. A third entity that implements the core functionality CCF of the Universal Application Programming Interface (CAPIF) framework, the third entity comprising: transceiver; and The controller, coupled to the transceiver, is configured to: The first entity, which implements the Authentication Application Programming Interface (AEF), receives a security information request for authentication between itself and a second entity that implements the API caller. Send security information to the first entity that is associated with the security method used for authentication between the first entity and the second entity. in, This security information includes a pre-shared key (PSK) bound to the identifier of the first entity. Specifically, PSK is exported after TLS is successfully established on the interface between the second and third entities.

13. The third entity as claimed in claim 12, wherein, The controller is configured to identify the security method based on the access scenario and capabilities of the second entity. The access scenario indicates whether the second entity accesses the first entity before the service API call.

14. The third entity as claimed in claim 12, wherein, This security method is used to provide authentication, integrity protection, and authorization for a second entity.

Images