Invoking a full authentication or a fast re-authentication at the beginning of a communication session in EAP-AKA protocol depends on the capabilities of the authentication server and the MS and is inevitable. In addition, the authentication service indeed is occurred periodically and frequently. Thus, minimizing authentication delay can greatly improve interworking performance and provide the support of seamless service in 3G/UMTS-WLAN heterogeneous mobile communication networks. Although fast re-authentication can enhance 46% authentication efficiency than the full authentication by neglecting unnecessary authentication-related transactions between the HLR/HSS and the RADIUS [12, 14], periodical fast re-authentication sessions are still handled by the RADIUS resided in the 3GHN when the MS requires a re-authentication. It is inefficient for stationary and mobile users to communicate with remote authentication server in the 3GHN whenever re-authentication is required. Meanwhile, a huge amount of re-authentication message transactions between the 3G domain and the WLAN might result in high authentication delays and might introduce unnecessary signaling and processing overhead. Such delays directly affect real-time applications and delay-sensitive applications running in 3G/UMTS-WLAN heterogeneous mobile communication networks. In addition, the impact of authentication delays is increased with a number of fast re-authentication session increases.
For improving re-authentication delays in 3G/UMTS-WLAN heterogeneous mobile communication networks, this paper proposed FIL re-authentication protocol that is based on the EAP-AKA fast re-authentication and also extends the concepts of FIL re-authentication in GSM-WLAN heterogeneous mobile communication networks [27–30] to 3G/UMTS-WLAN heterogeneous mobile communication networks. Furthermore, the AVD function in the RADIUS is responsible for the execution of MS full authentication and for delivering authentication-related messages to the LAA in the AP. The LAA take over the RADIUS to enable the MS re-authentication locally and iteratively. FIL re-authentication protocol model is depicted in Figure 3. In the figure, two major processes in the proposed model are localized re-authentication process and iterative process. In the full authentication, the AVD function is designated to distribute AV resources from the remote HLR/HSS to intended APs. When the MS requests a re-authentication access, the LAA can rederive new AVs and key sets according to received AV resources stored in the database of AP. Subsequently, the AP has sufficient AVs for handling re-authentication sessions with the intended MS locally. Such authentication operations between the AP and the MS are called as localized re-authentication process. The aim of localized re-authentication process is to decentralize re-authentication session loads and processing loads in the RADIUS server to APs. In addition, the iterative process is designed to enable the execution of localized re-authentication process iteratively and for completing re-authentications locally without contacting the RADIUS. It also contains iterative localized re-authentication and iterative AVs generation. The localized re-authentication process and iterative process are discussed in detail as follows.
3.1. FIL re-authentication protocol architecture
Figure 2 clearly shows that RADIUS server, AP and MS are participating in the fast re-authentication session. However, as comparing with Figure 4, the difference is that the fast re-authentication is replaced by the FIL re-authentication protocol performed between the AP and the MS. In Figure 4, ① represents the localized re-authentication process. ② and ③ represent iterative localized re-authentication and iterative AVs generation, respectively.
3.1.1. Localized re-authentication process
In order to explain how FIL re-authentication protocol works, the localized re-authentication process must be introduced first. The design objective of localized re-authentication process is to expedite authenticating mobile users by completing re-authentications locally without contacting the RADIUS. Note that the first round of FIL re-authentication must be activated after a successful full authentication session, and some AVs included temporal fast re-authentication identity (Fast_ID), MK, K_auth, and K_encr have been delivering to the AP's database via the AVD function during a full authentication. Fast_ID and MK attributes are used in subsequent first round iterative AVs generation of the iterative process that is introduced in the following iterative process sub-section. K_auth and K_encr keys not only are use to preserve integrity and confidentiality of EAP messages during the full authentication session, but those are responsible for preserving integrity and confidentiality of EAP messages during this round localized re-authentication process, which is also called the initial round of iterative process.
After a successful full authentication, when the MS provides its temporal Fast_ID to request a re-authentication access, the FIL re-authentication protocol is launched to trigger the localized re-authentication process so-called the initial round of the iterative process. The localized re-authentication process included some security-related functions shown in Figure 4 is executed between the AP and the MS. Upon receiving the temporal Fast_ID, the LAA first runs the identity authentication to check whether the identity is legal or not. If positive, then both the LAA and the UE runs the initial round iterative AVs generation for re-deriving new AVs, which are also stored back to its database, respectively. The iterative AVs generation details in the iterative process sub-section. By using the iterative AVs generation, the AP and the MS can acquire available AVs and key sets, which are used to enable the execution of the following security-related functions. Next, other security-related functions can be performed between the AP and the UE as well as the fast re-authentication. As the final 802.11i encryption function has been completed, it represents that this round localized re-authentication process has been finished. When the MS requests a re-authentication access to the same AP again, the FIL re-authentication protocol will be launched again to trigger new round iterative process introduced in detail as follows. According to the above mentioned, the database of the AP not only needs to store pre-loaded AV resources that are from the AVD function during an ongoing full authentication, but it stores new AVs that are re-derived by itself during an ongoing localized re-authentication process.
3.1.2. Iterative process
In order to continue executing the localized re-authentication process between the AP and UEs without contacting the RADIUS, the iterative process is proposed to achieve this objective. In FIL re-authentication protocol illustrated in Figure 4, the iterative process represents two aspects. One is iterative localized re-authentication (②) and other is iterative AVs generation (③). Meanwhile, the iterative AVs generation is one of functions included in the iterative localized re-authentication.
3.1.2.1. Iterative localized re-authentication
The previous section clearly shows one round localized re-authentication, which also represents initial round of iterative process. When the MS responses the Fast_ID(i - 1) to request a re-authentication access again where the index 'i' denotes the i-th iterative process, FIL re-authentication is invoked again for activating new round iterative process, which is so-called first round iterative process. Here, Fast_ID(i - 1) was generated by the AP during the previous iterative process. But in the first round iterative process, Fast_ID(i - 1) was from the RADIUS during the full authentication. Upon receiving the identity, the LAA runs the identity authentication function to check the identity and agrees running iterative localized re-authentication with the MS. As completing the identity authentication of this round iterative localized re-authentication, iterative AVs generation function of this round iterative localized re-authentication is subsequently invoked for deriving new AVs. The iterative AVs generation operation is shown in Figure 5 and details in the following section. The AP and the MS can acquire available AVs and key sets by using such iterative operations. Furthermore, those new derived AVs are used for enabling the execution of the subsequent security-related functions of this round iterative localized re-authentication between the AP and the MS. When the operations of other security-related functions perform as well as the localized re-authentication process and have succeeded. It represents that both this round iterative localized re-authentication and iterative AVs generation have been finished. When the MS requires a re-authentication access again, a new round iterative process is triggered for invoking a new round iterative localized re-authentication included a new round iterative AVs generation again. Accordingly, if any error has been occurred during any round iterative localized re-authentication, the iterative process is terminated immediately. Meanwhile, while the MS requests a re-connection again, the full authentication will be activated, rather than FIL re-authentication protocol. Otherwise, the iterative process is keeping on going.
3.1.2.2. Iterative AVs generation
The iterative AVs generation establishes a secure AVs and key sets generation operation that results in generating fresh AVs and keys to secure the communications between the AP and the MS. Moreover, iterative localized re-authentication is completed efficiently with minimum communications between the MS and the AP. As the MS responses the Fast_ID(i - 1) to requests a re-authentication access again and demonstrates the temporal identity is valid, FIL re-authentication protocol is trigger to invoke the new round iterative process. Then the new round iterative AVs generation shown in Figure 5 is also invoked in the LAA. In Figure 5, the LAA first acquires Fast_ID(i - 1) and MK(i - 1) attributes from the its database and generates new Counter_A(i) and Nonce_A(i) attributes where the index 'i' denotes the number of iterative process. Second, for the user identity privacy in the next round iterative process, the AP also generates new temporal Fast_ID, denoted as Fast_ID(i). Then new mater key denoted as MK(i) is derived as MK(i) = SHA - 1 (Fast_ID(i - 1) || Counter_A(i) || Nonce_A(i) || MK(i - 1)). Other new key sets included K_auth(i) and K_encr(i) are also acquired by using the PRF according to MK(i) key. Finally, new key sets (MK(i), K_auth(i) and K_encr(i)), Fast_ID(i), Counter_A(i), and Nonce_A(i) attributes need to store back to the AP's database for supporting the execution of following security-related functions of this round iterative localized re-authentication and the next round iterative process. When completing above operation, it represents that one round iterative AVs generation operation has been accomplished. Subsequently, other security-related functions can be executed between the AP and the MS in order during this round iterative localized re-authentication. In the final 802.11i encryption function, new re-derived key sets results in generating fresh PTK and GTK by using a four-way handshake and a two-way handshake to support IEEE 802.11i encryption operation. As the 802.11i encryption function has been completed, it represents that this round localized re-authentication has been finished. When the next round iterative process is invoked, the next round iterative AVs generation is also invoked.
3.2. FIL re-authentication protocol procedure
In this section, the sequence procedures of FIL re-authentication protocol are presented in detail. Since FIL re-authentication protocol is proposed to replace the fast re-authentication in EAP-AKA, it must be invoked after a successful full authentication session while the MS requires a re-authentication with the related APs again. The sequences are illustrated in Figure 6 and detail as follows.
3.2.1. STEP ⓪: initial state
Upon completing a full authentication, available AVs included temporal Fast_ID(i - 1), MK(i - 1), K_auth(i - 1), and K_encr(i - 1) have been stored in the AP and in the MS, respectively. It is so-called the initial state of the FIL re-authentication protocol. In the first round FIL re-authentication case, the related AVs are denoted as Fast_ID(0), MK(0), K_auth(0) and K_encr(0), respectively. Here, those AVs are generated by the RADIUS during an ongoing full authentication session.
3.2.2. STEP ①: identity authentication
When the MS sends an EAPOL-start message to request a FIL re-connection access, the AP immediately sends EAP request/identity message to the MS for running the identity authentication. Then the UE must response the Fast_ID(i - 1) to demonstrate the temporal identity is valid. Upon receiving the temporal identity, the AP first runs the identity authentication to check whether the received identity is valid. If the identity check is positive, the AP agrees on using the first round iterative localized re-authentication and also invokes the first round iterative AVs generation function.
3.2.3. STEP ②: iterative AVs generation (AP)
The symbol (AP) represents that the function operation is handled by the AP. In this function, the LAA first generates Counter_A(i) and Nonce_A(i) attributes. Then two attributes with MK(i - 1) and Fast_ID(i - 1) are used as the seeds to generate fresh key sets (MK(i), K_encr(i), K_auth(i)) by the iterative AVs generation operation shown in the Figure 5. Secondly, in order to implement the later HMAC authentication function, two message authentication code attributes (AT_MAC(i) and AT_XRES(i)) must be calculated, respectively. The AT_MAC(i) attribute is calculated as AT_MAC(i) = HMAC-SHA1-128 (K_auth(i - 1) || Nonce_A(i) || EAP message). The AT_XRES(i) attribute is calculated as AT_XRES(i) = HMAC-SHA1-128 (K_auth(i) || Nonce_A(i) || EAP message). Furthermore, for supporting the user identity privacy, the new temporal Fast_ID(i) must be generated randomly and is also used in the identity authentication and iterative AVs generation of the next round iterative localized re-authentication. Meanwhile, the temporal Fast_ID(i) is protected by an AES algorithm with K_auth(i) key and the encrypted attribute is denoted as *AT_Encr_Data(i). In addition, Nonce_A(i) and Counter_A(i) must be encrypted by using an AES algorithm with K_auth(i - 1) key to prevent from masquerading and compromising. Those encrypted attributes are denoted as *AT_Nonce_A(i) and *AT_Counter_A(i), respectively. Once completing the preceding security-related parameters generation, new AVs need to stored back to its database. Then the AP immediately sends the EAP-request/AKA/FIL re-authentication message including AT_MAC(i), AT_IV(i), *AT_Counter_A(i), *AT_Nonce_A(i), and *AT_Encr_Data(i) to the MS.
3.2.4. STEP ②: iterative AVs generation (UE)
Upon receiving the EAP-request message, the MS first decrypts *AT_Counter_A(i) and *AT_Nonce_A(i) with K_auth(i - 1) key to acquire Nonce_A(i) and Counter_A(i) attributes. Then the MS performs the iterative AVs generation operations as well as in the AP to re-derive fresh key sets (MK(i), K_encr(i), K_auth(i)) and message authentication codes (AT_XMAC(i) and AT_RES(i)).
3.2.5. STEP ③-④: HMAC authentication and counter-synchronization (UE)
When completing iterative AVs generation and message authentication code operations, then the MS runs the HMAC authentication function to verify the calculated AT_XMAC(i) with the received AT_MAC(i) to confirm whether the AP is legal. If invalid, the MS responses an EAP-response/AKA/client-error message to the AP for terminating FIL re-authentication exchanges and for asking a new full authentication. Otherwise, the counter-synchronization function has continued performing. In the counter-synchronization function, the MS checks the value of the received Counter_A(i) to make sure that the number of the FIL re-authentication has not exceeded the assigned limit. The detailed counter synchronization procedures in the FIL re-authentication are as well as the fast re-authentication in the EAP-AKA [14]. In addition, in order to prevent the Counter_A(i) attribute from masquerading and compromising, it must be encrypted by an AES algorithm with K_encr(i) key and the encrypted attribute is denoted as *AT_Encr_Data(i). If both HMAC authentication and counter-synchronization checks are valid, the UE replies the EAP-response message included *AT_Encr_Data(i), AT_IV(i), and AT_RES(i) to the AP.
3.2.6. STEP ③-④: HMAC authentication and counter-synchronization (AP)
As receiving the EAP-response message from the MS, the AP first decrypts the *AT_Encr_Data(i) with K_encr(i) key to acquire the Counter_A(i) attribute. Then it, respectively, runs the HMAC authentication function and counter-synchronization function to verify the received AT_RES(i) and Counter_A(i) with the AT_XRES(i) and Counter_A(i) that are stored in its database. If both checks are positive, the AP sends an EAP success message to the MS. Otherwise, the AP immediately announces an authentication failure message to the RADIUS serve for requesting a new full authentication. Meanwhile, it also sends a client-error notification to the MS for terminating the FIL re-authentication exchanges and for initiating a new full authentication.
3.2.7. STEP ⑤: 802.11i encryption
Upon receiving the EAP success message from the AP, the MS can decrypt the received *AT_Encr_Data(i) with K_auth(i) key to acquire new temporal Fast_ID(i). Then Fast_ID(i) and new derived AVs are stored back to the its database. Next, the AP and the MS get into the ciphering mode. When the final encryption function is completed, it represents one round iterative localized re-authentication has been finished.
3.2.8. STEP ⑥: iterative localized re-authentication
The steps from ① to ⑤ are represented one round iterative localized re-authentication. While the MS requests a FIL re-connection again, the FIL re-authentication protocol will be activated again for triggering the next round iterative localized re-authentication.
The preceding procedures clearly show that the FIL re-authentication enables the execution of the re-authentication session between the AP and the MS locally and iteratively. It expedites authenticating mobile users by using the localized re-authentication process and the iterative process. The localized re-authentication process is designated to the support of the local re-authentication, which results in distributing re-authentication session loads and processing loads. The iterative process is designated to enable the execution of localized re-authentication process iterative, which contributes to complete re-authentications iteratively without contact the RADIUS. Based on those advantages, the re-authentication efficiency can be obviously improved as comparing the FIL re-authentication with the standard fast re-authentication and the standard full authentication, respectively. For validating the re-authentication efficiency in the FIL re-authentication, the numerical analysis and performance evaluations about the authentication session time, bandwidth cost, and authentication delays are given in the following section.