Privacy Preserving Multi-Party Key Exchange Protocol for Wireless Mesh Networks

Presently, lightweight devices such as mobile phones, notepads, and laptops are widely used to access the Internet throughout the world; however, a problem of privacy preservation and authentication delay occurs during handover operation when these devices change their position from a home mesh access point (HMAP) to a foreign mesh access point (FMAP). Authentication during handover is mostly performed through ticket-based techniques, which permit the user to authenticate itself to the foreign mesh access point; therefore, a secure communication method should be formed between the mesh entities to exchange the tickets. In two existing protocols, this ticket was not secured at all and exchanged in a plaintext format. We propose a protocol for handover authentication with privacy preservation of the transfer ticket via the Diffie–Hellman method. Through experimental results, our proposed protocol achieves privacy preservation with minimum authentication delay during handover operation.


Introduction
As compared to conventional networks such as LAN and MANET, wireless mesh networks (WMN) have become the most promising network presently due to their advanced features. Due to their capacity to be self-organized and self-healing, WMN are the most favorable network [1]. Advanced features of WMN allow continuous network access to the end-users. Three mesh entities, namely gateway routers (GW), mesh routers (MR), and mesh clients (MC) form the architecture of WMN as shown in Figure 1. Mesh routers are also called mesh access points (MAP), which forward the mesh client's request to the gateway router (GW) for Internet access [2][3][4][5]. Due to the non-static nature, mesh clients can change their position from a home mesh access point to a foreign mesh access point. As a result, a secure handover authentication process should be carried out among mesh entities. Successful authentication during handover permits the client to join and access the Internet under a foreign MAP [6][7][8]. In the past, numerous protocols were proposed for handover authentication that are based on tickets [9,10]; however, they came up with certain issues and limitations, which are discussed in Section 2. The proposed multi-party key exchange protocol presented in this paper offers the privacy of the transfer ticket. Our proposed multi-party key exchange protocol is an extension of the Diffie-Hellman protocol [11]. The privacy of a transfer ticket is preserved throughout the login authentication process (LAP) and handover authentication process (HAP) among the mesh entities. The protocol does not require any MAC key generation and master key generated from the AS, as it was required in the existing protocols. Mostly in existing protocols, the transfer ticket is issued by the authentication server (AS), but in our proposed work, it is issued by the mesh access point (MAP) within one hop; therefore, the presence of the AS is not considered in our proposed protocol throughout the handover process.

Discussion and Contribution
In this paper, we present an efficient authentication protocol during handover operation along with privacy preservation of tickets shared over the insecure channel. Our proposed protocol is analyzed against the Li et al. protocol because in this protocol authentication is carried out via tickets and computations are performed mostly by the TA and MAP [12]; secondly, the amount of communication cost is minimized (i.e., three-way handshake performed) during the handover authentication process; lastly, involvement of the third party during handover operation is omitted. All these properties make the protocol to be lightweight for mobile users in WMN; however, we analyzed the existing protocol in detail in Section 3 and found certain drawbacks. In this paper, our main contributions can be described as follows: • We propose a multi-party key exchange protocol to generate a common secret key (CSK), which is shared among the MAP within a group. This common key is used for encrypting and decrypting the transfer tickets shared during the handover operation and offers privacy to the transfer tickets. • We consider only symmetric key-based operations during the handover operation, which results in minimal computational cost. • We achieve a complete handover authentication process with minimal communication cost, i.e., one-way handshake, which is efficient compared to two-way and three-way handshake of existing protocols.
The remainder of the paper is as follows: Section 2 describes the related works. In Section 3, the analysis of existing work and its drawbacks are discussed in detail. The proposed multi-party key exchange protocol and Diffie-Hellman protocol are discussed in Section 4. Proposed protocols during LAP and HAP are discussed in Section 5. Section 6 describes the experimental results and Section 7 concludes the paper.

Related Work
In this section, we discuss some of the existing protocols related to our proposed protocol. The existing protocols were mainly concerned with the handover authentication process carried out through a ticket-based approach.
Kassab et al. [13] proposed a secure protocol for proactive authentication for the IEEE 802.11F standard network during handover. During the handover process, the client sends a request message to the foreign access point to join the network. On acceptance, the foreign access point sends the message to the authentication server. The authentication server verifies the message. On successful verification, the authentication server issues an acceptance message to the foreign access point, which allows the client to join the network under the foreign access point; however, certain limitations were found in the protocol during the handover process. Limitations such as authentication delay due to verification of the request message by AS were required in a multi-hop fashion. Li et al. [14] proposed a handover protocol where re-authentication is strongly considered for the IEEE 802.11i standard network. Firstly, for mutual authentication, the complete process of authentication was formed among the mobile station and AS. Secondly, the AS issued a list of handover tickets of the neighboring access point to the mobile station. These lists of handover tickets allowed the mobile station to re-authenticate itself to the neighboring AP's during the handover operation; however, storing this list of tickets consumed massive storage space at mobile stations, which are usually resource constrained. Li et al. [15] proposed a protocol during handover based on broadcast authentication. The protocol allowed the client to be authenticated by the authentication server. During the handover operation, the authentication server issued and broadcast the tickets to each mesh access point, which allowed the clients to authenticate during the handover process; however, a massive authentication delay occurs due to multi-hop authentication required from the authentication server. He et al. [16] proposed a handover authentication protocol with a two-way handshake to complete the handover authentication process. The protocol was based on pre-shared pseudo identities (PIDi) generated by the AS to the mesh clients. However, a pseudo-identity involves the bilinear pairing operation, which results in high computational cost. Moreover, this approach pre-shared pseudo identities (PIDi) to the clients, putting extra load on clients' constrained resources. Xu et al. [17] proposed a protocol for wireless mesh network during handover authentication. The protocol allowed the authentication server (AS) to pre-distribute the tickets to the clients. These tickets were used during the re-authentication process. The client forwards the ticket to the intended mesh router based on its identity. Later, the mesh router verified the ticket sent by the client and on successful verification the client is re-authenticated; however, storing these pre-distributed tickets consumed massive storage space on the client side, which is resource constrained. Rathee et al. [18] proposed a secure protocol for WMN during handover operation. The protocol generates two keys, namely, the master key and group key shared between the authentication server (AS), mesh router, and mesh clients to authenticate each other. Then, the AS issued the ticket to the client and mesh router to authenticate each other during the handover process; however, the protocol comes up with certain limitations. First, during the handoff phase, target FMAP verifies the MC by comparing the tickets in step 2 but the protocol lacks the ability to verify the target FMAP by the MC side. Second, without verifying the target FMAP, the temporary session key is generated by both sides in step 3. Overall the protocol performs a 3-way handshake without completing the authentication process from the MC side. Third, a massive message was exchanged which leads to high communication costs during handover operation. Second, messages were exchanged in a plaintext format over the insecure channel, which violates the integrity of the message easily. Fourth, AS verifies the ticket and the client in a multi-hop fashion that leads to authentication delay. Wang et al. [19] proposed a batch handover authentication protocol based on the pre-distribution of handover keys to minimizing the authentication delay. The protocol preserved the privacy of the client where the identity of the foreign mesh router (MRj) and timestamp of the client (TMCi) was unknown to the attacker; however, storing these pre-distributed tickets consumed massive storage space at the client side, which are resource-constrained. Rekik et al. [20] proposed an optimized, secure authentication protocol based on extensible authentication protocol (EAP) for handover authentication; however, the protocol requires multi-hop authentication from the AS, which results in an authentication delay.
To improve the handover authentication process, privacy was considered in Tsai et al. [21] protocol, Fu et al. [22] protocol, and Zhu et al. [23] protocol. These protocols preserved the privacy of the clients with a three-way handshake to complete the handover authentication process; however, to complete the three-way handshake protocol, it suffered from high computational cost. Yang et al. [24] proposed an efficient handover authentication protocol with a two-way handshake to complete the handover authentication process. The protocol was based on the group signature performed by the group manager (mesh access point). The roaming client is required to forward the group signature to the foreign mesh access point (FMAP) to validate its authentication; however, the protocol was based on bilinear pairing, which results in high computational cost. Table 1 compares the existing protocols with different parameters during handover operation.

Analysis of Existing Protocol
In this section, we investigate in detail the existing protocol proposed by Li et al. [12] and discuss the security threat present in the protocol. The protocol considered a trust model, which employed a ticket agent (TA). The TA issues the MAP ticket and user ticket to authenticate each other during the login process and handover process. In the mesh network, TA acts as a centralized authority. The following shows the various faiths built among the mesh entities.

Types of Ticket Issued to MAP and User for Mutual Authentication
• User tickets (T C ): Faith between user and MAP is built through user ticket. The legality of user is proved to MAP through T C . T C contains the following elements where, I C = User identity. where, Transfer tickets (Θ C ): Builds faith between user and FMAP (e.g., MAP 2 ). After, the mutual trust/faith is built between user and home MAP, Θ C is generated by a home MAP (e.g., MAP 1 ). User proved its legality to MAP 2 through Θ C . Θ C contains the following elements where,

The Login Authentication Protocol (LAP)
Assume that the trust agent (TA) issued a user ticket (T C ) to user C and MAP ticket (T M ) to MAP 1 . Now the user and MAP 1 exchanged the tickets for mutual authentication.
Steps for exchanging the tickets for mutual authentication are as follows: Step 1: For Internet access, the identity (I C ) of C is broadcast as a request message to MAP 1 .
Step 2: On the acceptance of the request message, MAP 1 send its ticket (T M1 ) to user C. After receiving T M1 by C, T M1 is verified through signature (Sig A ) and through expiry time τ exp exists in T M1 .
Step 3: If verification of T M1 is successful, then the public key P M1 of MAP 1 is extracted from T M1 by C. Then User C encrypts the ticket T C , nonces N C1 , and N C2 by using the public key P M1 and sends to MAP 1 . On acceptance of the message, MAP 1 decrypts the message with its private key and verifies the ticket T C . Verification is achieved through signature (Sig A ) and expiry time τ exp present in T C . MAP 1 ignores the ticket T C , if the verification fails.
Step 4: After verification is successful, public key P C of C is extracted from T C by MAP 1 . Later, MAP 1 encrypts two nonce N M1 and N M2 using P C and forwards the encrypted message to user. Meanwhile, MAP 1 compute its shared MAC key K MAC = N C1 N M1 and pairwise master key PMK 0 = N C1 N M1 . On the acceptance of an encrypted message, this message is decrypted by user C with its own private key to gain N M1 and N M2 . Later, user C computes its shared MAC key K MAC = N C1 N M1 and pairwise master key PMK 0 = N C1 N M1 . The nonces N C1 , N C2 , N M1 , and N M2 are secured through asymmetric cryptography.
Step 5: After calculating a shared MAC key and pairwise master key, user C sends the nonce N M2 to MAP 1 . On the acceptance of a nonce N M2 , MAP 1 verifies a nonce N M2 with a nonce issued by MAP 1 itself earlier in Equation (7). MAP 1 ignores the nonce, if N M2 does not match with the earlier nonce.
Step 6: After successful verification till step 5, MAP 1 generates a transfer ticket Θ C . Then, MAP 1 sends to user C the nonce N C2 and transfer ticket Θ C . User C after receiving the N C2 and Θ C , verifies the nonce N C2 by checking with the nonce issued earlier by C itself in Equation (6). User C ignores the message if the N C2 does not match. Finally, step 1 to step 6 concludes the login authentication protocol. Later, Θ C allows the user C to initiate the handover authentication process from home MAP 1 to foreign MAP.

The Handover Authentication Protocol (HAP)
To initiate an efficient handover operation, MAP 1 pre-distributes the shared keys to all its neighboring MAP. These keys are shared between the user and MAP 1 during the login authentication process. It is assumed that all the MAP contain its neighboring MAP public key certificates. On successful completion of the login authentication process, MAP 1 pre-distributes the encrypted shared keys, which includes I C , I M1 , key K MAC , and pairwise master key PMK 0 to its neighboring MAP x . The encryption is performed via public key P x of neighboring MAP x . After receiving the encrypted shared keys, MAP x uses its private key to decrypt it. Finally, the new authentication process is carried out with user C through these shared keys. During the handover process from MAP 1 to MAP x , user C performs the following steps: Step 1: User C sends Θ C , new nonce N C and MAC V K MAC (N C ) to foreign MAP x shown in Equation (10). On the acceptance of the message, MAP x verifies the accuracy of V K MAC (N C ) by using previously received K MAC from the home MAP 1 . If the verification is successful, MAP 1 checks the elements in Θ C to verify the legality of Θ C . Likewise, only user C with K MAC knowledge could generate a valid pair of (N C , V K MAC (N C )).
Step 2: If the validation of Θ C is successful, MAP x send a nonce N M and V K MAC (N C , N M ) to user C shown in Equation (11).
Step 3: On the acceptance of a message, user C sends N M and V K MAC (N M ) to MAP x shown in Equation (12). On the acceptance of N M and V K MAC (N M ), MAP x verifies the V K MAC (N M ). On successful verification, the user's identity is approved as legal and concludes the HAP.

Discussion:
We analyze the Li et al. [12] protocol in detail and found certain limitations and security threats in the protocol, which are highlighted below: Two different authentication protocols are considered in the existing protocol: 1. To initiate mutual authentication, login authentication protocol (LAP) is considered. 2. To initiate the handover process, handover authentication protocol (HAP) is considered as shown in Figure 2. Both LAP and HAP rely on certain keys such as pairwise master key and group transient key for authentication between users and MAP. Within the network, users are offered constraint power; therefore, the exchange of these keys should be minimized. Both LAP and HAP protocols suffered from security threats. Firstly, throughout LAP the information T M1 , N M2 , N C2 and Θ C are shared in a plaintext format as MAP 1 → C: T M1 shown in Equation (5), C → MAP 1 : N M2 as shown in Equation (8) and MAP 1 → C: N C2 , Θ C as shown in Equation (9). As a result, an intruder could easily acquire this information and misuse it.
Secondly, Θ C are shared in the plaintext format as C→ MAP x : Θ C , N C2 , V K MAC (N C ) during HAP as shown in Equation (10). As a result, an intruder could easily tamper the elements of Θ C such as I C , I M , I A , τ exp and violates the integrity of transfer ticket (Θ C ); therefore, an intruder could easily eavesdrop on these exchanged messages at the time of the authentication process. Further, the intruder could replay these messages and try to obtain successful authentication as a user to access the network.

Proposed Multi-Party Key Exchange Protocol
The proposed multi-party key exchange protocol is an extension of the Diffie-Hellman approach, which is performed within a group by the ticket agent (TA) and the MAP, where the ticket agent (TA) is known as a group controller (GC). The ticket agent (TA) generates the common secret key (CSK) and shares it in an encrypted form among neighboring MAP. Further, the CSK is employed for encryption and decryption of the transfer ticket during LAP and HAP between MAP and users. The detailed procedure for multi-party key exchange protocol is presented in Algorithm 1. In line 13, the common secret key generated by the TA i is computed as CSK i = (∏ MAP i ) mod p. TA generates the common secret key (CSK) by adding all the public keys received from each MAP's using product of sum operation (∏). Later, CSK i is used for encrypting and decrypting the transfer ticket throughout the LAP and HAP.

Reason to Considered Diffie-Hellman Key Exchange Protocol
We considered an extension of the Diffie-Hellman protocol [11] in our proposed protocol, which allows multiple users to securely exchange the keys over an insecure channel. Further, the keys are used for encrypting and decrypting the message. The difficulty and complexity of discrete logarithms to compute directly reflect the advantage of the Diffie-Hellman algorithm. The difficulty and complexity to crack the Diffie-Hellman protocol can be discussed as follows

•
Discrete logarithms can be defined as a primitive root that belongs to the prime number p whose powers modulo p produce 1 to p1 integers; therefore, if a consider as prime number p, then a 1 mod p, a 2 mod p, . . . , a p1 mod p are distinct and contain integers from 1 to p1 in some permutation. • Discrete Logarithm Problem: It is considered as a multiplicative cyclic group. Where G = (g) is the generator of the cyclic group with element h of G; therefore, search unique integer x, where g x = h, and x is the discrete logarithm of h with base g. • Computational Diffie-Hellman Problem (CDH): It is defined as a cyclic group (G) with generator g and g x1 , g x2 ∈ G; therefore, known values are y1 = g x1 and y2 = g x2 whereas x1 and x2 are unknown, hence search y = g x1 g x2 . CDH assumption is considered in most of the security of the cryptosystem. CDH assumption is associated with discrete logarithm assumption, where computing the discrete logarithm for value base a generator g is hard.

Proposed Protocol during Login Authentication Protocol (LAP) and Handover Authentication Protocol (HAP)
To overcome the limitations present in [12], we proposed a multi-party key exchanged protocol shown in Section 4. We consider the existing ticket types in our proposed protocol with a change in transfer ticket Θ C elements. Changed elements in Θ C are given as where, I C = Identity of the user owning Θ C . I M = Identity of the MAP issuing Θ C . I A = TA Identity. τ exp = Θ C 's expiry time. N i = nonce to prevent replay attack.

Proposed Protocol for Login Authentication Protocol (LAP)
Initially, the user ticket and the MAP ticket were issued by the TA. Both MAP 1 and user exchanged their tickets for mutual authentication. Order of tickets exchanged between MAP 1 and User are as follows.
Step 1: Identity and public key of user C is broadcast as a request message to MAP 1 to allow Internet access in Equation (14).
Step 2: After the message received, MAP 1 extracts the users public key P C . MAP 1 uses the public key to encrypt the ticket T M1 and a nonce N M1 and sends to user C in Equation (15). On the acceptance of encrypted T M1 and a nonce N M1 , the user decrypts it by using its private key. After decryption, the user verifies a T M1 through Sig A and τ exp that resides within T M1 .
Step 3: After successful verification of T M1 , the public key P M1 of MAP 1 is extracted by the user from T M1 . The user encrypts T C and nonce N M1 using P M1 and send towards MAP 1 in Equation (16). On the arrival of E P M1 (T C , N M1 ), MAP 1 decrypts the message and verifies the parameters of T C . Further, the nonce N M1 is verified by MAP 1 to check the similarity of the nonce issued by the MAP 1 in Equation (15). If the verification is successful, then the authentication process is successful between the user and the MAP 1 .
Step 4: After successful authentication, when user C wants to migrate, it informs to the MAP 1 to which FMAP the user wants to join. Thereafter, the MAP 1 generates and sends the encrypted transfer ticket as E CSK i (Θ C ) to user C and FMAP in Equation (17). Later, user C forwards the encrypted transfer ticket E CSK i (Θ C ) to FMAP to authenticate itself.

Proposed Protocol for Handover Authentication Protocol (HAP)
The common secret key (CSK) described in Section 4 is shared among the neighboring MAP's beforehand the handover process took place to offer privacy. After the completion of mutual trust between the client and HMAP (i.e., MAP 1 ), transfer ticket (Θ C ) is issued by MAP 1 to the client and FMAP during the login process as described in Equation (17) of Section 5.1. Later, when the client wants to join the foreign mesh access point (FMAP) during the handover process, the client sends the transfer ticket in an encrypted form as E CSK i (Θ C ) to the foreign mesh access point to prove its authenticity as Step 1. User C sends E CSK i (Θ C ) to foreign mesh access point (FMAP) as shown in Equation (18). After receiving E CSK i (Θ C ), foreign mesh access point (FMAP) tries to decrypt it. If (successful in decrypting, i.e., D CSK i (Θ C )) then FMAP verifies the contents of the transfer ticket for successful authentication, i.e., Θ C sent by HMAP previously during the login process is equal to Θ C sent by the user during the handover process. If both the contents of Θ C are similar then the user is authenticated successfully by the foreign mesh access point.
Else If (unsuccessful in decrypting) then a user fails to authenticate itself to FMAP, as FMAP could not verify the transfer ticket (Θ C ) without decrypting it. Finally, FMAP concludes that the transfer ticket (Θ C ) was not issued from the corresponding HMAP with whom FMAP had shared the common secret key. Figure 3 shows the handover process of the proposed protocol. Figure 4 shows the proposed login authentication protocol (LAP) and handover authentication protocol (HAP).

Experimental Results
Implementation and experimental results of our proposed protocol is described in this section. Table 2 shows the experimental model setup, where Network Simulator 3 (NS3) is considered for simulating the proposed protocol as existing protocols have considered the same simulation tool. Other simulation parameters as mentioned in Table 2 is setup based on the existing protocols setup. Table 3 shows the simulation results gained during the login process. Table 4 shows the simulation results gained during the handover process. In both Tables 3 and 4, d represents the average delay transmission within a single hop. In this section we analyze the security of our proposed protocol with respect to the following features: Mutual Authentication: During login operation in Section 5.1, mutual authentication allowed the user and MAP 1 to verify each others identity. The verification is performed with their respective ticket's exchanged. Sig A ensures the authentication of the tickets. Later, MAP 1 encrypts the message through E P C as E P C (T M1 , N M1 ) shown in Equation (15) and the user encrypts the message through E P M1 as E P M1 (T C , N M1 ) shown in Equation (16). In Section 5.1, encryption of the messages shown in Equations (15) and (16)through public key ensures that only the user C and MAP 1 can decrypt the message.

Privacy preservation:
In the Li et al. [12] protocol during LAP and HAP, the information such as T M1 , N M2 , N C2 and Θ C are shared in a plaintext format as shown in Equations (5), (8)- (10). As a result, an intruder could easily tamper with the information exchanged during LAP and HAP. Our proposed protocol offers privacy to the exchanged information and prevents from tampering, such as E P C (T M1 , N M1 ) as shown in Equation (15) and E P M1 (T C , N M1 ) as shown in Equation (16) during LAP. Privacy of the transfer ticket (Θ C ) is also preserved such as E CSK i (Θ C ) during LAP in Equation (17) and during HAP in Equation (18); therefore, both mutual authentication and privacy preservation prevents intruders to tamper with the integrity of the exchanged messages and also prevents a replay attack. As a result, the transmitted information could neither be captured by intruders throughout the authentication process, nor could any information be replayed to access the network as a user.

Result Analysis of Proposed Protocol
We considered four performance metrics to compute the overall performance of our proposed protocol. Comparison of proposed protocol with existing protocols is performed in terms of computation and communication cost, login delay, and handover delay.
Computational cost is computed as the time required in processing the various security operations given in column 1, row 2, 3, 4, 5, and 6 of Table 3 during login operation and column 1, row 2, 3, 4, 5, and 6 of Table 4 during the handover operation [25][26][27]. Total computation cost comparison during login operation is given in row 7 of  Figure 5 shows the total computational cost required during the login authentication process. Figure 6 shows the total computational cost required during the handover authentication process.
Communication cost is the total message exchanged between mesh entities during login operation and handover operation. Figure 7 shows the total communication cost required during the login authentication process. Total communication cost is the number of messages exchanged during the login operation given in column 1, row 6 of Table 3 (i.e., 4 vs.6 vs. 9 vs. 5 vs. 7). Figure 8 shows the total communication cost required during the handover authentication process. Total communication cost is the number of messages exchanged during handover operation given in column 1, row 6 of      Login delay and handover delay are the time utilized during sending an authentication request and receiving the acceptance confirmation among mesh entities. The time utilized is the addition of computation cost and communication cost shown in the bottom row of Tables 3 and 4. Symbol d in the bottom row of Tables 3 and 4 denotes average delay transmission within a single hop. Figure 9 shows the login delay required during the login authentication process. Login delay is the time utilized during sending an authentication request and receiving the acceptance confirmation among mesh entities during the login process. The simulation result is shown in the bottom row of Table 3. Figure 10 shows the handover delay required during the handover authentication process. Handover delay is the time utilized during sending an authentication request and receiving the acceptance confirmation among mesh entities during the handover process. The simulation result is shown in the bottom row of Table 4.    Figure 11 show the results of minimum login authentication delay with the network size of 100 to 600 mobile clients.  170  160  158  175  200  161  174  168  166  179  300  174  188  182  179  191  400  183  191  188  185  198  500  210  236  230  225  241  600  251  267  260 254 270 Figure 11. Minimum login authentication delay. Table 6 and Figure 12 show the results of average login authentication delay with the network size of 100 to 600 mobile clients.  190  209  205  198  213  200  205  234  226  215  238  300  231  251  242  239  261  400  264  276  270  266  282  500  284  297  293  288  301  600  311  326  321 316 337 Figure 12. Average login authentication delay. Table 7 and Figure 13 show the results of maximum login authentication delay with the network size of 100 to 600 mobile clients.  229  223  216  235  200  225  245  238  231  254  300  244  261  254  249  273  400  279  293  289  282  298  500  309  326  319  313  338  600  345  361  357 349 372 Figure 13. Maximum login authentication delay. Table 8 and Figure 14 show the results of minimum handover authentication delay with the network size of 100 to 600 mobile clients.   Table 9 and Figure 15 show the results of average handover authentication delay with the network size of 100 to 600 mobile clients.  83  87  92  96  200  106  115  122  127  136  300  113  119  125  131  139  400  121  128  135  142  153  500  130  138  146  154  162  600  145  151  159 168 174 Figure 15. Average handover authentication delay. Table 10 and Figure 16 show the results of maximum handover authentication delay with the network size of 100 to 600 mobile clients.

Conclusions
Multi-party key exchange protocol preserves the privacy of the exchanged information shared during the login authentication process (LAP) and handover authentication process (HAP) to offer secure communication. The experimental results show that the proposed protocol achieves minimum authentication delay compared to existing protocols in terms of computation cost and communication cost. Through security analysis, it also proves that the proposed protocol offers a higher security level during the login authentication process (LAP) and handover authentication process (HAP) where no intruders can tamper with the exchanged information. In the future, the proposed protocol can be further extended to gain more efficiency and security during the login authentication process (LAP) and handover authentication process (HAP) for wireless mesh networks (WMN). Funding: This paper is partially supported by the Western Norway University of Applied Sciences, Bergen, Norway.

Institutional Review Board Statement: Not applicable.
Informed Consent Statement: Not applicable.

Data Availability Statement:
The data presented in this study are available on request from the corresponding author.

Conflicts of Interest:
The authors declare no conflict of interest.