1 FIVE STAGES OF I.

Transcription

1 1 1 FIVE STAGES OF I. Stage 1. AP and Security Capability Discovery This stage consists of messages numbered (1) to (3). The AP either periodically broadcasts its security capabilities, indicated by RSN IE (Robust Security Network Information Element), in a specific channel through the Beacon frame; or responds to a station s Probe Request through a Probe Response frame. A wireless station may discover available access points and corresponding security capabilities by either passively monitoring the Beacon frames or actively probing every channel. Stage Authentication and Association This stage consists of messages numbered (4) to (7). The station chooses one AP from the list of available APs, and tries to authenticate and associate with that AP. Note that Open System Authentication is included only for backward compatibility, and a station should indicate its security capabilities in the Association Request. After this stage, the station and the AP are in authenticated and associated state. However, the authentication achieved so far is weak, and will be supplemented by further steps. At the end of this stage, the 802.1X ports remain blocked and no data packets can be exchanged. Stage 3. EAP/802.1X/RADIUS Authentication This stage consists of messages numbered (8) to (14). The supplicant and the authentication server execute a mutual authentication protocol (de facto EAP-TLS [10]), with the authenticator acting as a relay. After this stage, the supplicant and the authentication server have authenticated each other and generated some common secret, called the Master Session Key (MSK). The supplicant uses the MSK to derive a Pairwise Master Key (PMK). The key material on the server side is securely transferred to the authenticator, indicated by message (13). This allows the authenticator to derive the same PMK. This stage might be skipped if the supplicant and the authenticator are configured using a static Pre-Shared Key (PSK) as the PMK, or when a cached PMK is used during a Re-association. Stage 4. 4-Way Handshake This stage consists of messages numbered (15) to (18). Regardless of whether the PMK is derived from Stage 3, configured using a PSK, or reused from a cached PMK, the 4-Way Handshake must be executed for a successful RSNA establishment. The supplicant and authenticator use this handshake to confirm the existence of the PMK, verify the selection of the cipher suite, and derive a fresh Pairwise Transient Key (PTK) for the following data session. Simultaneously, the authenticator might also distribute a Group Transient Key (GTK) in message (17). After this stage, a fresh PTK (and maybe GTK) is shared between the authenticator and the supplicant, and the 802.1X ports are unblocked for data packets. Stage 5. Group Key Handshake This stage consists of messages numbered (19) and (20). In case of multicast applications, the authenticator will generate a fresh GTK and distribute this GTK to the supplicants. These handshakes might not be present if the fresh GTK has been distributed in Stage 4. This stage may be repeated multiple STA t=t+1 3. Fast access authentication request (SNonce,User-ID,AS-ID, F, t) 5. Fast authentication response (SNonce, User-ID, AS-ID, E, t) AS 4. AS verifies t and F, then generates PMK Fig. 1. The interaction between the STA and AS. STA 8. Generates PMK and PTK,verifies MIC1 2. The first authentication message ( SNonce, User-ID) Authentication Request (open) 7. The second authentication message (ANonce, User-ID, MIC1) Authentication Response (open) 9. The third authentication message (SNonce, MIC2) Association Request 11. The fourth authentication message (MIC3) Association Response Fig. 2. The interaction between the STA and AP. AP 10. Verifies MIC2 times using the same PMK. Through these handshakes, the supplicant and the authenticator mutually authenticate each other and establish a secure session for data transmissions. 2 THE SECURITY ANALYSIS OF THE PRO- POSAL The proposed scheme first employs the shared key k to realize the mutual authentication between the STA and the AS, deriving the PMK. Then, using the PMK, the STA and the AP authenticate each other and generate the PTK. According to those two different functions, we divide the scheme into two parts which are the interaction between the STA and the AS, and the one between the STA and the AP. The former is shown in Figure 1 and the latter in Figure 2. In the two figures, the message fields that do not affect the security are omitted. From Figure 2, it can be seen that the message interactions are same as the 4-way handshake protocol. The only difference is that in the 4-way handshake protocol the STA and the AP already get the PMK before the protocol starts, while in our scheme the AP and the STA get the PMK through the message interactions shown in Figure 1, after the message (5) and (7) respectively. Therefore, only if the derived PMK in Figure 1 is secure, the protocol in Figure 2 is as secure as the 4- way handshake protocol. In the following, we will prove the security of the protocol in Figure 1 with the Canetti-Krawczyk (CK) model [12] which is a provably secure formal method for authentication and key agreement protocols.

2 2 Definition 1. Matching session: A key agreement protocol runs in a network where multiple users interconnect each other. And each entity runs an instance of the protocol which we call a session. A session can be expressed as a quaternion (A,B,X,Y) where A is the owner of the session, B is the correspondent of A, X is the messages sent and Y is the received message. The session (B,A,X,Y) is the matching session of (A,B,X,Y). The protocol attacker can choose, at any time during its run, a test-session among the sessions that are completed, unexpired and unexposed at the time. And the attacker is not allowed to expose the test-session or its matching session. Definition 2. Session-key security: A key agreement protocol is called Session-Key security (or SK-security) if the following properties hold for any attacker. (1) If two uncorrupted parties complete matching sessions then they both output the same key; (2) The attacker cannot distinguish a session key from a random value with a non-negligible advantage. For more details about the CK model, [12] can be referred to. The authentication protocol in Figure 1 is denoted by π. To prove that it is SK-secure, we design a game which combines π and the security of the hash function f(). We will prove that if π is not SK-secure, the attacker can take use of the capacity he gets from the protocol attack to win the game, then the hash function f() is broken. The participators of the game are G and B. G is of the Random Oracle function, and B is the attacker of the protocol π which takes use of the capacity he gets from the protocol attack to take part in the game. G knows the shared key k between STA and AS, while B does not know. The game is as follows. Phase 1: B challenges G with t 2 and Nonce 2. G chooses a bit b {0,1}. R If b=0, then G replies with f(k,t 2 Nonce 2 User-ID AS-ID). If b=1, G replies with a random value s which has the same length as f(k,t 2 Nonce 2 User-ID AS-ID). Phase 2: B queries G with arbitrary integrity t and random number Nonce, and G responds with F= f(k,t Nonce User-ID AS-ID). B can repeat this process multiple times, and t and Nonce are chosen adaptively by B. (i.e., according to the reply of G for the previous t and Nonce, B chooses the next t and Nonce.) Phase 3: After a number of queries, B outputs a bit b as the guess of b. If and only if b=b, B wins the game. In the above game, in Phase 2 B can query G with arbitrary t and Nonce, but he cannot use both t 2 and Nonce 2 at the same time. To reduce the difficulty, B can fix Nonce and always sets Nonce as Nonce 2. According to Definition 1, to prove that π is SK-secure we need to demonstrate that it satisfies two conditions. First, if the STA and the AS complete matching sessions, they will get a same session key. Second, the attacker cannot distinguish the session key PMK from a random value with a non-negligible advantage. In the following, we will prove that π satisfies the two conditions. Lemma 1: If the STA and the AS complete matching sessions, they will get a same session key. Proof: If the STA and AS complete matching sessions, they will get the same parameter t and derive a same key PMK= h(k, FIA PMK t User-ID AS-ID). Therefore, the first condition holds. Lemma 2: If the hash function f() and h() is secure, then when the protocol π completes, the attacker cannot distinguish the session key PMK from a random value with a non-negligible advantage. Proof: There are two methods that the attacker can get the session key with a non-negligible probability. One is to disable the STA and AS to complete matching sessions, and the other one is to attack the key derivation function h(). For the first method, the attacker can disable the STA and the AS to complete matching sessions only if he can forge an authentication request or an authentication response. First, it is assumed that the attacker fakes a fast authentication request message where the t is fresh (i.e., the t is bigger than any t that the STA ever used). Then he can run another station STA to send this message to AS. AS verifies the message and replies the fast authentication reply. Then the session in the STA is (STA,AS,X,Y) where X is the sent message and Y is the received message, while the session in the AS is (AS,STA,Y,X) because the AS thinks that he is communicating with the STA. Thus, the STA and AS do not hold matching sessions. Then, the attacker chooses the session in the STA as the test session (it should be noticed that this session is eligible for the test session, because it is completed, unexpired and unexposed), and then exposes the session (AS,STA,Y,X). In such a way, the attacker can get the session key PMK. Next, we assume that the attacker fakes a fast authentication response. Then, when the STA sends a fast authentication request, the attacker intercepts this message and runs another station STA to reply the faked message to the STA. So, the session in the STA is (STA,AS,X,Y), while the session in STA is (STA,STA,Y,X). They are not matching sessions. Then, the attacker chooses the session in the STA as the test session, and exposes the session (STA,AS,X,Y) and gets the PMK. In the following, we will prove that those two counterfeiting are infeasible using the reduction to absurdity. 1) It is assumed that with a non-negligible probability the attacker can fake a fast authentication request message {User- ID, AS-ID, F, t } (t is bigger than any t that STA ever sent, and F =f(k, t SNonce User-ID AS-ID), then the attacker can take use of this capacity to take part in the game designed. Specifically, in phase 1 t 2 is set as t and Nonce 2 is set as SNonce, then in the phase 3, the attacker B can easily figure out the value G replies is f(k, t 2 Nonce 2 User-ID AS-ID) or s, because the attacker can get the F =f(k, t SNonce User-

3 3 ID AS-ID) with a non-negligible probability. In such a way, the attacker wins the game. That is, after some rounds of training (phase 2), with a non-negligible advantage the attacker can distinguish the hash value of a fresh message from a random value without knowing the key k. (It should be noted that the hash value is fresh because in the phase 2 B cannot query G using t. Additionally, t is bigger than any t the STA ever used, therefore, the protocol attacker does not get the hash value corresponding to t. Only through the training can B get this capacity.) Then f() is broken, which conflicts with our assumption. Consequently, the attacker can not fake a fast authentication request with a non-negligible probability. 2) It is assumed that the attacker fakes a fast authentication response {User-ID, AS-ID, E*, t*} where E*=f(k, t* Nonce AS-ID User-ID) and t*=t+1 (t is the count value in the fast authentication request). To prove that this fake is impossible to succeed, we need to modify the game. In the phase 1, if b=0, G replies B with f(k,t 2 Nonce 2 AS-ID User-ID). In the phase 2, G replies with f(k,t Nonce AS-ID User-ID). It is assumed that with a non-negligible probability the attacker can fake a fast authentication response {User-ID, AS- ID, E*, t*} (t*=t+1), then the attacker can take use of this capacity to take part in the game. (Notice: the attacker cannot forward the fast authentication request from the STA to the AS, and get E* from the AS s reply. Because if so, rather than behave as a faker, the attacker just acts as a router between the STA and AS). Specifically, in phase 1 t 2 is set as t* and Nonce 2 is set as SNonce, then in the phase 3, the attacker B can easily tell the value G replies is f(k, t 2 Nonce 2 AS-ID User- ID) or s, because the attacker gets the E*=f(k, t* SNonce AS- ID User-ID) with a non-negligible probability. That is, after some rounds of training (phase 2), the attacker can distinguish the hash value of a message from a random value without knowing the key k. Then the f() is insecure, which conflicts the assumption. Therefore, the attacker cannot fake a fast authentication response with a non-negligible probability. From the above analysis, it can be seen that the attacker cannot fake a fast authentication request or a fast authentication response. Then, the only way he can take is to directly attack the key derivation function h(). According to the assumption, h() is secure, which means that without k, nobody can distinguish a keyed hash value (i.e., PMK) from a random value of same bit length with a non-negligible advantage. Otherwise, the h() is not secure. Therefore, this method does not work either. In summary, when the protocol π completes, the attacker cannot distinguish the session key PMK from a random value with a non-negligible advantage. According to Lemma 1 and Lemma 2, the following theorem can be achieved. Theorem 1: If the hash function f() and h() is secure, π is SK-secure, and the STA and the AP can securely get the session key PMK. It should be noticed that in some circumstances, the STA cannot complete the protocol π implementation, which are given as follows. (1) Because of the networks congestion, when the fast authentication response message reaches the STA, it has already aborted. (2) The attacker intercepts and holds the fast authentication response message (or the fast authentication request message) and sends it to the STA (or the AS) until the STA aborts. This kind of attack is called forced delay in [13], and we can take the attacker as a malicious router. The above circumstances will result that the STA thinks the authentication fails while the AS thinks it succeeds, which is an unexpected outcome. The new scheme takes into account of those circumstances, because in those circumstances the STA can not proceed the protocol (i.e., send the third message) any longer, then the AP will not receive the expected third authentication message in a given time or receive one with an incorrect MIC 2 (the attacker fakes a MIC 2 to impersonate the legal STA). Then the AP will inform the AS that the STA s authentication fails which will in turn delete the derived PMK and set the STA s state as unauthenticated. In such a way, for our whole scheme (shown in Figure 2), its possible outcome is: 1) the STA and the AS both complete the protocol and get the PMK securely, or, 2) they both think the protocol fails. And the inconsistency regarding the authentication result will not occur. Upon completing the protocol π, the AS delivers the PMK to the AP through the secure channel, and then the STA and the AP will securely share the PMK. So far, the security of the whole scheme rests on the protocol in Figure 2, which is essentially same as the 4-way handshake. Therefore, our scheme FLAP is at least as secure as the 4-way handshake. Furthermore, FLAP can overcome the DoS attack in the 4-way handshake that has pointed out in [14]. The reason resulting in the DoS attack is that the first message is an unprotected plaintext message. An attacker can impersonate the AP to generate a large quantity of such messages for the STA, and the STA cannot determine which ANonce the AP adopted to generate the PTK until the third step, therefore, the STA has to store vast two-tuples {ANonce, PTK}, resulting in the memory exhausting. But in FLAP, the first message is protected under the F. After the AP receives this message, he does nothing except forwarding it to the AS. Until the AS verifies the fast authentication request, the AP will then accept the SNonce in the response, and then generate ANonce and computes the PTK. Besides, the attacker cannot forge the first authentication message (this has been proven in Lemma 2), therefore, in Step 6 the AP just needs to store a triple {ANonce, SNonce, PTK} for one STA. Consequently, our scheme can overcome the DoS attack in the 4-way handshake. Notice that in FLAP it is meaningful that the AP is required not to store the SNonce after it receives the first authentication message. Otherwise, the AP has to store all of SNonce, if the attacker simultaneously sends a mass of the first authentication messages to the AP even if those messages cannot pass the AS verification, which also will result in a memory exhausting DoS attack for the AP. To sum up the above arguments, we can get the Deduction 1 as follows. Deduction 1: If the hash function f() and h() is secure, our scheme FLAP can achieve mutual authentications among the STA, AP and AS, and generates a secure key

4 4 PTK. Furthermore, FLAP is more secure than the 4-way handshake protocol. 3 THE CONFIGURATION OF THE TESTBED (1) STA One HP desktop (2.26GHz Core 2 Duo CPU and 2G RAM) is adopted as the STA, and its operation system is Linux Fedora 14 which kernel version is The wireless PCI network card is TP-LINK TL WN550G 54M. The OpenSSL 1 is used for encryptions and decryptions whose version is openssl-1.0.0d. The wpa supplicant 2 is adopted as the STA simulator which version is wpa supplicant (2) AP One HP desktop (2.26GHz Core 2 Duo CPU and 2G RAM) acts as the AP, and its operation system is Linux Fedora 14 which kernel version is The wireless PCI networks card is TP-LINK TL WN550G 54M. The same OpenSSL is installed. The hostapd 3 is adopted as the AP simulator which version is hostapd (3) AS The AS runs on a HP desktop (3.0GHz Core 2 Duo CPU and 2G RAM) and its operation system is Ubuntu The freeradius 4 is adopted which version is freeradius-server , and the same OpenSSL is installed. 4 RELATED WORK Before the establishment of the ai task group, the fast initial access authentication was not the research focus, and most researchers devoted their energy to reducing the handoff latency between the WLAN APs, and a lot of schemes have been proposed. The common method that they utilize is that before the STA starts the handoff process, a pre-authentication is performed and related key materials are distributed to the candidate APs. Then when the handoff begins, instead contacting with the backed AS, the STA just needs to carry out a simple authentication with the AP directly, using the key materials derived in the pre-authentication. Thus, the authentication delay is reduced substantially. For example, [20] introduces the concept of FHR (frequent handoff region) which is a set of APs selected based on users mobility patterns and their service classes. The STA entering an area of an AP performs authentication procedures with the APs in the FHR instead of the current AP. Since the STA is authenticated for FHR in advance, the handoff latency due to the re-authentication can be minimized. [21] introduces a novel data structure, the Neighbor Graph, which dynamically captures the mobility topology of the networks. During the initial access authentication, the key materials are distributed to the candidate APs in the Neighbor Graph. In such a method, the communication between the AP and the authentication server can be waived and the handoff latency is reduced when the handoff starts. To reduce the authentication delay further, proactive key distribution with anticipated four-way handshake supplicant/ is introduced in [22]. After the AS extracts the neighbor APs list, it sends MAC addresses of neighboring APs to the STA. As a result, the STA can generate PTKs before the handoff to waive the four-way handshake. The scheme proposed in [23] is a little different from the pre-authentication methods mentioned above. The tunnel technique is introduced to reduce authentication latency. When the handoff targeted AP is decided, the current AP generates a pairwise tunnel key for the STA and the targeted AP. When the handoff to the targeted AP starts, only the open authentication is performed. After the new association is established, all the data sent to the new AP are encrypted by the tunnel key and are forwarded to the old AP which will send the packets to their destinations. Simultaneously, the STA performs the EAP authentication with the backend authentication server through the new AP. Upon the EAP authentication is finished, the temporal tunnel key is obsoleted, and the STA can communicate with the new access point as usual. With the soared popularity of WLAN, new scenarios appear and they demand a faster initial access authentication, and some schemes have been proposed. For example, a novel technique has been suggested in [24] to exchange a valid token during registration phase between the AS and the STA. This token will be used to generate a valid token key to encrypt all messages in the authentication phase. But this method employs even four roundtrip messages, which limits its efficiency. The ai does a lot of work and several schemes have been put forward regarding the fast access authentication. [25] proposed two optional protocols which just needs 1.5 roundtrip messages to complete the authentication. In the first one, the 4-way handshake is reduced to 3-way handshake which is used to realize the fast authentication, and the AP sends the random value ANonce in the network discovery phase. But if the passive scan is employed by the STA, then at a given time slot, all the STAs receiving the beacon will share a same ANonce. Furthermore, the valid period of the ANonce is also an issue. If it is set too short, the ANonce maybe has expired before an STA gets the channel. If too long, the replay attack is possible. Those factors have the potential to compromise the security of the protocol. In the second proposal, a full i authentication is needed before the fast authentication. Based on the keys from the full authentication the fast authentication is performed. A common shortcoming of these two proposals is that at the end of the protocols the AP does not get an explicit confirmation that whether its authentication is successful or not, which possibly results that the STA does not pass the AP s authentication while the AP thinks otherwise. In [26], authors think that users may have different delay tolerance levels for network association and greedy/immediate association only reduces the association efficiency but not guarantees fast link setup. Therefore, STAs are allowed to associate with an AP with different priorities, to ensure timecritical STAs to achieve a shorter delay in the fast initial link setup. But association priority assignment is open for further discussion, and details of the differentiated association scheme need further investigation. In [27], when the full i authentication completes, the

5 STA and the AP will cache the related context information (such as the PMK). When the time duration has not been expired and the STA attempts to be associated with the AP, the authentication can be performed directly between the AP and the STA without the involvement of the AS. In such a way, the authentication delay is reduced. Whereas, for some scenarios where an STA enters into a new WLAN or the context has expired, e.g., a lot of passengers get off the metro and try to establish the WLAN link, this proposal is not applicable. In [28], a trusted third party (TTP) is introduced which authenticates the Diffie-Hellman [29] exchange between STA and AP. It features perfect forward secrecy (PFS) and 2 roundtrip messages. But the Diffie-Hellman exchange is not suitable for resource constrained mobile devices and also its computation delay is obviously longer than the symmetric cryptographic operations. 5