Outils pour utilisateurs

Outils du site


reseau:802.1x:principes

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
reseau:802.1x:principes [2023/11/19 20:45] techer.charles_educ-valadon-limoges.frreseau:802.1x:principes [2023/11/20 12:45] (Version actuelle) – [Les différentes phases (simplifiées) d'une connexion 802.1x] techer.charles_educ-valadon-limoges.fr
Ligne 91: Ligne 91:
  
 ==== Les méthodes d'authentification ==== ==== Les méthodes d'authentification ====
 +=== PAP ===
 +
 Le premier protocole a été **PAP** (Password Authentification Protocol) avec lequel les mots de passe circulaient en clair. La sécurité proposée par ce protocole est faible. Le premier protocole a été **PAP** (Password Authentification Protocol) avec lequel les mots de passe circulaient en clair. La sécurité proposée par ce protocole est faible.
-Le second protocole qu'ont utilisé les serveurs RADIUS a été CHAP (Challenge Handshake Authentication Protocol). Il est défini dans la RFC 1994. Avec CHAP, il n'y a pas d'échange de mots de passe sur le réseau.  + 
-Les deux interlocuteurs, qui disposent donc de la même chaîne de caractère secrète, s'authentifient sans échange du mot de passe par une technique de "challenge(ou "défi") basée sur une fonction de hachage à sens unique du secret partagé, telle que MD5. Cette méthode était disponible avec le couple XP/Windows-2003-Server, mais ne l'est plus en génération Seven/2008.+=== CHAP et MS-CHAP === 
 + 
 +Le second protocole qu'ont utilisé les serveurs RADIUS a été **CHAP** (Challenge Handshake Authentication Protocol). Il est défini dans la RFC 1994. Avec CHAP, il n'y a pas d'échange de mots de passe sur le réseau. Les deux interlocuteurs, qui disposent donc de la même chaîne de caractère secrète, s'authentifient sans échange du mot de passe par une technique de **challenge** (ou **défi**) basée sur une fonction de hachage à sens unique du secret partagé, telle que MD5. Cette méthode était disponible avec le couple XP/Windows-2003-Server, mais ne l'est plus en génération Seven/2008.
 Au début de la connexion, le serveur réclame la preuve de l’identité du client, en lui demandant de chiffrer une information. Le client ne peut relever le défi que s’il possède effectivement la clé unique et secrète partagée. Au début de la connexion, le serveur réclame la preuve de l’identité du client, en lui demandant de chiffrer une information. Le client ne peut relever le défi que s’il possède effectivement la clé unique et secrète partagée.
 +
 Dialogue client-serveur avec CHAP Dialogue client-serveur avec CHAP
-A. Après l'établissement de la connexion, l'authentificateur envoie une valeur aléatoire xxxxxx au client. +  * A. Après l'établissement de la connexion, l'authentificateur envoie une valeur aléatoire xxxxxx au client. 
-B. Le client concatène cette valeur xxxxxx au secret partagé, applique une fonction de hachage (telle que MD5) sur la chaîne obtenue et retourne le résultat.  +  B. Le client concatène cette valeur xxxxxx au secret partagé, applique une fonction de hachage (telle que MD5) sur la chaîne obtenue et retourne le résultat. 
-C. Le serveur effectue la même opération et compare avec le résultat reçu. La connexion n'est acceptée que si le résultat est identique. +  C. Le serveur effectue la même opération et compare avec le résultat reçu. La connexion n'est acceptée que si le résultat est identique. 
-D. A intervalle régulier, il y a un nouveau défi à relever pour pérenniser la connexion.+  D. A intervalle régulier, il y a un nouveau défi à relever pour pérenniser la connexion
 + 
 +Microsoft a développé une variante de CHAP appelée **MS-CHAP** qui ajoute une authentification mutuelle, MSCHAP-V1, puis MSCHAP-V2. 
 + 
 +Dialogue client-serveur avec MSCHAP-V2 : 
 +  * A. Le serveur envoie au client une chaîne composée d'un identifiant de session et une chaîne aléatoire xxxxx. 
 +  * B. Le client renvoie son nom d'utilisateur et le résultat d'un hachage de la chaîne aléatoire xxxxx + l'identifiant de session + le mot-de-passe, et une seconde chaîne aléatoire yyyyy. 
 +  * C. Le serveur vérifie le résultat (succès/échec) et retourne celui-ci, avec un hachage de la chaîne yyyyy et du mot de passe utilisateur. 
 +  * D. Le client vérifie enfin la correspondance entre les chaînes. 
 +  * E. La connexion est établie. 
 +=== PEAP === 
 + 
 +PEAP est un protocole de transfert sécurisé (P comme **Protected**) d'informations d'authentification. Il a été mis au point par Microsoft, Cisco et RSA. Il ne nécessite pas de certificat sur les postes clients, contrairement à EAP/TLS. MS-CHAP s'appuie sur PEAP. 
 + 
 +=== Articulation EAP / PEAP / MSCHAP-V2 === 
 +  * EAP est le mécanisme permettant à un client final de pouvoir communiquer sur un port 802.1x fermé à toute autre forme de communication. 
 +  * PEAP ajoute la notion de protection des échanges par tunnel à ce mécanisme 
 +  * MSCHAP est la méthode de reconnaissance mutuelle du client serveur et du serveur RADIUS qui passe par ce tunnel. 
 + 
 +==== Les différentes phases (simplifiées) d'une connexion 802.1x ==== 
 + 
 +{{ :reseau:802.1x:802.1x_05.png |}} 
 +Au démarrage de la communication, le client final est prié d'envoyer ses identifiants au serveur RADIUS.  
 + 
 +Or, à ce moment là, le client final ne connaît pas l'adresse du - ou des - serveurs RADIUS du réseau. Il ne dispose peut-être même pas d'adresse IP. De même, le port du commutateur sur lequel il est connecté est censé être fermé (état non contrôlé). 
 + 
 +En réalité, le port contrôlé du commutateur n'est pas totalement fermé. Il va laisser passer le protocole EAP (Phase 1 sur le schéma suivant). Cette communication ne peut donc se faire que par des trames Ethernet de base et non par des paquets IP. 
 + 
 +Le client final peut donc envoyer son identité dans un paquet EAP au commutateur. Celui-ci le retransmet, encapsulé dans un paquet au format RADIUS, au premier serveur RADIUS de sa liste (s'il en connaît plusieurs) (Phase 2). 
 + 
 +Le serveur RADIUS reçoit le paquet et interroge sa base de données (Phase 3).
  
-Microsoft a développé une variante de CHAP appelée MS-CHAP qui ajoute une authentification mutuelleMSCHAP-V1, puis MSCHAP-V2. +Il renvoie le résultat de cette interrogation au commutateur (Phase 4)sous forme d'un commandement d'ouverture du port, éventuellement assorti d'un numéro de VLAN dans lequel placer le client final
-Dialogue client-serveur avec MSCHAP-V2. +
-A. Le serveur envoie au client une chaîne composée d'un identifiant de session et une chaîne aléatoire xxxxx. +
-B. Le client renvoie son nom d'utilisateur et le résultat d'un hachage de la chaîne aléatoire xxxxx + l'identifiant de session + le mot-de-passe, et une seconde chaîne aléatoire yyyyy. +
-C. Le serveur vérifie le résultat (succès/échec) et retourne celui-ci, avec un hachage de la chaîne yyyyy et du mot de passe utilisateur. +
-D. Le client vérifie enfin la correspondance entre les chaînes. +
-E. La connexion est établie.+
  
-PEAP +A partir de ce moment seulement, il peut y avoir d'autres trames échangées entre le client final et le reste du réseaucomme une trame de requête DHCP par exemple
-PEAP est un protocole de transfert sécurisé (P comme "Protected"d'informations d'authentification. Il a été mis au point par MicrosoftCisco et RSA. Il ne nécessite pas de certificat sur les postes clients, contrairement à EAP/TLS. MS-CHAP s'appuie sur PEAP.+
  
-Articulation EAP / PEAP / MSCHAP-V2 +Avant authentification, le port ne laisse passer que des trames EAP:  
- EAP est le mécanisme permettant à un client final de pouvoir communiquer sur un port 802.1x fermé à toute autre forme de communication+{{ :reseau:802.1x:802.1x_06.png |}} 
- PEAP ajoute la notion de protection des échanges par tunnel à ce mécanisme +Après authentification, le port laisse passer tous les types de trames :  
- MSCHAP est la méthode de reconnaissance mutuelle du client serveur et du serveur RADIUS qui passe par ce tunnel.+{{ :reseau:802.1x:802.1x_07.png |}}
  
 +=== Conséquence de ce fonctionnement général. ===
 +L'équipement réseau ne connaît que le protocole RADIUS. Le protocole d'authentification entre le client final et le serveur RADIUS pourra varier sans que cela soit un blocage pour l'équipement. En ce sens, on dit que le client RADIUS est **transparent**.
 +==== Que faire des périphériques non 802.1x ? ====
 +L'objectif de contrôler toutes les prises réseau d'une entreprise en y imposant une authentification peut se heurter au fait que certains périphériques qui y sont connectés (comme des imprimantes, des vidéoprojecteurs ...) n'implémentent pas 802.1x. Il faut donc trouver d'autres solutions pour protéger ces prises : 
 +  * un VLAN spécifique par exemple réunissant les imprimantes, avec un serveur d'impression situé dans un autre VLAN joignable au travers d'un routeur filtrant,
 +  * une protection des ports par adresse MAC, ou encore une connexion sans-fil des vidéoprojecteurs dans une technologie de cryptage comme WPA2. 
  
 ==== Retour Authentification 802.1x ==== ==== Retour Authentification 802.1x ====
   * [[reseau:802.1x:accueil|Authentification réseau avec le protocole 802.1x]]   * [[reseau:802.1x:accueil|Authentification réseau avec le protocole 802.1x]]
reseau/802.1x/principes.1700423159.txt.gz · Dernière modification : 2023/11/19 20:45 de techer.charles_educ-valadon-limoges.fr