OVH Cloud OVH Cloud

802.1X et MD5Challenge/MSCHAP

5 réponses
Avatar
Thierry
Bonjour,


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 ?

--
« Le travail est probablement ce qu'il y a sur cette terre de plus bas et
de plus ignoble. Il n'est pas possible de regarder un travailleur sans
maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager,
dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. »
Boris VIAN
>> Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<

5 réponses

Avatar
Jacques Caron
Salut,

On 18 Aug 2005 08:52:55 GMT, Thierry wrote:

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.

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.


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?

Jacques.

Avatar
Thierry
Bonjour,

Jacques Caron a écrit :

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).


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 ?

De mémoire MSCHAPV2 le permet.


Effectivement.

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,


Heu.. pas avant l'association au sens 801.11 sinon les trames
n'arriveraientt pas.

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.


Ok.

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?


Effectivement j'assimilais abusivement 802.1X a l'unique echange des clés
alors qu'il encapsule aussi l'authentification (si besoin). Lire "protocole
EAP permettant l'echange de clé".

--
« Le travail est probablement ce qu'il y a sur cette terre de plus bas et
de plus ignoble. Il n'est pas possible de regarder un travailleur sans
maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager,
dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. »
Boris VIAN
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<




Avatar
Jacques Caron
Salut,

On 30 Aug 2005 10:17:58 GMT, Thierry wrote:

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.

Jacques.


Avatar
Thierry
Bonjour,

Jacques Caron a écrit :

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?


Justement ces trames EAPOL ne sont envoyées que pour le mode WPA, avec le
decriptor type WPA pour la trame EAPOL (contrairement a WEP où le
descriptor key est RC4), or sans master key (hash du SSID et de la
passphase en PSK, ou clé negociée lors de la phase d'authentification EAP
lorsque l'EAP utilisé le permet) impossible d'aller plus loin dans la
negociation des pairwise key et group key.

A moins qu'il y ait un moyen d'obtenir cette master key a partir des params
MD5... Vu la faiblesse de MD5 c'est pas une question essentielle mais ça
m'intrigue.

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.


Je n'ai jamais vu d'adaptateurs permettant cela; faut dire que sous Windows
les specs NDIS relatives au WiFi n'offre pas la possibilité de specifier au
driver quel protocol EAP utiliser ni ses parametres, et qu'on a pas acces
aux trames 802.11. Il y a donc un prog supplicant qui fait le travail, le
tout s'appuyant sur Ethernet.

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?


Je ne connais que ce cas de figure.

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.


Mais pourtant trés utilisé encore apparement.
Si j'ai bien suivi, PEAP est encore a l'etat de draft, et TLS reclame un
deploiement de certificats peut etre trop contraignant.

--
« Le travail est probablement ce qu'il y a sur cette terre de plus bas et
de plus ignoble. Il n'est pas possible de regarder un travailleur sans
maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager,
dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. »
Boris VIAN
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<





Avatar
Thierry
Bonjour,

Jacques Caron a écrit :

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?


Justement ces trames EAPOL ne sont envoyées que pour le mode WPA, avec
le decriptor type WPA pour la trame EAPOL (contrairement a WEP où le
descriptor key est RC4), or sans master key (hash du SSID et de la
passphase en PSK, ou clé negociée lors de la phase d'authentification
EAP lorsque l'EAP utilisé le permet) impossible d'aller plus loin dans
la negociation des pairwise key et group key.

A moins qu'il y ait un moyen d'obtenir cette master key a partir des
params MD5... Vu la faiblesse de MD5 c'est pas une question essentielle
mais ça m'intrigue.

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.


Je n'ai jamais vu d'adaptateurs permettant cela; faut dire que sous
Windows les specs NDIS relatives au WiFi n'offre pas la possibilité de
specifier au driver quel protocol EAP utiliser ni ses parametres, et
qu'on a pas acces aux trames 802.11. Il y a donc un prog supplicant qui
fait le travail, le tout s'appuyant sur Ethernet/802.1X.

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?


Je ne connais que ce cas de figure.

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.


Mais pourtant trés utilisé encore apparement.
Si j'ai bien suivi, PEAP est encore a l'etat de draft, et TLS reclame un
deploiement de certificats peut etre trop contraignant.




--
« Le travail est probablement ce qu'il y a sur cette terre de plus bas et
de plus ignoble. Il n'est pas possible de regarder un travailleur sans
maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager,
dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. »
Boris VIAN
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<