6 AKMA Procedures

33.5353GPPAuthentication and Key Management for Applications (AKMA) based on 3GPP credentials in the 5G System (5GS)Release 17TS

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

6.1 Deriving AKMA key after primary authentication

There is no separate authentication of the UE to support AKMA functionality. Instead, AKMA reuses the 5G primary authentication procedure executed e.g. during the UE Registration to authenticate the UE. A successful 5G primary authentication results in K_AUSF being stored at the AUSF and the UE. Figure 6.1-1 shows the procedure to derive K_AKMA after a successful primary authentication.

Figure 6.1-1: Deriving K_AKMA after primary authentication

1) During the primary authentication procedure, the AUSF interacts with the UDM in order to fetch authentication information such as subscription credentials (e.g. AKA Authentication vectors) and the authentication method using the Nudm_UEAuthentication_Get Request service operation.

2) In the response, the UDM may also indicate to the AUSF whether the AKMA Anchor key needs to be generated for the UE. If the AKMA indication is included, the UDM shall also include the RID of the UE.

3) If the AUSF receives the AKMA indication from the UDM, the AUSF shall store the K_AUSFand generate the AKMA Anchor Key (K_AKMA) and the A-KID from K_AUSF after the primary authentication procedure is successfully completed.

The UE shall generate the AKMA Anchor Key (K_AKMA) and the A-KID from the K_AUSF before initiating communication with an AKMA Application Function.

4) After AKMA key material is generated, the AUSF selects the AAnF as defined in clause 6.7, and shall send the generated A-KID and K_AKMA to the AAnF together with the SUPI of the UE using the Naanf_AKMA_KeyRegistration Request service operation. The AAnF shall store the latest information sent by the AUSF.

NOTE 1: The AUSF need not store any AKMA key material after delivery to the AAnF.

NOTE 1a: When re-authentication runs, the AUSF generates a new A-KID, and a new K_AKMA and sends the new generated A-KID and K_AKMA to the AAnF. After receiving the new generated A-KID and K_AKMA, the AAnF deletes the old A-KID and K_AKMA and stores the new generated A-KID and K_AKMA.

5) The AAnF sends the response to the AUSF using the Naanf_AKMA_AnchorKey_Register Response service operation.

A-KID identifies the K_AKMA key of the UE.

A-KID shall be in NAI format as specified in clause 2.2 of IETF RFC 7542 [6], i.e. username@realm. The username part shall include the RID and the A-TID (AKMA Temporary UE Identifier), and the realm part shall include Home Network Identifier.

The A-TID shall be derived from K_AUSF as specified in Annex A.3.

The AUSF shall use the RID received from the UDM as described in step 2 to derive A-KID.

NOTE 2: The chance of A-TID collision is not zero but practically low as the A-TID derivation is based on KDF specified in Annex B of TS 33.220 [4]. The detection of A-TID collision as well as potential handling of collision is not addressed in the present document.

K_AKMA shall be derived from K_AUSF as specified in Annex A.2. Since K_AKMA and A-TID in A-KID are both derived from K_AUSF based on primary authentication run, the K_AKMA and A-KID can only be refreshed by a new successful primary authentication.

6.2 Deriving AKMA Application Key for a specific AF

6.2.1 AAnF response with UE Identity

Figure 6.2-1 shows the procedure used by the AF to request application function specific AKMA keys from the AAnF, when the AF is located inside the operator’s network.

Figure 6.2-1: K_AF generation from K_AKMA

Before communication between the UE and the AKMA AF can start, the UE and the AKMA AF need to know whether to use AKMA. This knowledge is implicit to the specific application on the UE and the AKMA AF or indicated by the AKMA AF to the UE (see clause 6.5).

1. The UE shall generate the AKMA Anchor Key (K_AKMA) and the A-KID from the K_AUSF before initiating communication with an AKMA Application Function. When the UE initiates communication with the AKMA AF, it shall include the derived A-KID (see clause 6.1) in the Application Session Establishment Request message. The UE may derive K_AF before sending the message or afterwards.

2. If the AF does not have an active context associated with the A-KID, then the AF selects the AAnF as defined in clause 6.7, and sends a Naanf_AKMA_ApplicationKey_Get request to AAnF with the A-KID to request the K_AF for the UE. The AF also includes its identity (AF_ID) in the request.

AF_ID consists of the FQDN of the AF and the Ua* security protocol identifier (see Annex A.4). The latter parameter identifies the security protocol that the AF will use with the UE.

The AAnF shall check whether the AAnF can provide the service to the AF based on the configured local policy or based on the authorization information available in the signalling (i.e., Oauth2.0 token). If it succeeds, the following procedures are executed. Otherwise, the AAnF shall reject the procedure.

The AAnF shall verify whether the subscriber is authorized to use AKMA based on the presence of the UE specific K_AKMA key identified by the A-KID.

If K_AKMA is present in AAnF, the AAnF shall continue with step 3.

If K_AKMA is not present in the AAnF, the AAnF shall continue with step 4 with an error response.

3. The AAnF derives the AKMA Application Key (K_AF) from K_AKMAif it does not already have K_AF.

The key derivation of K_AF shall be performed as specified in Annex A.4.

4. The AAnF sends Naanf_AKMA_ApplicationKey_Get response to the AF with SUPI, K_AFand the K_AF expiration time.

5. The AF sends the Application Session Establishment Response to the UE. If the information in step 4 indicates failure of AKMA key request, the AF shall reject the Application Session Establishment by including a failure cause. Afterwards, UE may trigger a new Application Session Establishment request with the latest A-KID to the AKMA AF.

6.2.2 AAnF response without UE Identity

In some scenarios, anonymous user access to the AF is desirable (e.g., UE identification is not required at the AF). For allowing such anonymous user access to the AF, the procedure detailed in clause 6.2.1 of the present document is used with the following changes:

– in step 2, instead of Naanf_AKMA_ApplicationKey_Get request, Naanf_AKMA_ApplicationKey_AnonUser_Get request is used by the AF; and

– in step 4, the AAnF sends Naanf_AKMA_ApplicationKey_AnonUser_Get response to the AF with K_AFand the K_AF expiration time.

The A-KID functions as a temporary user identifier.

6.3 AKMA Application Key request via NEF

Figure 6.3-1 shows the procedure used by the AF to request K_AF from the AAnF via NEF, when the AF is located outside the operator’s network.

Figure 6.3-1: AKMA Application Key request via NEF

1. When the AF is about to request AKMA Application Key for the UE from the AAnF, e.g. when UE initiates application session establishment request as in clause 6.2.1, the AF discovers the HPLMN of the UE based on the A-KID and sends the request towards the AAnF via NEF service API. The request shall include the A-KID and the AF_ID and optionally UE Id not needed indication.

NOTE: In the case of architecture without CAPIF support, the AF is locally configured with the API termination points for the service. In the case of architecture with CAPIF support, the AF obtains the service API information from the CAPIF core function via the Availability of service APIs event notification or Service Discover Response as specified in TS 23.222 [5].

2. If the AF is authorized by the NEF to request K_AF, the NEF discovers and selects an AAnF as defined in clause 6.7.

3. The NEF sends a Naanf_AKMA_ApplicationKey_Get request to the selected AAnF with the A-KID to request the KAF for the UE.

The AAnF shall process the request in the same way as specified in clause 6.2.1 with following changes:

If K_AKMA is present in AAnF, the AAnF shall continue with step 4 in this clause.

If K_AKMA is not present in the AAnF, the AAnF shall continue with step 5 in this clause with an error response.

4. The AAnF generates the K_AF as specified in clause 6.2.1 and sends the response to the NEF with the K_AF, the K_AF expiration time (K_AFexptime) and SUPI.

5. The NEF forwards the response to the AF with the K_AF, the K_AF expiration time (K_AF exptime) and optionally GPSI (external ID). Based on local policy, the NEF uses the Nudm_SubscriberDataManagement service which is specified in TS 29.503[11] to translate SUPI to GPSI (external ID) and optionally include GPSI (external ID) in the response. If UE Id not needed indication is received in the incoming request, the NEF shall not provide the GPSI (external ID) to AF. The NEF shall not send the SUPI to the AF.

6.4 AKMA key change

6.4.1 K_AKMA re-keying

K_AKMA shall be re-keyed by running a successful primary authentication as described in clause 6.1.

6.4.2 K_AF re-keying

The K_AF re-keying depends on the lifetime of the K_AFand may be trigged by the AF, which means that when a new K_AKMA is derived, the K_AF will not be re-keyed automatically.

When the lifetime of K_AF expires, the AF may reject UE’s access to the AF or refresh the K_AF as described in clause 6.4.3 based on its policy. If the AF chooses to reject UE’s access, the AF may provide a cause indicating that the KAF has expired via Ua* protocol specific means so that the UE can take appropriate action. If therehas been a change of K_AUSF (e.g., due to a successful run of primary authentication), the UE may re-try accessing the AF by using the A-KID derived from the new K_AUSF.

6.4.3 K_AF refresh

Ua* protocol may support refresh of K_AF. If the Ua* protocol supports refresh of K_AF, the AF may refresh the K_AF at any time using the Ua* protocol.

NOTE: How a fresh key is derived for AKMA is up to Ua* protocol implementation.

6.5 Initiation of AKMA

In case when the UE does not know to use AKMA for a service, then the following procedure shown in figure 6.5-1 applies.

Figure 6.5-1: Initiation of AKMA

1. The UE may start communication over reference point Ua* with the AF with or without any AKMA-related parameters.

2. If the AF requires the use of shared keys obtained by means of the AKMA, but the request from UE does not include AKMA-related parameters, the AF replies with an AKMA initiation message. The form of this initiation message may depend on the particular reference point Ua*.

In case the UE knows to use AKMA for a service, then it directly initiates the procedure in clause 6.2.

6.6 AAnF AKMA context removal

6.6.1 General

This procedure is used to remove the AKMA context in the AAnF. NF consumers may initiate this procedure due to local policy.

Figure 6.6.1-1: AAnF AKMA context removal procedure

1. NF initiates an AAnF AKMA context removal procedure to delete the AKMA context in AAnF.

2. NF discovers the AAnF of the UE, as specified in clause 6.7 and sends a Naanf_AKMA_Context_Remove request to AAnF to remove AKMA context for the UE.

3. AAnF shall delete AKMA Context (e.g. SUPI, A-KID and K_AKMA) from its local database.

4. AAnF sends a Naanf_AKMA_Context_Remove response to NF.

6.7 AAnF Discovery and Selection

The NF consumer or the SCP performs AAnF discovery to discover an AAnF instance.

In the case of NF consumer-based discovery and selection, the following applies:

– Internal AFs and the NEF performs AAnF instance selection that handles the AKMA request. The AF/NEF shall utilize the NRF to discover the AAnF instance(s) unless AAnF information is available by other means, e.g. locally configured on the AF/NEF.

– The AUSF performs AAnF selection to allocate an AAnF Instance to send the AKMA key material related to the UE. The AUSF shall utilize the NRF to discover the AAnF instance(s) unless AAnF information is available by other means, e.g. locally configured on the AUSF.

– The NF specified in clause 6.6 performs AAnF instance selection that handles the AKMA request. The NF shall utilize the NRF to discover the AAnF instance(s) unless AAnF information is available by other means, e.g. locally configured on the the NF specified in clause 6.6.

The AAnF selection functionality in NF consumer or in SCP should consider the following factor:

– the UE’s Routing Indicator.

NOTE 1: The AF/NEF obtains the Routing Indicator as part of the A-KID in the AKMA request. The AUSF obtains the Routing Indicator within the Nudm_UEAuthentication_Get Response from the UDM.

Internal AFs, the NEF and the AUSF shall select the same AAnF set based on the UE’s Routing Indicator.

When the UE’s Routing Indicator is set to its default value as defined in TS 23.003 [9], the AAnF NF consumer can select any AAnF instance within the home network of the UE.

NOTE 2: In scenarios where multiple sets of AAnFs are deployed, it is left up to implementation how to ensure that the AAnF NF consumers select an AAnF instance within the AAnF set the UE belongs to when the UE’s Routing Indicator is set to its default value.

In the case of delegated discovery and selection in SCP, the AAnF NF consumer shall send all available factors to the SCP.