WO2019194242A1 - Procédures de sécurité pour cadre d'api commune dans des réseaux de prochaine génération - Google Patents

Procédures de sécurité pour cadre d'api commune dans des réseaux de prochaine génération Download PDF

Info

Publication number
WO2019194242A1
WO2019194242A1 PCT/JP2019/014864 JP2019014864W WO2019194242A1 WO 2019194242 A1 WO2019194242 A1 WO 2019194242A1 JP 2019014864 W JP2019014864 W JP 2019014864W WO 2019194242 A1 WO2019194242 A1 WO 2019194242A1
Authority
WO
WIPO (PCT)
Prior art keywords
api
application server
api invoker
invoker
service
Prior art date
Application number
PCT/JP2019/014864
Other languages
English (en)
Inventor
Hironori Ito
Anand Raghawa Prasad
Takahito Yoshizawa
Sheeba Backia Mary BASKARAN
Sivabalan ARUMUGAM
Sivakamy LAKSHMINARAYANAN
Original Assignee
Nec Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nec Corporation filed Critical Nec Corporation
Priority to EP19720701.2A priority Critical patent/EP3777084A1/fr
Priority to CN202310844706.5A priority patent/CN117082511A/zh
Priority to JP2020551438A priority patent/JP7040632B2/ja
Priority to US17/044,383 priority patent/US20210144550A1/en
Priority to CN201980024249.7A priority patent/CN112352409B/zh
Publication of WO2019194242A1 publication Critical patent/WO2019194242A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0231—Traffic management, e.g. flow control or congestion control based on communication conditions
    • H04W28/0236—Traffic management, e.g. flow control or congestion control based on communication conditions radio quality, e.g. interference, losses or delay
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks

Definitions

  • 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.
  • 3GPP 3rd Generation Partnership Project
  • the invention has particular although not exclusive relevance to security procedures in the so-called ‘5G’ (or ‘Next Generation’) systems.
  • 3GPP SA2 is defining northbound API to allow external entities to access services provided by the 3GPP system via Service Capability Exposing Function (SCEF).
  • SCEF Service Capability Exposing Function
  • 3GPP is defining the API for SCEF due to the request by an external SDO such as oneM2M.
  • 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.
  • 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.
  • TR Technical Report
  • API invoker Onboarding a.
  • the procedure for Onboarding API invoker does not specify security related aspects in the procedures.
  • the onboarding procedure lacks information of the API invoker with respect to its location/zone (trusted/untrusted/trust level).
  • the CCF assigns an API invoker identifier (ID) to the API invoker following a successful onboarding process, but this identifier is not CCF specific. This may lead to lack of control over the assignment and management of the API invoker ID.
  • ID API invoker identifier
  • the system lacks binding of onboarding results to subsequent procedures such as discovery of service API, authentication, and authorization of API invokers. d.
  • API invoker Offboarding a.
  • the system has only API invoker initiated offboarding. When a malicious API invoker exploits the access to service APIs, there is no way to curb such activity.
  • b. Lack of CAPIF core function initiated API invoker offboarding to protect against malicious API invoker activities. Although previous document in [6] and [7] discuss the offboarding procedure initiated by the CAPIF core function, they do not discuss security aspect.
  • c. Moreover in API invoker initiated offboarding process, there is no mechanism defined to validate the authenticity of offboarding invocation triggered by an API invoker.
  • (iii) Publish service APIs a.
  • the CAPIF supports publishing service APIs by the API provider. Attackers publishing Service APIs by impersonating a legitimate service API provider can lead to malicious service.
  • the service API publishing procedure does not provide clarity about the API provider and service API related authorization information. The authorization information binding with other aspects to improve security is not discussed.
  • the service API procedures do not include the publishing period assignment for the service APIs, which can lead to ineffective service API management.
  • Unpublish service APIs a.
  • the CAPIF supports unpublishing service APIs by the API provider. Once the service API information is unpublished, it can no longer be discovered by API invokers. Therefore, any illegitimate act to unpublish a service API will lead to unavailability of service API.
  • b There is no clear information on what exactly will be contained in authentication and authorization information used in the Unpublish service API procedure.
  • Update service APIs a.
  • the CAPIF supports updating of published Service APIs by the corresponding API publishing functions. But there is no clear information on how exactly an API publishing functions is authenticated or authorized by the CAPIF Core Function to perform the updates to the previously published Service APIs.
  • b There is also no clear information on what exactly will be contained in authentication and authorization information used in the update service API procedure discussed in TS 23.222 [2], clause 8.6.
  • Service APIs Discovery a.
  • the service API discovery procedure in CAPIF does not define any security requirements.
  • b. There is no clear demarcation between the discovery level defined or decided for different API invokers located in different trust zones or based on API invoker’s trust levels.
  • c. Any API invoker with malicious intent can cause network security issue and so the service topology need to be hidden from the API invoker discovering and accessing the service APIs outside the trust domain of the service API based on the trust level.
  • d. There is no binding between the API service discovery by API invoker and the topology hiding by the AEF and CCF. The lack of service API discovery results and topology hiding decision binding can lead to ineffective topology hiding.
  • API invoker obtaining authorization from CAPIF core function (CCF) to access service API a.
  • CCF CAPIF core function
  • the lack of binding between the CAPIF authentication and the Service API authorization Request between an API invoker and the CCF can lead to man-in-the-middle attack by any attacker obtaining the invocation/access token destined for a legitimate API invoker.
  • the invocation/access token can be exploited to allow for session fixation, wherein a hacker uses a real user’s invocation/access token to gain access to the user’s account.
  • AEF ID, CAPIF ID, Service API related ID binding to the generation of the invocation/access token can lead to API invoker authorization verification issues at the CCF or AEF when more than one API invokers requests service API with the same invocation/access token.
  • CAPIF core function or Service API has a vulnerability for DoS attack. With a large number of access attempts, the CAPIF in this condition can be flooded and shut down, to operate properly.
  • the lack of maintaining and enforcing a control over an API invoker related Authentication/Authorization counter at the CCF or AEF for every API invoker’s authorization request or service API access request can lead to DoS attack over the CCF, AEF and service API provider.
  • Lack of nonce or timestamp based Service API authorization Request/Response procedure can lead to replay attack.
  • API invoker and API exposing function (viii) Authentication between API invoker and API exposing function (AEF) upon the service invocation a.
  • the authentication between API invoker and API exposing function for every Service API invocation can be time consuming and can delay the service invocation process.
  • the invocation/access token or authentication/authorization information received by the API invoker from the CCF/AEF during an initial authentication if used as such or repeatedly for authentication between API invoker and AEF upon the service invocation can lead to replay or masquerading attack.
  • (x) CAPIF event subscription a.
  • the CAPIF core function enables the subscribing entity (i.e. API invoker, API exposing function, API publishing function, API management function) to subscribe to the CAPIF events such as availability events of service APIs, change in service API information, monitoring service API invocations, API invoker onboarding events, etc.
  • the CAPIF event subscription procedure does not discuss how exactly the authentication or authorization of API invokers or subscribing entities are carried out to prevent the malicious API invokers or subscribing entities from subscribing to the event notifications.
  • the subscription and notification for the CAPIF events to any malicious entity will lead to adverse effects.
  • CAPIF event unsubscription a.
  • the CAPIF core function sends event notifications to all the subscribing entity(s) that have subscribed for the event matching the criteria.
  • the CAPIF event unsubscription procedure does not discuss how exactly the authentication or authorization of API invokers are carried out to prevent the malicious API invokers from unsubscribing the event notifications of legitimate API invokers/subscribing entities.
  • API invoker authorization to access service APIs a The TS 33.122, clause 5.2.2.2 and 5.2.2.3 states that, “After successful establishment of TLS on CAPIF-2e reference point, API exposing function shall obtain API invoker’s authorization rights as specified in TS 23.222 [3] from the CAPIF core function.”. Whereas the TS 23.222 clause 8.15.2 Information flows has a note which confirms that it is in SA3 scope to develop the security related information flows for this procedure. Therefore, this NID proposes to include the security procedure for AEF to obtain the API invoker’s authorization rights in TS33.122.
  • 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.
  • 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.
  • an application server includes: a receiver configured to receive an Onboard API invoker request message from a device after authentication using TLS with the device; and a transmitter configured to send an Onboard API invoker response message to the device in response to the Onboard API invoker request message, the Onboard API invoker response message including an application server related API invoker ID which is assigned by the application server.
  • an information processing method in a device includes: sending an Onboard API invoker request message to an application server after authentication using TLS with the application server; and receiving 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.
  • an information processing method in an application server includes: receiving an Onboard API invoker request message from a device after authentication using TLS with the device; and sending an Onboard API invoker response message to the device in response to the Onboard API invoker request message, the Onboard API invoker response message including an application server related API invoker ID which is assigned by the application server.
  • Figure 1 illustrates schematically an exemplary system to which embodiments of the present invention are applicable.
  • Figure 2 illustrates schematically an exemplary security procedure for onboarding API invoker to the CAPIF.
  • Figure 3 illustrates schematically an exemplary procedure for API invoker initiated offboarding from the CAPIF.
  • Figure 4 illustrates schematically an exemplary procedure for CAPIF initiated offboarding from the CAPIF.
  • Figure 5 illustrates schematically an exemplary security procedure to publish Service APIs.
  • Figure 6 illustrates schematically an exemplary security procedure to unpublish Service APIs.
  • Figure 7 illustrates schematically an exemplary security procedure to Update Service APIs.
  • Figure 8 illustrates schematically an exemplary security procedure to discover Service APIs.
  • Figure 9 illustrates schematically an exemplary security procedure for the API invoker obtaining authorization for service API access.
  • Figure 10 illustrates schematically an exemplary security procedure for authentication between the API invoker and the AEF upon the service API invocation.
  • Figure 11 illustrates schematically an exemplary procedure for derivation of Invocation token*.
  • Figure 12 illustrates schematically an exemplary security procedure to retrieve Service APIs.
  • Figure 13 illustrates schematically an exemplary security procedure for CAPIF event subscription.
  • Figure 14 illustrates schematically an exemplary security procedure for CAPIF event unsubscription.
  • Figure 15 illustrates schematically an exemplary procedure for API invoker authorization to access service APIs.
  • Figure 16 schematically illustrates a mobile (cellular or wireless) telecommunication system 1 to which the above embodiments are applicable.
  • Figure 17 is a block diagram illustrating the main components of the UE (mobile device 3) shown in Figure 16.
  • Figure 18 is a block diagram illustrating the main components of an exemplary (R)AN node 5 (base station) shown in Figure 16.
  • Figure 19 is a block diagram illustrating the main components of a generic core network node (or function), for example, the CPF 8 or the UPF 9 shown in Figure 16 (or the API Invoker 20).
  • Figure 1 illustrates schematically an exemplary system to which embodiments of the present invention are applicable.
  • the architecture shown in Figure 1 corresponds to the overall CAPIF architecture as described in TS 23.222 [2] subclause 6.2.
  • CAPIF-1 through CAPIF-5 refer to the reference points between logical entities:
  • - CAPIF-1 reference point between the API invoker 20 and the CAPIF Core Function (CCF) 21, where the API invoker 20 is within the PLMN's trust domain.
  • - CAPIF-1e reference point between the API invoker 20 and the CAPIF Core Function (CCF) 21, where the API invoker 20 is outside the PLMN's trust domain.
  • - CAPIF-2 reference point between the API invoker 20 and the API Exposing Function (AEF) 22, where the API invoker 20 is within the PLMN's trust domain.
  • - CAPIF-2e reference point between the API invoker 20 and the API Exposing Function (AEF) 22, where the API invoker 20 is outside the PLMN's trust domain.
  • - CAPIF-3 reference point between the CAPIF Core Function (CCF) 21 and the API Exposing Function (AEF) 22.
  • - CAPIF-4 reference point between the CAPIF Core Function (CCF) 21 and the API Publishing Function (APF) 23.
  • - CAPIF-5 reference point between the CAPIF Core Function (CCF) 21 and the API Management Function (AMF) 24.
  • Figure 2 illustrates schematically an exemplary security procedure for onboarding API invoker 20 to the CAPIF.
  • 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.
  • Onboard token generation shall be bound to any combination of the following: API provider ID/CAPIF core function Specific API Invoker ID
  • Variant for secret or secret random number Can be any random number generated by the CCF 21 which can be pre-provisioned.
  • the security context that is established as a part of the NAS signaling e.g. UE attach procedure
  • the application layer i.e. between the API invoker 20 and the CAPIF core function 21
  • 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 figure 2 are pre-provisioned to the API invoker 20 by the network.
  • 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).
  • the Zone ID can be the Access Point Name or the access network related information through which the API invoker 20 is connected to the network.
  • Zone ID can be the Access Point Name or the access network related information through which the API invoker 20 is connected to the network.
  • Variant According to TS 33.501, Clause 5.7.1 Trust boundaries, “it is assumed for the set of requirements in this sub-clause that mobile network operators subdivide their networks into trust zones.
  • Every device will have the access point name (APN) or the access network information. So, if the device shares the APN through which it is connected to the network, then the CCF 21 makes use of the received APN information and the Trust value it stored within itself to analyze the trust it can have on a particular API invoker’s service API request. To support this the CCF 21 need to store the various zone related information, the information about the APN in the zone and the trust values corresponding to the various zone or the trust values corresponding to the CCF 21/Network and the various trusted Zones. c.
  • the API invoker Information contains a user specific application ID or Subscription/Subscriber ID or third party application ID along with the credentials related to the ID (e.g. password). If the API invoker Information contains a user specific ID which affects the user privacy, then a concealed identifier needs to be sent.
  • 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 networkit has received in Onboarding API invoker request message with its stored information.
  • 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.
  • 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. a.
  • 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.
  • 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.
  • 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. a.
  • the Onboard token is used as such or a derivative of it is used between the API invoker 20 and the CCF 21/ AEF 22 as proof or token of authorization for onboarded API invoker 20.
  • Both Authorization token and onboard token are sent by the CCF 21 to the API invoker 20 along with the success indication in the Onboard API invoker request message.
  • 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 onboarding results need to be bound to the subsequent CAPIF procedures such as discovery of service API, authentication, and authorization of API invokers.
  • 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.
  • the API invoker 20 and API exposing function 22 establish dedicated secure session using TLS connection based on Pre-Shared Key.
  • the API invoker 20 and the CAPIF core function 21 shall derive the key AEF PSK .
  • the AEF PSK can be bounded to the CAPIF core function specific API invoker identity, Onboarding token, CAPIF identity, Authorization Token and the AEF identity
  • Figure 3 illustrates schematically an exemplary procedure for API invoker 20 initiated offboarding from the CAPIF.
  • 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
  • the Authorization token to authorize offboarding is derived from the onboard token and its derivation is bound to the CAPIF ID and/or CAPIF API Invoker ID and/or Offboard code (Static or dynamic).
  • Either Authorization token or onboard token or both is/are sent in an Offboard API invoker request message.
  • 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.
  • the CAPIF core function 21 returns the offboard API invoker response message, providing successful offboarding indication to the API invoker 20.
  • Figure 4 illustrates schematically an exemplary procedure for CAPIF initiated offboarding from the CAPIF.
  • 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.
  • the authorization token derivation is bound to the CAPIF ID and/or the onboard token previously shared with the API invoker 20 during the successful onboarding.
  • Variant After sending the API invoker Offboard notification message to the API invoker 20 the CCF 21 revokes the service and no longer serves this API invoker's requests. c. Variant: If the reason for the offboarding is unintended or unacceptable or rogue action of the API invoker 20, the CCF 21 sends the API invoker Offboard notification message to the API invoker 20 without the authorization token/onboard token and the CCF 21 revokes the service and no longer serve this API invoker's requests.
  • 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.
  • API invoker 20 sends API invoker offboard acknowledgement message to positively acknowledges the offboarding notification to the CCF 21.
  • the CAPIF cancels the API invoker enrollment after receiving the API invoker offboard acknowledgement message from the API invoker 20.
  • Figure 5 illustrates schematically an exemplary security procedure to publish Service APIs.
  • 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.
  • 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.
  • API publishing function (APF) 23 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 service APIs and the required conditions to access it.
  • 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.
  • the CCF 21 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.
  • 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.
  • the publish token generation shown above involves any combination of one or more parameters such as API provider ID, APF ID, publishing related keyword, code for publishing (static or dynamic), service API type/name/related information, Secret and CCF ID.
  • 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.
  • 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.
  • the publish token received from the CCF 21 is used by the APF 23 as an authorization information to perform service API unpublishing, retrieval and updation operations. In other words, a valid publish token provided by the APF indicates that this APF 23 has been previously authorized.
  • Figure 6 illustrates schematically an exemplary security procedure to unpublish Service APIs.
  • 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.
  • 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.
  • 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.
  • 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.
  • Variant Irrespective of this procedure if the service API publish period expires, the CCF 21 unpublishes the published service API.
  • Figure 7 illustrates schematically an exemplary security procedure to Update Service APIs.
  • 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.
  • 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.
  • the CAPIF core function 21 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).
  • 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.
  • Figure 8 illustrates schematically an exemplary security procedure to discover Service APIs.
  • 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).
  • 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
  • Other Query information Criteria for discovering matching service APIs (e.g. API type, interfaces, protocols).
  • Variant The authorization token issued is specific to the discovery level or is derived from the Onboard token.
  • 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.
  • 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.
  • the API invoker 20 or the device shares the access point name (APN) through which it is connected to the network, then the CCF 21 makes use of the received APN information and the Trust value it stored within itself to analyze the trust it can have on a particular API invoker’s service API request. To support this the CCF 21 need to store the various zone related information, the information about the APN in the zone and the trust values corresponding to the various zone or the trust values corresponding to the CCF 21/Network and the various trusted Zones.
  • API access point name
  • Figure 9 illustrates schematically an exemplary security procedure for the API invoker obtaining authorization for service API access.
  • 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.
  • 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.
  • the API invoker 20 also includes the user or user application or API invoker specific subscription information in the service API authorization request message.
  • 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. a. Variant: The CCF 21 may involve additional message exchanges with the API invoker 20 if required during authorization.
  • 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.
  • AEF 22 Auth Token is derived by the CCF 21 using a secret (e.g. random value), AEF ID, CAPIF API Invoker ID and any Service API related information.
  • the obtain service API authorization response message also contains the validity period of invocation/access token.
  • the API invoker 20 refreshes the invocation/access token by itself using the incremented authentication/authorization counter. After every successful Service API invocation following an authentication or authorization, the corresponding counter is incremented at both API invoker 20 and CCF 21 side.
  • the API invoker 20 can obtain authorization from CCF 21 to access service API based on 1) per user: by sending the user ID or subscription ID or user specific application ID, 2) per API invoker 20: by sending the device ID or device subscription ID or device specific application ID and/or 3) Per Service API level by sending the requested service type/name/ID.
  • 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.
  • the service API authorization request message sent by the API invoker 20 also contains the user specific identifier/subscriber identification information/subscription identification information.
  • 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.
  • the security procedure is similar to the one described in the section 2.6.
  • 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.
  • the API invoker 20 obtains authorization from the CAPIF core function (CCF) 21 as described in the security procedure in section 2.6.
  • CCF CAPIF core function
  • Figure 10 illustrates schematically an exemplary security procedure for authentication between the API invoker 20 and the AEF 22 upon the service API invocation.
  • 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 Figure 11), Required or Requested Service API(s) ID(s) (Service type/name/ID) and related information to the API exposing function (AEF) 22. For every new invocation, a new Invocation Token* is computed to avoid security breach due to token reuse.
  • Invocation token* is derived using invocation / access / authorization token and/or key resulted in the authentication/authorization between API invoker 20 and CCF 21/ AEF 22 and invocation counter value. Invocation token* can be called as service API Invocation token*.
  • the API invoker 20 also sends its subscription related information to the AEF 22 in the Service API invocation request message.
  • 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.
  • the AEF 22 obtains invocation token or invocation token* from CCF 21 along with other parameters listed in step 2 to perform authentication.
  • the invocation token* is derived at API invoker 20 side and either at the CCF 21 or AEF 22 side.
  • 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).
  • 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.).
  • 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.
  • Figure 11 illustrates schematically an exemplary procedure for derivation of Invocation token*.
  • 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.
  • TDS token derivation function
  • 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.
  • Figure 12 illustrates schematically an exemplary security procedure to retrieve Service APIs.
  • 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:
  • 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.
  • the CCF 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.
  • 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.
  • 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.
  • Figure 13 illustrates schematically an exemplary security procedure for CAPIF event subscription.
  • 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.
  • 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: - Onboard token provided by the CCF 21 after a successful onboarding ID (API Invokers), CAPIF specific API ID (API Invokers), Subscriber ID of the subscribing entity, 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.
  • API Invokers CAPIF specific API ID (API Invokers)
  • Subscriber ID of the subscribing entity 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.
  • 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.
  • the subscribing entity can be API invoker 20, API exposing function 22, API publishing function 23 or API management function 24.
  • Variant If the subscribing entity is an API invoker 20, the subscribing entity ID is the CAPIF specific API invoker ID.
  • the CAPIF core function 21 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.
  • ID subscription identifier
  • the CAPIF core function 21 stores the subscription information such as the subscription ID and the subscription token.
  • the CAPIF core function 21 sends an event subscription response indicating successful operation along with the subscription ID and the subscription token.
  • Figure 14 illustrates schematically an exemplary security procedure for CAPIF event unsubscription.
  • 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.
  • the CAPIF core function 21 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.
  • the CAPIF core function 21 removes the subscription information.
  • the CAPIF core function 21 sends an event unsubscription response indicating successful or failure operation accordingly.
  • Figure 15 illustrates schematically an exemplary procedure for API invoker authorization to access service APIs.
  • 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.
  • the service API invocation request shall also contain a nonce or time stamp parameter to prevent reply and flooding attack.
  • 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.
  • 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 AEF PSK ), the CAPIF ID, AEF ID, CCF specific API invoker ID, Onboard token and the invocation count.
  • 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.
  • the AEF 22 verifies the authorization information and if it is successful executes the service logic for the invoked service API.
  • API invoker receives the service API invocation response as a result of the service API invocation.
  • 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]:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Variant A one-time / prolonged usage secret authorization value received by any subscribing entity from a CCF 21 after a successful registration to perform operations such as subscription to some events, discovery of service APIs.
  • the subscribing entity can be API invoker 20, API exposing function 22, API publishing function 23 or API management function 24.
  • the Authorization ken can be derviced from the Onboard token and other parameters described in the section 2.1 of the present document.
  • 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.
  • 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.
  • the publish token is used by the APF 23 as an authorization information to trigger the unPublish service API request.
  • the publish token is used by the APF 23 as an authorization information to trigger the update service API request.
  • the publish token is used by the APF 23 as an authorization information to trigger the retrieve service API request.
  • 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.
  • 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.
  • 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. a. Invocation token*/Access Token* is used as the authorization proof by the API invoker 20 to perform authentication between the API invoker 20 and the AEF 22 upon the service API invocation. It is also used to ensure token freshness to prevent replay attack. Single time usage of Invocation token/access token to request the Service API invocation will increase the security level.
  • a refresh token based access token request/response procedure needs extra round trip of messages.
  • the refresh token is used by the API invoker 20 to get a new authorization proof from the CCF 21 or AEF 22 to be used in invocation token* generation.
  • the CCF 21 or AEF 22 provided refresh token is used as authorization refresh notification token and it is provided back by the API invoker 20 to the CCF 21 or AEF 22 along with the invocation token*.
  • invocation key* or invocation secret* is used by the API invoker 20 to perform authentication between the API invoker 20 and the AEF 22 upon the service API invocation.
  • 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.
  • 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.
  • 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. a.
  • Subscription Token/Key is used as an authorization information by the subscribed entity to trigger unsubscription request regarding CAPIF events to the CCF 21.
  • the CCF 21 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.
  • 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:
  • the current system does not have a sufficient security procedure to deal with CAPIF security issues
  • the access token refreshment in the current state of art requires additional message exchanges.
  • Figure 16 schematically illustrates a mobile (cellular or wireless) telecommunication system 1 to which the above embodiments are applicable.
  • UEs 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.
  • RAT 3GPP radio access technology
  • a number of base stations 5 form a (radio) access network or (R)AN.
  • R radio access network
  • 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.
  • 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.
  • CPFs control plane functions
  • UPFs user plane functions
  • 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.
  • one or more nodes e.g. one or more CPFs 8
  • one or more nodes 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.
  • TDF Token Derivation Function
  • 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.
  • UE User Equipment
  • FIG 17 is a block diagram illustrating the main components of the UE (mobile device 3) shown in Figure 16.
  • the UE includes a transceiver circuit 31 which is operable to transmit signals to and to receive signals from the connected node(s) via one or more antenna 33.
  • the UE will of course have all the usual functionality of a conventional mobile device (such as a user interface 35) and this may be provided by any one or any combination of hardware, software and firmware, as appropriate.
  • a controller 37 controls the operation of the UE in accordance with software stored in a memory 39.
  • the software may be pre-installed in the memory 39 and/or may be downloaded via the telecommunication network 1 or from a removable data storage device (RMD), for example.
  • RMD removable data storage device
  • the software includes, among other things, an operating system 41 and a communications control module 43.
  • the communications control module 43 is responsible for handling (generating/sending/receiving) signaling messages and uplink/downlink data packets between the UE 3 and other nodes, including (R)AN nodes 5 and core network nodes.
  • FIG 18 is a block diagram illustrating the main components of an exemplary (R)AN node 5 (base station) shown in Figure 16.
  • the (R)AN node 5 includes a transceiver circuit 51 which is operable to transmit signals to and to receive signals from connected UE(s) 3 via one or more antenna 53 and to transmit signals to and to receive signals from other network nodes (either directly or indirectly) via a network interface 55.
  • the network interface 55 typically includes an appropriate base station - base station interface (such as X2/Xn) and an appropriate base station - core network interface (such as S1/N1/N2/N3).
  • a controller 57 controls the operation of the (R)AN node 5 in accordance with software stored in a memory 59.
  • the software may be pre-installed in the memory 59 and/or may be downloaded via the telecommunication network 1 or from a removable data storage device (RMD), for example.
  • the software includes, among other things, an operating system 61 and a communications control module 63.
  • the communications control module 63 is responsible for handling (generating/sending/receiving) signaling between the (R)AN node 5 and other nodes, such as the UE 3 and the core network nodes.
  • the communications control module 63 is also responsible for carrying out API related security procedures.
  • FIG 19 is a block diagram illustrating the main components of a generic core network node (or function), for example, the CPF 8 or the UPF 9 shown in Figure 16 (or the API Invoker 20).
  • the core network node includes a transceiver circuit 71 which is operable to transmit signals to and to receive signals from other nodes (including the UE 3 and the (R)AN node 5) via a network interface 75.
  • a controller 77 controls the operation of the core network node in accordance with software stored in a memory 79.
  • the software may be pre-installed in the memory 79 and/or may be downloaded via the telecommunication network 1 or from a removable data storage device (RMD), for example.
  • RMD removable data storage device
  • the software includes, among other things, an operating system 81 and a communications control module 83.
  • the communications control module 83 is responsible for handling (generating/sending/ receiving) signaling between the core network node and other nodes, such as the UE 3, (R)AN node 5, and other core network nodes.
  • signaling includes appropriately formatted requests and responses relating to API related security procedures.
  • the UE, the (R)AN node, and the core network node 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 / caches (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.
  • 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 / caches (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.
  • 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 program described in the above example aspects is stored in a storage device or recorded on a computer-readable recording medium.
  • the recording medium is a portable medium such as a flexible disk, an optical disk, a magneto-optical disk, and a semiconductor memory.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

La présente invention propose des procédures de sécurité pour une structure API commune 3 GPP (CAPIF) permettant de résoudre divers problèmes de sécurité qui peuvent survenir pendant diverses phases telles que, (i) l'intégration d'un invocateur API, (ii) la mise hors service d'un invocateur API, (iii) la publication d'une API de service, (iv) l'annulation de la publication d'une API de service, (v) la mise à jour d'API de service, (vi) la découverte d'une API de service, (vii) l'invocateur d'API obtenant une autorisation de la fonction centrale CAPIF (CCF) d'accès à l'API de service, (viii) l'authentification entre un invocateur API et une fonction d'exposition d'API (AEF) après la demande de service, (ix) la récupération d'API de service, (x) un abonnement d'évènement CAPIF, (xi) un désabonnement d'événement CAPIF, et (xii) une autorisation d'invocateur API d'accès aux API de service.
PCT/JP2019/014864 2018-04-06 2019-04-03 Procédures de sécurité pour cadre d'api commune dans des réseaux de prochaine génération WO2019194242A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP19720701.2A EP3777084A1 (fr) 2018-04-06 2019-04-03 Procédures de sécurité pour cadre d'api commune dans des réseaux de prochaine génération
CN202310844706.5A CN117082511A (zh) 2018-04-06 2019-04-03 Api调用者装置及其方法和ccf节点及其方法
JP2020551438A JP7040632B2 (ja) 2018-04-06 2019-04-03 次世代ネットワークにおける共通ａｐｉフレームワークのセキュリティ手順
US17/044,383 US20210144550A1 (en) 2018-04-06 2019-04-03 Security procedures for common api framework in next generation networks
CN201980024249.7A CN112352409B (zh) 2018-04-06 2019-04-03 下一代网络中的通用api框架所用的安全过程

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN201811013212 2018-04-06
IN201811013212 2018-04-06

Publications (1)

Publication Number Publication Date
WO2019194242A1 true WO2019194242A1 (fr) 2019-10-10

Family

ID=66334518

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/014864 WO2019194242A1 (fr) 2018-04-06 2019-04-03 Procédures de sécurité pour cadre d'api commune dans des réseaux de prochaine génération

Country Status (5)

Country Link
US (1) US20210144550A1 (fr)
EP (1) EP3777084A1 (fr)
JP (1) JP7040632B2 (fr)
CN (2) CN112352409B (fr)
WO (1) WO2019194242A1 (fr)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3770784A4 (fr) * 2018-04-08 2021-04-14 Huawei Technologies Co., Ltd. Procédé, dispositif et système de masquage de topologie d'api
WO2021224545A1 (fr) * 2020-05-05 2021-11-11 Nokia Technologies Oy Enregistrement amélioré dans des réseaux de communication
JP2022526477A (ja) * 2019-02-16 2022-05-25 サムスン エレクトロニクス カンパニー リミテッド Ｃａｒｉｆコア機能エンティティにａｐｉプロバイダドメイン機能エンティティらを登録するための方法及び装置
CN114915430A (zh) * 2021-01-28 2022-08-16 中国移动通信有限公司研究院 实现动态能力开放的方法、装置、通信设备及存储介质
CN115023931A (zh) * 2020-02-14 2022-09-06 瑞典爱立信有限公司 用于服务api发布的方法和网络实体
WO2022203386A1 (fr) * 2021-03-23 2022-09-29 Samsung Electronics Co., Ltd. Procédé et système de découverte d'une interface de programme d'application cible
EP4109835A4 (fr) * 2020-03-17 2023-04-12 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Procédé et appareil de communication de l'internet des objets
EP4114091A4 (fr) * 2020-03-29 2023-05-10 Huawei Technologies Co., Ltd. Procédé, appareil et système de communication
WO2023144681A1 (fr) * 2022-01-28 2023-08-03 Lenovo (Singapore) Pte. Ltd. Gestion d'informations de consentement de propriétaire de ressource
WO2023186580A1 (fr) * 2022-03-29 2023-10-05 Sony Group Corporation Procédé permettant à un premier dispositif sans fil de déterminer une position relative entre une pluralité de seconds dispositifs sans fil, un dispositif sans fil apparenté et des nœuds de réseau apparentés
WO2023213988A1 (fr) * 2022-05-06 2023-11-09 Telefonaktiebolaget Lm Ericsson (Publ) Accès d'interface de programmation d'application dans un réseau de communication
WO2024031722A1 (fr) * 2022-08-12 2024-02-15 北京小米移动软件有限公司 Procédé et appareil d'invocation d'interface de programmation d'application (api) ascendante
WO2024100055A1 (fr) * 2022-11-07 2024-05-16 Telefonaktiebolaget Lm Ericsson (Publ) Accès à interface de programmation d'application dans un réseau de communication

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110362412A (zh) * 2018-04-09 2019-10-22 华为技术有限公司 一种服务api调用方法和相关装置
US11140165B2 (en) * 2019-07-22 2021-10-05 Bank Of America Corporation System for selective mapping of distributed resources across network edge framework for authorized user access
US11706260B2 (en) * 2020-08-21 2023-07-18 Oracle International Corporation Security zone policy enforcement in a cloud infrastructure system
US20220086189A1 (en) * 2020-09-16 2022-03-17 Salesforce.Com, Inc. Network security orchestration and management across different clouds
KR20230009656A (ko) * 2021-07-09 2023-01-17 삼성전자주식회사 단말에 대한 네트워크 기능 개방 서비스 지원 방법 및 장치
US20230015697A1 (en) * 2021-07-13 2023-01-19 Citrix Systems, Inc. Application programming interface (api) authorization
JPWO2023021583A1 (fr) * 2021-08-17 2023-02-23
WO2023084606A1 (fr) * 2021-11-09 2023-05-19 株式会社Ｎｔｔドコモ Nœud de réseau, dispositif de propriétaire de ressource, système et procédé de communication
US11882057B2 (en) 2022-03-28 2024-01-23 Bank Of America Corporation Pluggable cloud security system
CN114584328B (zh) * 2022-05-09 2022-08-02 武汉四通信息服务有限公司 Api接口的访问方法、计算机设备及计算机存储介质
CN115277046B (zh) * 2022-05-24 2024-01-30 中国电信股份有限公司 5g能力开放安全控制方法、装置、设备及存储介质
CN117882348A (zh) * 2022-08-12 2024-04-12 北京小米移动软件有限公司 应用程序接口api调用方法及装置、存储介质
CN117641358A (zh) * 2022-08-12 2024-03-01 华为技术有限公司 通信方法和通信装置
WO2024031723A1 (fr) * 2022-08-12 2024-02-15 北京小米移动软件有限公司 Procédé et dispositif d'invocation d'interface de programme d'application (api)
WO2024031730A1 (fr) * 2022-08-12 2024-02-15 北京小米移动软件有限公司 Procédé et appareil de révocation d'autorisation et support de stockage
WO2024065565A1 (fr) * 2022-09-29 2024-04-04 北京小米移动软件有限公司 Procédé et appareil de révocation d'autorisation
WO2024065564A1 (fr) * 2022-09-29 2024-04-04 北京小米移动软件有限公司 Procédé d'appel d'api, appareil, dispositif et support d'enregistrement

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100281249A1 (en) * 2009-05-03 2010-11-04 Kabushiki Kaisha Toshiba Media independent handover protocol security

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6668322B1 (en) * 1999-08-05 2003-12-23 Sun Microsystems, Inc. Access management system and method employing secure credentials
US9043886B2 (en) * 2011-09-29 2015-05-26 Oracle International Corporation Relying party platform/framework for access management infrastructures
US9282457B2 (en) 2013-02-05 2016-03-08 Mediatek Inc. Method of sharing credential and wireless communication system thereof
WO2016024893A1 (fr) * 2014-08-15 2016-02-18 Telefonaktiebolaget L M Ericsson (Publ) Procédés et nœuds de mappage entre un abonnement et une identité d'utilisateur de service
CN115412885A (zh) * 2015-03-31 2022-11-29 日本电气株式会社 核心网络实体及其方法
US10412068B2 (en) * 2015-12-07 2019-09-10 Salesforce.Com, Inc. API authentication

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100281249A1 (en) * 2009-05-03 2010-11-04 Kabushiki Kaisha Toshiba Media independent handover protocol security

Non-Patent Citations (10)

* Cited by examiner, † Cited by third party
Title
"Common API Framework for 3GPP Northbound APIs; Stage 2 (Release 15", 3GPP TS 23.222, January 2018 (2018-01-01)
"Security Aspects of Common API Framework for 3GPP Northbound APIs", 3GPP TS 33.122, January 2018 (2018-01-01)
"Study on Common API Framework for 3GPP Northbound APIs (Release 15", 3GPP TR 23.722, September 2017 (2017-09-01)
LG ELECTRONICS: "Miscellaneous corrections to procedures and information flows", vol. SA WG6, no. Gothenburg, Sweden; 20180122 - 20180126, 15 January 2018 (2018-01-15), XP051391424, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg%5Fsa/WG6%5FMissionCritical/TSGS6%5F021%5FGothenburg/docs/> [retrieved on 20180115] *
MOTOROLA SOLUTIONS: "Pseudo-CR on API invoker authentication", vol. SA WG6, no. Sophia Antipolis, France; 20170904 - 20170907, 12 September 2017 (2017-09-12), XP051336515, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_sa/WG6_MissionCritical/Ad-hoc_meetings/2017-09-04_CAPIF_and_FRMCS_adhoc/Docs/> [retrieved on 20170912] *
NEC: "Issues of functionalities in the CAPIF TS 23.222", 3GPP S6-171534, November 2017 (2017-11-01)
NEC: "Issues of functionalities in the CAPIF TS 23.222", vol. SA WG6, no. Reno, Nevada, USA; 20171127 - 20171201, 20 November 2017 (2017-11-20), XP051381535, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg%5Fsa/WG6%5FMissionCritical/TSGS6%5F020%5FReno/Docs/> [retrieved on 20171120] *
NEC: "Pseudo-CR on CAPIF authentication related requirements and procedures", vol. SA WG6, no. Reno, Nevada, USA; 20171127 - 20171201, 20 November 2017 (2017-11-20), XP051381536, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg%5Fsa/WG6%5FMissionCritical/TSGS6%5F020%5FReno/Docs/> [retrieved on 20171120] *
NEC: "Pseudo-CR on missing functionalities in CAPIF - offboarding", 3GPP S6-171538, November 2017 (2017-11-01)
NEC: "Pseudo-CR on missing functionalities in CAPIF - offboarding", vol. SA WG6, no. Reno, Nevada, USA; 20171127 - 20171201, 20 November 2017 (2017-11-20), XP051381539, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg%5Fsa/WG6%5FMissionCritical/TSGS6%5F020%5FReno/Docs/> [retrieved on 20171120] *

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11726848B2 (en) 2018-04-08 2023-08-15 Huawei Technologies Co., Ltd. API topology hiding method, device, and system
EP4161120A1 (fr) * 2018-04-08 2023-04-05 Huawei Technologies Co., Ltd. Procédé, dispositif et système de masquage de topologie d'api
EP3770784A4 (fr) * 2018-04-08 2021-04-14 Huawei Technologies Co., Ltd. Procédé, dispositif et système de masquage de topologie d'api
US11194641B2 (en) 2018-04-08 2021-12-07 Huawei Technologies Co., Ltd. API topology hiding method, device, and system
JP7191442B2 (ja) 2019-02-16 2022-12-19 サムスン エレクトロニクス カンパニー リミテッド Ｃａｒｉｆコア機能エンティティにａｐｉプロバイダドメイン機能エンティティらを登録するための方法及び装置
JP2022526477A (ja) * 2019-02-16 2022-05-25 サムスン エレクトロニクス カンパニー リミテッド Ｃａｒｉｆコア機能エンティティにａｐｉプロバイダドメイン機能エンティティらを登録するための方法及び装置
CN115023931A (zh) * 2020-02-14 2022-09-06 瑞典爱立信有限公司 用于服务api发布的方法和网络实体
CN115023931B (zh) * 2020-02-14 2023-10-03 瑞典爱立信有限公司 用于服务api发布的方法和网络实体
EP4109835A4 (fr) * 2020-03-17 2023-04-12 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Procédé et appareil de communication de l'internet des objets
EP4114091A4 (fr) * 2020-03-29 2023-05-10 Huawei Technologies Co., Ltd. Procédé, appareil et système de communication
WO2021224545A1 (fr) * 2020-05-05 2021-11-11 Nokia Technologies Oy Enregistrement amélioré dans des réseaux de communication
CN114915430A (zh) * 2021-01-28 2022-08-16 中国移动通信有限公司研究院 实现动态能力开放的方法、装置、通信设备及存储介质
WO2022203386A1 (fr) * 2021-03-23 2022-09-29 Samsung Electronics Co., Ltd. Procédé et système de découverte d'une interface de programme d'application cible
WO2023144681A1 (fr) * 2022-01-28 2023-08-03 Lenovo (Singapore) Pte. Ltd. Gestion d'informations de consentement de propriétaire de ressource
WO2023186580A1 (fr) * 2022-03-29 2023-10-05 Sony Group Corporation Procédé permettant à un premier dispositif sans fil de déterminer une position relative entre une pluralité de seconds dispositifs sans fil, un dispositif sans fil apparenté et des nœuds de réseau apparentés
WO2023213988A1 (fr) * 2022-05-06 2023-11-09 Telefonaktiebolaget Lm Ericsson (Publ) Accès d'interface de programmation d'application dans un réseau de communication
WO2024031722A1 (fr) * 2022-08-12 2024-02-15 北京小米移动软件有限公司 Procédé et appareil d'invocation d'interface de programmation d'application (api) ascendante
WO2024100055A1 (fr) * 2022-11-07 2024-05-16 Telefonaktiebolaget Lm Ericsson (Publ) Accès à interface de programmation d'application dans un réseau de communication

Also Published As

Publication number Publication date
CN117082511A (zh) 2023-11-17
US20210144550A1 (en) 2021-05-13
CN112352409A (zh) 2021-02-09
JP2021516515A (ja) 2021-07-01
JP7040632B2 (ja) 2022-03-23
CN112352409B (zh) 2023-06-27
EP3777084A1 (fr) 2021-02-17

Similar Documents

Publication Publication Date Title
WO2019194242A1 (fr) Procédures de sécurité pour cadre d&#39;api commune dans des réseaux de prochaine génération
JP5390619B2 (ja) Ｈｏｍｅｎｏｄｅ−ｂ装置およびセキュリティプロトコル
US11870765B2 (en) Operation related to user equipment using secret identifier
JP7388464B2 (ja) 第１のネットワーク装置及び第１のネットワーク装置のための方法
TW202142010A (zh) 用戶資料更新方法、裝置、節點和儲存媒體
WO2022067667A1 (fr) Procédé pour empêcher les attaques par relecture sur une identité d&#39;utilisateur cryptée
US20230396602A1 (en) Service authorization method and system, and communication apparatus
WO2022067627A1 (fr) Procédé pour empêcher une fuite d&#39;un numéro de séquence d&#39;authentification d&#39;un terminal mobile
US11381387B2 (en) Proof-of-presence indicator
WO2022183427A1 (fr) Procédé, dispositif et système de protection de numéro de séquence dans un réseau sans fil
US20240056805A1 (en) Method, apparatus and system relating to a response to an request for an application key
WO2023142102A1 (fr) Mise à jour de configuration de sécurité dans des réseaux de communication
WO2022067628A1 (fr) Procédé pour empêcher une identité d&#39;utilisateur chiffrée d&#39;attaques par relecture
EP4285623A1 (fr) Systèmes et procédés d&#39;autorisation de services basés sur la proximité

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19720701

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020551438

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2019720701

Country of ref document: EP