Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 33.535  Word version:  16.0.0

Top   Top   Up   Prev   Next
1…   6…   A…

 

6  AKMA ProceduresWord‑p. 10

6.1  Deriving AKMA key after primary authentication

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

6.2  Deriving AKMA Application Key for a specific AFWord‑p. 11
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
Up
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.
Step 1.
When the UE initiates communication with the AKMA AF, it shall include the derived A-KID in the Application Session Establishment request message (see clause 6.1).
Step 2.
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.
Step 3.
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.
Step 4.
The AAnF sends Naanf_AKMA_AFKey response to the AF with K AF and lifetime.
Step 5.
The AF response the Application Session Establishment request to the UE.
Up

6.3  AKMA Application Key request via NEFWord‑p. 12
Figure 6.3-1 shows the procedure used by the AF to request AKMA Application Key from 5GC via NEF, when the AF is located outside the operator's network.
[not reproduced yet]
Figure 6.3-1: AKMA Application Key request via NEF
Up
Step 1.
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.
Step 2.
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.
Step 3.
The NEF forwards the AKMA Application Key request to the selected AAnF.
Step 4.
The AAnF generates the AKMA Application Key in clause 6.2 and sends the response to the NEF with the K AF, the K AF expiration time (K AF_exptime) and potentially other parameters.
Step 5.
The NEF forwards the response to the AF.
Editor's Note: Whether other parameters are to be returned to the AF via NEF is FFS.
Up

6.4  AKMA key changeWord‑p. 13

6.4.1  KAKMA re-keying

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

6.4.2  KAF re-keying

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

7  Security related services

7.1  Services Provided by AAnF

7.1.1  General

The AAnF provides AKMA Application Key derivation service to the requester NF by Naanf_AKMA_KeyRegistration.

7.1.2  Naanf_AKMA_KeyRegistrationWord‑p. 14
Service operation name:
Naanf_AKMA_KeyRegistration.
Description:
The NF consumer requests the AAnf to provide AF related key material.
Input, Required:
A-KID, AF ID.
Input, Optional:
None.
Output, Required:
K AF, lifetime.
Output, Optional:
None.

7.2  Services Provided by AUSF

7.2.1  General

The AUSF provides AKMA key provision service to the requester NF by Nausf_AKMAkey_Get.

7.2.2  Nausf_AKMAKey_Get Service

Service operation name:
Nausf_AKMAkey_Get.
Description:
The NF consumer requests the AUSF to get the K AKMA of A-KID.
Input, Required:
A-KID.
Input, Optional:
None.
Output, Required:
K AKMA.
Output, Optional:
None.

7.3  Services Provided by NEF

7.3.1  General

The NEF exposes AKMA Application Key derivation service to the requester NF by Nnef_AKMA_AFKey.

7.3.2  Nnef_AKMA_AFKeyCreate Service

Service operation name:
Nnef_AKMA_AFKey.
Description:
The NF consumer requests the AAnF to provide AF related key material.
Input, Required:
A-KID, AF ID
Input, Optional:
None.
Output, Required:
K AF, lifetime.
Output, Optional:
None.

Up   Top   ToC