Content for &nbsp; TS 33.535 &nbsp; Word version:&nbsp; 17.7.0

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.

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.

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

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

Figure 6.2-1: KAF generation from KAKMA

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 KAKMA 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.

Step 5.

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

A-KID identifies the KAKMA key of the UE.

A-KID shall be in NAI format as specified in Section 2.2 of RFC 7542, 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 KAUSF 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.

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

6.2 Deriving AKMA Application Key for a specific AF p. 14

6.2.1 AAnF response with UE Identity |R17| p. 14

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.

Reproduction of 3GPP TS 33.535, Fig. 6.2-1: KAF generation from KAKMA

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).

The UE shall generate the AKMA Anchor Key (KAKMA) and the A-KID from the KAUSF 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 KAF before sending the message or afterwards.

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 KAF 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 KAKMA key identified by the A-KID.

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

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

The AAnF derives the AKMA Application Key (KAF) from KAKMA if it does not already have KAF.

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

Figure 6.3-1: AKMA Application Key request via NEF

The AAnF sends Naanf_AKMA_ApplicationKey_Get response to the AF with SUPI, KAF and the KAF expiration time.

Step 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 |R17| p. 15

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 KAF and the KAF expiration time.

The A-KID functions as a temporary user identifier.

6.3 AKMA Application Key request via NEF p. 15

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

Reproduction of 3GPP TS 33.535, Fig. 6.3-1: AKMA Application Key request via NEF

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.

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

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 KAKMA is present in AAnF, the AAnF shall continue with step 4 in this clause.

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

Figure 6.5-1: Initiation of AKMA

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

Step 5.

The NEF forwards the response to the AF with the KAF, the KAF expiration time (KAF exptime) and optionally GPSI (external ID). Based on local policy, the NEF uses the Nudm_SubscriberDataManagement service which is specified in TS 29.503 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 p. 16

6.4.1 K_AKMA re-keying p. 16

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

6.4.2 K_AF re-keying p. 16

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

When the lifetime of KAF expires, the AF may reject UE's access to the AF or refresh the KAF 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 KAUSF (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 KAUSF.

6.4.3 K_AF refresh p. 16

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

6.5 Initiation of AKMA p. 16

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.

Reproduction of 3GPP TS 33.535, Fig. 6.5-1: Initiation of AKMA

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

Figure 6.6.1-1: AAnF AKMA context removal procedure

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 |R17| p. 17

6.6.1 General p. 17

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

Reproduction of 3GPP TS 33.535, Fig. 6.6.1-1: AAnF AKMA context removal procedure

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

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.

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