actuellement je cherche une bonne doc expliquant la manière dont sont
renégociées
les clés, dans le cas de TKIP : quelles trames sont envoyées, etc.
J'ai un peu cherché sur le net, mais sans succès. J'ai fait des
captures de trafic
également, en cherchant les N x 10000e paquets émis par une station,
mais je n'ai
rien trouvé de spécial.
Visiblement la nouvelle TK n'est pas échangée entre la STA et l'AP
via 802.1x.
Dans la norme 802.11i, je n'ai pas trouvé mon bonheur non plus.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Cedric Blancher
Le Wed, 05 Jul 2006 13:16:10 +0000, guillaume.leconte a écrit :
actuellement je cherche une bonne doc expliquant la manière dont sont renégociées les clés, dans le cas de TKIP
Il n'y a pas de renégociation de clé en WPA/WPA2 sauf en cas de roaming. Une fois la PMKSA établies à l'issu de l'authentification 802.1x, on va établir une PTKSA qui ne sera jamais renégociée. De fait, on ne renégocie pas la PTK. Le seul moyen (hors roaming) est de casser la PMKSA et donc de repasser à l'authentification 802.1x. Ceci peut-être fait aussi bien par le client que par l'AP. Mais dans la pratique, le client ne casse jamais une PMKSA s'il a envie de rester. c'est l'AP qui casse en fonction du session-timeout renvoyé par le RADIUS à la suite de l'authentification.
Je disais sauf en cas de roaming. Parce qu'en cas de roaming, on peut mettre en place du PMK Caching qui permet au client de conserver la même PMK sur l'ensemble des APs de l'ESS. Quand il change d'AP, il garde la même PMKSA, mais renégocie une PTKSA avec le nouvelle AP, ce qui induit un renouvellement de PTK, donc de toutes les clés (chiffrement+MIC).
Désolé si je ne précise pas plus les messages, mais ça devrait t'éviter de chercher des trucs qui n'ont pas lieu.
Le dernier truc qui est renouvelable, c'est la GTK. La GTKSA est renégociée systématiquement à chaque fois qu'un client se désassocie et peut aussi être fonction d'un timeout géré par l'AP, puisque c'est lui qui a la main sur la GTK (normal).
My 0.02¤...
Et bonne chance à l'équipe de France pour samedi :)
-- BOFH excuse #333:
A plumber is needed, the network drain is clogged
Le Wed, 05 Jul 2006 13:16:10 +0000, guillaume.leconte a écrit :
actuellement je cherche une bonne doc expliquant la manière dont sont
renégociées les clés, dans le cas de TKIP
Il n'y a pas de renégociation de clé en WPA/WPA2 sauf en cas de roaming.
Une fois la PMKSA établies à l'issu de l'authentification 802.1x, on va
établir une PTKSA qui ne sera jamais renégociée. De fait, on ne
renégocie pas la PTK.
Le seul moyen (hors roaming) est de casser la PMKSA et donc de repasser à
l'authentification 802.1x. Ceci peut-être fait aussi bien par le client
que par l'AP. Mais dans la pratique, le client ne casse jamais une PMKSA
s'il a envie de rester. c'est l'AP qui casse en fonction du
session-timeout renvoyé par le RADIUS à la suite de l'authentification.
Je disais sauf en cas de roaming. Parce qu'en cas de roaming, on peut
mettre en place du PMK Caching qui permet au client de conserver la même
PMK sur l'ensemble des APs de l'ESS. Quand il change d'AP, il garde la
même PMKSA, mais renégocie une PTKSA avec le nouvelle AP, ce qui induit
un renouvellement de PTK, donc de toutes les clés (chiffrement+MIC).
Désolé si je ne précise pas plus les messages, mais ça devrait
t'éviter de chercher des trucs qui n'ont pas lieu.
Le dernier truc qui est renouvelable, c'est la GTK. La GTKSA est
renégociée systématiquement à chaque fois qu'un client se désassocie
et peut aussi être fonction d'un timeout géré par l'AP, puisque c'est
lui qui a la main sur la GTK (normal).
My 0.02¤...
Et bonne chance à l'équipe de France pour samedi :)
Le Wed, 05 Jul 2006 13:16:10 +0000, guillaume.leconte a écrit :
actuellement je cherche une bonne doc expliquant la manière dont sont renégociées les clés, dans le cas de TKIP
Il n'y a pas de renégociation de clé en WPA/WPA2 sauf en cas de roaming. Une fois la PMKSA établies à l'issu de l'authentification 802.1x, on va établir une PTKSA qui ne sera jamais renégociée. De fait, on ne renégocie pas la PTK. Le seul moyen (hors roaming) est de casser la PMKSA et donc de repasser à l'authentification 802.1x. Ceci peut-être fait aussi bien par le client que par l'AP. Mais dans la pratique, le client ne casse jamais une PMKSA s'il a envie de rester. c'est l'AP qui casse en fonction du session-timeout renvoyé par le RADIUS à la suite de l'authentification.
Je disais sauf en cas de roaming. Parce qu'en cas de roaming, on peut mettre en place du PMK Caching qui permet au client de conserver la même PMK sur l'ensemble des APs de l'ESS. Quand il change d'AP, il garde la même PMKSA, mais renégocie une PTKSA avec le nouvelle AP, ce qui induit un renouvellement de PTK, donc de toutes les clés (chiffrement+MIC).
Désolé si je ne précise pas plus les messages, mais ça devrait t'éviter de chercher des trucs qui n'ont pas lieu.
Le dernier truc qui est renouvelable, c'est la GTK. La GTKSA est renégociée systématiquement à chaque fois qu'un client se désassocie et peut aussi être fonction d'un timeout géré par l'AP, puisque c'est lui qui a la main sur la GTK (normal).
My 0.02¤...
Et bonne chance à l'équipe de France pour samedi :)
-- BOFH excuse #333:
A plumber is needed, the network drain is clogged
guillaume.leconte
Bonjour,
[...]
merci pour cet éclairage.
Ceci dit j'ai l'impression de ne pas avoir compris quelque chose, tu m'arrêtes si je me trompe :)
- les TK sont associées à des IV sur 16 bits, dans le cas de WPA/TKIP.
- donc au pire tous les 2^16 messages on doit changer de TK pour éviter les collisions et de compromettre la sécurité de RC4, non ?
- Il me semblait donc avoir compris qu'il est nécessaire de changer les TK via des messages de "rekeying" entre AP et STA, permettant de dériver des nouvelles TK (le tout, protégé avec les KEK). Faux ?
J'ai cherché vite fait dans les sources de madwifi-ng, mais sans succès.
Guillaume.
PS : je souhaite bonne chance aux Bleus pour dimanche, moi :)
Bonjour,
[...]
merci pour cet éclairage.
Ceci dit j'ai l'impression de ne pas avoir compris quelque chose, tu
m'arrêtes si je me trompe :)
- les TK sont associées à des IV sur 16 bits, dans le cas de
WPA/TKIP.
- donc au pire tous les 2^16 messages on doit changer de TK pour
éviter les collisions et de compromettre la sécurité de RC4, non ?
- Il me semblait donc avoir compris qu'il est nécessaire de changer
les TK via des messages de "rekeying" entre AP et STA, permettant
de dériver des nouvelles TK (le tout, protégé avec les KEK). Faux ?
J'ai cherché vite fait dans les sources de madwifi-ng, mais sans
succès.
Guillaume.
PS : je souhaite bonne chance aux Bleus pour dimanche, moi :)
Ceci dit j'ai l'impression de ne pas avoir compris quelque chose, tu m'arrêtes si je me trompe :)
- les TK sont associées à des IV sur 16 bits, dans le cas de WPA/TKIP.
- donc au pire tous les 2^16 messages on doit changer de TK pour éviter les collisions et de compromettre la sécurité de RC4, non ?
- Il me semblait donc avoir compris qu'il est nécessaire de changer les TK via des messages de "rekeying" entre AP et STA, permettant de dériver des nouvelles TK (le tout, protégé avec les KEK). Faux ?
J'ai cherché vite fait dans les sources de madwifi-ng, mais sans succès.
Guillaume.
PS : je souhaite bonne chance aux Bleus pour dimanche, moi :)
Cedric Blancher
Le Thu, 06 Jul 2006 12:08:49 +0000, guillaume.leconte a écrit :
- les TK sont associées à des IV sur 16 bits, dans le cas de WPA/TKIP.
Non, 48. L'Extended IV fait 48 bits, et l'épuisement de cet espace de valeur est une condition d'arrêt à la PMKSA. Ceci étant, 2^48, ça fait du monde...
- Il me semblait donc avoir compris qu'il est nécessaire de changer les TK via des messages de "rekeying" entre AP et STA, permettant de dériver des nouvelles TK (le tout, protégé avec les KEK). Faux ?
J'ai bien cherché, mais dans 802.11i, il n'y a pas de contrainte temporelle sur la PTKSA. Seule la PMKSA en possède, qu'on peut régler comme on veut au niveau d'un RADIUS. Je pense que pour le mode PSK, ils ont considéré que ce n'était pas important dans le cadre où il est utilisé.
J'ai cherché vite fait dans les sources de madwifi-ng, mais sans succès.
Je pense qu'il faut plutôt regarder du côté de hostapd/wpa_supplicant...
Et oui, c'est dimanche, pas samedi ;)
--
http://www.aixcomputers.com Jamais rien lu de plus con excepté une notice de magnétoscope.
-+- JdC in GNU : Quatres têtes hi-fi stéréo et toujours aussi con -+-
Le Thu, 06 Jul 2006 12:08:49 +0000, guillaume.leconte a écrit :
- les TK sont associées à des IV sur 16 bits, dans le cas de
WPA/TKIP.
Non, 48. L'Extended IV fait 48 bits, et l'épuisement de cet espace de
valeur est une condition d'arrêt à la PMKSA. Ceci étant, 2^48, ça fait
du monde...
- Il me semblait donc avoir compris qu'il est nécessaire de changer les
TK via des messages de "rekeying" entre AP et STA, permettant de
dériver des nouvelles TK (le tout, protégé avec les KEK). Faux ?
J'ai bien cherché, mais dans 802.11i, il n'y a pas de contrainte
temporelle sur la PTKSA. Seule la PMKSA en possède, qu'on peut régler
comme on veut au niveau d'un RADIUS. Je pense que pour le mode PSK, ils
ont considéré que ce n'était pas important dans le cadre où il est
utilisé.
J'ai cherché vite fait dans les sources de madwifi-ng, mais sans
succès.
Je pense qu'il faut plutôt regarder du côté de hostapd/wpa_supplicant...
Et oui, c'est dimanche, pas samedi ;)
--
http://www.aixcomputers.com
Jamais rien lu de plus con excepté une notice de magnétoscope.
-+- JdC in GNU : Quatres têtes hi-fi stéréo et toujours aussi con -+-
Le Thu, 06 Jul 2006 12:08:49 +0000, guillaume.leconte a écrit :
- les TK sont associées à des IV sur 16 bits, dans le cas de WPA/TKIP.
Non, 48. L'Extended IV fait 48 bits, et l'épuisement de cet espace de valeur est une condition d'arrêt à la PMKSA. Ceci étant, 2^48, ça fait du monde...
- Il me semblait donc avoir compris qu'il est nécessaire de changer les TK via des messages de "rekeying" entre AP et STA, permettant de dériver des nouvelles TK (le tout, protégé avec les KEK). Faux ?
J'ai bien cherché, mais dans 802.11i, il n'y a pas de contrainte temporelle sur la PTKSA. Seule la PMKSA en possède, qu'on peut régler comme on veut au niveau d'un RADIUS. Je pense que pour le mode PSK, ils ont considéré que ce n'était pas important dans le cadre où il est utilisé.
J'ai cherché vite fait dans les sources de madwifi-ng, mais sans succès.
Je pense qu'il faut plutôt regarder du côté de hostapd/wpa_supplicant...
Et oui, c'est dimanche, pas samedi ;)
--
http://www.aixcomputers.com Jamais rien lu de plus con excepté une notice de magnétoscope.
-+- JdC in GNU : Quatres têtes hi-fi stéréo et toujours aussi con -+-
guillaume.leconte
Salut,
- les TK sont associées à des IV sur 16 bits, dans le cas de WPA/TKIP.
Non, 48. L'Extended IV fait 48 bits, et l'épuisement de cet espace de valeur est une condition d'arrêt à la PMKSA. Ceci étant, 2^48, ça fait du monde...
Ok l'Ext IV fait 48 bits, mais 32+16 bits, et il me semble que ces 16 bits sont utilisés conjointement avec les TK. Je viens de trouver un document intéressant qui semble aller dans mon sens. Sur http://cache-www.intel.com/cd/00/00/01/77/17769_80211_part2.pdf je lis : "Previously we observed that WEP IVs can never be reused with the same key without voiding the RC4 privacy guarantees, and that the TKIP key mixing function can construct at most 2^16 IVs. This implies that TKIP requires a key-update mechanism operating at least every 2^16 packets."
Bon après, peut-être que le monsieur se trompe, dans son document, j'avoue que plus je me renseigne, moins ça semble clair.
- Il me semblait donc avoir compris qu'il est nécessaire de changer les TK via des messages de "rekeying" entre AP et STA, permettant de dériver des nouvelles TK (le tout, protégé avec les KEK). Faux ?
J'ai bien cherché, mais dans 802.11i, il n'y a pas de contrainte temporelle sur la PTKSA. Seule la PMKSA en possède, qu'on peut régler comme on veut au niveau d'un RADIUS. Je pense que pour le mode PSK, ils ont considéré que ce n'était pas important dans le cadre où il est utilisé.
Ben même en PSK on doit changer les clés (TK, pas PMK/PTK) via TKIP de manière régulière pourtant, non ? Dans la norme j'ai pas trouvé grand chose, mais il semble communément admis que la rotation doit se faire tous les 10k paquets. (même si ça reste paramétrable).
J'ai cherché vite fait dans les sources de madwifi-ng, mais sans succès.
Je pense qu'il faut plutôt regarder du côté de hostapd/wpa_supplicant...
En effet, c'est plus judicieux, merci :)
Bon week end.
Guillaume.
Salut,
- les TK sont associées à des IV sur 16 bits, dans le cas de
WPA/TKIP.
Non, 48. L'Extended IV fait 48 bits, et l'épuisement de cet espace de
valeur est une condition d'arrêt à la PMKSA. Ceci étant, 2^48, ça fait
du monde...
Ok l'Ext IV fait 48 bits, mais 32+16 bits, et il me semble que ces 16
bits
sont utilisés conjointement avec les TK.
Je viens de trouver un document intéressant qui semble aller dans mon
sens. Sur
http://cache-www.intel.com/cd/00/00/01/77/17769_80211_part2.pdf
je lis :
"Previously we observed that WEP IVs can never be reused with the same
key without voiding the RC4 privacy guarantees, and that the TKIP key
mixing function can construct at most 2^16 IVs. This implies that TKIP
requires a key-update mechanism operating at least every 2^16 packets."
Bon après, peut-être que le monsieur se trompe, dans son document,
j'avoue que plus je me renseigne, moins ça semble clair.
- Il me semblait donc avoir compris qu'il est nécessaire de changer les
TK via des messages de "rekeying" entre AP et STA, permettant de
dériver des nouvelles TK (le tout, protégé avec les KEK). Faux ?
J'ai bien cherché, mais dans 802.11i, il n'y a pas de contrainte
temporelle sur la PTKSA. Seule la PMKSA en possède, qu'on peut régler
comme on veut au niveau d'un RADIUS. Je pense que pour le mode PSK, ils
ont considéré que ce n'était pas important dans le cadre où il est
utilisé.
Ben même en PSK on doit changer les clés (TK, pas PMK/PTK) via TKIP
de manière régulière pourtant, non ? Dans la norme j'ai pas trouvé
grand
chose, mais il semble communément admis que la rotation doit se faire
tous les 10k paquets. (même si ça reste paramétrable).
J'ai cherché vite fait dans les sources de madwifi-ng, mais sans
succès.
Je pense qu'il faut plutôt regarder du côté de hostapd/wpa_supplicant...
- les TK sont associées à des IV sur 16 bits, dans le cas de WPA/TKIP.
Non, 48. L'Extended IV fait 48 bits, et l'épuisement de cet espace de valeur est une condition d'arrêt à la PMKSA. Ceci étant, 2^48, ça fait du monde...
Ok l'Ext IV fait 48 bits, mais 32+16 bits, et il me semble que ces 16 bits sont utilisés conjointement avec les TK. Je viens de trouver un document intéressant qui semble aller dans mon sens. Sur http://cache-www.intel.com/cd/00/00/01/77/17769_80211_part2.pdf je lis : "Previously we observed that WEP IVs can never be reused with the same key without voiding the RC4 privacy guarantees, and that the TKIP key mixing function can construct at most 2^16 IVs. This implies that TKIP requires a key-update mechanism operating at least every 2^16 packets."
Bon après, peut-être que le monsieur se trompe, dans son document, j'avoue que plus je me renseigne, moins ça semble clair.
- Il me semblait donc avoir compris qu'il est nécessaire de changer les TK via des messages de "rekeying" entre AP et STA, permettant de dériver des nouvelles TK (le tout, protégé avec les KEK). Faux ?
J'ai bien cherché, mais dans 802.11i, il n'y a pas de contrainte temporelle sur la PTKSA. Seule la PMKSA en possède, qu'on peut régler comme on veut au niveau d'un RADIUS. Je pense que pour le mode PSK, ils ont considéré que ce n'était pas important dans le cadre où il est utilisé.
Ben même en PSK on doit changer les clés (TK, pas PMK/PTK) via TKIP de manière régulière pourtant, non ? Dans la norme j'ai pas trouvé grand chose, mais il semble communément admis que la rotation doit se faire tous les 10k paquets. (même si ça reste paramétrable).
J'ai cherché vite fait dans les sources de madwifi-ng, mais sans succès.
Je pense qu'il faut plutôt regarder du côté de hostapd/wpa_supplicant...
En effet, c'est plus judicieux, merci :)
Bon week end.
Guillaume.
Cedric Blancher
Le Fri, 07 Jul 2006 22:34:21 +0000, guillaume.leconte a écrit :
Ok l'Ext IV fait 48 bits, mais 32+16 bits, et il me semble que ces 16 bits sont utilisés conjointement avec les TK.
La production d'une PPK par TKIP se fait en deux phases. La première utilise les 32 premiers bits (poids fort) de l'ExtIV, et la seconde les 16 derniers (poids faible).
Bon après, peut-être que le monsieur se trompe, dans son document, j'avoue que plus je me renseigne, moins ça semble clair.
Le monsieur ne doit se tromper, Jesse Walker est... comment dire... une référence dans le domaine. Par contre, j'avoue que la lecture de son document me laisse un doute sur les clés dont il parle. De plus, même 802.11i reste assez vague sur ce dont il parle, en particulier la fameuse TA :)
Ben même en PSK on doit changer les clés (TK, pas PMK/PTK) via TKIP de manière régulière pourtant, non ? Dans la norme j'ai pas trouvé grand chose, mais il semble communément admis que la rotation doit se faire tous les 10k paquets. (même si ça reste paramétrable).
Le but de TKIP _est_ de faire tourner des clés, d'où le Temporal de l'acronyme.
La question est très intéressante. Je vais creuser.
-- Lu sur alt.france : Peut-on installer Win 95 par dessus win 95 tout en gardant les differents données des logiciels fonctionnant auparavant sur wwin 95 ? -+- JMT in : Guide du neuneu d'Usenet - Neuneu persiste et signe -+-
Le Fri, 07 Jul 2006 22:34:21 +0000, guillaume.leconte a écrit :
Ok l'Ext IV fait 48 bits, mais 32+16 bits, et il me semble que ces 16
bits sont utilisés conjointement avec les TK.
La production d'une PPK par TKIP se fait en deux phases. La première
utilise les 32 premiers bits (poids fort) de l'ExtIV, et la seconde les 16
derniers (poids faible).
Bon après, peut-être que le monsieur se trompe, dans son document,
j'avoue que plus je me renseigne, moins ça semble clair.
Le monsieur ne doit se tromper, Jesse Walker est... comment dire... une
référence dans le domaine. Par contre, j'avoue que la lecture de son
document me laisse un doute sur les clés dont il parle. De plus, même
802.11i reste assez vague sur ce dont il parle, en particulier la fameuse
TA :)
Ben même en PSK on doit changer les clés (TK, pas PMK/PTK) via TKIP de
manière régulière pourtant, non ? Dans la norme j'ai pas trouvé
grand chose, mais il semble communément admis que la rotation doit se
faire tous les 10k paquets. (même si ça reste paramétrable).
Le but de TKIP _est_ de faire tourner des clés, d'où le Temporal de
l'acronyme.
La question est très intéressante. Je vais creuser.
--
Lu sur alt.france :
Peut-on installer Win 95 par dessus win 95 tout en gardant les
differents données des logiciels fonctionnant auparavant sur wwin 95 ?
-+- JMT in : Guide du neuneu d'Usenet - Neuneu persiste et signe -+-
Le Fri, 07 Jul 2006 22:34:21 +0000, guillaume.leconte a écrit :
Ok l'Ext IV fait 48 bits, mais 32+16 bits, et il me semble que ces 16 bits sont utilisés conjointement avec les TK.
La production d'une PPK par TKIP se fait en deux phases. La première utilise les 32 premiers bits (poids fort) de l'ExtIV, et la seconde les 16 derniers (poids faible).
Bon après, peut-être que le monsieur se trompe, dans son document, j'avoue que plus je me renseigne, moins ça semble clair.
Le monsieur ne doit se tromper, Jesse Walker est... comment dire... une référence dans le domaine. Par contre, j'avoue que la lecture de son document me laisse un doute sur les clés dont il parle. De plus, même 802.11i reste assez vague sur ce dont il parle, en particulier la fameuse TA :)
Ben même en PSK on doit changer les clés (TK, pas PMK/PTK) via TKIP de manière régulière pourtant, non ? Dans la norme j'ai pas trouvé grand chose, mais il semble communément admis que la rotation doit se faire tous les 10k paquets. (même si ça reste paramétrable).
Le but de TKIP _est_ de faire tourner des clés, d'où le Temporal de l'acronyme.
La question est très intéressante. Je vais creuser.
-- Lu sur alt.france : Peut-on installer Win 95 par dessus win 95 tout en gardant les differents données des logiciels fonctionnant auparavant sur wwin 95 ? -+- JMT in : Guide du neuneu d'Usenet - Neuneu persiste et signe -+-
