On Tue, May 13, 2008 at 11:18:29AM +0300, Emmanuel Grumbach wrote: > the spec of 11n makes the support on AES mandatory, but not TKIP. > Meaning that a NIC can support WPA2 and 11n separately, but not TKIP > in 11n. The RC4 encryption machine has a delay that makes difficult to > encrypt in TKIP (or WEP) in 11n rates. Intel's 11n are such NICs, 11n > + TKIP/WEP is not supported. This is not just a hardware support question; 11n explicitly disallows use of TKIP between HT STAs and this needs to be enforced somewhere. > The problem here is that the association (which can be 11n or not) > occurs before the 4-way handshake. Let's say that I have an AP that > publishes only TKIP in its WPA IE and 11n IE, I can understand that > there is no way I should do 11n association. But what happens with an > AP that publishes TKIP + AES in its RSN IE and 11n IE ? I could > associate in 11n, but then wpa_supplicant might be configured to > associate in TKIP (although the AP support AES), and I would be in an > unsupported mode. In most cases, the pairwise cipher is selected during association, not during 4-way handshake. Consequently, the driver/firmware should refuse to send an (Re)Association Request that requests TKIP as the pairwise cipher when using .11n. In the corner case (which I don't think I have even implemented yet in wpa_supplicant..) the AP/Authenticator could request the STA to use another pairwise cipher if security policy for that specific STA does not allow the pairwise cipher suite that the STA tried to select in (re)association request. In this particular case (should it ever be implemented), it could be useful for wpa_supplicant to know that .11n is used. However, no sane security policy would require TKIP as the pairwise cipher in such a case, so I don't think this is really going to ever happen in real networks and any kind of failure to use the network is suitable end result for such an attempt.. > One solution would be to make wpa_supplicant understand what 11n is, > but that's not it's job. > Another solution would be to make wpa_supplicant tell me that it > intends to use TKIP before asking me to associate. The exact mechanism depends on whether ap_scan=1 or ap_scan=2 is being used, i.e., whether wpa_supplicant is responsible for selecting a BSS from scan results or not. In ap_scan=1, I would say that it would be useful for wpa_supplicant to know whether the BSS (and the local wlan driver/hardware for that matter!) supports .11n. If the scan results indicate this in some reliable way (e.g., all IEs are delivered to wpa_supplicant), the AP's support for 11n can be figured out. The local side support would need to be added, e.g., to driver capabilities reporting. In ap_scaqn=2, wpa_supplicant requests the driver to select a BSS based on configuration (SSID, security policy, including a specific cipher suite), i.e., the driver would be told about TKIP use before association and the driver would be responsible for not trying to use 11n in that case. The corner case of AP/Authenticator requesting another pairwise cipher would still be possible here, but not really something that I would consider a real problem that needs to be solved. -- Jouni Malinen PGP id EFC895FA -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
