CS259 Final Project Analysis of 4-way handshake protocol in IEEE 802.11i By Changhua He March 11, 2004 1. Protocol Overview IEEE 802.11i standard defines a Robust Security Network Association to provide authentication and confidentiality in wireless networks, based on IEEE 802.1x authentication architectures. During each authentication process between the specific supplicant and authenticator, after the PMK (Pair-wise Master Key) is generated, or the PMK is shared by configuring a PSK (Pre-Shared Key), the authenticator will initialize a 4-way handshake protocol to confirm the possession of PMK in both parties and derive a fresh PTK (Pair-wise Transient Key) for the session. On the other hand, the supplicant could also request the authenticator to initilize the handshakes. First some notations are listed: S represents supplicant and A represents authenticator; SPA and AA represent the MAC address of the supplicant and authenticator respectively; PTK is calculated from PRF(PMK, "Pairwise key expansion", AA||SPA||ANonce||SNonce) and splitted to KCK (Key Confirmation Key), KEK (Key Encryption Key) and TK (temporary key); MIC{.}PTK represents the Message Integrity Code calculated with the PTK, actually it is calculated with KCK, but here we won't distinguish KCK and PTK because we only consider the authentication process, and there is no confusion among KCK, KEK and TK. The idealized 4-way handshake protocol can be described as follows: A -> S: AA, ANonce, Sequence(n), msg1 S -> A: SPA, SNonce, Sequence(n), msg2, MIC{SNonce, Sequence(n), msg2}PTK A -> S: AA, ANonce, Sequence(n+1), msg3, MIC(ANonce, Sequence(n+1), msg3}PTK S -> A: SPA, Sequence(n+1), msg4, MIC{Sequence(n+1), msg4}PTK Note that in the original protocol, there are RSNIE fields included in msg2 and msg3, and encrypted GTK (Group Transient Key) fields in msg3, we omit them here because they are not functional in the separate 4-way handshake protocol. After the 4-way handshake protocol, both the authenticator and the supplicant should share a fresh PTK for the current session, and use this PTK to encrypt unicase data transmission or transmit GTK securely for multicast data transmission. 2. Objectives IEEE 802.11i is a quite new standard which is approved in October 2003, there is no analysis on this protocl until now. In this project, we want to analyze the protocl with Murphi, make clear the functionality of each field and find out the possible attacks which cause the authentication process to fail. Note that here the secrecy is not a problem because we assume PMK is shared between the authenticator and supplicant and it is never transmitted over networks. 3. Murphi Models There are three entities in the Murphi modelling, the authenticator, the supplicant and the intruder. The authenticator and the supplicant act according to the protocol, the intruder can intecept, store and replay each message, it can learn the nonce and MIC in each message, it can forge msg1 from known nonces, and it can responds to every message with the arbitrary combination of known nonces and MICs. Each pair of authenticator and supplicants share a secret PMK, and they can execute several sequential 4-way handshake sessions. In order to make clear the functionality of Address, Nonce, Sequence and mtype, i start from the simplest version of protocol, which includes only nonces and MICs in the message: A -> S: ANonce S -> A: SNonce, MIC{SNonce}PTK A -> S: ANonce, MIC(ANonce}PTK S -> A: MIC{}PTK Easily Murphi finds out the attacks that using MICs from msg2 and msg3 to forge msg4, using msg2 to forge msg3 or vice versa because msg2 and msg3 are indistinguable. Based on these, we can conclude we should include message type in each message and make them unchangable, say, calculate MIC over mtype, the improved version of protocol are as follows: A -> S: ANonce, msg1 S -> A: SNonce, msg2, MIC{SNonce, msg2}PTK A -> S: ANonce, msg3, MIC(ANonce, msg3}PTK S -> A: msg4, MIC{msg4}PTK Surprisingly, this version of protocol achieves our objectives. The address and sequence fields are redundant in the separate 4-way handshake protocol. However, they are useful when we consider the whole 802.11i authentication process. The sequence field is useful to prevent replay attacks in the group key handshake protocols following the 4-way handshake protocol. The address field can bind the PTK to the specific stations. Nonce generation plays the essential role in this protocol, therefore i want to find out the requirements on the nonces. i improve the intruder's ability to predict the future nonces and ask the supplicant to pre-compute the MIC for that nonce, and i permit the overlap of nonce spaces in the authenticator and the supplicant, Murphi find out the typical pre-computation attacks. This gives us the idea that the nonce among all parties should be unpredictable or globally unique. After checking the proposed scheme for nonce generation in the standard, these requirements are satisfied with a high probability. Furthermore, Murphi finds out a DoS attack of msg1 in both our achieved protocol and the original complete protocol, which will cause the protocol to fail and no data transmission is possible. I will describe this in details later. 4. DoS attacks Because msg1 is forgeable by any device in the network, the intruder can compose and send msg1 to the supplicant again and again, which will cause PTK inconsistancy between the authenticator and the supplicant. In order to deal with this, the standard proposes a solution by using TPTK and PTK instead of the single PTK. The supplicant only change its PTK after it receives a valid msg3. This fix the attacks that the intruder send msg1 after msg4 is sent from the supplicant to the authenticator, but it fails when the intruder send msg1 to the supplicant after the supplicant send out msg2. There are several ways to fix this problem. The easiest way is, the supplicant keeps all the states, but this might cause a memory exhaustion. This is a problem because it is so easy for the intruder to flood msg1, though the supplicant is not a heavy-loaded server. We can also include both Anonce and Snonce in msg3, then the supplicant need not keep all the states, but with this way we need to change the format of the packet, which might cause compatibility problem. Finally, because this is very similar to the well-known SYN flooding attacks, we can also adopt the strategies of defensing SYN flooding attacks to solve the problem here. 5. Conclusions The 4-way handshake protocol is well-designed and achieve the objectives, some fields (Address and sequence) are not necessary for the separate subprotocol but is useful in the whole authentication process. DoS attacks on msg1 always exist, just like SYN flooding attacks, we can adopt several ways to fix it.