Découvrir EAP-TEAP

21/03/2022 · 11 mins de lecture · cybersecurite eap teap authentification reseaux nac  ·
Partager sur:

Traductions

Sommaire

Dans cet article, je vous emmène à la découverte d’un protocole d’authentification pour les réseaux, à savoir Tunnel Extensible Authentication Protocol (TEAP), une méthode qui permet la réalisation de plusieurs mécanismes d’authentification au sein d’un tunnel sécurisé. Le principe est de pouvoir cumuler des méthodes d’authentifications et ainsi augmenter le niveau de sécurité d’une communication.

Introduction

TEAP est un protocole défini en 2014 dans la continuité des méthodes du protocole Extensible Authentication Protocol (EAP). Ce dernier est une sorte de cadre permettant de définir des moyens d’authenfication pour les communications sur réseaux filaires ou sans-fil. Nous allons d’abord expliquer ce qu’est EAP, avant de plonger dans TEAP.

EAP et ses méthodes

EAP est un protocole extensible qui s’exécute au-dessus du niveau 2 du modèle OSI pour permettre la réalisation de mécanismes d’authentification entre deux éléments : un peer et un authenticator. Le peer est généralement celui qui demande à être authentifié sur un réseau, tandis que l’authenticator est celui qui authentifie le peer. Par exemple, le peer pourrait être un ordinateur ou un téléphone, tandis que l’authenticator serait un commutateur (ou switch) d’accès réseau.
Dans EAP, l’authenticator émet d’abord, de manière optionnelle, une requête de demande d’identité ou EAP Identity-request à laquelle le peer répond avec une identité (un nom d’utilisateur par exemple) ou Identity response. Ensuite, l’authenticator envoie une requête Challenge Request à laquelle le peer répond avec une réponse Challenge response afin de prouver son identité. L’authenticator peut ainsi recommencer plusieurs fois les envoies de requêtes Challenge request. A la fin, si l’authentification est réussie, l’authenticator émet un message EAP Success, sinon il émet un message EAP Failure.

EAP : un protocole d'authentification extensible

EAP est utilisé dans les liaisons point-à-point régies par le protocole Point-to-Point Protocol (PPP). Il s’inscrit également dans le standard 802.1X, y définissant l’authentification dans le contrôle d’accès aux réseaux (ou Network Access Control) locaux filaires ou Local Area Network (LAN) et sans-fil ou Wireless LAN (WLAN). On parle alors d’EAP over LAN (EAPoL). Dans 802.1X, le peer s’appelle le supplicant et un composant supplémentaire vient épauler l’authenticator : le serveur d’authentification ou authentication server. Ce dernier est utilisé pour vérifier l’identité du supplicant lors d’échanges avec l’authenticator au travers d’un autre protocole d’authentification : Remote Authentication Dial-In User Service (RADIUS), manipulant des messages Access-Request, Access-Challenge et Access-Accept ou Access-Reject.
En outre, des messages supplémentaires sont aussi émis par le supplicant, à savoir EAPOL-Start au démarrage pour déclencher le processus, et EAPOL-Logoff à la fin d’utilisation du média réseau pour remettre le statut de l’accès en non-authentifié.

EAP pour 802.1X

Le standard 802.11i affine les pre-requis spécifiques d’EAP pour l’authentification sur réseaux sans-fils.

EAP étant extensible, de nombreuses méthodes différentes existent pour fournir différents moyens d’authentification. Le tableau ci-dessous fournit un aperçu des principales méthodes utilisées.

Méthode Moyen d’authentification Génération de clés de session pour l’échange de données chiffrées Authentification du peer Authentification de l’authenticator
LEAP Utilisation d’un nombre aléatoire chiffré à l’aide de 3 clés DES dérivées d’une empreinte MD4 du mot de passe de l’utilisateur Oui Oui Oui
EAP-MD5 Utilisation d’une empreinte MD5 de l’identifiant et du mot de passe de l’utilisateur Non Oui Non
EAP-PWD Utilisation d’un mot de passe et d’une suite cryptographique pour dériver un secret partagé Non Oui Non
EAP-PSK Utilisation d’une clé partagée pour dériver des clés de chiffrement subsidiaires utilisées pour l’authentification et la génération de clés de session Oui Oui Non
EAP-POTP Utilisation d’un mot de passe à usage unique ou One Time Password (OTP) pour l’authentification mutuelle et la génération de clés de session Oui Oui Possible
EAP-MSCHAPv2 Utilisation du mot de passe utilisateur pour calculer une empreinte afin d’authentifier le peer et l’authenticator Non Oui Oui
EAP-TLS Utilisation de certificats pour l’authentification mutuelle et la génération de clés de session grâce au protocole TLS Oui Oui Oui
EAP-TTLS Utilisation de certificats pour l’authentification de l’authenticator et la mise en place d’un canal de communication chiffré TLS pour authentifier le peer avec une autre méthode d’authentification (CHAP, PAP, MS-CHAP, MS-CHAPv2, EAP…) Non Oui Oui
EAP-PEAP Utilisation de certificats pour l’authentification de l’authenticator et la mise en place d’un canal de communication chiffré TLS pour authentifier le peer avec une autre méthode d’authentification EAP Non Oui Oui
EAP-IKEv2 Utilisation de clés de chiffrement asymétriques, symétriques ou d’un secret partagé pour l’authentification mutuelle Oui Oui Possible
EAP-FAST Utilisation d’un Protected Access Credential (PAC, comprenant un secret partagé) pour mettre en place un canal de communication chiffré TLS afin d’authentifier le peer avec des identifiants Oui Oui Possible
EAP-SIM Utilisation de la carte SIM d’un téléphone et du centre d’authentification de l’opérateur sur réseau mobile 2G afin de dériver une empreinte pour d’authentifier le peer Oui Oui Possible
EAP-AKA Utilisation de la carte SIM d’un téléphone et du centre d’authentification de l’opérateur sur réseau mobile 3G afin de dériver des empreintes et clés symétriques pour d’authentifier le peer et l’authenticator Non Oui Oui
EAP-AKA' Variante d’EAP-AKA utilisant une méthode de dérivation différente et utilisable en dehors des réseaux mobiles Oui Oui Oui
EAP-GTC Utilisation de jetons en clair pour authentifier le peer (à utiliser au sein d’un tunnel préalablement établi avec une autre méthode) Non Oui Non
EAP-EKE Utilisation d’un secret partagé pour dériver une clé de chiffrement symétrique afin d’authentifier le peer et l’authenticator Non Oui Oui

Nous allons maintenant détailler une autre de ces méthodes : TEAP.

TEAP

TEAP est donc une méthode supplémentaire d’EAP relativement récente, puisque définie en 2014, supportée par le système d’exploitation Windows 10 depuis le 27/05/2020 et pas encore supportée par de nombreux autres systèmes utilisés par le supplicant. TEAP se déroule avec une première phase d’établissement d’un tunnel authentifié et chiffré au moyen du protocole Transport Layer Security (TLS), puis une deuxième phase d’authentification dans ce tunnel. Vous allez sûrement vous demander en quoi cela diffère des autres méthodes EAP qui reposent sur le même principe (EAP-TTLS, EAP-PEAP, EAP-FAST…). En fait, ces méthodes étant souvent proposées initialement par des éditeurs, une des motivations principales de TEAP est de fournir un standard modulaire pour effectuer plusieurs méthodes EAP tunnelisées.
Après les messages EAP Identity-Request et Identity-Response, la première phase débute avec une requête EAP-Request de type TEAP/Start contenant un object Type-Length-Value (TLV) de type Authority-ID (décrit plus bas dans l’article) envoyée par l’authenticator. Le peer répond avec une requête EAP-Response initiant les échanges pour l’établissement du tunnel sécurisé TLS ou TLS handshake. Les messages TLS sont ainsi encapsulés dans les paquets EAP.
Une fois le tunnel TLS établi, la deuxième phase de TEAP prend place avec une série de messages chiffrés (sachant que le premier peut-être envoyé avec le dernier message du TLS handshake afin de réduire le nombre total d’échanges) dans lesquels des objects TLV sont échangés. TLV est un format pour représenter des données au sein d’un protocole, composé d’un champ représentant le type des données, un autre représentant la longueur et un autre la valeur. Pour TEAP, il y a 17 TLV possibles:

  • Authority-ID : utilisé par l’authenticator dans le message TEAP/Start pour indiquer son identité au peer afin de l’aider à choisir les bons identifiants à utiliser par la suite.
  • Identity-Type : utilisé par l’authenticator pour indiquer le type d’identité attendue au peer : utilisateur ou machine.
  • Result : utilisé pour indiquer la réussite ou l’échec de l’authentification TEAP.
  • NAK : utilisé pour indiquer les TLV non supportés.
  • Error : utilisé pour indiquer une erreur lors de l’authentification TEAP. Il existe 39 codes d’erreurs possibles.
  • Channel-Binding : utilisé pour transmettre des méta-données EAP channel-binding afin d’échanger des informations sur les propriétés du réseau.
  • Vendor-Specific : libre pour les éditeurs afin d’utiliser des attributs spécifiques.
  • Request-Action : utilisé par l’authenticator ou le peer pour demander une nouvelle négociation EAP ou de traiter des TLV supplémentaires.
  • EAP-Payload : utilisé pour encapsuler des paquets EAP et des TLV.
  • Intermediate-Result : utilisé pour partager des messages EAP Success (alors accompagné d’un TLV Crypto-Binding) ou EAP Failure entre plusieurs méthodes EAP.
  • PAC : utilisé pour fournir un Protected Access Credential (PAC), c’est-à-dire un secret partagé généré par l’authenticator pour le peer.
  • Crypto-Binding : utilisé pour la vérification du type et version de TEAP négociés et pour valider la participation du peer et de l’authenticator dans l’authentification EAP.
  • Basic-Password-Auth-Req : utilisé par l’authenticator pour demander un nom d’utilisateur et un mot de passe au peer.
  • Basic-Password-Auth-Resp : utilisé par le peer pour répondre au TLV Basic-Password-Auth-Req avec un nom d’utilisateur et un mot de passe.
  • PKCS#7 : utilisé par l’authenticator pour délivrer un ou plusieurs certificats au peer.
  • PKCS#10 : utilisé par le peer pour effectuer une requête Simple PKI afin de demander un certificat.
  • Trusted-Server-Root : utilisé par le peer pour demander le certificat racine de confiance à l’authenticator qu’il peut alors transmettre avec un TLV PKCS#7 dans un TLV Trusted-Server-Root

La conversation TEAP se termine alors par un échanges d’objets TLV Crypto-Binding et Result qui prouve le bon déroulement des échanges et entraîne les messages EAP Success ou EAP Failure.

Exemple d'utilisation de TEAP

TEAP étant un standard assez ouvert, grâce à l’utilisation de TLV, la manière dont les éditeurs l’implémentent peut varier et être incomplète. Au moment où j’écris cet article, les autres méthodes EAP (notamment EAP-TLS, EAP-TTLS, EAP-PEAP) sont encore principalement utilisées. Cependant, à l’heure du Zero Trust, TEAP est censée apporter assez facilement une double authentification machine et utilisateur dans le contrôle d’accès au réseau.

Conclusion

TEAP s’inscrit dans la continuité d’EAP comme une méthode d’authentification permettant plusieurs moyens d’authentification au sein d’un tunnel sécurisé. Le principal besoin actuel est de pouvoir chaîner authentification machine et authentification utilisateur dans le contrôle d’accès au réseau. Reste à savoir à quel rythme les éditeurs vont adopter ce standard et quelles fonctionnalités supplémentaires seront offertes.

Sources

Traductions