J'ai une borne Cisco avec deux VLAN/SSID (l'un en WEP/EAP, l'autre en
WPA/EAP), et un serveur RADIUS sur en machine relié a la borne en
Ethernet.
En me connectant au VLAN WPA, une fois l'autentification MD5 ou MSCHAPV2
finie, la borne envoie des trames EAPOL or il me semblait que ces
protocoles n'etaient pas utilisables pour du 802.1X (pas de gestion de
clé). Comment se fait-il ?
Sur le VLAN Wep, aucune trames EAPOL apres l'authentification avec ces 2
protocoles alors qu'il envoie bien les trames EAPOL si j'utilise LEAP
(qui lui permet le 802.1X).
C'est donc comme si en WPA la borne n'etait pas capable de voir si le
protocole EAP utilisé permet le 802.1X, alors qu'elle a un comportement
"normal" sur un VLAN WEP.
Une explication ?
J'ai une borne Cisco avec deux VLAN/SSID (l'un en WEP/EAP, l'autre en
WPA/EAP), et un serveur RADIUS sur en machine relié a la borne en
Ethernet.
En me connectant au VLAN WPA, une fois l'autentification MD5 ou MSCHAPV2
finie, la borne envoie des trames EAPOL or il me semblait que ces
protocoles n'etaient pas utilisables pour du 802.1X (pas de gestion de
clé). Comment se fait-il ?
Sur le VLAN Wep, aucune trames EAPOL apres l'authentification avec ces 2
protocoles alors qu'il envoie bien les trames EAPOL si j'utilise LEAP
(qui lui permet le 802.1X).
C'est donc comme si en WPA la borne n'etait pas capable de voir si le
protocole EAP utilisé permet le 802.1X, alors qu'elle a un comportement
"normal" sur un VLAN WEP.
Une explication ?
J'ai une borne Cisco avec deux VLAN/SSID (l'un en WEP/EAP, l'autre en
WPA/EAP), et un serveur RADIUS sur en machine relié a la borne en
Ethernet.
En me connectant au VLAN WPA, une fois l'autentification MD5 ou MSCHAPV2
finie, la borne envoie des trames EAPOL or il me semblait que ces
protocoles n'etaient pas utilisables pour du 802.1X (pas de gestion de
clé). Comment se fait-il ?
Sur le VLAN Wep, aucune trames EAPOL apres l'authentification avec ces 2
protocoles alors qu'il envoie bien les trames EAPOL si j'utilise LEAP
(qui lui permet le 802.1X).
C'est donc comme si en WPA la borne n'etait pas capable de voir si le
protocole EAP utilisé permet le 802.1X, alors qu'elle a un comportement
"normal" sur un VLAN WEP.
Une explication ?
J'ai une borne Cisco avec deux VLAN/SSID (l'un en WEP/EAP, l'autre en
WPA/EAP), et un serveur RADIUS sur en machine relié a la borne en
Ethernet.
En me connectant au VLAN WPA, une fois l'autentification MD5 ou
MSCHAPV2 finie, la borne envoie des trames EAPOL or il me semblait
que ces protocoles n'etaient pas utilisables pour du 802.1X (pas de
gestion de clé). Comment se fait-il ?
EAPOL = 802.1X. Aussi bien l'authentification que l'envoi des clefs se
fait dans des trames EAPOL. Maintenant, effectivement, on ne peut pas
utiliser MD5 pour dériver des clefs de session (en plus du fait que
ce protocole est d'une faiblesse extrême).
De mémoire MSCHAPV2 le permet.
Sur le VLAN Wep, aucune trames EAPOL apres l'authentification avec
ces 2 protocoles alors qu'il envoie bien les trames EAPOL si
j'utilise LEAP (qui lui permet le 802.1X).
LEAP n'est pas du 802.1X, même si de loin ça y ressemble. LEAP est
effectué avant l'association,
alors qu'EAPOL est effectué après. Avec
du WEP et 802.1X activé, la première chose que l'AP devrait envoyer
après l'association c'est un EAPOL-Start, après quoi il y a
l'authentification EAP (dans des trames EAPOL aka 802.1X), puis
éventuellement transmission des clefs.
Je ne comprends pas comment un "protocole EAP permet le 802.1X",
puisqu'EAP est transporté par 802.1X. Donc j'ai du mal à saisir le
reste de la problématique.Une explication ?
Utiliser les bons termes ou revoir ses notions de base sur 802.1X?
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
J'ai une borne Cisco avec deux VLAN/SSID (l'un en WEP/EAP, l'autre en
WPA/EAP), et un serveur RADIUS sur en machine relié a la borne en
Ethernet.
En me connectant au VLAN WPA, une fois l'autentification MD5 ou
MSCHAPV2 finie, la borne envoie des trames EAPOL or il me semblait
que ces protocoles n'etaient pas utilisables pour du 802.1X (pas de
gestion de clé). Comment se fait-il ?
EAPOL = 802.1X. Aussi bien l'authentification que l'envoi des clefs se
fait dans des trames EAPOL. Maintenant, effectivement, on ne peut pas
utiliser MD5 pour dériver des clefs de session (en plus du fait que
ce protocole est d'une faiblesse extrême).
De mémoire MSCHAPV2 le permet.
Sur le VLAN Wep, aucune trames EAPOL apres l'authentification avec
ces 2 protocoles alors qu'il envoie bien les trames EAPOL si
j'utilise LEAP (qui lui permet le 802.1X).
LEAP n'est pas du 802.1X, même si de loin ça y ressemble. LEAP est
effectué avant l'association,
alors qu'EAPOL est effectué après. Avec
du WEP et 802.1X activé, la première chose que l'AP devrait envoyer
après l'association c'est un EAPOL-Start, après quoi il y a
l'authentification EAP (dans des trames EAPOL aka 802.1X), puis
éventuellement transmission des clefs.
Je ne comprends pas comment un "protocole EAP permet le 802.1X",
puisqu'EAP est transporté par 802.1X. Donc j'ai du mal à saisir le
reste de la problématique.
Une explication ?
Utiliser les bons termes ou revoir ses notions de base sur 802.1X?
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
J'ai une borne Cisco avec deux VLAN/SSID (l'un en WEP/EAP, l'autre en
WPA/EAP), et un serveur RADIUS sur en machine relié a la borne en
Ethernet.
En me connectant au VLAN WPA, une fois l'autentification MD5 ou
MSCHAPV2 finie, la borne envoie des trames EAPOL or il me semblait
que ces protocoles n'etaient pas utilisables pour du 802.1X (pas de
gestion de clé). Comment se fait-il ?
EAPOL = 802.1X. Aussi bien l'authentification que l'envoi des clefs se
fait dans des trames EAPOL. Maintenant, effectivement, on ne peut pas
utiliser MD5 pour dériver des clefs de session (en plus du fait que
ce protocole est d'une faiblesse extrême).
De mémoire MSCHAPV2 le permet.
Sur le VLAN Wep, aucune trames EAPOL apres l'authentification avec
ces 2 protocoles alors qu'il envoie bien les trames EAPOL si
j'utilise LEAP (qui lui permet le 802.1X).
LEAP n'est pas du 802.1X, même si de loin ça y ressemble. LEAP est
effectué avant l'association,
alors qu'EAPOL est effectué après. Avec
du WEP et 802.1X activé, la première chose que l'AP devrait envoyer
après l'association c'est un EAPOL-Start, après quoi il y a
l'authentification EAP (dans des trames EAPOL aka 802.1X), puis
éventuellement transmission des clefs.
Je ne comprends pas comment un "protocole EAP permet le 802.1X",
puisqu'EAP est transporté par 802.1X. Donc j'ai du mal à saisir le
reste de la problématique.Une explication ?
Utiliser les bons termes ou revoir ses notions de base sur 802.1X?
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
Pourquoi alors la borne envoi ces trames EAPOL-Key une fois
l'autentification EAP effectuée et pourquoi uniquemement si la borne
utilise WEP (les deux VLAN sont configurés en "Open authentication with
EAP"), alors que MD5 ne permet pas l'echange des clés ?
LEAP n'est pas du 802.1X, même si de loin ça y ressemble. LEAP est
effectué avant l'association,
Heu.. pas avant l'association au sens 801.11 sinon les trames
n'arriveraientt pas.
Pourquoi alors la borne envoi ces trames EAPOL-Key une fois
l'autentification EAP effectuée et pourquoi uniquemement si la borne
utilise WEP (les deux VLAN sont configurés en "Open authentication with
EAP"), alors que MD5 ne permet pas l'echange des clés ?
LEAP n'est pas du 802.1X, même si de loin ça y ressemble. LEAP est
effectué avant l'association,
Heu.. pas avant l'association au sens 801.11 sinon les trames
n'arriveraientt pas.
Pourquoi alors la borne envoi ces trames EAPOL-Key une fois
l'autentification EAP effectuée et pourquoi uniquemement si la borne
utilise WEP (les deux VLAN sont configurés en "Open authentication with
EAP"), alors que MD5 ne permet pas l'echange des clés ?
LEAP n'est pas du 802.1X, même si de loin ça y ressemble. LEAP est
effectué avant l'association,
Heu.. pas avant l'association au sens 801.11 sinon les trames
n'arriveraientt pas.
Pourquoi alors la borne envoi ces trames EAPOL-Key une fois
l'autentification EAP effectuée et pourquoi uniquemement si la borne
utilise WEP (les deux VLAN sont configurés en "Open authentication
with EAP"), alors que MD5 ne permet pas l'echange des clés ?
EAPOL-Key permet de transporter tout plein de clefs, en particulier
les clefs multicast/broadcast. Il faudrait regarder le détail de ce
qui est envoyé, c'est peut-être bêtement un clef multicast envoyée
chiffrée avec la clef WEP configurée statiquement?
Pour WPA j'avoue que je n'ai jamais lu la spec qui doit être quelque
part sur mon disque, donc je ne sais pas comment ça fonctionne en
détail, mais il m'avait semblé comprendre que c'était très similaire
à du 802.1X avec juste quelques modifs au niveau des algos
supportés/utilisés pour le chiffrement et l'intégrité (avec AES,
Michael, TKIP...).LEAP n'est pas du 802.1X, même si de loin ça y ressemble. LEAP est
effectué avant l'association,
Heu.. pas avant l'association au sens 801.11 sinon les trames
n'arriveraientt pas.
Si si, justement, LEAP est implémenté (ou était la dernière fois que
j'ai regardé) comme une méthode d'authentification 802.11 (comme
"open" ou "shared key"), et se fait donc pendant la phase
d'authentification 802.11, qui intervient avant la phase
d'association. Et ce sont des trames 802.11 "pures" (trames de
management), pas de l'Ethernet encapsulé dans une trame de données
802.11 comme c'est le cas pour 802.1X/EAPOL.
Maintenant si ça se trouve il y a maintenant une version
LEAP-dans-802.1X pour utiliser les back-ends (serveurs RADIUS + bases
d'utilisateurs) compatibles LEAP avec du matériel qui ne supporte que
du 802.1X?
J'ai pas trop suivi l'actualité sur le sujet récemment,
mais ça ma paraîtrait pas très futé, LEAP est connu comme étant
faible.
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
Pourquoi alors la borne envoi ces trames EAPOL-Key une fois
l'autentification EAP effectuée et pourquoi uniquemement si la borne
utilise WEP (les deux VLAN sont configurés en "Open authentication
with EAP"), alors que MD5 ne permet pas l'echange des clés ?
EAPOL-Key permet de transporter tout plein de clefs, en particulier
les clefs multicast/broadcast. Il faudrait regarder le détail de ce
qui est envoyé, c'est peut-être bêtement un clef multicast envoyée
chiffrée avec la clef WEP configurée statiquement?
Pour WPA j'avoue que je n'ai jamais lu la spec qui doit être quelque
part sur mon disque, donc je ne sais pas comment ça fonctionne en
détail, mais il m'avait semblé comprendre que c'était très similaire
à du 802.1X avec juste quelques modifs au niveau des algos
supportés/utilisés pour le chiffrement et l'intégrité (avec AES,
Michael, TKIP...).
LEAP n'est pas du 802.1X, même si de loin ça y ressemble. LEAP est
effectué avant l'association,
Heu.. pas avant l'association au sens 801.11 sinon les trames
n'arriveraientt pas.
Si si, justement, LEAP est implémenté (ou était la dernière fois que
j'ai regardé) comme une méthode d'authentification 802.11 (comme
"open" ou "shared key"), et se fait donc pendant la phase
d'authentification 802.11, qui intervient avant la phase
d'association. Et ce sont des trames 802.11 "pures" (trames de
management), pas de l'Ethernet encapsulé dans une trame de données
802.11 comme c'est le cas pour 802.1X/EAPOL.
Maintenant si ça se trouve il y a maintenant une version
LEAP-dans-802.1X pour utiliser les back-ends (serveurs RADIUS + bases
d'utilisateurs) compatibles LEAP avec du matériel qui ne supporte que
du 802.1X?
J'ai pas trop suivi l'actualité sur le sujet récemment,
mais ça ma paraîtrait pas très futé, LEAP est connu comme étant
faible.
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
Pourquoi alors la borne envoi ces trames EAPOL-Key une fois
l'autentification EAP effectuée et pourquoi uniquemement si la borne
utilise WEP (les deux VLAN sont configurés en "Open authentication
with EAP"), alors que MD5 ne permet pas l'echange des clés ?
EAPOL-Key permet de transporter tout plein de clefs, en particulier
les clefs multicast/broadcast. Il faudrait regarder le détail de ce
qui est envoyé, c'est peut-être bêtement un clef multicast envoyée
chiffrée avec la clef WEP configurée statiquement?
Pour WPA j'avoue que je n'ai jamais lu la spec qui doit être quelque
part sur mon disque, donc je ne sais pas comment ça fonctionne en
détail, mais il m'avait semblé comprendre que c'était très similaire
à du 802.1X avec juste quelques modifs au niveau des algos
supportés/utilisés pour le chiffrement et l'intégrité (avec AES,
Michael, TKIP...).LEAP n'est pas du 802.1X, même si de loin ça y ressemble. LEAP est
effectué avant l'association,
Heu.. pas avant l'association au sens 801.11 sinon les trames
n'arriveraientt pas.
Si si, justement, LEAP est implémenté (ou était la dernière fois que
j'ai regardé) comme une méthode d'authentification 802.11 (comme
"open" ou "shared key"), et se fait donc pendant la phase
d'authentification 802.11, qui intervient avant la phase
d'association. Et ce sont des trames 802.11 "pures" (trames de
management), pas de l'Ethernet encapsulé dans une trame de données
802.11 comme c'est le cas pour 802.1X/EAPOL.
Maintenant si ça se trouve il y a maintenant une version
LEAP-dans-802.1X pour utiliser les back-ends (serveurs RADIUS + bases
d'utilisateurs) compatibles LEAP avec du matériel qui ne supporte que
du 802.1X?
J'ai pas trop suivi l'actualité sur le sujet récemment,
mais ça ma paraîtrait pas très futé, LEAP est connu comme étant
faible.
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
Pourquoi alors la borne envoi ces trames EAPOL-Key une fois
l'autentification EAP effectuée et pourquoi uniquemement si la borne
utilise WEP (les deux VLAN sont configurés en "Open authentication
with EAP"), alors que MD5 ne permet pas l'echange des clés ?
EAPOL-Key permet de transporter tout plein de clefs, en particulier
les clefs multicast/broadcast. Il faudrait regarder le détail de ce
qui est envoyé, c'est peut-être bêtement un clef multicast envoyée
chiffrée avec la clef WEP configurée statiquement?
Pour WPA j'avoue que je n'ai jamais lu la spec qui doit être quelque
part sur mon disque, donc je ne sais pas comment ça fonctionne en
détail, mais il m'avait semblé comprendre que c'était très similaire
à du 802.1X avec juste quelques modifs au niveau des algos
supportés/utilisés pour le chiffrement et l'intégrité (avec AES,
Michael, TKIP...).LEAP n'est pas du 802.1X, même si de loin ça y ressemble. LEAP est
effectué avant l'association,
Heu.. pas avant l'association au sens 801.11 sinon les trames
n'arriveraientt pas.
Si si, justement, LEAP est implémenté (ou était la dernière fois que
j'ai regardé) comme une méthode d'authentification 802.11 (comme
"open" ou "shared key"), et se fait donc pendant la phase
d'authentification 802.11, qui intervient avant la phase
d'association. Et ce sont des trames 802.11 "pures" (trames de
management), pas de l'Ethernet encapsulé dans une trame de données
802.11 comme c'est le cas pour 802.1X/EAPOL.
Maintenant si ça se trouve il y a maintenant une version
LEAP-dans-802.1X pour utiliser les back-ends (serveurs RADIUS + bases
d'utilisateurs) compatibles LEAP avec du matériel qui ne supporte que
du 802.1X?
J'ai pas trop suivi l'actualité sur le sujet récemment, mais ça ma
paraîtrait pas très futé, LEAP est connu comme étant faible.
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
Pourquoi alors la borne envoi ces trames EAPOL-Key une fois
l'autentification EAP effectuée et pourquoi uniquemement si la borne
utilise WEP (les deux VLAN sont configurés en "Open authentication
with EAP"), alors que MD5 ne permet pas l'echange des clés ?
EAPOL-Key permet de transporter tout plein de clefs, en particulier
les clefs multicast/broadcast. Il faudrait regarder le détail de ce
qui est envoyé, c'est peut-être bêtement un clef multicast envoyée
chiffrée avec la clef WEP configurée statiquement?
Pour WPA j'avoue que je n'ai jamais lu la spec qui doit être quelque
part sur mon disque, donc je ne sais pas comment ça fonctionne en
détail, mais il m'avait semblé comprendre que c'était très similaire
à du 802.1X avec juste quelques modifs au niveau des algos
supportés/utilisés pour le chiffrement et l'intégrité (avec AES,
Michael, TKIP...).
LEAP n'est pas du 802.1X, même si de loin ça y ressemble. LEAP est
effectué avant l'association,
Heu.. pas avant l'association au sens 801.11 sinon les trames
n'arriveraientt pas.
Si si, justement, LEAP est implémenté (ou était la dernière fois que
j'ai regardé) comme une méthode d'authentification 802.11 (comme
"open" ou "shared key"), et se fait donc pendant la phase
d'authentification 802.11, qui intervient avant la phase
d'association. Et ce sont des trames 802.11 "pures" (trames de
management), pas de l'Ethernet encapsulé dans une trame de données
802.11 comme c'est le cas pour 802.1X/EAPOL.
Maintenant si ça se trouve il y a maintenant une version
LEAP-dans-802.1X pour utiliser les back-ends (serveurs RADIUS + bases
d'utilisateurs) compatibles LEAP avec du matériel qui ne supporte que
du 802.1X?
J'ai pas trop suivi l'actualité sur le sujet récemment, mais ça ma
paraîtrait pas très futé, LEAP est connu comme étant faible.
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
Pourquoi alors la borne envoi ces trames EAPOL-Key une fois
l'autentification EAP effectuée et pourquoi uniquemement si la borne
utilise WEP (les deux VLAN sont configurés en "Open authentication
with EAP"), alors que MD5 ne permet pas l'echange des clés ?
EAPOL-Key permet de transporter tout plein de clefs, en particulier
les clefs multicast/broadcast. Il faudrait regarder le détail de ce
qui est envoyé, c'est peut-être bêtement un clef multicast envoyée
chiffrée avec la clef WEP configurée statiquement?
Pour WPA j'avoue que je n'ai jamais lu la spec qui doit être quelque
part sur mon disque, donc je ne sais pas comment ça fonctionne en
détail, mais il m'avait semblé comprendre que c'était très similaire
à du 802.1X avec juste quelques modifs au niveau des algos
supportés/utilisés pour le chiffrement et l'intégrité (avec AES,
Michael, TKIP...).LEAP n'est pas du 802.1X, même si de loin ça y ressemble. LEAP est
effectué avant l'association,
Heu.. pas avant l'association au sens 801.11 sinon les trames
n'arriveraientt pas.
Si si, justement, LEAP est implémenté (ou était la dernière fois que
j'ai regardé) comme une méthode d'authentification 802.11 (comme
"open" ou "shared key"), et se fait donc pendant la phase
d'authentification 802.11, qui intervient avant la phase
d'association. Et ce sont des trames 802.11 "pures" (trames de
management), pas de l'Ethernet encapsulé dans une trame de données
802.11 comme c'est le cas pour 802.1X/EAPOL.
Maintenant si ça se trouve il y a maintenant une version
LEAP-dans-802.1X pour utiliser les back-ends (serveurs RADIUS + bases
d'utilisateurs) compatibles LEAP avec du matériel qui ne supporte que
du 802.1X?
J'ai pas trop suivi l'actualité sur le sujet récemment, mais ça ma
paraîtrait pas très futé, LEAP est connu comme étant faible.
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<