Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 33.535  Word version:  17.3.0

Top   Top   Up   Prev   Next
1…   4…   6…   7…   A…

 

6  AKMA ProceduresWord‑p. 12

6.1  Deriving AKMA key after primary authenticationWord‑p. 12

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.
(not reproduced yet)
Figure 6.1-1: Deriving KAKMA after primary authentication
Up
Step 1.
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.
Step 2.
In the response, the UDM may also indicate to the AUSF whether AKMA Anchor keys need to be generated for the UE. If the AKMA Ind is included, the UDM shall also include the RID of the UE.
Step 3.
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.
Step 4.
After AKMA key material is generated, the AUSF selects the AAnFas 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 step2 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.
Up

6.2  Deriving AKMA Application Key for a specific AFWord‑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.
(not reproduced yet)
Figure 6.2-1: KAF generation from KAKMA
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 or indicated by the AKMA AF to the UE (see clause 6.5).
Step 1.
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. UE may derive KAF before sending the message or afterwards.
Step 2.
If the AF does not have an active context associated with the A-KID, then the AF selects the AAnFas 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.
Step 3.
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.
Step 4.
The AAnF sends Naanf_AKMA_ApplicationKey_Get response to the AF with 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.
Up

6.3  AKMA Application Key request via NEFWord‑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.
(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 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.
Step 2.
If the AF is authorized by the NEF to request KAF, the NEF discovers and selects an AAnF as defined in clause 6.7.
Step 3.
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.
Step 4.
The AAnF generates the KAF as specified in clause 6.2 and sends the response to the NEF with the KAF, the KAF expiration time (KAFexptime) and potentially other parameters.
Step 5.
The NEF forwards the response to the AF.
Up

6.4  AKMA key changeWord‑p. 16

6.4.1  KAKMA re-keyingWord‑p. 16

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

6.4.2  KAF re-keyingWord‑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 description in clause 6.4.3 based on its policy. If there has 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 .
Up

6.4.3  KAF refreshWord‑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 AKMAWord‑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.
(not reproduced yet)
Figure 6.5-1: Initiation of AKMA
Up
Step 1.
The UE may start communication over reference point Ua* with the AF with or without any AKMA-related parameters.
Step 2.
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.
Up

6.6  AAnF AKMA context removalWord‑p. 16

6.6.1  GeneralWord‑p. 17

This procedure is used to remove the AKMA context in the AAnF. NF consumers may initiate this procedure due to local policy.
(not reproduced yet)
Figure 6.6.1-1: AAnF AKMA context removal procedure
Up
Step 1.
NF initiates an AAnF AKMA context removal procedure to delete the AKMA context in AAnF.
Step 2.
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.
Step 3.
AAnF shall delete AKMA Context (e.g. A-KID, KAKMA) from its local database.
Step 4.
AAnF sends a Naanf_AKMA_Context_Remove response to NF.
Up

6.7  AAnF Discovery and SelectionWord‑p. 17

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

Up   Top   ToC