PEAP
Un article de Wikipédia, l'encyclopédie libre.
Vous avez de 
Sommaire |
[modifier] Introduction
Protected Extensible Authentication Protocol, Protected EAP, ou plus simplement PEAP, est une méthode de transfert sécurisée d'informations d'authentification, 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(Internet Engineering Task Force). Il faut noter que PEAP n'est pas une méthode de chiffrement, c'est juste une procédure pour authentifier un client sur un réseau.
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 PKI (Public Key Infrastructure) que du coté serveur, pour la création d'un Tunnel TLS (Transport Layer Security) protégeant l'authentification. Dans ces deux standards, l'utilisation d'une clef publique coté client est optionnelle.
Il existe 2 versions de PEAP Certifiées WPA (mise à jour) et WPA2 :
- PEAPv0/EAP-MSCHAPv2
- PEAPv1/EAP-GTC
PEAP se déroule en 2 phases :
- La phase 1 permet l'authentification du Serveur grâce une PKI. Une fois le serveur authentifié il y a la création d'un tunnel sécurisé qui permettra à la phase 2 d'être chiffrée.
- La phase 2 permet l'authentification du client au travers du tunnel chiffré.
[modifier] 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 au 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 users valides. Ce problème est résolu dans PEAPv2.
Cette version de PEAP est définie dans les brouillons Internet de IETF draft-kamath-pppext-eap-mschapv2-01.txt et draft-kamath-pppext-peapv0-00.txt
[modifier] 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 a faire correspondre les réponses avec les requêtes
Length :
Le champ Longueur fait 2 octets, il indique la taille du paquet EAP avec l'entête.
Type :
Le champ "type" défini 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
MS-Length :
le champ MS-lenght 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
[modifier] 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é en clair) | |
| <--- EAP-Success | |
[modifier] 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’ont jamais intégré cette version de PEAP dans leurs 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
[modifier] 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 = Reservé, doit être à 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.
Version :
0 1 +-+-+ |R 1| +-+-+ R = Reservé, doit être a zero
Data : Ce champ est déterminé par le format du champ Code Field
[modifier] 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é 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. | |
[modifier] 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
[modifier] 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
[modifier] Scénario
[modifier] 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-TLV[EAP-Request/Identity]]) | |
| // Le tunnel TLS est créé. L’identité est protégée par TLS. Les paquets EAP-TLV n’ont pas d’entête EAP. | |
| EAP-TLV [EAP-Payload-TLV [EAP-Response/Identity (MyID2)]] ---> | |
| <--- EAP-TLV [EAP-Payload-TLV[EAP-Request/EAP-Type=X]] | |
| EAP-TLV [EAP-Payload-TLV[EAP-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 | |
[modifier] 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 | |
