The present invention relates to a communication system. The invention has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof. The invention has particular although not exclusive relevance to security procedures in the so-called ‘5G’ (or ‘Next Generation’) systems.
In the past, multiple working groups (WGs) in 3GPP have defined different solutions to support northbound API interface external to 3GPP system. Those specifications were triggered by specific needs without coordination with one another. This led to the multiple incompatible API definitions addressing specific needs. Most recently, 3GPP SA2 is defining northbound API to allow external entities to access services provided by the 3GPP system via Service Capability Exposing Function (SCEF). 3GPP is defining the API for SCEF due to the request by an external SDO such as one M2M.
Up to this point, 3GPP has not defined a common framework to provide access to the services provided by the 3GPP system to the external entities via API. The SCEF in LTE and the NEF in 5G are two examples that can utilize such common framework.
To address this situation, in Release 15, 3GPP SA6 WG specified a stage 2 specification (TS 23.222 [2]) to define the common API framework (CAPIF) architecture which can be used by any future API definitions in 3GPP. This stage-2 Technical Specification (TS) defines the architecture of how the 3rd party API provider can provide its service to the user. The Study done prior to this normative work is summarized in 3GPP Technical Report (TR) 23.722 [1] and it was used as the base for the following normative specification TS 23.222 [2]. This stage-2 specification was completed in December 2017.
Currently 3GPP SA3 has an ongoing work item (WI) to define the security aspect of CAPIF. The corresponding SA3 TS is 33.122 [3].
There are several issues from the security perspective according to the specification in [2] and [3]. They are described as follows:
(i) API Invoker Onboarding
(ii) API Invoker Offboarding
(iii) Publish Service APIs
(iv) Unpublish Service APIs
(v) Update service APIs
(vi) Service APIs Discovery
(vii) API invoker obtaining authorization from CAPIF core function (CCF) to access service API
(viii) Authentication Between API Invoker and API Exposing Function (AEF) Upon the Service Invocation
(ix) Retrieve Service APIs
(x) CAPIF Event Subscription
(xi) CAPIF Event Unsubscription
(xii) API Invoker Authorization to Access Service APIs
(xiii) API Invoker Authentication
The present document describes some exemplary security procedures for CAPIF to solve or at least alleviate one or more security issues, including but not limited to the following: (i) API invoker Onboarding, (ii) API invoker Offboarding, (iii) Service API publishing, (iv) Service API unpublishing, (v) Update service APIs, (vi) Service API discovery, (vii) API invoker obtaining authorization from CAPIF core function (CCF) to access service API, (viii) Authentication between API invoker and API exposing function (AEF) upon the service invocation, (ix) Retrieve service APIs, (x) CAPIF event subscription, (xi) CAPIF event unsubscription, (xii) API invoker authorization to access service APIs, and (xiii) API invoker authentication.
As one aspect of the present disclosure, a device includes: a transmitter configured to send an Onboard API invoker request message to an application server after authentication using TLS with the application server; and a receiver configured to receive an Onboard API invoker response message from the application server, the Onboard API invoker response message including an application server related API invoker ID which is assigned by the application server.
As another aspect of the present disclosure, an application server includes:
As another aspect of the present disclosure, an information processing method in a device includes:
As another aspect of the present disclosure, an information processing method in an application server includes:
In
A detailed description of the security procedures corresponding to the problems mentioned above are presented as follows in subsections 2.1 to 2.13 respectively.
To make the description clear, the proposed parameters in this section (including the figures) are shown in bold fonts or underlined in the following CAPIF security procedures. However, the present invention is not limited to the points highlighted in the figures. All the CAPIF security procedures (all the parameters involved in the procedures) stated from section 2.1 to section 2.13 are confidentiality and/or integrity protected by a security context derived from any of the preceding authentication or authorization procedure between the communicating entities in the CAPIF.
Description in this section corresponds to the procedure described in TS 23.222 [2] subclause 8.1.
Authorization and onboard token can be generated using one or more information. The following describes one example of how this token can be generated. However, other generation methods using other type of information are not excluded.
Variant for Onboard Token generation: Onboard token generation shall be bound to any combination of the following: API provider ID/CAPIF core function Specific API Invoker ID∥CAPIF ID∥Onboarded Subscription Type∥Discovery level∥Lifetime∥Secret.
Variant for secret or secret random number: Can be any random number generated by the CCF 21 which can be pre-provisioned.
There is an authentication/authorization procedure between the API invoker 20 (Device or subscriber or subscription) and the CAPIF core function 21/network prior to the API invoker onboarding process using TLS or any related authentication mechanism such as EAP-AKA′ or 5G AKA or any security method. For example, the security context that is established as a part of the NAS signaling, e.g. UE attach procedure, can be shared with the application layer (i.e. between the API invoker 20 and the CAPIF core function 21) after the mutual authentication between the UE and the network is established. The security context required to secure onboarding procedure is explicitly derived from the security context derived for NAS signaling protection. That security context can be used to derive CAPIF Onboard protection keys to confidentiality and/or integrity protect the Onboarding message exchanges (Parameters or information elements involved in the onboarding process) between the API invoker 20 and the CCF 21.
Variant: The security context required to confidentiality or integrity protect the onboarding message exchanges between the API invoker 20 and the CAPIF core function 21 or parameters discussed in section 2.1-Security procedure for API invoker Onboarding or
1. The API invoker 20 sends the Onboarding API invoker request to the CAPIF core function 21 with the API Invoker Information along with the subscription identification information, subscription identifier, subscriber identifier or device identifier, user or device specific application identifier, requested subscription type, its locations Trust Zone Level Indication or zone identifier (Zone ID) and the maximum or minimum Onboarding Lifetime (Optional parameter).
2. The CAPIF core function (CCF) 21 on receiving the API invoker Information verifies if that particular API invoker 20 is previously onboarded or not. If the API invoker 20 is already onboarded to the CCF 21, it ignores the Onboarding API invoker request message. If the API invoker 20 is not previously onboarded, the CCF 21 verifies the received API Invoker's subscription related information and received Zone ID related trust information, the trust level of both API invoker 20 and/or its location/network information or the trust value of access point through which the API invoker connects with the network/trust value of the zone from which the API invoker connects with the network it has received in Onboarding API invoker request message with its stored information. If the verification is successful and if the API invoker requested an onboarding lifetime, then the CCF 21 assigns an Onboarding lifetime for the API invoker 20 based on the verification results and stores the API provided information and the onboarding results for later usage (To set the API invoker service discoverability). Based on the trust level and onboarding results, a subscription to the onboarding/registration and the level of topology hiding for service API discovery are determined and relevant data is stored at the CCF 21. As the onboarding lifetime parameter requested by the API invoker 20 can be optional, the CCF 21 will determine an onboarding lifetime based on the API invoker Information, trust level of API invoker's residing zone, subscription verification and its policy. The CCF 21 determines the Onboarding lifetime value if it is requested by the API invoker 20.
3. If the API invoker 20 is successfully granted onboarding, then the CCF 21 sends the Onboard API invoker response message with Success Indication, CAPIF ID (CAPIF/CCF related Identifier that can identify uniquely to which CAPIF or CCF 21 does an API invoker 20 got onboarded) , CAPIF specific API Invoker ID (CAPIF core function or CAPIF hosted operator specific API invoker ID), Onboarding Lifetime, Authorization/Onboard Token (To support further authentication/authorization between API invoker 20 and CCF 21/AEF 22) and the Service API Availability notification. The CAPIF specific API Invoker ID is the CCF associated API invoker identifier assigned by the CCF 21 after a successful onboarding process. This CAPIF core function specific API Invoker ID remains the same throughout the onboarding lifetime. The Onboard token is a secret token that is required to be sent by the onboarded API invoker 20 while sending the authentication request as a token of successful onboarding. The onboard token remains the same for the onboarding lifetime. The authorization token given to the API invoker 20 is a dynamic secret which will be updated after every authentication with a CCF 21 during an onboarding lifetime. On a successful onboarding, the applicable or Service API Availability notification parameter contains the list of all service API (names and/or identifiers and/or type) that is discoverable for/invoked by the API invoker 20.
4. On a successful onboarding, the API invoker 20 stores the CCF provided service API list that it is liable to invoke/or managed by the CAPIF as the Onboarded Service API List.
The TS 33.122 describes the authentication and authorization procedure between the API invoker 20 and the AEF 22 in clause 5.2.2.1 Method 1—Using TLS-PSK. Where the API invoker 20 and API exposing function 22 establish dedicated secure session using TLS connection based on Pre-Shared Key. After successful establishment of TLS on CAPIF-1e, the API invoker 20 and the CAPIF core function 21 shall derive the key AEFPSK.
Proposal: The AEFPSK can be bounded to the CAPIF core function specific API invoker identity, Onboarding token, CAPIF identity, Authorization Token and the AEF identity
Description in this section corresponds to the procedure described in TS 23.222 [2] subclause 8.2.
1. The API invoker 20 triggers offboard API invoker request to the CAPIF core function 21, providing the CAPIF ID, CAPIF specific API Invoker ID, Authorization token/Onboard token as required by the CCF 21 for API management
2. The CCF 21 verifies if the requesting API invoker 20 is the genuine one to offboard the claimed onboarded API invoker 20 with CAPIF API Invoker ID. If the verification is successful, the CAPIF core function 21 cancels the enrollment of the API invoker 20 from CAPIF. The API invoker 20 ceases to be a recognized user of the CAPIF. All the authorizations and related information corresponding to the API invoker 20 are deleted from CAPIF. Optionally, the information of API invoker 20 may be retained at the CAPIF core function 21 as per the operator policy.
3. The CAPIF core function 21 returns the offboard API invoker response message, providing successful offboarding indication to the API invoker 20.
1. The CCF 21 sends the API invoker Offboard notification message to the API invoker 20. The reason of this action includes situations such as the API invoker management function or CAPIF finding the act of API invoker 20 over service API accesses as unintended or unacceptable or rogue. The API invoker Offboard notification message contains the CAPIF ID, CAPIF specific API Invoker ID/information and the reason for offboarding.
2. The API invoker 20 after receiving the API invoker Offboard notification message, verifies the CAPIF ID, CAPIF specific API Invoker ID and the received Authorization/Onboard Token with the stored information to prevent masquerading attack.
3. If the verification is successful, the API invoker 20 sends API invoker offboard acknowledgement message to positively acknowledges the offboarding notification to the CCF 21.
4. The CAPIF cancels the API invoker enrollment after receiving the API invoker offboard acknowledgement message from the API invoker 20.
Description in this section corresponds to the procedure described in TS 23.222 [2] subclause 8.3.
On a successful verification of the publisher ID and the SLA, the CCF assigns a unique CAPIF specific Service API Identifier (Service API ID) corresponding to the publishing of requested service API. Moreover Publish token can be generated by the CCF 21 using one or more information as stated below. The following describes one example of how this token can be generated. However, other generation methods using other type of information are not excluded.
1. API publishing function (APF) 23 sends the Service API publish request with Publish Period along with other parameters such as API publisher ID/APF ID, authentication and authorization information (if any) specific to the service API type, service API information and an indicator to indicate the level of security required for the Service API to be maintained by the CCF 21 while publishing to the API invokers.
2. The CCF 21 on receiving the Service API publish request message verifies the authorization information (related to security context (1) pre-shared during an authentication or authorization or (2) pre-configured), API Publisher ID/APF ID based on the SLA and verify with the API provider. The CCF 21 also set a publish period for notified the Service API ID based on the trust, SLA and the requested publish period. After the successful verification, the CCF 21 generates a publish token for the requesting API publishing function 23 and generates/assigns a unique CAPIF specific Service API ID for the published service API. Then the CCF 21 stores the API information along with the publish token, APF ID, Service API ID and the security requirement indicator corresponding to the Service API provided by the APF 23.
3. If the verification is successful, the CCF 21 sends the Service API publish response message to the APF 23 with success indication, the publish token, Service API ID and the approved publish period.
4. The APF 23 stores the received Service API ID, publish period and the corresponding publish token for further processing such as unpublishing, service API retrieval and updations.
Description in this section corresponds to the procedure described in TS 23.222 [2] subclause 8.4.
The generation of the publish token is described in section 2.3. The publish token is used by the APF 23 to unPublish service APIs from the CCF 21.
1. API publishing function (APF) 23 sends the Service API unpublish request message with the publish token (as derived in the section 2.3) and previously published CAPIF specific Service API ID/Service API related information along with other parameters such as API publisher ID/APF ID, authentication and authorization information.
2. The CCF 21 on receiving the Service API unpublish request message, using the Service API ID, CCF identifies the service API related stored information, then verifies the API Publisher ID based on the SLA and also verifies the publish token as a proof for authorization to request unpublishing of service APIs and if the verification is successful, the CCF 21 removes the mentioned Service APIs from the list of available APIs.
3. If publish token verification is successful, the CCF 21 sends the Service API unpublish response message to the APF 23 with success indication, CAPIF ID, Unpublished Service API IDs and related information as an acknowledgement to the APF 23.
The generation of the publish token is described in section 2.3. The publish token is used by the APF 23 to update service APIs from the CCF 21.
Variant 1: The publish token is pre-shared during the authentication/authorization between the CAPIF core function 21 and the API provider/publisher.
Variant 2: publish token is derived using a key/SECRET derived after a successful authentication between CCF 21 and API publisher to be used as the authentication or authorization information to update the published Service API(s) at the CCF 21 by the APF 23.
Description in this section corresponds to the procedure described in TS 23.222 [2] subclause 8.6.
1. The API publishing function 23 sends a service API update request to the CAPIF core function 21, which includes the API publisher ID, the publish token, Service API ID (type/name/ID) provided by the CCF 21 after a successful publication of the service API.
2. Upon receiving the service API update request, the CAPIF core function 21 checks the publish token and/or Service API ID (type/name/ID) and the API publisher ID to verify whether the API publishing function 23 is authorized to update the published service APIs information. If the check is successful, the service API information provided by the API publishing function 23 is updated at the CAPIF core function 21 (API registry).
3. The CAPIF core function 21 provides a service API update response message to the API publishing function 23 along with the CAPIF ID and the updated Service API ID(s) (type/name/ID) and triggers notifications to subscribed API invokers.
Description in this section corresponds to the procedure described in TS 23.222 [2] subclause 8.7.
1. The API invoker 20 sends the Service API discover request message to the CCF 21 with API invoker identity information (CAPIF API Invoker ID and/or its related credentials), Authorization Token (it is the onboard token itself or a token derived from the Onboard token), Zone id (API invoker's current network or location), and other Query information: Criteria for discovering matching service APIs (e.g. API type, interfaces, protocols).
2. The CCF 21, on receiving the Service API discover request message, verifies the CAPIF specific API Invoker ID, its stored Onboarding result, Trust level of API invoker and Zone/network/location corresponding to the Zone ID from where the API invoker resides and Authorization Token (it is bounded to the onboard token and/or CAPIF API ID and/or CAPIF ID) and if the verification is successful, the CCF 21 retrieves the service API(s) information based on the verification results.
3. If the verification is successful, the CCF 21 sends the Service API discover response message to the API invoker 20 along with Result, Service API information. Based on the verification of the trust level of the API invoker 20 and/or its API invoker Zone, or User/API invoker/application specific subscription information stored at the CCF 21, the Discovery of Service API level for an API invoker 20 is decided and Topology is hidden accordingly.
Description in this section corresponds to the procedure described in TS 23.222 [2] subclause 8.11.
Invocation token generation:
Variant: The invocation token is otherwise termed as service API invocation token or Service API access token or API invoker authorization token or Service API authorization token. Either case, the assignment of this token to the API invoker signifies that the API invoker 20 is authorized and given permission to access the service API.
1. The API invoker 20 sends the service API authorization request message to the CAPIF core function 21 for obtaining permission to access the service API by including the API invoker information such as CAPIF specific API Invoker ID, Authorization token derived from the initial/CAPIF 1e/CAPIF 2e authentication (e.g. TLS), Authentication/Authorization counter, Timestamp (or Nonce), Requested Service type/name/API ID(s) and any related information required for authentication/authorization of the API invoker 20.
2. The CAPIF core function 21 validates the authentication of the API invoker 20 (using authentication information) by verifying the CAPIF API Invoker ID, Authorization token, Authentication/Authorization counter received with the one managed with the CCF 21 and also this can prevent resource exhaustion. Based on the verification results and the user or user application or API invoker specific subscription information received from the API invoker 20, the CCF 21 checks the locally-stored subscription information, the CCF 21 decides whether the API invoker 20 can be authorized to access the requested service type/name/API.
3. The authorization information to access the service APIs is sent to the API invoker 20 by the CCF 21 in the service API authorization response message along with service API Invocation Token for subsequent API invoker authentication/authorization with AEF 22, Refresh token to get a new Invocation/Access Token after its lifetime or validity period, Accepted/Applicable Service API(s) Indicator and related Information (Service API type and/or ID/name), and AEF Auth Token to support further mutual authentication between API invoker 20 and the AEF 22.
The API invoker 20 obtains authorization per user (specific to an application)/subscriber/subscription of a human user from the CCF 21 to request access for service APIs from the related AEF 22.
The security procedure is similar to the one described in the section 2.7.
Additionally, the service API authorization request message sent by the API invoker 20 also contains the user specific identifier/subscriber identification information/subscription identification information. Along with the other verifications described in section 2.7, the CCF 21 also verifies the received user specific identifier/subscriber identification information/subscription identification information to provide the authorization information such as invocation token and refresh token. If the verification is successful, the CCF 21 sends the authorization information such as invocation token and/or refresh token to the API invoker 20
The authorization information until expiry is used by the API invoker 20 for one or any number of authentications with the AEF 22 upon the service invocation.
API invoker 20 may correspond to a UE or device shared by multiple users as opposed to a specific user. The security procedure is similar to the one described in the section 2.6. In addition to this, the API invoker 20 obtains authorization from the CCF 21 to request access for service APIs from the related AEF 22 by providing its CAPIF specific API Invoker ID and/or the onboard token received after a successful onboarding with the specific CAPIF or CCF in the service API authorization request message.
The CCF 21 verifies the CAPIF specific API Invoker ID and/or the onboard token received from the API invoker 20 to the information it stored with itself to provide the authorization information such as invocation token and refresh token. If the verification is successful, the CCF 21 sends the authorization information such as invocation token and/or refresh token to the API invoker 20.
The authorization information until expiry is used by the authorized API invoker for one or any number of authentications with the AEF 22 upon the same or different service (API) invocation.
Once an API invoker 20 gets authorization from a CCF 21, it is not required for that specific API invoker 20 to perform authorization with the same CCF 21 for any further service invocation with its AEF 22.
Variant 3: Authorization Per Service API level
The security procedure is similar to the one described in the section 2.6. In addition to this, the API invoker 20 obtains authorization from the CCF 21 to request access for service APIs from the related AEF 22 by providing its CAPIF specific API Invoker ID, Service API ID(s) (type/name/identifier) and/or the onboard token received after a successful onboarding with the specific CAPIF or CCF in the obtain service API authorization request message.
The CCF 21 verifies the CAPIF specific API Invoker ID, Service API ID(s) (type/name/identifier) and/or the onboard token received from the API invoker 20 to the information it stored with itself to provide the authorization information such as invocation token and refresh token. The CCF 21 also verifies if the API invoker 20 is eligible to receive authorization for the requested Service API ID(s) (type/name/identifier). If the verification is successful, the CCF 21 sends the authorization information such as invocation token and/or refresh token to the API invoker 20.
The authorization information until expiry is used by the authorized API invoker 20 for one or any number of authentications with the AEF 22 upon the same or similar (Service API ID(s) (type/name/identifier) service invocation.
For every different service (type/name/identifier), the API invoker 20 obtains authorization from the CAPIF core function (CCF) 21 as described in the security procedure in section 2.6.
Description in this section corresponds to the procedure described in TS 23.222 [2] sub clause 8.15.
1. The API invoker 20 sends the Service API invocation request message with authentication information such as CAPIF API Invoker ID, Invocation token* (derived as shown in
2. The AEF 22 on receiving the Service API invocation request message, it further obtains the API invoker related information such as CAPIF API Invoker ID, authorization information such as Invocation/authorization token or invocation token*, the Requested/Required/Applicable service API(s) related identification (name/type/ID) information, trust level of the API invoker/API invoker's residing zone and the AEF Auth Token from the CCF 21 to perform mutual authentication between API invoker 20 and AEF 22.
3. The AEF 22 performs the Identity verification and authentication of the API invoker 20 based on the information it obtained from the CCF 21. Also, the AEF 22 verifies the CAPIF API Invoker ID, Invocation token/Invocation token* and the requested Service API(s) Indicator to check if the API invoker 20 with its subscription is liable to access the requested Service API (type/name/ID).
4. If the verification is successful, AEF 22 sends the Service API invocation response message with the AEF Auth Token received from CCF 21 and accepted Service API(s) with its ID and related information, assigned Service API(s) Invocation Count (Based on subscription, trust level of API invoker/its Zone, Associated CAPIF, System load, no. of active users, duration etc.).
5. The API invoker 20 verifies the received AEF Auth token to verify the authenticity/authorization of the AEF 22 and if the verification is successful, the API invoker 20 invokes the accepted Service API(s). This ensures mutual authentication between the API invoker 20 and the AEF 22 upon service invocation.
Variant: Instead of using invocation Token* as the authorization proof from API invoker 20, the authorization proof can be any secret such as invocation key* or invocation secret*. The API invoker 20, CCF 21 or AEF 22 uses any function such as token derivation function (TDS) for invocation token* generation, key derivation function for invocation key* generation or any function to generate invocation secret* generation respectively.
Variant: Invocation token* or invocation key* or invocation secret*can be derived using any Service API related information, Invocation token/access token received from CCF 21, CAPIF API ID, CAPIF ID, Invocation count specific to the service type/ID/name. Combination of any one or more of the listed parameters is used in the Invocation Token* or invocation key* or invocation secret* derivation.
Description in this section corresponds to the procedure described in TS 23.222 [2] subclause 8.5.
The generation of the publish token is described in section 2.3. The publish token provided by the CCF 21 during service API publish procedure as described in section 2.3 of the present document is used as the authorization information by the APF 23 to retrieve service APIs from the CCF 21. The security procedure corresponding to the TS 23.222, clause 8.5 is discussed below:
1. The API publishing function 23 sends a service API get request to the CAPIF core function 21, with API publisher information, publish token, service API ID corresponding to the service API published information reference provided by CAPIF core function 21 when the service API was published.
2. Upon receiving the service API get request, the CCF retrieves the API information based on the Service API ID(s) and the CAPIF core function 21 checks whether the API publishing function 23 is authorized to retrieve the published service APIs information. If the check is successful, the corresponding service API information is retrieved from the CAPIF core function 21 (API registry) by the API publishing function 23.
3. The CAPIF core function 21 provides a service API get response to the API publishing function 23 which includes the service API information and the CAPIF ID.
Description in this section corresponds to the procedure described in TS 23.222 [2] sub clause 8.8.3.
In the following figure, the “subscriber entity” refers to entities that use the service of the CAPIF core function 21. These “subscriber entity” includes entity such as: 1) API invoker 20, 2) API exposing function 22, 3) API publishing function 23, and 4) API management function 24.
The subscription Token/Key is derived using any combination of the following one or more parameters:
Onboard token provided by the CCF 21 after a successful onboarding (in case an API invoker 20 is a subscriber entity), Subscriber ID (in case other subscriber entity), Subscription ID, Subscriber entity ID, CAPIF Event ID, CAPIF ID, subscription code/keyword, Service API type/Name/ID, any pre-shared Secret, any key/token derived using initial authentication/authorization between API invoker 20/Subscriber entity and CCF 21.
If the subscriber entity is an API invoker 20, then the authorization token is derived and shared by the CCF 21 during an onboarding process for the API invoker 20. The method to derive the authorization token for the API invoker 20 is described in section 2.1. If the subscriber entity is any of the other types as described earlier in this section, then the authorization token is derived during a successful registration procedure.
The authorization token is derived using any combination of the following one or more parameters:
Description in this section corresponds to the procedure described in TS 23.222 [2] sub clause 8.8.3.
1. The subscribing entity sends an event subscription request to the CAPIF core function 21 along with the subscribing entity identifier, authorization token, event type, service API ID, Service API name in order to receive notification of events.
2. Upon receiving the event subscription request from the subscribing entity, the CAPIF core function 21 checks for the relevant authorization for the event subscription. The CCF 21 validates the authorization token and if the validation/verification is successful, the CC assigns a subscription identifier (ID) and generates a subscription token.
3. If the authorization is successful, the CAPIF core function 21 stores the subscription information such as the subscription ID and the subscription token.
4. The CAPIF core function 21 sends an event subscription response indicating successful operation along with the subscription ID and the subscription token.
Description in this section corresponds to the procedure described in TS 23.222 [2] subclause 8.8.5.
Security Procedure:
1. The subscribing entity sends an event unsubscription request to the CAPIF core function 21 with Subscriber ID/Subscriber entity ID, Subscription Information such as Subscription ID, subscriber CAPIF Event ID, and Subscription Token/Key received during the successful subscription procedure as described in section 2.10.
2. Upon receiving the event unsubscription request from the subscribing entity, the CAPIF core function 21 checks for the event subscription corresponding to the subscribing entity by verifying the subscriber ID, subscription information, and further checks if the subscribing entity is authorized to unsubscribe from the CAPIF event by verifying the Subscription Token/Key and CAPIF Event ID.
3. If all the verification is successful and if the event subscription information corresponding to the subscribing entity is available and the subscribing entity is authorized to unsubscribe for the CAPIF event, the CAPIF core function 21 removes the subscription information.
4. The CAPIF core function 21 sends an event unsubscription response indicating successful or failure operation accordingly.
Description in this section corresponds to the procedure described in TS 23.222 [2] subclause 8.16.
1. The API invoker 20 triggers service API invocation request to the AEF 22, including the CAPIF core function specific API invoker ID, CAPIF ID, invocation token/invocation token* and the requested service API (type/name/ID) to be invoked. The invocation token* shall be derived as described in section 2.8. As the API invoker 20 can trigger several service API invocations asynchronously, the service API invocation request shall also contain a nonce or time stamp parameter to prevent reply and flooding attack.
2. Upon receiving the service API invocation request, the AEF 22 retrieve the API invoker service API authorization information from the CAPIF core function (CCF) 21. The CCF 21 shall provide the AEF 22 with API invoker's authorization information such as checks whether API invoker is authorized to invoke that service API, based on the information such as CAPIF core function specific API invoker ID, CAPIF ID, invocation token/invocation token* and the applicable service API (type/name/ID) that can be invoked. The authorization token acts as the authorization information. For every new service API invocation request, an invocation token* is derived from the previously used invocation token/invocation token*, service API ID and its corresponding invocation count.
Invocation Token Generation at the CCF 21: The Invocation token is used as authorization information for an API invoker to access the service API and it is generated based on the keys derived after the successful authentication between the API invoker 20 and CCF 21 or between the AP invoker and the AEF 22 (example. Using AEFPSK), the CAPIF ID, AEF ID, CCF specific API invoker ID, Onboard token and the invocation count.
2a. If the AEF 22 does not have information required to authorize service API invocation, the AEF 22 obtains the authorization information such as an invocation token/invocation token*, the CAPIF ID, AEF ID, CCF specific API invoker ID, Onboard token and the invocation count.
3. The AEF 22 verifies the authorization information and if it is successful executes the service logic for the invoked service API.
4. API invoker receives the service API invocation response as a result of the service API invocation.
In TS 33.122, clause 5.2.2.3 Method 3—Token Based authorization, post successful access token grant request verification by CAPIF core function 21, it shall generate an Access Token for API invoker 20 using the Onboard Token and any key shared during the successful CAPIF-1e authentication previously.
Beneficially, the above described exemplary embodiments include, although they are not limited to, one or more of the following details of functionalities that are not addressed by the current 3GPP specifications in [2] and [3]:
1) CAPIF specific API Invoker ID provided by any CAPIF or CAPIF Core Function (CCF) 21 for an API invoker 20 after a successful onboarding is bounded to the API invoker 20 and the specific CAPIF/CCF issuing the CAPIF API Invoker ID. This prevents the re-use of CAPIF API invoker ID with other CAPIF/CCF to which an API invoker 20 is not onboarded. This ID can otherwise termed as CCF specific API invoker ID.
2) CAPIF ID is used to uniquely identify a CAPIF core function 21 in a CAPIF Framework. The CAPIF ID is or is not bound/specific to the deployment scenarios such as centralized, distributed, and cascading. But the CAPIF ID is specific to the CAPIF core function 21 as a logical entity.
3) Trust Zone level indication/indicator indicates a zone where the API invoker 20 resides or the API invoker's Access point or radio or access network element through which it connects to the network. The CCF 21 decides the trust level of the API invoker's residing zone based on the Zone ID/APN/access network information it received from the API invoker 20 or the trust level information it maintains with various network zone it can support communication and services. Every CCF 21 maintains a specific trust level for every network/location/zone it can support service/communication.
4) API invoker's Trust level related indicator is a different from parameter specified in point 3. This trust level indicator parameter is specific to the behavior of any API invoker 20 with the CCF 21/CAPIF network/AEF 22 and its service APIs. This parameter is assigned by the CCF 21/AEF 22 based on the past behavior of API invoker 20.
5) Zone ID and its trust level related indicator: Mobile network operators subdivide their networks into trust zones. Each trust zone has a unique Zone ID. Any network entity that communicates with another entity that reside in a particular zone has a trust level assigned for that Zone ID based on their policies or service level history. A specific zone's Zone ID and its trusted level differ or does not differ across its relation with other different network.
6) Onboarding Lifetime is limited to a time period during which the API invoker 20 can be trusted to act genuine throughout its lifetime. More over the current system discuss about offboarding and so the onboarding optionally may not be a one-time registration process for the entire lifetime of the API invoker 20. Onboarding Lifetime is bounded to the subscription, API invoker type and trust level of the API invoker 20 are also based on the CAPIF policy in a network.
7) Onboard Token: A secret authorization value or token assigned or generated by the CCF 21 and sent to/received by the API invoker 20 after a successful onboarding with a CCF 21, that binds the onboarding to all subsequent procedures that happen between an APF invoker, the CCF 21 and AEF 22. It is valid throughout the onboarding lifetime.
8) Authorization Token: A one-time/prolonged usage secret authorization value received by the API invoker 20 after a successful onboarding with a CCF 21. It is used between API invoker 20, CCF 21 or AEF 22 for authorization.
9) CAPIF initiated API Offboarding is proposed to prevent any unexpected malicious activities found or monitored with an API invoker 20. The specification in [2] has only an API invoker 20 initiated offboarding process which does not have mechanisms to control malicious API invokers.
10) Publish token is bounded to a secret, API provider, APF 23, CCF 21, service API related information and the publish code used between the authenticated APF 23 and CCF 21 in CAPIF to prevent malicious API publishers from publishing malicious service.
11) Publish period is a time period assigned to publish a requested service API. This supports efficient resource utilization at the CCF 21 and better Service API management at the CAPIF. After the expiry of the publish period, the CCF 21 unPublish the service APIs previously published by any APF 23 in the CCF 21.
12) Discovery level of Service API and topology hiding is based on the trust level of the API invoker 20 and/or its current residing network zone or the trust level of APN through which the API invoker 20 is connected to the network.
13) AEF Auth Token is the derived by the CCF 21 using a secret (random), AEF ID, CAPIF API Invoker ID and any Service API related information and on a successful authentication/authorization CCF shares AEF Auth Token with API invoker 20 and AEF 22, which can be later shared by the AEF 22 to API invoker 20 to authorize itself/to perform mutual authentication during the service invocation. AEF Auth Token is static or dynamic.
Invocation Token/Access Token: Whenever an API invoker 20 attempts to request a service invocation to AEF 22, it sends the Invocation Token received from a CCF 21 following an authentication as such or it is used to derive the Invocation token* along with other parameters discussed such as key resulted in the authentication/authorization between API invoker 20 and CCF 21/AEF 22, invocation counter value and service API related information.
15) Security level Indicator: The security level indicator notified by the APF 23 to the CCF 21 contains any information related to the security (function/cryptographic algorithm/access level and operation permissions/minimum security required/invoker type/trust level of the API invoker 20/trust level of the API residing zone) of the published service APIs and the required conditions to access it.
16) CAPIF Event ID: Any CAPIF event management by a CCF 21 such as Availability of service APIs, Service API updated, Monitoring service API invocations, API invoker onboarded, System related events, Performance related events have a unique CAPIF Event Identifier (CAPIF Event ID). The CAPIF Event ID is used by the Subscriber entity or the API invoker 20 or the CCF 21 to uniquely identify the CAPIF events.
17) Subscription Token/Key: Subscription Token/Key is generated and used as an authentication or authorization information by the Subscriber entity to request for subscription and unsubscription of events at the CCF 21. Subscription Token/Key corresponding to a Subscriber entity requesting subscription of events are generated by the CCF 21 to verify the authorization of the subscriber entity to request the subscription of events. The Subscription Token/Key is derived using any combination of the one or more of the following parameters such as, Onboard token provided by the CCF 21 after a successful onboarding, Registration ID, Subscriber ID, Subscriber entity ID, CAPIF Event ID, CAPIF ID, subscription code/keyword, Service API type/Name/ID, any preshared Secret, any key/token derived using initial authentication/authorization between API invoker 20/Subscriber entity and CCF 21.
1) After a successful onboarding of an API invoker 20, the CCF 21 provides an Onboard token to the API invoker 20. This Onboard token is used in deriving any authentication or authorization information used for CAPIF security procedures.
2) Any of the authorization token used in the CAPIF procedure is bound to the authentication results, the identifiers of the communicating parties, a secret value, a counter and service API related information.
3) The onboarding result is bounded to all CAPIF security procedures executed between the API invoker 20 and CCF 21 (and other entities) through an onboarding token or authorization token derived from it.
4) The topology hiding and level of Service API discovery take the trust level of the requesting API invoker 20, or residing zone and/or its network into consideration.
5) The service API invocation token is refreshed without additional message exchanges.
6) There is a lifetime for Onboarding of an API invoker 20 to the CCF 21.
7) Publishing, unpublishing, updating and retrieval of Service API by an API publishing function 23/API provider are authorized by the CCF/CAPIF using a publish token provided to the APF 23 by the CCF/CAPIF.
8) Request for subscription of CAPIF events is checked by the CCF 21 by verifying the authentication or authorization information such as authorization token/Key provided by subscriber entity. The authorization token is provided to the subscribing entity during its registration with the CCF 21.
9) The subscription token is issued to the subscribing entity by the CCF 21 after a successful subscription procedure. This subscription token is used by the subscribing entity to unsubscribe the subscription from the CCF 21 or CAPIF.
The proposed exemplary embodiments provide a number of benefits, including:
In this network, users of mobile devices 3 (UEs) can communicate with each other and other users via respective base stations 5 and a core network 7 using an appropriate 3GPP radio access technology (RAT), for example, an E-UTRA and/or 5G RAT. It will be appreciated that a number of base stations 5 form a (radio) access network or (R)AN. As those skilled in the art will appreciate, whilst one mobile device 3 and one base station 5 are shown in
Each base station 5 controls one or more associated cells (either directly or via other nodes such as home base stations, relays, remote radio heads, and/or the like). A base station 5 that supports E-UTRA/4G protocols may be referred to as an ‘eNB’ and a base station 5 that supports NextGeneration/5G protocols may be referred to as a ‘gNBs’. It will be appreciated that some base stations 5 may be configured to support both 4G and 5G, and/or any other 3GPP or non-3GPP communication protocols.
The mobile device 3 and its serving base station 5 are connected via an appropriate air interface (for example the so-called ‘Uu’ interface and/or the like). Neighboring base stations 5 are connected to each other via an appropriate base station to base station interface (such as the so-called ‘X2’ interface, ‘Xn’ interface and/or the like). The base station 5 is also connected to the core network nodes via an appropriate interface (such as the so-called ‘S1’, ‘N1’, ‘N2’, ‘N3’ interface, and/or the like).
The core network 7 typically includes logical nodes (or ‘functions’) for supporting communication in the telecommunication system 1. Typically, for example, the core network 7 of a ‘Next Generation’/5G system will include, amongst other functions, control plane functions (CPFs) 8 and user plane functions (UPFs) 9. From the core network 7, connection to an external IP network 10 (such as the Internet) is also provided (e.g. via one or more gateways).
The CAPIF is hosted within the operator network. Accordingly, the nodes of the system 1 are configured to provide CAPIF functionality, where appropriate. For example, one or more nodes (e.g. one or more CPFs 8) may be configured to operate as a CAPIF core function 21, an API exposing function 22, an API management function 24, an API publishing function 23, a Token Derivation Function (TDF), a subscriber entity, and/or the like.
An API invoker 20 is typically provided by a 3rd party application provider who has service agreement with the operator. The API invoker 20 may reside within the same trust domain as the operator network or outside the trust domain of the operator network.
Core Network Node
Detailed embodiments have been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above embodiments whilst still benefiting from the inventions embodied therein. By way of illustration only a number of these alternatives and modifications will now be described.
In the above description, the UE, the (R)AN node, and the core network node (including the API Invoker) are described for ease of understanding as having a number of discrete modules (such as the communication control modules). Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the invention, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities. These modules may also be implemented in software, hardware, firmware or a mix of these.
Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input/output (IO) circuits; internal memories/aches (program and/or data); processing registers; communication buses (e.g. control, data and/or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and/or timers; and/or the like.
In the above embodiments, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the UE, the (R)AN node, and the core network node as a signal over a computer network, or on a recording medium. Further, the functionality performed by part or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the UE, the (R)AN node, and the core network node in order to update their functionalities.
The above embodiments are also applicable to ‘non-mobile’ or generally stationary user equipment.
Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.
The program described in the above example aspects is stored in a storage device or recorded on a computer-readable recording medium. For example, the recording medium is a portable medium such as a flexible disk, an optical disk, a magneto-optical disk, and a semiconductor memory.
Although the present disclosure has been described above with reference to the example aspects, the present disclosure is not limited to the above-described example aspects. The configurations and details of the present disclosure can be changed in various manners that can be understood those skilled in the art within the scope of the present disclosure.
This application is based upon and claims the benefit of priority from Indian patent application No. 201811013212, filed on Apr. 6, 2018, the disclosure of which is incorporated herein in its entirely by reference.
Number | Date | Country | Kind |
---|---|---|---|
201811013212 | Apr 2018 | IN | national |
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/JP2019/014864 | 4/3/2019 | WO | 00 |