Sur ce coup là, je ne suis pas en avance… Mais quelle idée de sortir un article en début d’un week-end de 4 jours ? 
Je ne vais pas revenir sur les détails, l’article est très bien fait, et vous avez l’explication en français par Sid également.
Pour les conclusions, on peut dire ça : C’est pas encore la fin, mais ça sent pas bon. Donc, oubliez TKIP pour les déploiements Wi-Fi.
Néanmoins, je vais m’attarder un peu sur les contre-mesures. Les auteurs disent dans l’article :
« To prevent this attack, we suggest using a very short rekeying time, for example 120 seconds or less. In 120 seconds, the attacker can only decrypt parts of the ICV value at the end of a packet. Alternatively disabling the sending of MIC failure report frame frames on the clients would also prevent the attack. The best solution would be disabling TKIP and using a CCMP only network. »
Le deuxième point est le plus évident : désactiver TKIP et mettre en œuvre uniquement CCMP. Malheureusement, tous les clients sans fil en entreprise ne parlent pas encore AES-CCMP couramment. Donc, il va falloir trouver une solution… Le premier point va dans ce sens en proposant de diminuer le temps de rotation des clés de sessions.
Mouais, dans la théorie, c’est pas une mauvaise idée. Mais quelques problèmes à l’horizon : ajout de charge de traitement au point d’accès et le comportement des client sans fil va s’en retrouver modifié. C’est pas vraiment la meilleure solution. De plus qu'il faut faire attention aux conseils que l’ont peut trouver... Par exemple, le CERTA, dans son dernier bulletin d'actualité, dit : « Les points d’accès de type Aruba ("timer mkey-rotation-period") et Cisco ("broadcast-key change", "devshell dot1xUpdateBroadcastRekeyTimer") permettent par exemple de modifier ce paramètre. ». Pour la commande ArubaOS citée, elle ne concerne que les trames multicast. Ainsi, il est nécessaire d’utiliser également « timer ukey-rotation-period <nSeconds> » pour les unicast. Pour la commande Cisco, dans le Cisco Response to TKIP Encryption Weakness, il y est indiqué d’utiliser la commande « dot1x timeout reauth-period <nSeconds> » pour les bornes lourdes et « config wlan session-timeout <wlanID> <nSeconds> » pour une architecture en borne légère. Quoi qu’il en soit, avant de faire une modification sur votre architecture, valider avec votre intégrateur pour éviter que l’infrastructure sans fil s’écroule…
Personnellement, si la désactivation de TKIP est impossible, je pencherai pour une surveillance du réseau sans fil à l’aide de WIDS ou tout simplement les logs (parfois les SNMP Trap selon les éditeurs). En effet, l’attaque est bruyante et provoque des erreurs rares (MIC Failure).
On peut également noter que cette faille aura eu le mérite de faire comprendre que WPA, WPA2, TKIP et AES-CCMP se conjuguent à tous les temps : hé oui, WPA2/TKIP ça existe et WPA/AES-CCMP aussi. Autre point, maintenant tout le monde sait que RC4 est à AES ce que CCMP est à TKIP ! C’est beau le marketing : dans un des deux modes, on ne nomme pas l’algorithme de chiffrement, dans l’autre si
C’est certain, suite aux déboires du WEP, mettre RC4 dans le nom du truc qui protège, ça donne pas confiance :D
M’enfin, pour ceux qui n'ont vraiment pas le choix, y'a toujours aussi la possibilité d'ajouter une couche VPN (ou alors tirer un câble).