2. Extensible Authentication Protocol (EAP)

L'échange d'authentification EAP se déroule comme suit :

[1] L'authenticateur envoie une Request pour authentifier l'homologue. Cette Request contient un champ Type indiquant ce qui est demandé. Des exemples de types de Request incluent Identity, MD5-challenge, etc. Le type MD5-challenge est très proche du protocole d'authentification CHAP [RFC1994]. En général, l'authenticateur envoie une Identity Request initiale ; cependant, la Identity Request initiale n'est pas obligatoire et peut être omise. Par exemple, l'identité peut ne pas être requise dans les cas où elle est déterminée par le port auquel l'homologue est connecté (ligne louée, commutateur privé ou port composé), ou obtenue par d'autres moyens (via l'identification de l'appelant ou l'adresse MAC, dans le champ Name de la MD5-Challenge Response, etc.).

[2] L'homologue envoie un paquet Response en réponse à une Request valide. Comme le paquet Request, le paquet Response contient un champ Type correspondant au champ Type de la Request.

[3] L'authenticateur envoie une Request supplémentaire, à laquelle l'homologue répond par une Response. La séquence de Request et Response se poursuit tant que nécessaire. EAP étant un protocole "pas à pas" (lock step), aucune nouvelle Request ne peut être envoyée avant la réception d'une Response valide (à l'exception de la Request initiale). L'authenticateur est responsable de la retransmission des Request comme décrit à la section 4.1. Après un nombre approprié de retransmissions, l'authenticateur doit mettre fin à la conversation EAP. Lors d'une retransmission, ou en l'absence de réponse de l'homologue, l'authenticateur NE DOIT PAS envoyer de paquets Success ou Failure.

[4] La conversation se poursuit jusqu'à ce que l'authenticateur ne puisse pas authentifier l'homologue (réponse inacceptable à une ou plusieurs Request), auquel cas l'implémentation DOIT envoyer un EAP Failure (Code 4). Sinon, la conversation d'authentification peut se poursuivre jusqu'à ce que l'authenticateur détermine que l'homologue a été authentifié avec succès, auquel cas l'authenticateur DOIT envoyer un EAP Success (Code 3).

Avantages :

o Le protocole EAP peut prendre en charge plusieurs mécanismes d'authentification sans avoir à négocier au préalable un mécanisme spécifique.

o Les périphériques NAS (Network Access Server, comme les commutateurs ou les points d'accès) n'ont pas besoin de comprendre chaque méthode d'authentification et PEUVENT agir comme proxy pass-through pour un serveur d'authentification backend. La prise en charge du pass-through est facultative. L'authenticateur peut authentifier l'homologue localement tout en agissant comme pass-through pour les homologues distants et les méthodes d'authentification qu'il n'implémente pas localement.

o La séparation de l'authenticateur et du serveur d'authentification backend simplifie la gestion des informations d'identification et la prise de décision de politique.

Inconvénients :

o Lorsqu'il est utilisé dans PPP, EAP nécessite l'ajout d'un nouveau type d'authentification au PPP LCP, modifiant ainsi les implémentations PPP pour l'utiliser. Il s'écarte également du modèle d'authentification PPP précédent qui négociait un mécanisme d'authentification spécifique pendant le LCP. De même, les implémentations de commutateurs ou de points d'accès doivent prendre en charge [IEEE-802.1X] pour utiliser EAP.

o Dans les cas où l'authenticateur est séparé du serveur d'authentification backend, l'analyse de sécurité est compliquée, tout comme la distribution des clés lorsque nécessaire.

2.1. Prise en charge des séquences

Une conversation EAP PEUT utiliser une séquence de méthodes. Un exemple courant est une demande Identity suivie d'une seule méthode d'authentification EAP, comme MD5-Challenge. Cependant, l'homologue et l'authenticateur DOIVENT utiliser une seule méthode d'authentification (Type 4 ou supérieur) dans une conversation EAP, après quoi l'authenticateur DOIT envoyer un paquet Success ou Failure.

Une fois que l'homologue a envoyé une Response du même Type que la Request initiale, l'authenticateur NE DOIT PAS envoyer de Request d'un Type différent (à l'exception d'une Notification-Request) avant la fin du tour final de la méthode spécifique, et NE DOIT PAS envoyer de Request de méthode supplémentaire d'aucun Type après l'achèvement de la méthode d'authentification initiale ; l'homologue recevant une telle Request DOIT la considérer comme non valide et la rejeter silencieusement. Par conséquent, la ré-interrogation d'identité n'est pas prise en charge.

L'homologue NE DOIT PAS envoyer de Nak (traditionnel ou étendu) en réponse à une Request après avoir envoyé une Response initiale non Nak. Étant donné que des paquets EAP Request contrefaits peuvent être envoyés par un attaquant, l'authenticateur qui reçoit un Nak inattendu DOIT le rejeter et enregistrer l'événement.

En raison de la vulnérabilité aux attaques de l'homme du milieu (voir section 7.4) et de l'incompatibilité avec les implémentations existantes, l'utilisation de plusieurs méthodes d'authentification dans une conversation EAP n'est pas prise en charge.

Dans le cas où une seule méthode d'authentification EAP est utilisée, mais que d'autres méthodes (méthodes "tunnelisées") sont exécutées à l'intérieur de cette méthode, l'interdiction de plusieurs méthodes d'authentification ne s'applique pas. De telles méthodes "tunnelisées" apparaissent comme une seule méthode d'authentification à EAP. Étant donné que les homologues ne prenant pas en charge les méthodes "tunnelisées" peuvent répondre par un Nak à la EAP-Request initiale (traditionnelle ou étendue), la rétrocompatibilité peut être fournie. Pour résoudre la vulnérabilité de sécurité, les méthodes "tunnelisées" DOIVENT prendre en charge la protection contre les attaques de l'homme du milieu.

2.2. Modèle de multiplexage EAP

Conceptuellement, une implémentation EAP est composée des composants suivants :

[a] Couche inférieure. La couche inférieure est chargée de transporter et de recevoir les trames EAP entre l'homologue et l'authenticateur. EAP fonctionne sur plusieurs couches inférieures, notamment PPP, les réseaux locaux filaires IEEE 802 [IEEE-802.1X], les réseaux locaux sans fil IEEE 802.11 [IEEE-802.11], UDP (L2TP [RFC2661] et IKEv2 [IKEv2]) et TCP [PIC]. Le comportement de la couche inférieure est discuté à la section 3.

[b] Couche EAP. La couche EAP reçoit et envoie des paquets EAP via la couche inférieure, implémente la détection de doublons et la retransmission, et distribue et reçoit des messages EAP vers et depuis les couches homologue et authenticateur EAP.

[c] Couches homologue et authenticateur EAP. La couche EAP démultiplexe les paquets EAP entrants vers les couches homologue et authenticateur EAP en fonction du champ Code. En général, une implémentation EAP sur un hôte donné ne prendra en charge qu'une des fonctions homologue ou authenticateur, mais un hôte peut également agir simultanément comme homologue et authenticateur EAP. Dans une telle implémentation, les couches homologue et authenticateur EAP seront toutes deux présentes.

[d] Couche de méthode EAP. La méthode EAP implémente l'algorithme d'authentification et émet/reçoit des messages EAP via les couches homologue et authenticateur EAP. Comme EAP ne prend pas en charge la fragmentation, c'est la responsabilité de la méthode EAP, discutée à la section 5.

Le modèle de multiplexage EAP est illustré ci-dessous. Notez que l'implémentation n'est pas tenue de se conformer à ce modèle tant que le comportement sur le réseau est cohérent avec celui-ci.

         +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
                 +------------>-------------+

Figure 1: EAP Multiplexing Model

Dans EAP, le champ Code joue un rôle similaire au numéro de protocole dans IP. On suppose que la couche EAP démultiplexe les paquets EAP entrants en fonction du champ Code. Les paquets EAP avec Code=1 (Request), 3 (Success) et 4 (Failure) sont distribués à la couche homologue EAP (si elle est implémentée). Les paquets EAP avec Code=2 (Response) sont distribués à la couche authenticateur EAP (si elle est implémentée).

Dans EAP, le champ Type joue un rôle similaire au numéro de port dans UDP ou TCP. On suppose que les couches homologue et authenticateur EAP démultiplexent les paquets EAP entrants en fonction du Type et ne les distribuent qu'à la méthode EAP correspondant à ce Type. Les implémentations de méthode EAP sur un hôte peuvent s'enregistrer pour recevoir des paquets de la couche homologue ou authenticateur (ou les deux), selon le rôle qu'elles prennent en charge.

Étant donné que les méthodes d'authentification EAP peuvent souhaiter accéder à l'identité, les implémentations DEVRAIENT rendre la Request et la Response Identity accessibles aux méthodes d'authentification (Type 4 ou supérieur), à l'exception de la méthode Identity. Le type Identity est discuté à la section 5.1.

La Notification Response est utilisée uniquement pour confirmer que l'homologue a reçu la Notification Request, et non pour confirmer qu'il a traité le message ou l'a affiché à l'utilisateur. Le contenu de la Notification Request ou Response n'est pas garanti être disponible pour d'autres méthodes. Le type Notification est discuté à la section 5.2.

Le Nak (Type 3) ou l'Expanded Nak (Type 254) est utilisé pour la négociation de méthode. L'homologue répond à une EAP Request initiale de Type inacceptable par une Nak Response (Type 3) ou une Expanded Nak Response (Type 254). Le contenu des Nak Response(s) n'est pas garanti être disponible pour d'autres méthodes. Les types Nak sont discutés à la section 5.3.

Les paquets EAP dont le Code est Success ou Failure ne contiennent pas de champ Type et ne sont pas distribués aux méthodes EAP. Success et Failure sont discutés à la section 4.2.

Compte tenu de ces considérations, les messages Success, Failure, Nak Response(s) et Notification Request/Response NE DOIVENT PAS être utilisés pour transporter des données destinées à d'autres méthodes EAP.

2.3. Comportement pass-through

Lorsqu'il fonctionne en tant qu'"authenticateur pass-through", l'authenticateur effectue les vérifications des champs Code, Identifier et Length comme décrit à la section 4.1. Il relaie les paquets EAP reçus de l'homologue et destinés à sa couche authenticateur vers le serveur d'authentification backend ; les paquets reçus du serveur d'authentification backend et destinés à l'homologue lui sont relayés.

Un hôte recevant un paquet EAP ne peut faire qu'une seule de ces trois choses : le traiter, l'ignorer, ou le relayer. La décision de relai est généralement basée uniquement sur la vérification des champs Code, Identifier et Length. L'implémentation d'un authenticateur pass-through DOIT être capable de relayer les paquets EAP avec Code=2 (Response) reçus de l'homologue vers le serveur d'authentification backend. Elle DOIT également être capable de recevoir des paquets EAP du serveur d'authentification backend et de relayer les paquets avec Code=1 (Request), Code=3 (Success) et Code=4 (Failure) vers l'homologue.

À moins que l'authenticateur n'implémente pas localement une ou plusieurs méthodes d'authentification prenant en charge le rôle authenticateur, les champs d'en-tête de la couche de méthode EAP (Type, Type-Data) ne sont pas vérifiés dans le cadre de la décision de relai. Dans le cas où l'authenticateur prend en charge des méthodes d'authentification locales, il peut vérifier le champ Type pour décider de traiter le paquet lui-même ou de le relayer. Les implémentations compatibles d'authenticateur pass-through DOIVENT relayer par défaut les paquets EAP de n'importe quel Type.

Les paquets EAP reçus avec Code=1 (Request), Code=3 (Success) et Code=4 (Failure) sont démultiplexés par la couche EAP et distribués à la couche homologue. Par conséquent, à moins que l'hôte n'implémente la couche homologue EAP, ces paquets sont ignorés silencieusement. De même, les paquets EAP reçus avec Code=2 (Response) sont démultiplexés par la couche EAP et distribués à la couche authenticateur. Par conséquent, à moins que l'hôte n'implémente la couche authenticateur EAP, ces paquets sont ignorés silencieusement. Le comportement d'un "homologue pass-through" n'est pas défini dans ce document, et les protocoles AAA comme RADIUS [RFC3579] et Diameter [DIAM-EAP] ne prennent pas en charge ce comportement.

Le modèle de relai est illustré à la figure 2.

Peer Pass-through Authenticator Authentication Server

   +-+-+-+-+-+-+                                   +-+-+-+-+-+-+
   +-+-+-!-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-!-+-+-+
   |EAP  ! peer|   |     | +-----------+       |   |EAP  !Auth.|
   +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
   +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
   +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
         +-------->--------+           +--------->-------+

Figure 2: Pass-through Authenticator

Pour une session où l'authenticateur agit en pass-through, il DOIT déterminer le résultat de l'authentification uniquement sur la base de l'indication Accept/Reject envoyée par le serveur d'authentification backend ; le résultat NE DOIT PAS être déterminé par le contenu des paquets EAP encapsulés avec l'indication Accept/Reject, ni par l'absence de tels paquets EAP encapsulés.

2.4. Fonctionnement pair-à-pair

Étant donné qu'EAP est un protocole pair-à-pair, une authentification inverse indépendante et simultanée peut se produire (selon les capacités de la couche inférieure). Les deux extrémités de la liaison peuvent agir simultanément comme authenticateur et homologue. Dans ce cas, les deux extrémités doivent implémenter les couches homologue et authenticateur EAP. De plus, les implémentations de méthode EAP sur les deux extrémités doivent prendre en charge à la fois les fonctions authenticateur et homologue.

Bien qu'EAP prenne en charge le fonctionnement pair-à-pair, certaines implémentations EAP, méthodes, protocoles AAA et couches liaison peuvent ne pas prendre en charge cette fonctionnalité. Certaines méthodes EAP peuvent prendre en charge une authentification asymétrique, exigeant de l'homologue un type d'informations d'identification et de l'authenticateur un autre type. Les hôtes prenant en charge l'authentification pair-à-pair utilisant de telles méthodes doivent configurer les deux types d'informations d'identification.

Par exemple, EAP-TLS [RFC2716] est un protocole client-serveur, utilisant généralement des profils de certificats différents pour le client et le serveur. Cela signifie que les hôtes prenant en charge l'authentification pair-à-pair utilisant EAP-TLS doivent implémenter les couches homologue et authenticateur EAP, prendre en charge les rôles homologue et authenticateur dans l'implémentation EAP-TLS, et configurer le certificat approprié pour chaque rôle.

Les protocoles AAA comme RADIUS/EAP [RFC3579] et Diameter EAP [DIAM-EAP] ne prennent en charge que le fonctionnement "authenticateur pass-through". Comme décrit dans [RFC3579] section 2.6.2, le serveur RADIUS répond par un Access-Reject à un Access-Request encapsulant un paquet EAP-Request, Success ou Failure. Par conséquent, le fonctionnement "homologue pass-through" n'est pas pris en charge.

Même dans le cas de l'utilisation d'une méthode prenant en charge l'authentification bidirectionnelle et l'indication de résultat, plusieurs considérations peuvent nécessiter deux authentifications EAP (une dans chaque sens). Celles-ci incluent :

[1] Prise en charge de la dérivation de clés de session bidirectionnelles dans la couche inférieure. Les couches inférieures comme IEEE 802.11 peuvent ne prendre en charge que la dérivation et la transmission unidirectionnelles de clés de session temporaires. Par exemple, l'échange de clés de groupe défini dans [IEEE-802.11i] est unidirectionnel, car en mode infrastructure IEEE 802.11, seul le point d'accès (AP) envoie du trafic multicast/diffusion. En mode ad hoc IEEE 802.11, les deux extrémités pouvant envoyer du trafic multicast/diffusion, un échange de clés de groupe unidirectionnel dans chaque sens est nécessaire. En raison des limitations de conception, cela signifie également qu'une dérivation de clés unicast et un échange de méthode EAP sont nécessaires dans chaque sens.

[2] Prise en charge du "bris d'égalité" (tie-breaking) dans la couche inférieure. Les couches inférieures comme le mode ad hoc IEEE 802.11 ne prennent pas en charge le "bris d'égalité", où deux hôtes s'initiant mutuellement l'authentification ne subiraient qu'une seule authentification. Cela signifie qu'even si 802.11 prenait en charge l'échange de clés de groupe bidirectionnel, deux authentifications dans chaque sens pourraient toujours se produire.

[3] Satisfaction de la politique de l'homologue. La méthode EAP peut prendre en charge l'indication de résultat, permettant à l'homologue d'indiquer à l'intérieur de la méthode qu'il a authentifié avec succès le serveur EAP, et le serveur d'indiquer qu'il a authentifié l'homologue. Cependant, à moins que cette information ne soit fournie à l'authenticateur via un protocole AAA, l'authenticateur pass-through ne saura pas que l'homologue a accepté les informations d'identification fournies par le serveur EAP. L'authenticateur DOIT interpréter la réception d'un attribut de clé dans un paquet Accept comme une indication que l'homologue a authentifié avec succès le serveur.

Cependant, même en cas d'authentification bidirectionnelle, la politique d'accès de l'homologue peut ne pas être satisfaite pendant l'échange EAP initial. Par exemple, l'authenticateur EAP peut ne pas démontrer l'autorisation d'agir simultanément dans les rôles homologue et authenticateur. Par conséquent, même si l'homologue fournit une indication qu'il a authentifié avec succès le serveur EAP, il peut nécessiter une authentification supplémentaire dans le sens inverse.