Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 33.122  Word version:  18.4.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   6.5…   6.6…   A…   B…   C… 
6.5 Security procedures for CAPIF-2e reference point  6.5.1 General  6.5.2 Authentication and authorization  6.5.2.1 Method 1 - Using TLS-PSK  6.5.2.2 Method 2 - Using PKI  6.5.2.3 Method 3 - TLS with OAuth token  6.5.3 Authentication and authorization for RNAA  6.5.3.1 General  6.5.3.2 Authorization using oauth client credential flow  6.5.3.3 Authorization using authorization code (optional PKCE) flow  6.5.3.4 Revocation 
...

 

6.5  Security procedures for CAPIF-2e reference point  p. 15

6.5.1  General  p. 15

Based on the selected security method by the CAPIF Core Function (c.f., subclause 6.3.1), one of the methods specified in subclause 6.5.2 shall be used between the API invoker and a 3GPP defined API exposing function for CAPIF-2e interface authentication and protection.
Up

6.5.2  Authentication and authorization  p. 15

6.5.2.1  Method 1 - Using TLS-PSK  p. 15

The API invoker and the API exposing function shall follow the procedure in this sub-clause to establish dedicated secure session using TLS connection based on Pre-Shared Key (PSK). CAPIF-1e authentication shall be used to bootstrap a Pre-Shared key for authenticating a TLS connection for CAPIF-2e. It is assumed that both the API invoker and the CAPIF core function are pre-provisioned with certificates. The TLS profile as specified in Annex E of TS 33.310 shall be used. Figure 6.5.2.1-1 details the message flow between the API invoker, the CAPIF core function and the API exposing function, to establish secure CAPIF-2e interface using a pre-shared key for authentication.
Reproduction of 3GPP TS 33.122, Fig. 6.5.2.1-1: CAPIF-2e interface authentication and protection using TLS-PSK
Figure 6.5.2.1-1: CAPIF-2e interface authentication and protection using TLS-PSK
Up
Step 1.
CAPIF-1e authentication and secure session is established as specified in subclause 6.3.1 of the present document. The CAPIF core function shall provide the validity timer value for the key AEF PSK.
Step 2.
After successful establishment of TLS on CAPIF-1e, the API invoker and the CAPIF core function shall derive the key AEF PSK.
The Key AEF PSK shall be bound to an AEF and shall be derived as specified in Annex A. The API invokswer and the CAPIF core function starts the validity timer for the key AEF PSK.
Step 3.
The API Invoker shall send Authentication Initiation Request to the AEF, including the CAPIF core function assigned API invoker ID.
Steps 1 and 2 of this procedure may be skipped if the API invoker is already in possession of a valid key AEF PSK. In this case, the API invoker begins the procedure at step 3.
Step 4.
The AEF shall request for security information from the CAPIF Core Function to perform authentication and secure interface establishment with the API invoker, if the AEF does not have a valid key. The CAPIF Core Function provides the security information related to the chosen security method (TLS-PSK: AEF PSK) to the AEF over CAPIF-3 reference point. The CAPIF core function shall provide the remaining validity timer value for the key AEF PSK.
Step 5.
After fetching the relevant security information (AEF PSK) for the authentication, the AEF shall send Authentication Initiation Response message to API invoker to initiate the TLS session establishment. The AEF starts the validity timer based on the value received from the CAPIF core function in step 4.
Step 6.
The API Invoker and the AEF shall perform mutual authentication using the key AEF PSK and establish TLS session over the CAPIF-2e.
After successful establishment of TLS on CAPIF-2e reference point, the API exposing function shall authorize the API invoker's service API invocation request based on authorization information obtained from CAPIF core function as specified in subclause 8.16 of TS 23.222.
Up

6.5.2.2  Method 2 - Using PKI  p. 17

The API invoker and the API exposing function shall follow the procedure in this subclause to establish dedicated secure session over CAPIF-2e using TLS based on certificate based mutual authentication. It is assumed that both API invoker and API exposing function are pre-provisioned with certificates. Figure 6.5.2.2-1 details the message flow between the API invoker, the CAPIF core function and the API exposing function related to this security method.
Reproduction of 3GPP TS 33.122, Fig. 6.5.2.2-1: CAPIF-2e interface authentication and protection using certificate based mutual authentication
Figure 6.5.2.2-1: CAPIF-2e interface authentication and protection using certificate based mutual authentication
Up
Step 1.
The API invoker shall send Authentication Initiation Request to the AEF, including API invoker ID.
Step 2.
The AEF shall request for security information from the CAPIF Core Function to perform authentication and secure interface establishment with the API invoker. The CAPIF Core Function provides the security information related to the chosen security method (TLS-PKI) to the AEF over CAPIF-3 reference point. CAPIF core function may return API invoker's root CA certificate for the AEF to validate the API invoker's certificate.
Step 3.
After fetching the relevant security information for the authentication, AEF shall send Authentication Initiation Response message to API invoker to initiate the TLS session establishment procedure.
Step 4.
Then the API Invoker and the AEF shall perform mutual authentication using certificates and establish TLS session over the CAPIF-2e. Certificate based authentication shall follow the profiles given in clauses 6.1.3a and 6.1.4a of TS 33.310. The structure of the PKI used for the certificate is out of scope of the present document.
After successful establishment of TLS on CAPIF-2e reference point, the API exposing function shall authorize the API invoker's service API invocation request based on authorization information obtained from CAPIF core function as specified in subclause 8.16 of TS 23.222.
Up

6.5.2.3  Method 3 - TLS with OAuth token  p. 17

This method details establishment of secure channel over CAPIF-1e, CAPIF-2e reference points, and uses the OAuth 2.0 [4] token based mechanism to authorize and honour API invoker's northbound API invocations to the API exposing function. Figure 6.5.2.3-1 details security information flows between the API invoker, the CAPIF core function and the API exposing function. It is assumed that the API invoker, the CAPIF core function and the AEF are pre-provisioned with the appropriate credentials and related information to establish a secure session.
As per OAuth 2.0 [4], the CAPIF core function shall perform the functionality of the authorization server and provide the token endpoint, the API invoker shall perform the function of the client functionality, while the API exposing function shall perform the resource server functions. The API invoker client (client endpoint) shall be registered as a confidential client type with an authorization grant type of 'client credentials'. The authorization shall be previously arranged in the CAPIF core function. The access token shall follow the profile described in Annex C.
Reproduction of 3GPP TS 33.122, Fig. 6.5.2.3-1: CAPIF-2e interface authentication and protection using Access Tokens
Figure 6.5.2.3-1: CAPIF-2e interface authentication and protection using Access Tokens
Up
Step 1.
CAPIF-1e authentication and secure session establishment is performed as specified in subclause 6.3.1.
Step 2.
After successful establishment of TLS session over CAPIF-1e, as described in subclause 6.3.1 of the present document, the API invoker shall send an Access Token Request message to the CAPIF core function as per the OAuth 2.0 [4] specification.
Step 3.
The CAPIF core function shall verify the Access Token Request message per OAuth 2.0 [4] specification.
Step 4.
If the CAPIF core function successfully verifies the Access Token Request message, the CAPIF core function shall generate an access token specific to the API invoker and return it in an Access Token Response message.
Steps 1 to 4 of this procedure may be skipped if the API invoker is already in possession of a valid OAuth access token. In this case, the API invoker begins the procedure at step 5.
Step 5.
On CAPIF-2e, the API invoker authenticates to the AEF by establishing a TLS session with the API exposing function based on the authentication and authorization method (i.e. Server (AEF) side certificate authentication or certificate-based mutual authentication) as indicated by CAPIF core function. The following procedure shall be performed prior to establishment of TLS session.
The API invoker shall send Authentication Initiation Request to the AEF, including API invoker ID.
The AEF shall request for security information from the CAPIF Core Function to perform authentication and secure interface establishment with the API invoker. The CAPIF Core Function provides the security information related to the chosen security method (TLS with OAuth token) to the AEF over CAPIF-3 reference point. The CAPIF core function may return API invoker's root CA certificate for the AEF to validate the API invoker's certificate.
After fetching the relevant security information for the authentication, the AEF shall send Authentication Initiation Response message to API invoker to initiate the TLS session establishment procedure.
Step 6.
With successful authentication to the AEF on CAPIF-2e, the API invoker shall initiate invocation of a 3GPP northbound API with the AEF. The access token received from the CAPIF core shall be sent along with the northbound API invocation request as per OAuth 2.0 [4].
Step 7.
The API exposing function shall validate the access token. The AEF verifies the integrity of the access token by verifying the CAPIF core function signature If validation of the access token is successful, the AEF shall verify the API invoker's Northbound API invocation request against the authorization claims in access token, ensuring that the API Invoker has access permission for the requested service API.
Step 8.
After successful verification of the access token and authorization claims of the API invoker, the requested northbound API shall be invoked and the appropriate response shall be returned to the API invoker.
Up

6.5.3  Authentication and authorization for RNAA |R18|  p. 19

6.5.3.1  General  p. 19

The authorization function shall obtain the necessary permission from the resource owner for allowing the API invoker to access a northbound API.
RNAA shall use token-based authorization using OAuth 2.0 framework with the following roles:
  • The API invoker has the role of the OAuth 2.0 client.
  • The CCF has the role of the OAuth 2.0 authorization server, i.e., providing the access token used for RNAA.
  • The AEF has the role of the resource server.
The access tokens used for RNAA shall contain the resource owner ID.
The resource owner may be the user of the UE or the owner of the subscription depending on the use case and regulations.The resource owner ID is specified as the GPSI of the corresponding UE if the resource is related to a UE.
The access token shall include the resource owner ID and the API invoker ID. The resource owner ID is the GPSI. The API invoker ID binds the token to the API invoker. To avoid privacy issues, GPSI should be different from MSISDN, SUPI etc.
The AEF shall check if the token includes resOwnerId claim, which includes resource owner ID, to identify that it is a token used in RNAA.
AEF shall do the authorization check of the API invocation request for accessing the resources of the resource owner. AEF checks the request against the token, including:
  1. checking the token integrity and
  2. checking whether the GPSI (if present) in the API invocation request is compliant with the resource owner ID in the access token. As the token includes resource owner ID, there is no need for additional UE authentication in API invocation. Moreover, the token should be able to restrict the API invoker to a specific resource (e.g., location, QoS, PDN connectivity status) of the resource owner.
For OAuth 2.0 flows involving redirection, authentication between CCF/AUF and UE should be performed after API Invoker redirects the UE to CCF/AUF.
In case of an external AF (i.e., not the application on the UE) being the API invoker, for mutual authentication of API invoker AF and API exposing function, the authentication methods of clause 6.4 and clause 6.5.2 are reused.
For authorization, the following OAuth 2.0 flows may be used:
  • Client credential flow (according to RFC 6749),
  • Authorization code flow (according to RFC 6749), or
  • Authorization code flow with PKCE (according to RFC 7636).
CCF shall indicate the selected flows to the API invoker.
CCF shall give service authorization which subscribers or users can use RNAA.
For selecting the authorization method, the procedure as specified in clause 6.3.1.2 is used with the following RNAA specific additions. The API invoker shall include in the Security Method Request the supported RNAA authorization flows. The CCF shall determine the RNAA authorization flow based on the RNAA capabilities of the CCF, AEF, and API invoker. The API invoker shall use the determined RNAA authorization flow in the subsequent communication with the CCF and AEF.
Up

6.5.3.2  Authorization using oauth client credential flow  p. 20

If client credential flow is used for authorization of the API invoker by the AEF, the procedures in RFC 6749 shall be followed with the following profile:
  • The access token request message may include the resource owner ID.
  • The CCF shall check whether the API invoker is entitled to consume the API and allowed to access the resources of the resource owner, by using authorization information available in the CCF.
  • If the API invoker is on a UE, the CCF shall check that the UE is accessing its own resources. If the API invoker is an AF not on a UE, the check is omitted.
Up

6.5.3.3  Authorization using authorization code (optional PKCE) flow  p. 20

If authorization code flow, optionally with PKCE, is used by the AEF for authorization of the API invoker, the procedures in RFC 6749 and optionally RFC 7636 shall be followed, with the following profile:
  • The authorization token and/or authorization request may include the resource owner ID.
  • The resource owner dynamically authorizes the API invoker to access the resource owner's resources as described in RFC 6749 and optionally RFC 7636.
  • If the API invoker is on a UE, the CCF shall check that the UE is accessing its own resources. The access token shall contain the resource owner ID (i.e. GPSI) and the API invoker ID. If the API invoker is an AF not on a UE, the check is omitted.
Up

6.5.3.4  Revocation  p. 21

The CCF can initiate the Authorization Revocation Request message as defined in clause 8.23.4 of TS 23.222 with additional information to identify the RNAA-related revoked token.
AEF, storing the information about the RNAA-related revoked token, shall check whether the token presented by an API invoker is revoked or not, before responding to the API invoker's invocation request.
The CCF provided notification message to the API invoker shall include the information to identify the RNAA-related revoked token.
Up

Up   Top   ToC