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 KAUSF being stored at the AUSF and the UE. Figure 6.1-1 shows the procedure to derive KAKMA after a successful primary authentication.
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.
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.
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.
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. 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 or policy provided by the NRF using the AF_ID. 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 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.
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.
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, 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.
The NEF forwards the KAF request to the selected AAnF.
The AAnF shall process the request in the same way as specified in clause 6.2 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.
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. The NEF shall not send the SUPI to the AF.
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.
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.
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 selection to allocate an AAnF Instance 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 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.