There is no separate authentication of the UE to support AKMA functionality. Instead, it 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.
[not reproduced yet]
Figure 6.1-1: Deriving AKMA root key after 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. In the response, the UDM may also indicate to the AUSF whether AKMA keys need to be generated for the UE. If the AUSF receives the AKMA indication from the UDM, the AUSF shall store the K AUSF and generate the AKMA Anchor Key (K AKMA) and the A-KID from K AUSF after the primary authentication procedure is successfully completed.
After AKMA key material is generated, the AUSF shall send the generated A-KID, and K AKMA to the AAnF together with the UE SUPI using the Naanf_AKMA_KeyRegistration Request service operation. The AAnF shall store the latest information sent by the AUSF.
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.
A-KID identifies the K AKMA key of the UE from which other AKMA keys are derived.
A-KID shall be in NAI format as specified in clause 2.2 of RFC 7542, i.e. username@realm. The username part includes the Routing Identifier 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 defined in clause A.3.
The key derivation of K AKMA shall be performed using the key derivation function (KDF) specified in TS 33.220. K AKMA is computed (as per Annex A.2) as K AKMA=KDF (K AUSF, "AKMA", SUPI), where the key derivation parameters consist of a static string "AKMA", and SUPI.
Since AKMA keys are based on K AUSF from primary authentication run, the AKMA keys can only be refreshed by running a fresh primary authentication.
Figure 6.2-1 shows the procedure used by the AF to request application function specific AKMA keys from 5GC directly, when the AF is located in the operator's network.
[not reproduced yet]
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 needs to know whether to use AKMA. This knowledge is implicit to the specific application on the UE and the AKMA AF.
If the AF does not have an active context associated with the A-KID, then the AF sends a Naanf_AKMA_AFKey request to AAnF with the A-KID to request the AKMA Application Key for the UE. The AF also includes its identity (AF Id) in the request. The AAnF shall authorize AF. 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 NEF/NRF using the AF Id. If succeeds, the following procedures are executed. Otherwise, the AAnF shall reject the procedure.
The AAnF can check whether the subscriber is authorized to use AKMA by the presence of the AKMA anchor key K_AKMA that has been received from the AUSF.
If the AAnF is in possession of the AKMA Application Key (K AF), it responds to the AF with the K AF. If not, the AAnF shall check if it has the UE specific K AKMA key identified by the A-KID.
If K AKMA is available in AAnF, the AAnF shall continue with step3.
If K AKMA is not available, the AAnF shall continue with step 4 and send an error response.
The AAnF derives the AKMA Application Key (K AF) from K AKMA.
The key derivation of K AF shall be performed using the key derivation function (KDF) specified in TS 33.220. K AF is computed (as per clause A.4) as K AF=KDF (K AKMA, AF_ID), where the AF_ID is constructed as follows: AF_ID = FQDN of the AF || Ua* security protocol identifier. The Ua* security protocol identifier is specified as Ua security protocol identifier in Annex H of TS 33.220. The key used for the derivation of K AF is K AKMA.
When the AF is about to request AKMA Application Key for the UE from the 5GC, 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 5GC via NEF service API.
If the AF is authorized by the NEF to request AKMA Application Key, the NEF discovers and selects an AAnF instance based on local configuration or via NRF in the same way as the AF selects the AAnF in clause 6.2.
The K AF refresh depends on the lifetime of the K AF and may be trigged by the AF, which means 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 access to the UE based on its policy. If there has been a change of K AKMA (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 AKMA.
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.