Protected Extensible Authentication Protocol
Protected Extensible Authentication Protocol, Protected EAP, ou plus simplement PEAP, est une méthode de transfert sécurisée d'informations d'authentification, créée au départ pour les réseaux sans fil. Ce protocole a été développé conjointement par Microsoft, RSA Security et Cisco Systems. C’est un standard ouvert de l'IETF.
PEAP n'est pas une méthode de chiffrement, c'est une procédure pour authentifier un client sur un réseau.
Introduction
PEAP est très semblable à une autre méthode EAP : EAP-TTLS. Protected EAP a été créé pour contrer EAP-TTLS qui était jusque là, la seule méthode EAP à n'utiliser une infrastructure à clés publiques (PKI) que du côté serveur, pour protéger l'authentification par la création d'un tunnel TLS. Dans ces deux standards, l'utilisation d'une clef publique côté client est optionnelle. PEAP impose une identification interne (inner authentication) par une autre méthode EAP, alors que TTLS autorise toute méthode d'identification interne CHAP, PAP, MS-CHAP, MS-CHAPv2 ou méthode EAP.
Il existe 2 versions de PEAP certifiées WPA (mise à jour) et WPA2 :
- PEAPv0/EAP-MSCHAPv2 (seule méthode d'identification interne), aussi appelé PEAP version Microsoft
- PEAPv1/EAP-GTC ou EAP-TLS, ou EAP-MS-CHAP-V2, aussi appelé PEAP version Cisco
PEAP se déroule en 2 phases :
- La phase 1 ou 'identification externe' permet l'authentification du serveur grâce à une infrastructure à clés publiques. Une fois le serveur authentifié il y a création d'un tunnel sécurisé qui permettra à la phase 2 d'être chiffrée.
- La phase 2 ou 'identification interne' permet l'authentification du client au travers du tunnel chiffré.
PEAPv0/EAP-MSCHAPv2
PEAPv0/EAP-MSCHAPv2 est la version la plus utilisée de PEAP. C'est à cette version que l'on fait référence lorsque l'on parle de PEAP sans plus de précisions. Après EAP-TLS, PEAP est l'EAP le plus utilisé. Cette version utilise la version de Microsoft du protocole CHAP (Challenge Handshake Authentication Protocol). Il est basé sur un challenge. Si le correspondant arrive à déchiffrer le challenge envoyé (chiffré avec la clef publique) c'est qu'il dispose bien de la clef secrète. Ce qui prouve son identité.
Il existe des implémentations de ce protocole dans de nombreuses marques d'AP, On trouve des implémentations de ce protocole pour Windows, Linux, MacOs, ... Les systèmes suivants le supportent nativement : MAC OS 10.3 et supérieur, Windows 2000 SP4, Windows XP, Windows Mobile 2003 et supérieur et Windows CE 4.2. La partie serveur est nativement présente dans Windows 2003 Serveur.
MSCHAPv2 est sensible aux attaques de dictionnaire. Mais avec le protocole PEAP ce n'est pas un problème car les informations circulent dans un canal sécurisé.
PEAPv0 comporte une autre faiblesse. Il transmet le logon en dehors du tunnel TLS. L'utilisation d'un sniffer peut permettre de récupérer un nom d'utilisateur valide. Grâce à cette information un individu mal intentionné peut provoquer un DOS en verrouillant les utilisateurs valides. Ce problème est résolu dans PEAPv2.
Cette version de PEAP est définie dans les brouillons Internet de l'IETF draft-kamath-pppext-eap-mschapv2-01.txt et draft-kamath-pppext-peapv0-00.txt
Format de Trames
+---------------+---------------+---------------+---------------+ | Code | Identifier | Length | +---------------+---------------+---------------+---------------+ | Type | OpCode | MS-CHAPv2-ID | MS-Length... +---------------+---------------+---------------+---------------+ | MS-Length | Data... +---------------+---------------
Code :
Le champ code est sur 1 octet, il sert à définir le type de trame :
1 - Request
2 - Response
Identifier :
Le champ Identifier est sur un octet, il sert à faire correspondre les réponses avec les requêtes
Length :
Le champ Length fait 2 octets, il indique la taille du paquet EAP avec l'en-tête.
Type :
Le champ Type définit sur un octet le type de protocole EAP utilisé
26 - EAP MS-CHAP-V2
OpCode :
Le champ OpCode est sur un octet, il identifie le type de paquets EAP MS-CHAP-v2 :
1 Challenge
2 Response
3 Success
4 Failure
7 Change-Password
MS-CHAPv2-ID :
Le champ identifiant MS-CHAPv2 est sur 1 octet, il permet de faire correspondre les requêtes et les réponses MS-CHAPv2
1. Les réseaux LAN câblés du type Ethernet ont toujours été susceptibles aux attaques génériques. Les réseaux IEEE 802.11 introduisent quel type unique de vulnérabilité ? a. Usurpation d’identité du client, -b. Eavesdropping (écoute clandestine) c.^^^^ Jamming du milieu de transmission, -d. Attaques « Man in the Middle », -e. Cracking du cryptage
2. Avant qu’une station puisse participer dans un réseau sans-fil utilisant une solution de sécurité basée sur WPA2-Entreprise, que doit-il arriver ? ^^^^^^a. La station client doit être authentifiée et associée par EAP b. La station client doit dériver la clé PMK à partir de la PSK ^^^^^^c. La station client doit négocier un protocole d’authentification à utiliser avec le point d’accès d. La station client doit se voir octroyé une adresse IP par un serveur DHCP e. La station client doit être authentifiée et associée en Système Ouvert f. La station client doit configurer et activer la sécurité IPSec
3. Quels sont les mécanismes définis par la norme IEEE 802.11-1999 pour fournir le contrôle d’accès et la privacité dans un réseau sans-fil ? a. IPSec Virtual Private Networking (VPN) b. Authentification 802.1X/EAP ^^^^c. Wired Equivalent Privacy (WEP) ^^^^d. Authentification à clé partagée e. Services d’authentification RADIUS f. Temporal Key Integrity Protocol (TKIP)
5. L’amendement 802.11i-2004 spécifie quels mécanismes d’authentification ? a. Services Kerberos -b. Filtres MAC, ^^^^^^^^-c. Control d’accès basé sur port 802.1X d. Services VPN, -e. DHCP authentifié, ^^^^-f. Preshared key
6. Quel type de trame IEEE 802.11 une station sans-fil envoie-t-elle pour obtenir une réponse du point d’accès dans le procès de scanning actif ? a. Trame CF-Poll, -b. Trame ICMP Request ,-c. Trame Location Request ,-d. Trame PS-Poll e. Trame Association Request, ^^^^^^-f. Trame Probe Request
7. Quelle situation demande la méthode de protection 802.11 pour une opération optimale ? a. Quelques stations clientes dans un basic service set 802.11b sont 802.11b et d’autres sont 802.11g ^^^^^^b. Quelques stations clientes dans un basic service set 802.11g sont 802.11b et d’autres sont 802.11g c. Toutes les stations clientes dans un basic service set 802.11g sont compatibles 802.11g d. Toutes les stations clientes dans un basic service set 802.11b sont compatibles 802.11g
8. L’entreprise ABC a un seul AP 802.11g et beaucoup de dispositifs clients sans-fil. La plupart du temps, les transferts de fichiers et d’autres opérations du réseau sans-fil dans le WLAN ABC expérimentent un débit d’environs 20 Mbps. Occasionnellement, le débit tombe à presque la moitié de sa capacité normale. Quelle pourrait être la cause de ce phénomène ? ^^^^^^a. Un client 802.11b s’associe de temps en temps au point d’accès 802.11g b. Le point d’accès est configuré pour utiliser la fragmentation de trames c. Des laptops qui utilisent des cartes Mini-PCI au lieu de cartes PCMCIA s’associent de temps en temps au point d’accès d. Un des clients 802.11g utilise de temps en temps un analyseur de protocoles WLAN (Wireshark ou autre) e. Une entreprise voisine a un WLAN 802.11a avec beaucoup de stations associées
10. L’amendement IEEE 802.11i-2004 spécifie explicitement lesquels de ces mécanismes d’authentification ? ^^^^^^a. Passphrases ^^^^^^b. 802.1X/EAP c. Protected Access Credentials (PACs) d. Token Cards e. Certificats x.509
11. L’entreprise XYZ utilise 802.1X/EAP-LEAP dans son réseau 802.11g pour sécuriser les transmissions de données. Certains employés se déplacent souvent à l’étranger et doivent utiliser le réseau corporatif depuis des hotspots WIFI autour de la planète. Quel protocole de sécurité serait le mieux adapté pour ces accès à distance depuis des hotspots Wireless ? a. WPA2-Personal b. PEAP-MS-CHAPv2 c. EAP-TTLS ^^^^^^d. VPN
12. 256 couleurs => 8 bits 8 niveaux d'intensité => 3 bits Total par pixel=8+3 bits = 11 bits Un frame a 60x60 pixels. Donc, le nombre total de bits pour un frame est 60x60x11=39'600 bits Avec 15 frames par seconde, le nombre de bits par seconde est 39'600x15= 594'000 bit/seconde
14. La technologie FH utilisée dans Bluetooth permet
^^^^^^-de communiquer de manière fiable en présence de bruit de bande étroite
^^^^^^-d'établir des canaux physiques différents pour des piconets co-localisées
-d'établir des liens physiques actifs différents entre le maître et un esclave
dans un piconet
15. L'existence d'un canal physique entre deux dispositifs signifie qu'il y a un lien physique entre eux => faux
16. Si un dispositif Bluetooth fait partie de deux piconets - Il peut être le maître des deux piconets ^^^^^^- Il peut être esclave dans les deux piconets - Il doit être le maître dans un des piconets et esclave dans l'autre
17. L'adresse BT_ADDR d'un dispositif qui participe à un piconet -Est générée par le maître - Peut être changée par le Link Manager Protocole ^^^^- Est utilisée pour déterminer la séquence de fréquences FH si le dispositif est le maître du piconet ^ 18. L'adresse LT_ADDR ^^^^- A une longueur de trois bits - Puisque le nombre de dispositifs actifs est au maximum 7, la LT_ADDR = 000 est réservée pour le maître -Tant qu'une LT_ADDR est assignée à un dispositif dans un piconet, elle ne peut pas être réutilisée pour un autre dispositif
22. Quelle(s) fonctionnalité(s) n'existent pas dans L2CAP ? -Multiplexing, -QoS, ^^^^^^-Authentification, -Segmentation et réassemblage
24. Le transport logique SCO ^^^^-A toujours le même débi ^^^^-Est symétrique (même débit du maître vers l'esclave que dans l'autre sens) ^^^^-Utilise des paquets qui n'ont pas de CRC -Utilise des paquets qui n'ont pas de codage pour la correction d'erreurs ^^^^-N'utilise que des paquets à 1 slot, -Peut transporter des PDUs de la couche L2CAP -Peut transporter des PDUs de la couche LM, -Transport toujours des data non–encapsulés par L2CAP^
26. Le transport logique eSCO -Peut utiliser des paquets qui occupent de 1, 3 et 5 slots -Peut transmettre des cargaisons à 1 Mbit/s, à 2 Mbit/s, à 3 Mbits/s
27. π/4-DQPSK permet de transmettre à 2 bits/symbole => vrai 28. 8DQPSK permet de transmettre à 4 bits/symbole =>faux 29. Il est possible d'effectuer un changement de rôle entre un maître et un esclave => vrai 30. Quelle est la cadence nominale de changement de fréquences dans Bluetooth lorsqu'un transport logique SCO est utilisé? => 1600 changement 31. Lorsque deux dispositifs établissent un piconet pour la première fois, ils doivent se synchroniser sur le même canal physique afin de pouvoir communiquer. Quels sont les noms des procédures utilisées pour cette synchronisation? 1: Inquiry 2 : scan
33. La couche Radio associe à chaque slot une fréquence. Pour les paquets qui occupent un nombre multiple de slots, - La fréquence est laissée constante pendant toute la transmission -La fréquence est changée lorsque l'on change de slot
34. Sachant qu'un transport logique SCO transmet des paquets à des intervalles réguliers, avec quelle fréquence (tous le 2 slots, tous les 4 slots ou tous les 6 slots) doit-on transmettre un paquet HV3 pour arriver à 64 kbit/s? Le paquet HV3 a 30 octets d'information (voir spécification). Ceci correspond à 30x8=240 bits d'information. Le débit doit être 64kbit/s. Si le paquet est transmis tous les n slots. Nous pouvons alors écrire : 64000 = 240/ (n * 625us) la valeur de n est alors : n =240 / (64000 * 625 µs) = 6
35. Calculez le débit efficace maximum de Bluetooth pour les transmissions asymétriques Débit = (1023 * 8 )/(6 * 625us)
42. Quelle est la différence entre 802.11 et Bluetooth lorsqu'un dispositif (ou une station) découvre par le biais d'un CRC erroné, qu'il y a eu une erreur dans un paquet. ^^^^Dans 802.11, l'acquittement n'est pas transmis. Dans BT, un NACK est envoyé avec la réponse.
43. Qu'est-ce qu'un dispositif Bluetooth fait si un paquet transmis sur un transport logique SCO contient des erreurs. ^^^^Rien de spéciale : il ne se rende pas compte puisqu'il n'y a pas de CRC.
44. Le nombre de bits dans l'entête des paquets Bluetooth correspond-t-il à la somme des bits dans les différents champs? Sinon, pourquoi? ^^^^Non, puique l'entête est codée avec 1/3 FEC et, de ce fait, chacun des bits est transmis trois fois.
MS-Length :
le champ MS-length est sur 2 octets et doit être identique au champ Length moins 5.
Data :
Le format de ce champ est déterminé par le champ OpCode
Scénario
| Client | Authentificateur |
|---|---|
| <--- EAP-Request/Identity | |
| EAP-Response/Identity (MyID) ---> | |
| <--- EAP-Request/EAP-Type=PEAP, V=0 (PEAP Start, S bit set) | |
| EAP-Response/EAP-Type=PEAP, V=0 (TLS client_hello) ---> | |
| <--- EAP-Request/EAP-Type=PEAP, V=0 (TLS server_hello, TLS certificate, [TLS server_key_exchange,][TLS certificate_request,] TLS server_hello_done) | |
| EAP-Response/ EAP-Type=PEAP, V=0 ([TLS certificate,] TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS finished) ---> | |
| <--- EAP-Request/EAP-Type=PEAP, V=0 (TLS change_cipher_spec, TLS finished) | |
| EAP-Response/EAP-Type=PEAP ---> | |
| Tunnel TLS créé : A partir de là les messages sont envoyés dans le tunnel TLS c'est également ici que débute le protocole MS-CHAPv2 pour l'échange de l'identité du client. | |
| <--- EAP-Requete/Identité | |
| EAP-Response/Identité (MyID) ---> | |
| <--- EAP-Requete/EAP-Type=EAP MS-CHAP-V2(Challenge) | |
| EAP-Reponse/EAP-Type=EAP-MS-CHAP-V2 (Reponse) ---> | |
| <--- EAP-Requete/EAP-Type=EAP-MS-CHAP-V2 (Succes) | |
| EAP-Reponse/EAP-Type=EAP-MS-CHAP-V2(Succes) ---> | |
| Fin du tunnel TLS (les messages suivants sont envoyés en clair) | |
| <--- EAP-Success | |
PEAPv1/EAP-GTC
PEAPv1/EAP-GTC a été créé par Cisco pour être une alternative à PEAPv0/EAP-MSCHAPv2. Bien que PEAP ait été développé conjointement par Microsoft, Cisco et RSA, Microsoft n’a jamais intégré cette version de PEAP dans ses OS. EAP-GTC n'est donc pas présent nativement sur les systèmes Microsoft. Cisco préfère supporter ses autres protocoles LEAP ou EAP-FAST Plutôt que PEAP. Cette version de PEAP est très peu utilisée.
Cette version de PEAP est définie dans le brouillon draft-josefsson-pppext-eap-tls-eap-05.txt
Format de trame
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flags |Ver| Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code :
- 1 - Request
- 2 - Response
Identifier : Ce champ sur un octet permet de faire correspondre les requêtes et les réponses.
Length : ce champ fait 2 octets, il indique la taille du paquet EAP
Type : 25 - PEAP
Flags :
0 1 2 3 4 5 +-+-+-+-+-+-+ |L M S R R R| +-+-+-+-+-+-+ L = Length included M = More fragments S = PEAP start R = Réservé, doit être à zéro
Le bit L sert à indiquer la présence des champs suivants. Le bit M est à 1. Le bit S est à 1 pour les message PEAP Start.
Version :
0 1 +-+-+ |R 1| +-+-+ R = Réservé, doit être à zéro
Data : Ce champ est déterminé par le format du champ Code Field
Scénario
| Client | Authentificateur |
|---|---|
| <--- EAP-Request/Identity | |
| EAP-Response/Identity (MyID) ---> | |
| <--- EAP-Request/EAP-Type=PEAP(PEAP Start, S bit set) | |
| EAP-Response/EAP-Type=PEAP(TLS client_hello) ---> | |
| <--- EAP-Request/EAP-Type=PEAP(TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done) | |
| EAP-Response/EAP-Type=PEAP ([TLS certificate,] TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS finished) ---> | |
| <--- EAP-Request/EAP-Type=PEAP (TLS change_cipher_spec, TLS finished) | |
| Le tunnel TLS est établi. A partir de là les messages sont envoyés aux travers du tunnel TLS | |
| EAP-Response/EAP-Type=PEAP ---> | |
| <--- EAP-Request/Identity | |
| EAP-Response/Identity (MyID) ---> | |
| <--- EAP-Request/EAP-Type=X | |
| EAP-Response/EAP-Type=X or NAK ---> | |
| <--- EAP-Request/EAP-Type=X | |
| EAP-Response/EAP-Type=X ---> | |
| <--- EAP-Success | |
| Fin du tunnel TLS. A partir de là les messages sont envoyés en clair. | |
PEAPv2
PEAPv2 est le successeur de PEAPv0. Cette version corrige plusieurs faiblesses (dont la transmission du nom de l' utilisateur en dehors du tunnel TLS). Elle a été développée par Microsoft, Cisco Systems et Extundo. Elle corrige les faiblesses de la version 0
Pour l'instant, il n'existe pas beaucoup d'implémentation de cette version. Elle est peu utilisée à l'heure actuelle.
Cette version de PEAP est définie dans le brouillon Internet de IETF draft-josefsson-pppext-eap-tls-eap-10.txt
Format de trame
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flags | Ver | Fragment Message Length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment Message Length | TLS Message Length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLS Message Length | TLS Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer TLVs... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code :
- 1 - Request
- 2 - Response
Identifier : le champ Identifier fait un octet et permet de faire correspondre les requêtes et les réponses.
Length : le champ Length fait 2 octets; il donne la longueur du paquet EAP
Type : 25 - PEAP
Flags :
0 1 2 3 4
+-+-+-+-+-+
|L M S T R|
+-+-+-+-+-+
L = Length included
M = More fragments
S = PEAP start
T = TLS Length included
R = Reserved (must be zero)
Le bit L sert à indiquer la présence des champs suivants. Le bit M est à 1. Le bit S est à 1 pour les message PEAP Start. Le bit T permet d'indiquer la présence du champ TLS Message Length field.
Version :
0 1 2
+-+-+-+
|R|1|0|
+-+-+-+
R = Réservé, doit être à zéro
Fragmented Message Length : Ce champ fait 4 octets, il n'est présent que si le bit L est à 1. Il donne la taille du message après le champ Flag.
TLS Message Length : Ce champ fait 4 octets, il est présent seulement si le bit T est à 1. Il définit la taille totale des données TLS.
TLS Data : ce champ contient des paquets TLS encapsulés.
Outer TLVs : Ce champ est optionnel, il permet d'aider à établir le tunnel TLS
Scénario
A. Echange de l'identité en clair
Dans cette version, une partie de l'identité est donnée en clair mais cette "demi-identité" n'est pas suffisante pour qu'un pirate utilise l'identité pour provoquer un déni de service (DOS) en verrouillant les utilisateurs dont il a pu récupérer la "demi-identité".
| Client | Authentificateur |
|---|---|
| <--- EAP-Request/Identity | |
| EAP-Response/Identity (MyID1) ---> | |
| Une partie de l’identité est envoyée en clair. | |
| <--- EAP-Request/EAP-Type=PEAP, V=2 (PEAP Start, S bit set) | |
| EAP-Response/EAP-Type=PEAP, V=2 (TLS client_hello)---> | |
| <--- EAP-Request/EAP-Type=PEAP, V=2 (TLS server_hello, TLS certificate,[TLS server_key_exchange,][TLS certificate_request,] TLS server_hello_done) | |
| EAP-Response/EAP-Type=PEAP, V=2([TLS certificate,] TLS client_key_exchange,[TLS certificate_verify,] TLS change_cipher_spec, TLS finished) ---> | |
| <--- EAP-Request/EAP-Type=PEAP, V=2(TLS change_cipher_spec, TLS finished, EAP-Request/EAP-Type=EAP-TLV [EAP-Payload-TLVEAP-Request/Identity) | |
| // Le tunnel TLS est créé. L’identité est protégée par TLS. Les paquets EAP-TLV n’ont pas d’en-tête EAP. | |
| EAP-TLV [EAP-Payload-TLV EAP-Response/Identity (MyID2) ---> | |
| <--- EAP-TLV [EAP-Payload-TLVEAP-Request/EAP-Type=X | |
| EAP-TLV [EAP-Payload-TLVEAP-Response/EAP-Type=X ---> | |
| Fin de la protection. | |
| <--- EAP-TLV [Result TLV (Success), Crypto-Binding TLV (Version=2, received-version=2, Nonce, B1_MAC),Intermediate-Result TLV (Success)] | |
| EAP-TLV [Result TLV (Success),Intermediate-Result TLV (Success), Crypto-Binding TLV (Version=2, received-version=2,Nonce, B2_MAC)] ---> | |
| Fin du tunnel TLS (les messages sont à présent envoyés en text clair). | |
| <--- EAP-Success | |
B. Scénario sans échange de texte en clair
Dans cette version il n'y pas d'échange d'identité en clair.
| Client | Authentificateur |
|---|---|
| <--- EAP-Request/EAP-Type=PEAP, V=2(PEAP Start, S bit set) | |
| EAP-Response/EAP-Type=PEAP, V=2 (TLS client_hello) ---> | |
| <--- EAP-Request/EAP-Type=PEAP, V=2 (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done) | |
| EAP-Response/EAP-Type=PEAP, V=2 ([TLS certificate,] TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS finished) ---> | |
| <--- EAP-Request/EAP-Type=PEAP, V=2 (TLS change_cipher_spec, TLS finished, EAP-TLV [EAP-Payload-TLV (EAP-Request/Identity)]) | |
| Tunnel TLS créé (les messages sont envoyés via le tunnel TLS) | |
| EAP-TLV [EAP-Payload-TLV EAP-Response/Identity (MyID) ---> | |
| <--- EAP-TLV [EAP-Payload-TLV EAP-Type=EAP-Request/EAP-Type=X EAP-TLV [EAP-Payload-TLV | |
| [EAP-Response/EAP-Type=X or NAK] ---> | |
| <--- EAP-TLV [EAP-Payload-TLV EAP-Request/EAP-Type=X | |
| EAP-TLV [EAP-Payload-TLV EAP-Response/EAP-Type=X ---> | |
| <--- EAP-TLV [Crypto-Binding TLV=(Version=2, Received-version=2, Nonce, B1_MAC),Intermediate-Result TLV(Success), Result TLV (Success)] | |
| EAP-TLV [Crypto-Binding TLV=(Version=2,Received-version=2, Nonce, B2_MAC), Intermediate-Result TLV (Success), Result TLV (Success)] ---> | |
| Fin du tunnel TLS (les messages sont envoyés en clair) | |
| <--- EAP-Success | |
Voir aussi
Cet article ou cette section contient trop de liens externes (indiquez la date de pose grâce au paramètre date).
- (en) PEAPv0 : draft-kamath-pppext-peapv0-00.txt
- (en) PEAPv1 : draft-josefsson-pppext-eap-tls-eap-05.txt
- (en) PEAPv2 : draft-josefsson-pppext-eap-tls-eap-10.txt
- (en) EAP-MSCHAPv2 : draft-kamath-pppext-eap-mschapv2-01.txt
- (en) PEAPv2 Web Page
- (fr) le protocole MS-CHAP sur commentcamarche.net
- (fr) Mise en oeuvre de PEAP avec Windows 2003 Serveur et le serveur radius IAS
