## 4 Integration of AKMA and the TLS 1.3 PSK Option for the AKMA Authentication Phase
### TLS 1.3 PSK Option as the \(\text{Ua}^{*}\) Protocol  
As a \(\text{Ua}^{*}\) protocol, the TLS 1.3 PSK option is predicated on the assumption that \(K_{AKMA}\) has been derived through primary authentication as elucidated in Section 2. As illustrated in Figure 6, when the UE, functioning as the TLS client, requests access to the 5G cAPP from the AF, which serves as the TLS server, the AF, with the support of the AAnF, obtains the \(K_{AF}\) derived from \(K_{AKMA}\). Subsequently, the UE and AF utilize this \(K_{AF}\) as the pre-shared secret key for the TLS 1.3 PSK option. In this way, the option is employed as a \(\text{Ua}^{*}\) protocol to ensure secure communication between the two parties. Figure 6 outlines the AKMA authentication phase with the TLS 1.3 PSK option, which consists of five messages: the Application Session Establishment Request, Naanf_AKMA_ApplicationKey_Get_Request, Naaf_AKMA_ApplicationKey_Get_Response, Application Session Establishment Response, and Application Session Communication messages. The UE begins the AKMA authentication phase by sending the Application Session Establishment Request message to the AF while initializing the TLS 1.3 PSK option. This process is then continued and finalized with the Application Session Establishment Response and Application Session Communication messages, thereby establishing a TLS secure channel between the UE and the AF. Meanwhile, the AF contacts the AAnF to get the UE's \(K_{AF}\) through the Naanf_AKMA_ApplicationKey_Get_Request and Naaf_AKMA_Applicationkey_Get_Response messages. The detailed process of key derivation during the communication is also included in Figure 6[12]. Figure 6: AKMA TLS 1.3 integrated protocol. 1. **Application Session Establishment Request** It is assumed that the UE stores the \(K_{AKMA}\), SUPI, and A-KID obtained from the AKMA initial phase. To start the AKMA authentication phase, the UE sends the AF the Application Session Establishment Request message, including the ClientHello sub-message whose values vary according to the TLS 1.3 PSK option modes as follows: * **Common part** At first, the UE should prepare for the ClientHello sub-message. For this, regardless of the mode, it should randomly generate \(crand\), compute \(K_{AF}\) as the pre-shared key \(PSK\), and include the A-KID in the 'pre_shared_key' value. Once the ClientHello sub-message is prepared, the UE derives the early secret \(ES\) from the \(K_{AF}\) and subsequently the binder key \(K_{bind}\) from the \(ES\). Finally, the \(binder\) is calculated using \(HMAC(K_{bind},H(ClientHello))\). * **PSK-only (1a)** In case of the PSK-only mode, psk_ke is set as the 'psk_key_exchange_modes' value. * **PSK-(EC)DHE (1b)** For the PSK-(EC)DHE option, the 'psk_key_exchange _modes' value is set to psk_dhe_ke. More importantly, to support the (EC)DHE key exchange, the UE should randomly generate its (EC)DHE private key \(x\) and compute the corresponding public key \(x\cdot G\) (in case of the Diffie-Hellman key exchange, \(g^{x}\) is used). Here, ECDHE, \(x\cdot G\), is used for ease of notation. The computed public key \(x\cdot G\) is included in the 'key_share' value. * **0-RTT (1c)** In this mode, similar to the PSK-(EC)DHE one, the UE adopts psk_dhe_ke and adds the (EC)DHE public key \(x\cdot G\) to 'key_share' after generating the ephemeral public key pair \(x\) and \(x\cdot G\). Moreover, the 'early_data' value should be added to indicate that the 0-RTT mode is applied and thus application data is accompanied with the ClientHello sub-message. Specifically, the UE calculates the client early traffic secret \(tk_{cts}\) = Derive-Secret(\(ES\), \"c e traffic\", ClientHello) and encrypts the early application data Application Data1 with the \(tk_{cts}\) into (Application Data1) = AEAD\({}_{ENC}\)(\(tk_{cts}\), AD1, Application Data1), where the associate data AD1 = \(crand||x\cdot G\).