Aller au contenu

Protected Extensible Authentication Protocol

Un article de Wikipédia, l'encyclopédie libre.

Protected Extensible Authentication Protocol, Protected EAP, ou plus simplement PEAP, est une mĂ©thode de transfert sĂ©curisĂ© 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

[modifier | modifier le code]

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 deux 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 deux phases :

  1. 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.
  2. La phase 2 ou 'identification interne' permet l'authentification du client au travers du tunnel chiffré.

PEAPv0/EAP-MSCHAPv2

[modifier | modifier le code]

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

[modifier | modifier le code]
+---------------+---------------+---------------+---------------+
|     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

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

[modifier | modifier le code]
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éé : À 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

[modifier | modifier le code]

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

[modifier | modifier le code]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     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 messages 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

[modifier | modifier le code]
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. À 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. À partir de lĂ  les messages sont envoyĂ©s en clair.

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

PEAPV2 requiert que le service RADIUS Ă©tablisse la clĂ© maĂźtresse qui servira Ă  la gĂ©nĂ©ration des autres clĂ©s requises aux chiffrements. L’implantation de PEAPv2 demande peu d’effort Ă  dĂ©ployer et est considĂ©rĂ©e comme sĂ©curitaire par l’industrie.

Format de trame

[modifier | modifier le code]
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     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

[modifier | modifier le code]

A. Échange de l'identitĂ© en clair

[modifier | modifier le code]

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

[modifier | modifier le code]

Dans cette version, il n'y a 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

Liens externes

[modifier | modifier le code]