• No results found

The Handover Authentication Protocol (HAP)

3.2 The Proposed Authentication Protocols

3.2.2 The Handover Authentication Protocol (HAP)

To support fast handovers for clients roaming from one MAP to another, we propose a method of key pre-distribution among neighboring MAPs. After a home MAPM1 suc- cessfully authenticates a clientC through the login authentication protocol, it generates a message containing the ID of the intra-network transfer certificate,M1’s ID,C’s ID, key

KM AC associated with C’s intra-network transfer certificate. The MAP then encrypts the message using the public keyPxof a neighboring MAPMx, and sends the encrypted message toMx. (We assume that each MAP has the public key certificates of its neigh- boring MAPs.) The neighbor MAP Mx decrypts the message using its private key to extract key KM AC to prepare for future authentications of client C. The above public key operations are performed by MAPs, which are not constrained in terms of computing capability or power supply.

Since the client may move in any direction, the home MAP should send key KM AC to all of its neighbors in anticipation of clientCs mobility. The home MAP can combine several encrypted messages (each containing the ID of the intra-network transfer certifi- cate, client ID, client’s public key andKM AC) into one packet and transmit the packet to all neighbors using a broadcast in order to save bandwidth. After a neighboring MAPM2

receives keysKM AC and a request for connection from clientC, it executes the following handover authentication protocol (presented in the order of the messages exchanged):

(1)C −→M2: ΘC, NC, VKM AC(NC)

(2)M2 −→C: NR, VKM AC(NC, NR)

(3)C −→M2: NR, VKM AC(NR)

(1) Client C submits its intra-network transfer certificate ΘC to the foreign MAP M2, along with a nonce NC, and a message authentication code VKM AC(NC). The

message authentication code is the result of applying the MAC algorithm and secret keyKM AC to nonce NC.

WhenM2receives this message, it first verifies the correctness ofVKM AC(NC) using

the MAC keyKM AC it received from the home MAP M1. If the computed MAC value matchesVKM AC(NC),M2 can confirm that message (1) of HAP is valid. Next, M2verifies the validity of the intra-network transfer certificate. It checks the content of the intra-network transfer certificate, especially the ID of the client’s certificate agent and the certificate expiry date. It then applies the MAC algorithm and the secret keyKM AC received from M1 to messageµ to output a message authentica-

tion code V0

KM AC(µ). (Recall from Section 3.1.2.3 that an intra-network transfer

certificate consists of two parts: the relevant information stored in a message µ

and a message authentication code VKM AC(µ), which is the result of applying a

MAC algorithm and a MAC key to messageµ.) IfVK0M AC(µ) =VKM AC(µ),M2 can

confirm that the intra-network transfer certificate is valid (i.e., C was successfully authenticated by its home MAP).

Note that an attacker may capture the intra-network transfer certificate and attempt to use it, but will not pass the MAP’s authentication, because the attacker cannot produce a valid pair (NC, VKM AC(NC)) without the knowledge of key KM AC. Fur-

thermore, the pair (NC, VKM AC(NC)) enables the protocol to resist denial-of-service attacks (see Section 3.3.6).

(2) M2generates a nonceNR, and computes a message authentication codeVKM AC(NC, NR), which are sent to clientC. WhenCreceives this message, it computes a MAC value

VK0M AC(NC, NR), using noncesNC andNR. IfVK0M AC(NC, NR) =VKM AC(NC, NR),

the client has successfully authenticated the foreign MAPM2. NonceNC serves as a challenge whichC presents toM2. The inclusion ofNC in the MAC computation is the response of M2 to the challenge. (We also include nonce NR in the MAC computation so that the recipient of the message can detect unauthorized changes to the nonce.)

(3) Client C then executes the MAC algorithm using the MAC keyKM AC it computed in step (4) of the login authentication (Section 3.2.1), and the nonceNR as input.

The result is a message authentication codeVKM AC(NR), whichC will send to M2

along withNR, which was the challenge fromM2. Upon receivingNR, VKM AC(NR),

M2 repeats the same MAC calculation on NR. If it obtains the same message authentication code as VKM AC(NR), then this proves C’s identity since C is the

only client who has the knowledge of the keyKM AC.

Following are additional implementation issues and discussions.

(a) If the foreign MAPM2 receives the intra-network transfer certificate ΘC before the message r ={Icert, IR, IC, KM AC} from the home MAP (Section 3.1.2.3), M2 will not be able to verify the validity of the intra-network transfer certificate because it does not have the MAC key KM AC in order to apply the MAC algorithm to the certificate. In that case,M2 sends back an error message to C and C will initiate a login authentication instead of a handover authentication.

M2 will issue a new intra-network transfer certificate to C through the login au- thentication protocol. Client C will use the new intra-network transfer certificate issued by M2 for its subsequence roaming instead of using C’s previous intra- network transfer certificate issued by M1. If MAP M3 is a neighboring MAP of both M1 and M2, M3 may receive two messages r1 = {IcertM

1, IM1, IC, KM AC1}

and r2 ={IcertM2, IM2, IC, KM AC2} after C performs the login authentication pro-

tocol with M1 and M2, respectively. When C moves from MAP M2 to the next MAP M3, C submits the new intra-network transfer certificate generated by M2 to M3. The combination of IcertM2, IM1 and IC in the message r2 indicates the

association of keyKM AC2 with the corresponding intra-network transfer certificate

Θ2C. M3 will use the keyKM AC2 and Θ2C to authenticateC through the handover authentication protocol.

In this worst-case scenario, the handover authentication reverts back to the current practice in WMNs, i.e., repeating the login authentication with the foreign MAP. However, with low to moderate mobility speeds, we expect that this worst-case scenario will not happen often, and the handover authentication protocol will be used in most cases.

(b) After M2 receives message r = {Icert, IR, IC, KM AC} from the home MAP, it also propagates this message to its neighbors to prepare for clientC’s future move to an- other MAP, sayM3. M3 will use messagerand the intra-network transfer certificate submitted byC to authenticateC as described above.

(c) The MAC keyKM AC has to be updated periodically to maintain its security. When it is updated, the intra-network transfer certificate associated with it has to be renewed as well. The MAPR currently serving the client (either a foreign MAP or its home MAP) is responsible for generating a new intra-network transfer certificate and a new MAC key. The MAP then encrypts them using the shared key PTK and sends the encrypted message to the client.

(d) After a successful handover authentication, the foreign MAP will generate a new pairwise master key P M K, and encrypt the P M K using client’s public key PC.

The foreign MAP then sends the encrypted P M K to the client. The client will use his private key to decrypt the message to obtainP M K. The foreign MAP and the client will use the PMK to compute a shared key (pairwise transient key PTK) for their subsequent secure communications, which will be discussed in the next subsection.

(e) The handover processing delay should be as short as possible to ensure quality of service for real-time applications, such as voice over IP [111].

The International Telecommunication Union defines network delay for voice applica- tions in Recommendation G.114 [95]. This recommendation specifies the standards for one-way delay limits as shown in Table 3.2.

Table 3.2: Standards for one-way delay limits Range in Description

milliseconds

0-150 acceptable for most user applications

acceptable provided that administrators are aware of the

150-400 transmission time and the impact it has on the transmission quality of user application

above 400 unacceptable for general network planning purpose

The handover authentication protocol (HAP) does not use digital signatures (public key cryptography), but rather a MAC algorithm (symmetric key cryptography), to

minimize authentication latency during the handover process.

The computation cost of a MAC operation is 0.015ms [74]. Three MAC values are generated in the HAP. To verify them, a receiver also needs to perform three MAC operations. Thus, there is a total of six MAC operations executed in the HAP, which requires 0.09ms for the computation cost.

The computation costs for generating and verifying a digital signature are 11.6ms and 17.2ms [100], respectively. If using digital signatures in the HAP instead of the MACs, three digital signature generations and three digital signature verifications are required. The total computation cost of all digital signature operations in the HAP will be 86.4ms. Thus, the computation cost of the MAC operations used in the HAP is only about 1% of that of digital signatures.

Given the acceptable delay limit of 150ms specified by International Telecommuni- cation Union (see Table 3.2), if digital signatures are used in the HAP, the com- putation cost of the digital signatures would consume 57.6% of the total delay in addition to other types of delay such as transmission, packet processing and queuing delay. The total delay would be unacceptable for handover authentication of real- time applications. On the other hand, the computation cost of the MAC operations used in the proposed HAP results in only 0.06% of the total delay. Therefore, we use a MAC algorithm in the HAP instead of digital signatures.

(f) Fast handover authentication requires the deployment of certificate agents, and gen- eration and maintenance of certificates. The offline deployment of certificate agents

compensates for the elimination of an authentication server during the handover authentication process. (The HAP does not involve an authentication server.) Fast handover authentication also requires MAPs to execute more complex operations of the handover authentication protocol in order to directly authenticate mobile clients.