A New Ticket-Based Authentication Mechanism for Fast Handover in Mesh Network

Due to the ever-growing popularity mobile devices of various kinds have received worldwide, the demands on large-scale wireless network infrastructure development and enhancement have been rapidly swelling in recent years. A mobile device holder can get online at a wireless network access point, which covers a limited area. When the client leaves the access point, there will be a temporary disconnection until he/she enters the coverage of another access point. Even when the coverages of two neighboring access points overlap, there is still work to do to make the wireless connection smoothly continue. The action of one wireless network access point passing a client to another access point is referred to as the handover. During handover, for security concerns, the client and the new access point should perform mutual authentication before any Internet access service is practically gained/provided. If the handover protocol is inefficient, in some cases discontinued Internet service will happen. In 2013, Li et al. proposed a fast handover authentication mechanism for wireless mesh network (WMN) based on tickets. Unfortunately, Li et al.’s work came with some weaknesses. For one thing, some sensitive information such as the time and date of expiration is sent in plaintext, which increases security risks. For another, Li et al.’s protocol includes the use of high-quality tamper-proof devices (TPDs), and this unreasonably high equipment requirement limits its applicability. In this paper, we shall propose a new efficient handover authentication mechanism. The new mechanism offers a higher level of security on a more scalable ground with the client’s privacy better preserved. The results of our performance analysis suggest that our new mechanism is superior to some similar mechanisms in terms of authentication delay.


Introduction
With mobile devices coming to play a bigger and bigger part in our everyday lives, the need for wireless network systems to remain state of the art has become an indispensable urge if the service providers are to stay competitive. The wireless mesh network (WMN) is one of the best-mechanism we have developed to solve the problems that trouble Li et al.'s mechanism. The main contributions of this paper are as follows.
1. Distinct from the existing handover authentication schemes, the proposed new scheme saves the trouble of digital signature computations on the client side, which significantly reduces the computation cost and handover latency, making the scheme especially suitable for applications where the clients have mobile devices with limited computation power.
2. Unlike most existing handover authentication schemes, the proposed new scheme is applicable when the MAPs are not equipped with high-quality TPDs. Besides, our new scheme can keep another MAP from using the broadcast ticket to pretend to be the current MAP, and therefore there is absolutely no room for the domino effect to happen. In other words, our new scheme is not only more scalable but more secure.
3. In the proposed new scheme, privacy is well preserved, and the authentication imposes negligible overhead.
In this paper, we review Li et al.'s scheme and propose an improvement to refine the approach and make it become applicable. The rest of this paper is organized as follows. Section 2 reviews various ticket-based handover protocols and briefly introduces the basic underlying concepts. Section 3 gives some preliminaries that are to be used throughout this paper. Then, in Section 4, we review and analyze the Li et al.'s scheme. After that, we present an improved scheme in Section 5, followed by a security analysis and a performance analysis of the proposed scheme in Section 6 and Section 7, respectively. Finally, the conclusion will be in Section 8.

Related Work
Instead of accelerating the full authentication mechanism while repeating the authentication procedure every time, some protocols based on the Kerberos-style ticket [15] have been proposed. The main idea behind these methods is to reduce the authentication latency during the handover process by using a symmetric encrypted ticket. Only certified MAPs own the legal symmetric key and can generate a legal ticket for a verified client. For this reason, any client can submit a legal ticket to prove he/she has passed the authentication procedure with another certified MAP. This way, a legal MAP can simply handover authenticate a verified client. That means a client can wander all over the place receiving non-stop Internet service as long as the ticket has not expired yet. Based on the different mutual authentication mechanisms between client and MAP, we can mainly divide ticket-based authentication schemes into three types: single authentication, group key authentication, and broadcast authentication.

Single Authentication
In ticket-based handover by single authentication [13,18,19], it is assumed that each MAP has the pre-stored symmetric key shared among neighboring MAPs. Before a client steps off the coverage of some specific MAP (e.g. MAP 1 ), the client submits a handover single to MAP 1 to inform it as to which MAP (e.g. MAP 2 ) he/she will move to. Upon receiving the signal, MAP 1 uses Key MAP1-MAP2 to generate a ticket and send this ticket to MAP 2 . When the client arrives at MAP 2 , MAP 2 can verify the client simply by using the ticket generated by MAP 1 . However, it will get very confusing when the MAPs within the network are situated in a complicated way [23], for in that case it might not be very clear which MAP is the so-called MAP 2 that the client is moving on to.

Group Key Authentication
In ticket-based handover by group key authentication [6-10, 15, 18, 21], the authentication, authorization, and accounting (AAA) server sets up a multi-MAP group, and pre-distributes a private Multi-MAP Group Key (MGK) to each MAP in the group. Thus, a client does not need to inform MAP 1 which MAP he/she will move to. MAP 1 can use the general MGK to encrypt a ticket and then send it to the client. When the client arrives at MAP 2 , he/she can readily submit the ticket to MAP 2 and get the service. This design based on a single group key, however, is neither secure nor scalable in large-scale mesh networks. To ensure the security of the single group key, each MAP in the group should be a high-quality TPD [24], assuming that they are secure against any compromise attempt in any circumstances. Unfortunately, this is too high a ground to reach [14]. In addition, ticket-based handover by group key authentication will not be an option when any MAP in the group might be malicious.

Broadcast Authentication
In ticket-based handover by broadcast authentication [4,6,14,16,17,19], the AAA server maintains every MAP and its neighbors' locations. When a client is about to leave a MAP, the AAA server will send tickets to all the neighboring MAPs over a secure channel. However, this means there will be a very long latency time because the AAA server is normally many hops away from the client [3,19]. To solve this problem, Li et al. proposed a fast handover authentication mechanism based on ticket broadcast for mesh network [22]. In their scheme, the task of pre-sending tickets is forwarded from the AAA server to the current MAP (e.g. MAP 1 ). In other words, when the client is about to leave, MAP 1 can use a pre-established symmetric key to generate tickets and send corresponding tickets to its neighbors (e.g. MAP 2 , MAP 3 , and MAP 4 ). This way, the ticket pre-distribution is completed right between the current MAP and its neighbors, only one hop across. However, in Li et al.'s scheme there are some leaks such as sending expiration time and date in plaintext and pre-sending the same ticket to all the neighboring MAPs. Later in Section 4 we shall give a thorough review of Li et al.'s scheme and detail the leaks we have found.

Preliminaries
In this section, we present some models and tools commonly used in this field. They include the trust model, different types of tickets, and elliptic curve cryptography (ECC).

Trust Model
The trust model is illustrated in Fig 2. A ticket agent (TA) is a trusted third party who generates and manages various types of tickets in a mesh network. The following are the elements shown in Fig 2: • TA-mesh access points (MAPs): The mutual trust is based on public key cryptography and is built when a MAP requests a MAP ticket from TA. In response, TA embeds a digital signature in the MAP ticket to make MAPs believe the ticket was created by TA.
• TA-client: The mutual trust is based on public key cryptography and is built when a client requests a client ticket from TA. In response, TA embeds a digital signature in the client ticket to make the client believe the ticket was created by TA.
• MAP-client: The mutual trust relationship between a client and its home MAP is built through their respective client ticket and MAP ticket, which will be elaborated later.
• MAP 1 -MAP 2 : Any two neighboring MAPs build up mutual trust via symmetric key certificates. This trust allows a client to roam among different MAPs in a mesh network.
Please note that technically both the MAP ticket and the client ticket can be obtained before a client even joins a mesh network, so this portion of time consumption in public key operations should not count as part of the authentication process, which adds to the efficiency of the authentication protocol.

Different Types of Tickets
Three types of tickets are used in this paper: client ticket, MAP ticket, and transfer ticket. They are needed for mutual authentication between a client and a MAP when the client logs into the network or roams from a MAP to another. Before looking any further into the details of the three types of tickets, let's check out the notations listed in Table 1 below.
3.2.1 Client tickets. The client ticket (T C ) enables a client to gain a MAP's trust. The MAP (e.g. MAP 1 ) can verify the client by checking the client ticket to see if the ticket was really issued by TA.  A client ticket T C typically includes the following elements: T C ¼ fI C ; I A ; t exp C ; P C ; Sig A g • I C : ID of the client who keeps this ticket.
• I A : ID of TA who generated this ticket.
• τ exp_C : expiry time of T C . When this ticket expires, the client needs to re-request a new ticket from TA.

MAP tickets.
The MAP ticket (T M ) enables a MAP to gain a client's trust. The client (e.g. C) can verify the MAP (e.g. MAP 1 ) by checking the MAP ticket to see if the ticket was truly issued by TA.
A typical MAP ticket T M includes the following elements: ID of the MAP who keeps this ticket.
• I A : ID of TA who generated this ticket.
• τ exp_M : expiry time of T M . When this ticket expires, the MAP needs to re-request a new ticket from TA.

Transfer tickets.
When a client C starts to access the mesh network, he/she needs to exchange his/her client ticket for the nearest MAP's (e.g. MAP M 1 ) MAP ticket to perform mutual login authentication. If the authentication phase is a success, M 1 issues a transfer ticket to C and becomes the home MAP of C. The transfer ticket helps to construct trust relationship between a foreign MAP (e.g. MAP M 2 ) and C. When C roams to M 2 , he/she submits the transfer ticket to M 2 for handover authentication. With the transfer ticket, the client C can prove to M 2 that he/she has been authenticated by M 1 . Thus, M 2 can run a simple authentication process to verify C.
The elements of a typical transfer ticket θ C include: ID of the client who obtained this ticket.
• I M : ID of the home MAP who generated this ticket.
• I A : ID of TA who issued I C 's client ticket.
• τ exp_θ : expiry time of θ C which is determined by its issuer's policy. When this ticket expires, the client needs to re-select a MAP to be the home MAP and re-login to obtain a new transfer ticket. Before that, the client can roam past MAP after MAP with ease.

Elliptic Curve Cryptography (ECC)
Elliptic curve cryptography (ECC) was created by Neal Koblitz and Victor Miller [27] in 1985, and it has been widely used nowadays [20,28,29]. Suppose G is a group of p members, where p is a large prime number. Let {a, b}2 Z Ã n be such that 4a 3 +27b 2 6 ¼ 0 (mod p) in G. The set E(G) consists of all points (x, y)2 G that satisfy the equation y 2 = x 3 +ax +b, together with a special point O, namely the point at infinity. Then, let's select a q-order subgroup G q of the additive group of points over E(G) and choose an arbitrary generator P of G q . According to the Elliptic curve discrete logarithm problem (ECDLP), given mP 2 E(G) and P 2 G q for an unknown m 2 Z Ã n , it is intractable to find m. Finally, we preload each client and MAP with the public system parameters {p, q, E(G), Z Ã n , P}.

Li et al.'s Authentication Protocols
In this section, we shall review Li et al.'s authentication protocols and present our analysis of their protocols. In Li et al.'s scheme [22], there are two distinct authentication protocols: initial login authentication protocol (LAP) and handover authentication protocol (HAP), as shown in

The Login Authentication Protocol (LAP)
Assume that the client and the MAP have respectively obtained a client ticket and a MAP ticket from TA. Now the pair of client and MAP submit tickets to each other for mutual authentication. The steps are as follows: 1. When a client C starts to access the mesh network, he/she broadcasts a request message containing his/her ID number to the neighboring MAPs.
2. Assuming MAP M 1 receives the request message, M 1 replies with a message containing its MAP ticket T M1 to inform C of its presence. After receiving T M1 , C verifies Sig A . If the verification fails, C ignores this ticket. Otherwise, C checks the τ exp_M of T M1 and determines whether or not the τ exp_M has expired.
3. If the above verifications are successful, C extracts M 1 's public key P M1 from T M1 . Then C encrypts ticket T C along with two nonces N C1 and N C2 by using P M1 , and sends the encrypted message to M 1 . Upon receiving the encrypted message, M 1 uses its own private key to decrypt the message and then verifies Sig A in T C . If the verification fails, M 1 ignores this ticket. After that, M 1 checks the τ exp_C of T C and determines whether or not it has expired.
4. If the above verifications are successful, M 1 extracts C's public key P C from T C . Then uses P C to encrypt two nonces N M11 and N M12 . After that, M 1 sends the encrypted message to C and calculates their shared MAC key K MAC = N C1 ||N M11 and pairwise master key PMK 0 = N C2 || N M11 . Upon receiving the message, C decrypts it by using his/her private key to obtain N M11 and N M12 . Then, C calculates their shared MAC key K MAC = N C1 ||N M11 and pairwise master key PMK 0 = N C2 ||N M11 . Due to the public-key cryptography, the security of nonces N C1 , N C2 , N M11 , and PMK 0 is ensured. This concludes the login authentication protocol. The pairwise master key PMK 0 can then be used to encrypt messages between the two parties. In the meantime, C can use this transfer ticket θ C to legally roam from MAP 1 to another MAP in the network.

The Handover Authentication Protocol (HAP)
To support fast handover for clients roaming from M 1 to another MAP, M 1 should pre-distribute the keys shared with C to all the neighboring MAPs by broadcast. Throughout the network, it is assumed that each MAP has established symmetric shared keys with all its neighboring MAPs. After successfully authenticating C, M 1 encrypts I C , I M1 , key K MAC , and the pairwise master key PMK 0 shared with C by using the key M 1 shares with its neighbor M x , and then M 1 sends the encrypted message to M x . Upon receiving the message, M x decrypts it and extracts K MAC and PMK 0 to prepare for future authentication with C. The above computations are performed by MAPs, so there is no extra burden laid on the client's side. When C leaves M 1 and visits M x , he/she executes the following handover authentication protocol: . The latter MAPs, however, can still decrypt the ticket and obtain the same secret information (e.g., PMK). This increases security risks. Moreover, the domino effect [6] can also be a problem. The current pairwise master key (PMK) is generated by using the previous PMK along with some public information. Once some MAP M n has obtained an old PMK, it can track down the current PMK at any time and even disguise as the client to communicate with other MAPs. In other words, once a MAP is compromised, all the MAPs directly or indirectly connected to it will also be affected, and so the whole security system will collapse.

The Proposed Authentication Protocols
To solve above problems, we shall present an efficient and secure authentication protocols as shown in Fig 4. Furthermore, the proposed protocols preserve clients' privacy well and only imposes negligible overhead. In the design of proposed protocols, TA is in charge of not only ticket issuing but also ECC public parameter management (e.g., {p, q, E(G), Z

The Login Authentication Protocol (LAP)
As is stated in the preliminaries section, our login authentication protocol runs upon the assumption that the client and the MAP have respectively obtained a client ticket and a MAP Authentication Mechanism for Fast Handover in Mesh Network ticket from TA. Now the client-MAP pair submit tickets to each other to do mutual authentication as follows.
1. When a client C starts to access the mesh network, he/she broadcasts a request message to the nearby MAPs.
2. Assuming that MAP M 1 replies with a message containing its MAP ticket T M1 to inform C of its presence. Upon receiving T M1 , C verifies Sig A of T M1 . If Sig A fails the verification, C ignores this T M1 ; otherwise, C checks τ exp_M of T M1 .
3. If the above verifications are successful, C extracts M 1 's public key P M1 from T M1 . Then C encrypts his/her ticket T C and a nonce N C1 using P M1 , and sends the encrypted message to , and θ C using P C , and sends the encrypted message to C. Upon receiving the message, C decrypts it to obtain N M1 , calculates the shared MAC key K MAC0 = N C1 ||N M1 , and verifies H(K MAC0 ). Note that we do not produce any extra pairwise master key PMK, so the bandwidth and key generation cost can both be reduced. In the proposed protocol, we set the MAC key or its derivatives as the session key between C and M 1 . Thus, in the following steps, we only focus on the passing and using of the MAC key. This concludes LAP. The value K MAC0 will then be used to encrypt messages between C and M 1 . On the other hand, C can use K MAC0 along with the transfer ticket θ C to prove his/her legality and roam from M 1 to another MAP within the mash network.

The Handover Authentication Protocol (HAP)
To support fast handover for clients roaming from M 1 to another MAP, M 1 should pre-share some information to all its neighboring MAPs. Instead of broadcasting, we decide to take another route and construct a corresponding temporary MAC key K' MAC1 = H(K MAC0 ||I Mx ) for every neighbor MAP M x (x = 2, 3, 4. . .). Due to the protection of the one-way hash function, even though M x has its own K' MAC1 , it still cannot produce another MAP's K' MAC1 . In addition, to preserve clients' privacy and protect their identity information, we set I C1 = H(I C0 ||K' MAC1 ). That means every MAP M x will obtain a number of anonymous ID numbers, one for a different client, and only this specific client C knows which anonymous ID number will be used. As is stated in the preliminaries section, it is assumed that each MAP has established symmetric keys with all its neighboring MAPs. After M 1 successfully authenticates the client C, M 1 encrypts the corresponding I C1 , K' MAC1 , and θ C by using a different symmetric key shared with MAP M x , and sends those encrypted messages to its neighboring MAPs. Note that M 1 sends the transfer ticket θ C 's original τ exp_θ to M x so that it will not be manipulated to illegally postpone the expiration time.
Upon receiving the message, M x decrypts it using the same shared key and extracts K' MAC1 to prepare for future authentications with C. The above computations are performed by MAPs, and so no extra burdens are laid on the client. When C leaves M 1 and visits M x , he/she executes the following handover authentication protocol: 1. Depending on the moving direction, C calculates a temporary MAC key K' MAC1 = H (K MAC0 ||I Mx ) and I C1 = H(I C0 ||K' MAC1 ) in accordance with the ID number of the foreign MAP M x to visit. Then, C chooses a nonce N C2 2 Z Ã n and computes N C2 P. Note that C can prepare N C2 P in advance so as to reduce the workload during HAP. If C knows which MAP is the next one yet to visit, he/she can also pre-compute I C1 and H(θ C ||I C1 ). Then, C submits I C1 , H(θ C ||I C1 ), N C2 P, and the MAC value V K'MAC1 (I C1 , H(θ C ||I C1 ), N C2 P) to the foreign MAP M x . Upon receiving the message, M x checks the τ exp_θ of θ C received from M 1 and determines whether or not the τ exp_θ has expired. Then, M x verifies H(θ C ||I C1 ) and the MAC value by using K' MAC1 .
2. If the above verifications are successful, M x chooses a nonce N Mx 2 Z Ã n , computes N Mx N C2 P and N Mx P, and produces a formal MAC key K MAC1 = H(K' MAC1 ||N Mx N C2 P). After that, M x sends N Mx P and a MAC value V KMAC1 (N Mx P, N C2 P, θ C ) to C. Upon receiving those messages, C computes N C2 N Mx P and also produces a formal MAC key K MAC1 = H(K' MAC1 || N C2 N Mx P) and verifies the MAC value transferred from M x . If the verification result is positive, C sends V KMAC1 (θ C || N Mx P) to M x to inform M x he/she has successfully constructed K MAC1 .
3. Upon receiving V KMAC1 (θ C ||N Mx P), M x verifies the value. Since C is the only client that keeps K MAC1 , it proves the validity of C. Now the handover authentication process is completed, and K MAC1 is the session key used for further communications between C and M x . Meanwhile, M x can prepare K' MAC2 and I C2 for C's next execution of HAP.

Security Analysis
In this section, we list the common security requirements and threats [2, 9, 11-17, 22, 28, 30-46, 44-46], along with the proof that the proposed protocol can satisfy those requirements and withstand those threats. We shall compare with some similar protocols including  Table 2.

1) Mutual authentication:
Mutual authentication means that the participators of communication verify the legality of each other. In the proposed LAP, M 1 and C exchange and verify each other's ticket. The digital signature of TA can provide the legality of both M 1 and C. In addition, C encrypts his/her ticket and the authentication information by using M 1 's public key. Under the protection of public key cryptography, only M 1 can decrypt this message and extract the plaintext. Therefore, it is difficult for an attacker to obtain the authentication information (e.g., N C1 ) and generate the correct reply message (e.g., H(N C1 )). That means C can verify M 1 's validity if M 1 returns correct H(N C1 ). On the other hand, M 1 can also verify C if C returns correct H(N M1 ), for only C can extract N M1 from E PC (N M1 ). Before C moves from M 1 to M x , M 1 encrypts K' MAC1 by using the symmetric key M 1 M x . Based on symmetric cryptography, M 1 and M x can achieve mutual authentication with each other. Since the client only C has the necessary information for the construction of K' MAC1 , M x can authenticate C by checking the MAC value based on K' MAC1 during HAP. In the meantime, C can authenticate M x if M x replies with the MAC value based on correct K MAC1 , for only M x is capable of constructing the correct K MAC1 .
2) Privacy preservation: In the proposed protocol, I C is only used when C launches the login request, whereas I Ck , which is for the k-th handover, is composed of a number of nonces provided by C and the MAPs that C roams through. In addition, I C is encrypted by P M1 when the message is transmitted. That means two things: firstly, only M 1 can obtain I C , and an interceptor cannot extract I C from the encrypted message; secondly, M 1 cannot track I Ck because it is always re-constructed by a couple of nonces provided respectively by C and the current MAP when C is roaming to a new MAP. Besides, instead of the plaintext θ C , we use H(θ C ||I Ck ) in HAP. That means it is hard to extract θ C . Even when an adversary fortuitously obtains C's θ C in plaintext, they still have to intercept all possible I Ck and compute H(θ C ||I Ck ) if he/she wish to track down C.

3) Forward and backward security:
To satisfy this requirement, we have to prove that, should an adversary somehow acquire a secret key for a certain communication session, the adversary has no way to derive the secret keys for the previous and following sessions. In the proposed scheme, the K MACk for the k-th handover includes a couple of nonces respectively provided by C and the current MAP. Those nonces are protected by the elliptic curve discrete logarithm problem (ECDLP) and elliptic curve diffie-Helman (ECDH). That means given {N Mx P, N Ck P} 2 E(G), {N Mx , N Ck }2 Z Ã n , and P 2 G q , it is intractable to derive N Mx N Ck P. Therefore, even if N Mx P and N Ck P are intercepted by an adversary, the adversary still cannot derive the MAC key N Mx N Ck P. Furthermore, those nonces are randomly generated, so an adversary cannot derive a new MAC key should the adversary be able to break an old MAC key. In addition, since the k-th secret key is constructed from the collision-free one-way hash function of the (k-1)-th secret key, an adversary cannot derive any previous secret keys from it. To conclude, the proposed protocol guarantees perfect forward /backward security.

4) Replay attack resistance:
An adversary may eavesdrop some messages during authentication sessions and replay these messages in the future in an attempt to get authenticated and successfully access the network as a client. Similarly, an attacker may attempt to gain the client's trust as a MAP. To protect clients and MAPs from reply attacks, we set two nonces in LAP and HAP. In LAP, the nonces N C1 and N M1 are randomly generated by C and M 1 respectively and protected by public key cryptography. An adversary cannot succeed in being authenticated by replaying the message because C and M 1 discard those nonces once the LAP is completed. Besides, since we use public key cryptography and one-way hash function to protect the nonces N C1 and N M1 , the adversary cannot decrypt the messages and thus cannot launch a successful replay attack when the LAP is ongoing.
In HAP, the private MAC key and nonces protect the client and MAP from replay attacks. What the attacker has in hand are only the old nonces and an old MAC value recorded, which cannot pass a new authentication procedure. Even if the attacker should come by some new nonces, there is still no way they can compute the correct MAC value in the absence of the private MAC key. In conclusion, both our LAP and HAP can resist the replay attack.

5) Forgery attack resistance:
In LAP, TA's digital signature ensures that both the client's ticket and the MAP's ticket are valid and unmodified. In HAP, since the MAP that C is leaving M 1 for has obtained the correct information of θ C from M 1 , C cannot forge a fabricated θ C . On the other hand, since the MAC value is different for each round-trip, we can ensure the integrity of these messages and thus guarantee that our HAP can resist attacks from outside. Any unofficial modification to the content of message will result in an incorrect MAC value due to the lack of the MAC key and will be identified.

Performance Analysis
In this section, we shall analyze the performance of the proposed handover authentication scheme by showing how it compares with some similar protocols including EAP-TLS [47], Li et al.'s scheme [22], and Yang et al.'s scheme [45]. EAP-TLS is a popular authentication protocol for IEEE 802.11-based wireless networks and represents the multi-hop handover authentication approach. Note that to keep real-time applications going and to provide better user experience, the overall handover latency should not exceed 50ms [2].

Computation Cost
The computation cost represents the processing delays of the cryptographic operations on both the client side and the MAP side. These operations include encryption using public key (T E ), decryption using private key (T D ), generation of digital signature (T sig ), verification of digital signature (T ver ), computation of MAC value (T MAC ), computation of hash value(T H ), and computation of point multiplication (T pmul ). To be fair, we used the same public key cryptographic system-RSA-1024 as the RFC 5216 suggested for T E , T D , T sig , and T ver .-to run all the schemes compared. We learned the authentication latencies of T E , T D , T sig , T ver , T MAC , and T H from Long and Wu's experimental results [48]. However, Long and Wu's experimental results do not include the latency of T pmul . Although they did provide ECDSA's signature latencies, those operations are way too complex, so the results cannot translate to the latency of T pmul . Therefore, we turned and referred to other studies concerned to obtain the ratio of ECC to RSA. Since the decryption of ECC only involves a point multiplication and a point subtraction, we can say that the cost of time for the decryption of ECC is almost the same as that of T pmul . According to Ariffin and Mahad's study, the time cost of decryption at a ratio of ECC-128 to RSA-1024 is approximately 0.0113 (0.770s: 68.042s per 625 blocks) [49]. We can then translate this to an approximated T pmul time cost of 0.376ms (33.3ms×0.0113). Please note that in Long and Wu's experiment RSA used a short-length public key and a long-length privacy key to expedite the process of public key operations (e.g., T E and T ver ), and the ratio of T D to T E was approximately 23.45. Because we use the public key operations as the intermediary value, the time cost of T pmul may be overestimated. To clearly see how the schemes compared in terms of performance, Table 3 lists the operations discussed above, the algorithms implementing the operations, time cost of these algorithms, and the numbers of different kinds of operations performed by different protocols.
Because the first T pmul can be performed in advance (e.g., N M P and N C2 P), the number of T pmul is cut down from two to one for the client. Similarity, the MAP also only needs to perform one T pmul . That means the total number of T pmul is only two in HAP. According to Table 2, the total computation cost of the proposed scheme in LAP (72.334ms) is slightly higher than those of EAP-TLS (72.307ms) and of Li et al. (72.259ms) but significantly lower than Yang et al.'s scheme (105.595ms). However, since the client only needs to do LAP one time and it lasts until the transfer ticket expires, the impact of a long LAP processing time is relatively small. More importantly, the computation cost of the proposed scheme in HAP is only 0.854ms and significant lower than Yang et al.'s scheme. Although the proposed HAP is slower than Li et al.'s scheme, the price is paid to mend the security flaws in Li et al.'s protocols mentioned earlier, and we think it is worth the while. With the overall handover latency kept under 1ms, the proposed scheme still shows pretty good efficiency.

Communication Cost
The communication cost is estimated in accordance with the number of message transmissions between a MAP and a client during LAP or MAP because the transmissions are what cause the communication delays. The notation d stands for the average delay of a transmission made across one hop, and h is the number of hops between the client and the verifier. Because EAP-TLS is the only scheme in the comparison that requires a client to communicate with the EAP server, which is always multi-hops away, during the handover process, the parameter h is applicable to only EAP-TLS. The results show that the number of transmissions made between the client and the MAP in the proposed HAP is equal to those of Li

Conclusion
In this paper, we have proposed fast handover authentication protocols based on ticket for wireless mesh network. Not only does the proposed protocol satisfy all the essential handover security requirements, but it also preserves the privacy of the client. The results of our security analysis and performance comparison show that the proposed protocol is superior to the other protocols of the kind. Even though the proposed HAP is slightly slower than Li et al.'s work, the security level is significantly higher. Moreover, like the proposed protocol, Yang et al.'s protocol is also the product of a follow-up study meant to fix the security problems of Li et al.'s work, but our new protocol turns out to be both faster and more secure. Besides, in our new design, no complicated computations need to be done on the client's side, and therefore our new protocol is especially suitable for applications in wireless mesh networks where the mobile devices have limited computation power. Our future research will continue to focus on the development of authentication protocols that are more efficient, more reliable, and more userfriendly.