4 Services offered by the AAnF

29.5353GPP5G SystemAKMA Anchor ServicesRelease 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

4.1 Introduction

The AKMA Anchor Service is used for the AAnF to store AKMA related key material and provide AKMA Application Key information. The AAnF offers to other NFs the following service:

– Naanf_AKMA.

Table 4.1-1: Service provided by AAnF

Service Name	Description	Service Operations	Operation Semantics	Example Consumer(s)
Naanf_AKMA	This service enables the NF service consumers to request the AAnF to store the AKMA related key material or get the AKMA Application Key information from the AAnF.	AnchorKey_Register	Request/Response	AUSF
		ApplicationKey_Get	Request/Response	AF, NEF
		ApplicationKey_AnonUser_Get (NOTE 2)	Request/Response	AF
		ContextRemove	Request/Response	AUSF
NOTE 1: The service corresponds to the Naanf_AKMA service as defined in 3GPP TS 33.535 [14]. NOTE 2: The ApplicationKey_AnonUser_Get service operation is defined reusing the ApplicationKey_Get service operation.

Table 4.1-2 summarizes the corresponding APIs defined for this specification.

Table 4.1-2: API Descriptions

Service Name	Clause	Description	OpenAPI Specification File	apiName	Annex
Naanf_AKMA	4.2	API for Naanf_AKMA	TS29535_Naanf_AKMA.yaml	naanf-akma	Annex A.2 Naanf_AKMA API

4.2 Naanf_AKMA Service

4.2.1 Service Description

4.2.1.1 Overview

The Naanf_AKMA, as defined in 3GPP TS 33.535 [14] is provided by the AKMA Anchor Function (AAnF).

This service:

– allows consumer NFs to store the AKMA related key material.

– allows consumer NFs and the AFs to request the AKMA Application Key information for the UE.

4.2.1.2 Service Architecture

The 5G System Architecture is defined in 3GPP TS 23.501 [2]. The Authentication and Key Management for Applications architecture is defined in 3GPP TS 33.535 [14].

The Naanf_AKMA service is part of the Naanf service-based interface exhibited by the AAnF.

Known consumers of the Naanf_AKMA service are:

– AUthentication Server Function (AUSF)

– Application Function (AF)

– Network Exposure Function (NEF)

Figure 4.2.1.2-1: Reference Architecture for the Naanf_AKMA Service; SBI representation

Figure 4.2.1.2-2: Reference Architecture for the Naanf_AKMA Service; reference point representation

4.2.1.3 Network Functions

4.2.1.3.1 AKMA Anchor Function (AAnF)

The AKMA Anchor Function (AAnF) is a functional element that stores the AKMA Anchor Key (K_AKMA), A-KID for AKMA service, which is received from the AUSF after the UE completes a successful 5G primary authentication. The AAnF also generates the key material to be used between the UE and the Application Function (AF) and maintains the UE AKMA context as defined in 3GPP TS 33.535 [14].

4.2.1.3.2 NF Service Consumers

The known NF service consumers are as follows:

The AUthentication Server Function (AUSF):

– provides the AKMA key material of the UE to the AAnF.

The Network Exposure Function (NEF):

– enables and authorizes the external AF accessing AKMA service and forwards the request towards the AAnF;

– performs the AAnF selection.

The Application Function (AF):

– requests for AKMA Application Key from the AAnF;

– shall be authenticated and authorized by the operator network before receiving the K_AF from the AAnF;

– performs the AAnF selection if the AF located inside the operator’s network.

4.2.2 Service Operations

4.2.2.1 Introduction

Table 4.2.2.1-1: Operations of the Naanf_AKMA Service

Service operation name	Description	Initiated by
Naanf_AKMA_AnchorKey_Register	This service operation is used by an NF to store the AKMA related key material.	AUSF
Naanf_AKMA_ApplicationKey_Get	This service operation is used by an NF to request the AKMA Application Key information for the UE	NEF, AF
Naanf_AKMA_ApplicationKey_AnonUser_Get	This service operation is used by an AF to request the AKMA Application Key information for the UE when authorized AF are not expected to receive the SUPI of the UE	AF

4.2.2.2 Naanf_AKMA_AnchorKey_Register service operation

4.2.2.2.1 General

The procedures support:

– store the AKMA related key material by the NF service consumer to the AAnF as described in 3GPP TS 33.535 [14];

4.2.2.2.2 Store the AKMA related key material

Figure 4.2.2.2.2-1 illustrates the registration of AKMA related key material at the AAnF.

Figure 4.2.2.2.2-1: Registration of AKMA related key material

In order to store the AKMA related key material, the NF service consumer shall send an HTTP POST request message to the resource URI "{apiRoot}/naanf-akma/<apiVersion>/register-anchorkey" as shown in step 1 of figure 4.2.2.2.2-1, and the AkmaKeyInfo data structure as request body.

The AkmaKeyInfo data structure shall include:

– SUPI as "supi" attribute;

– A-KID as "aKId" attribute; and

– K_AKMA as "kAkma" attribute.

If the AAnF cannot successfully fulfil the received HTTP POST request due to an internal error or an error in the HTTP POST request, the AAnF shall send an HTTP error response as specified in clause 5.1.7.

If the AAnF determines the received HTTP POST request needs to be redirected, the AAnF shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [4].

Upon successful reception of an HTTP POST request, the AAnF shall store the key material information and respond to the NF service consumer with a 200 OK status code, including the AkmaKeyInfo data structure as response body.

4.2.2.3 Naanf_AKMA_ApplicationKey_Get service operation

4.2.2.3.1 General

The Naanf_AKMA_ApplicationKey_Get service operation is used by an NF service consumer to request the AKMA Application Key information for the UE.

4.2.2.3.2 AKMA Application Key request

Figure 4.2.2.3.2-1 shows a scenario where the NF service consumer sends a request to the AAnF to request and get the AKMA Application Key information for the UE (as shown in 3GPP TS 33.535 [14]).

Figure 4.2.2.3.2-1: NF service consumer retrieve AKMA Application Key information

The NF service consumer shall invoke the Naanf_AKMA_ApplicationKey_Get service operation to retrieve the AKMA Application Key information. The NF service consumer shall send for this purpose an HTTP POST request with "{apiRoot}/naanf-akma/<apiVersion>/retrieve-applicationkey" as Resource URI, as shown in step 1 of figure 4.2.2.3.2-1, and the request body containing the AkmaAfKeyRequest data structure.

If the request corresponds to a Naanf_AKMA_ApplicationKey_AnonUser_Get request, then the AkmaAfKeyRequest shall contain the "anonInd" attribute set to "true".

If the AAnF determines the received HTTP POST request needs to be redirected, the AAnF shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [4].

The AAnF shall also verify the presence of the UE specific K_AKMA key identified by the A-KID.

– If K_AKMA is not present in the AAnF, the AAnF shall reply with an HTTP "403 Forbidden" status code and the response message body including a ProblemDetails data structure with the "cause" attribute set to the "K_AKMA_NOT_PRESENT" application error specified in table 5.1.7.3-1.

– If K_AKMA is present in the AAnF, the AAnF shall continue and process the request as specified below.

Upon the reception of the HTTP POST request, the AAnF shall respond with an HTTP "200 OK" status code and the response message body containing the AkmaAfKeyData data structure which shall include:

– K_AF as "kaf" attribute;

– K_AF expiration time as "expiry" attribute; and

– SUPI as "supi" attribute, if the "anonInd" attribute was not present in the request or it was present and set to "false".

If the requested AKMA Application Key information for the UE does not exist, the AAnF shall respond with "204 No Content".

If the NF service consumer is an NEF, and if UE identifier is required to relay to the AF based on local policy, the NEF invokes the Nudm_SubscriberDataManagement service defined in 3GPP TS 29.503 [17] to translate the SUPI to a GPSI (External Id), and then invoke the AKMA API to include the GPSI (External Id) in the response to the AF as defined in 3GPP TS 29.522 [16]. The NEF shall not send the SUPI to the AF.

4.2.2.4 Naanf_AKMA_ContextRemove service operation

4.2.2.4.1 General

The Naanf_AKMA_ContextRemove service operation is used by an NF service consumer to request the AAnF to remove the AKMA related key material.

4.2.2.4.2 AKMA Context removal

Figure 4.2.2.4.2-1 shows a scenario where the NF service consumer sends a request to the AAnF to delete the AKMA related key material (as shown in 3GPP TS 33.535 [14]).

Figure 4.2.2.4.2-1: NF service consumer request to remove the AKMA related key material

The NF service consumer shall invoke the Naanf_AKMA_ContextRemove service operation to request the AAnF to remove the AKMA related key material. The NF service consumer shall send an HTTP POST request with "{apiRoot}/naanf-akma/<apiVersion>/remove-context" as Resource URI, as shown in figure 4.2.2.4.2-1, step 1, to request to remove AKMA related key material according to the value of the "CtxRemove" data type in the request body.

If errors occur when processing the HTTP POST request, the AAnF shall send an HTTP error response as specified in clause 5.1.7.

If the AAnF determines the received HTTP POST request needs to be redirected, the AAnF shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [4].

Upon the reception of the HTTP POST request, if the AKMA context (e.g. A-KID, K_AKMA) for the UE has been removed successfully, the AAnF shall send an HTTP "204 No Content" response.

If the AKMA Context resource does not exist, the AAnF shall respond with "404 Not Found" and the "cause" attribute of the "ProblemDetails" data structure set to "AKMA_CONTEXT_NOT_FOUND".