Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 33.122  Word version:  18.3.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   6.5…   6.6…   A…   B…   C…

 

B  Security flowsp. 25

B.1  Onboardingp. 25

Figure B.1-1 shows the functional security flow for online onboarding. Offline onboarding is out of scope for the present document.
Reproduction of 3GPP TS 33.122, Fig. B.1-1: Onboarding security flow
Up
As a pre-requisite to onboarding, the API Invoker and the CAPIF are provisioned with the necessary onboarding enrolment information for the API Invoker. The method to do this is out of scope for the present document.
Initially, the API Invoker attempts to establish a secure connection with the CAPIF core. If the onboarding session cannot be secured, the session is released and the onboarding flow ends.
If the session is secured, the API Invoker requests onboarding using the Onboard API Invoker Request message defined in clause 8.1 of TS 23.222. The API Invoker includes an onboarding credential in the Onboard API Invoker Request message. The CAPIF core receives the Onboard API Invoker request message and validates the onboarding credential. If the onboarding credential is valid, the CAPIF core creates and returns an Onboard API Invoker Response message defined in clause 8.1 of TS 23.222, which contains the API Invoker profile and includes the API Invoker ID. Security information for CAPIF-1 or CAPIF-1e authentication and (optionally) security information for CAPIF-2 or CAPIF-2e is also transferred to the API Invoker as part of the onboarding response. If the CAPIF core cannot validate the onboarding credentials, then an Onboard API Invoker response message containing an error response is returned to the API Invoker instead.
Following the return of an Onboard API Invoker response message (either successful or unsuccessful), the secure session is torn down and the onboarding security flow ends.
Up

B.2  Authentication and authorizationp. 26

CAPIF authentication and authorization consists of CAPIF-1e authentication and CAPIF-2e authentication and authorization. Figure B.2-1 shows the functional security flow for CAPIF-1e authentication while Figure B.2-2 shows the functional security flow for CAPIF-2e authentication and authorization.
Prior to starting the security flow for either CAPIF-1e or CAPIF-2e authentication and authorization, successful onboarding of the API Invoker has taken place.
In Figure B.2-1, the security flow starts with the API Invoker establishing a TLS connection to the CAPIF core over the CAPIF-1e interface per clause 6.3. Successful TLS establishment results in the opportunity for the CAPIF core to transfer CAPIF-2e AEF authentication and authorization information to the API invoker. After transfer of the CAPIF-2e AEF authentication and authorization information to the API invoker, the TLS session is released and the CAPIF-1e security flow ends.
In the case that either the CAPIF-1e TLS session or API invoker authentication procedure fails, the API Invoker authentication is rejected, AEF authentication and authorization information is not transferred to the API Invoker, and the TLS session with the API Invoker is closed.
Reproduction of 3GPP TS 33.122, Fig. B.2-1: CAPIF-1e authentication
Up
Figure B.2-2 shows the security flow for the CAPIF-2e interface. Successful CAPIF-1e authentication and AEF authentication information (as a minimum) is needed for the API invoker to communicate with the AEF.
The security flow begins when the API Invoker makes an authentication request to the AEF. The AEF receives the request and attempts to authenticate the API Invoker. If the AEF does not possess the authentication information to authenticate the API invoker, the AEF can query the CAPIF core for it. If authentication of the API invoker is successful, then a TLS session is established. If authentication of the API invoker fails, the security flow ends.
If authentication of the API invoker is successful, then based on the interested service API, the API Invoker makes a northbound API request.
The AEF attempts to validate the northbound API request. If the AEF does not possess the authorization information for the requested service API, the AEF can query the CAPIF core for it. If validation of the northbound API request is successful, the northbound API is serviced.
Upon completion of the northbound API action(s), the secure session is torn down and the security flow ends.
If the AEF cannot validate the northbound API request, the AEF rejects the northbound API request, tears down the secure session, and ends the security flow.
Reproduction of 3GPP TS 33.122, Fig. B.2-2: CAPIF-2e authentication and authorization
Up

Up   Top   ToC