WPA2 panel at the GCN/WiFi show

by Matthew Gast


My main reason for attending the GCN/Wi-Fi Alliance show that I wrote about previously is that I was invited to be part of a panel on WPA2. I was joined on the panel by Jim Burns of Meetinghouse Data Communications, who has been extensively involved in the 802.11 and 802.1 working groups. Our moderator was David Cohen of Broadcom, who is also the chair of the Wi-Fi Alliance Security Group. David started off with presentation about WPA2, and then opened the floor to the questions:




Question: How often is the temporal key changed in WPA, and what is the impact of key change messages?

This question was motivated by the presentation, which noted that every frame has a unique key. I answered that the impact of key change messages isn't what it appears to be because of the key hierarchy. Unlike WEP, TKIP and CCMP (WPA & WPA2) take the authentication data and compute keys from it. The authentication exchange derives a "pre-master key," which is the source of all the keys used to encrypt frames. Pre-master keys are used as the basis for deriving "temporal keys" for unicast and broadcast/multicast data with the key handshake messages. The temporal key is combined with sequence numbers and other data to further derive a key used to encrypt the frame. So, there is a unique key used for each frame, but it does not require refreshing the temporal key. The temporal key timeout can be set for whatever you like, and does not need to be set to a short time-out.




Jim pointed out that the per-frame keying is often confused with WEP. Dynamic WEP doesn't have a key hierarchy. The master key is used directly in frame encryption, so it is unprotected from attacks like Fluhrer/Mantin/Shamir. In WEP, the re-key interval is vital. In TKIP and CCMP, it is not required.




Question: How can WPA and WPA2 co-exist?

David noted that most cards have AES support burned into the radio chipset, which enables cards to support either TKIP (WPA) or CCMP (WPA2), and that the standards allow a network to use both encryption types simultaneously.




I added that there's a difference between theory and practice. Although the standard supports using both TKIP and CCMP simultaneously, it does not yet work in practice. In a mixed-encryption network, the broadcast/multicast ("group") key must be the lowest common denominator encryption. If there are CCMP- and TKIP-capable stations, the group key must be TKIP. If you throw dynamic WEP stations into the mix, the group key must be dynamic WEP. Infrastructure devices do support mixing the encryption type. Every client I have yet encountered has one notable exception. All the clients that support WPA are able to mix the RC4-based encryption methods (dynamic WEP and TKIP), but are not yet able to do CCMP for unicast frames while using an RC4-based encryption method for group frames.




David said that support for coexistence would be required in a future Wi-Fi certification test plan.




Question: How is WPA affected by EAP methods, and how can users choose an EAP method?

EAP methods are not formally part of the Wi-Fi Alliance certification test plan, but may be in the future. Right now, users have to know the EAP methods and make the trade-off on their own. Navigating the forest of EAP methods is one of the major areas in which network deployment could be simplified.




After our panel, Jim said that the Wi-Fi Alliance was not a standards body, though they've done a good job of marketing the WPA standards. WPA is a brilliant job of "standards packaging" into a comprehensible, easy-to-look for single checkbox. By incorporating pieces of 802.11i, 802.1X, and several IETF standards, WPA makes it easy for the average user to buy.




Question: Are there FIPS-certified WPA systems?

The short answer is no. I gave the long answer first, and a member of the audience asked a follow up question asking whether I meant yes or no.




FIPS-140 is a tough requirement. The baseline to get in the door for testing is that you need to use an approved algorithm (such as DES or AES), in an approved mode. You wouldn't want systems using good cryptographic algorithms (DES) in weak modes (ECB), after all. 802.11i uses the Counter Mode with CBC-MAC, which was not an approved mode until late May of this year. So, 802.11i-based solutions can now apply for certification because they use the "right stuff."




However, there's a lot more to FIPS than that. It involves a detailed review of coding practices, the architecture of the software, and so on. After a vendor pulls the trigger and decides to FIPS-certify, it takes a significant amount of time. A year from the decision to seek certification is considered fast. I would have expected a FIPS-certified 802.11i system on the market because I assumed that some of the vendors started the certification process before the approval of CCM mode. (For the record, I don't know if this is permissible or not.) I would have to believe we'll see FIPS-certified equipment by this time next year at the latest, but I'd bet even money we get something by next summer.




Question: Is there any way to make the certificate deployment easier?

Jim said that certificate deployment was the weak point of many of the EAP methods in common use (PEAP, TTLS, and EAP-TLS). However, that's the rationale for the development of pre-shared key EAP methods such as EAP-FAST.




On a follow-up, an audience member asked if there was a tool that could automatically generate and deploy certificates. With a great deal of trepidation, I answered that there was. Microsoft's Active Directory can be combined with domain policies to automatically generate and push out a certificate when a machine is joined to the domain. However, this is only useful if you have deployed Active Directory and run a pure Windows environment, which is almost never true in practice. There's usually a little island of MacOS or Unix somewhere.