Content for &nbsp; TS 33.535 &nbsp; Word version:&nbsp; 18.4.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.

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.

Figure 6.2-1: KAF generation from KAKMA

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

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

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. If AF wants to receive a notification for AKMA service disabling, the AF shall include AKMA service disable URI in the Naanf_AKMA_ApplicationKey_Get request. Based on the AKMA service disable URI, the AAnF shall create an implicit subscription for the AF for the AAnF to later notify the AF about AKMA service disable as defined in 6.x. Implicit subscription has an expiration time set by operator policy.

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 6 with an error response.

Once receiving the request from the AF, if the AAnF determines this specific AF needs GPSI, according to its local policy, the AAnF sends a Nudm_SDM_Get Request to the UDM to fetch the GPSI of the UE. If the specific AF does not need GPSI, the AAnF shall continue with step 5.

The UDM responds with the GPSI of the UE. The AAnF shall store the received GPSI as part of UE's AKMA context.

Figure 6.3-1: AKMA Application Key request via NEF

Once receiving the request from the AF, the AAnF shall send a Nudm_EventExposure_Subscribe request to UDM with SUPI/GPSI to request the RoamingStatusReport from the UDM.

Step 6.

The UDM shall send the Nudm_EventExposure_Subscribe response to the AAnF with the information of roaming status.

Step 7.

Once the AAnF receives the roaming status from the UDM, it checks the local policy and determines whether to provide service to the UE. If yes, the AAnF derives the AKMA Application Key (KAF) from KAKMA if it does not already have KAF. The AAnF shall store the KAF expiration time as part of UE's AKMA context.

When UE is dual registered, the UE is treated as roaming if at least one of the serving PLMNs indicates the UE is roaming.

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

Step 8.

If the AAnF determines to provide AKMA service to the UE, the AAnF sends Naanf_AKMA_ApplicationKey_Get response to the AF with SUPI/GPSI, KAF and the KAF expiration time. Whether to send SUPI or GPSI is determined by AAnF based on the local policy. If the AAnF finds that roaming is not allowed, it shall respond the AF containing a failure indication that roaming is not allowed.

Step 9.

The AF sends the Application Session Establishment Response to the UE. If the information in step 8 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. 18

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 6, the AAnF sends Naanf_AKMA_ApplicationKey_AnonUser_Get response to the AF with KAF and the KAF expiration time. The AAnF shall store the KAF expiration time as part of UE's AKMA context.

The A-KID functions as a temporary user identifier.

6.3 AKMA Application Key request via NEF p. 18

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, including the authorization after verification of the AF_ID in step 1, 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.

Once receiving the request from the AF, AAnF shall request the UE roaming status report from UDM as specified in clause 6.2.1, step 5-6. If the AAnF determines to provide AKMA service to the UE, 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. The AAnF shall store the KAF expiration time as part of UE's AKMA context. If the AAnF finds that roaming is not allowed, it shall respond the AF containing a failure indication that roaming is not allowed.

Figure 6.5-1: Initiation of AKMA

The NEF forwards the response to the AF, the response contains the KAF, the KAF expiration time (KAF exptime) and optionally GPSI (external ID) or the failure indication of roaming not allowed. 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. 20

6.4.1 K_AKMA re-keying p. 20

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

The KAF re-keying depends on the lifetime of the KAF and may be triggered 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. 20

There is no support for an explicit KAF refresh procedure in this document. If a primary authentication does not take place, the KAUSF, KAKMA and KAF remain unchanged since the latest primary authentication.

The KAF may be refreshed by the KAKMA refresh defined in clause 6.4.4 as decided by AAnF.

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

6.4.4 K_AKMA refresh |R18| p. 20

As defined in clause 6.1.5 of TS 33.501, the AAnF may decide to refresh the KAKMA based on the operator's local authentication policy by sending the Nudm_UECM_AuthTrigger Request message to the UDM. The UDM may further decide whether to trigger the primary authentication as defined in clause 6.1.5 of TS 33.501.

6.5 Initiation of AKMA p. 20

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

6.6.1 General p. 21

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 with SUPI to AAnF to remove AKMA context for the UE.

AAnF shall delete AKMA Context (e.g. SUPI, A-KID, KAKMA, GPSI and KAF expiration time) from its local database identified by SUPI.

Figure 6.8.1-1: AAnF notification to AF about AKMA service disable

AAnF sends a Naanf_AKMA_Context_Remove response to NF. This response is just an acknowledgement of the request received.

6.7 AAnF Discovery and Selection |R17| p. 21

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.

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, the AAnF NF consumer can select any AAnF instance within the home network of the UE.

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

6.8 Notification about AKMA service disabling |R18| p. 22

This procedure is used when the AKMA sessions have already been started (before roaming was detected), and as soon as PLMN change is detected at the AAnF, the AAnF may execute this procedure based on the roaming policy.

Reproduction of 3GPP TS 33.535, Fig. 6.8.1-1: AAnF notification to AF about AKMA service disable

UE registers with a (H)PLMN.

UE is accessing the AF and key material is provided to AF as described in 6.2.1. While accessing the AAnF, AF may also provide the Notification URI.

UE is getting registered in a VPLMN and AAnF detects the PLMN change via the Nudm_EventExposure_Notification received from UDM.

AAnF determines if AF(s) have subscribed to receive notifications for AKMA service disabling and roaming policy is configured and restrict the AKMA access in the VPLMN; if yes, steps 6 and 7 are executed. Otherwise, steps 6 and 7 are skipped.