2. Protocole d'Authentification Extensible (EAP)

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

[1] L'authentificateur (authenticator) envoie une requête (Request) pour authentifier le pair (peer).

La requête a un champ Type pour indiquer ce qui est demandé. Des exemples de types de requête incluent Identity (identité), MD5-challenge, etc. Le type MD5-challenge correspond étroitement au protocole d'authentification CHAP [RFC1994]. Typiquement, l'authentificateur enverra une Identity Request initiale ; cependant, une Identity Request initiale n'est pas requise et PEUT être contournée. Par exemple, l'identité peut ne pas être requise lorsqu'elle est déterminée par le port auquel le pair s'est connecté (lignes louées, commutateur dédié ou ports d'accès à distance), ou lorsque l'identité est obtenue d'une autre manière (via l'identité de la station appelante ou l'adresse MAC, dans le champ Name de la MD5-Challenge Response, etc.).

[2] Le pair envoie un paquet Response en réponse à une requête valide.

Comme pour le paquet Request, le paquet Response contient un champ Type, qui correspond au champ Type de la requête.

[3] L'authentificateur envoie un paquet Request supplémentaire, et le pair répond avec une Response.

La séquence de requêtes et de réponses continue aussi longtemps que nécessaire. EAP est un protocole "lock step", de sorte qu'à l'exception de la requête initiale, une nouvelle requête ne peut pas être envoyée avant de recevoir une Response valide. L'authentificateur est responsable de retransmettre les requêtes comme décrit dans la section 4.1. Après un nombre approprié de retransmissions, l'authentificateur DEVRAIT terminer la conversation EAP. L'authentificateur NE DOIT PAS envoyer un paquet Success ou Failure lors de la retransmission ou lorsqu'il n'obtient pas de réponse du pair.

[4] La conversation continue jusqu'à ce que l'authentificateur ne puisse pas authentifier le pair (réponses inacceptables à une ou plusieurs requêtes), auquel cas l'implémentation de l'authentificateur DOIT transmettre un EAP Failure (Code 4). Alternativement, la conversation d'authentification peut continuer jusqu'à ce que l'authentificateur détermine qu'une authentification réussie s'est produite, auquel cas l'authentificateur DOIT transmettre un EAP Success (Code 3).

Avantages :

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

o Les dispositifs Network Access Server (NAS) (par exemple, un commutateur ou un point d'accès) n'ont pas besoin de comprendre chaque méthode d'authentification et PEUVENT agir comme agent pass-through pour un serveur d'authentification backend. Le support du pass-through est optionnel. Un authentificateur PEUT authentifier des pairs locaux, tout en agissant en même temps comme pass-through pour les pairs non locaux et les méthodes d'authentification qu'il n'implémente pas localement.

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

Inconvénients :

o Pour une utilisation dans PPP, EAP nécessite l'ajout d'un nouveau type d'authentification à PPP LCP et donc les implémentations PPP devront être modifiées pour l'utiliser. Il s'écarte également du modèle d'authentification PPP précédent de négociation d'un mécanisme d'authentification spécifique pendant LCP. De même, les implémentations de commutateur ou de point d'accès doivent prendre en charge [IEEE-802.1X] pour utiliser EAP.

o Lorsque l'authentificateur est séparé du serveur d'authentification backend, cela complique l'analyse de sécurité et, si nécessaire, la distribution de clés.

2.1. Support des Séquences (Support for Sequences)

Une conversation EAP PEUT utiliser une séquence de méthodes. Un exemple courant de ceci est une requête Identity suivie d'une seule méthode d'authentification EAP telle que MD5-Challenge. Cependant, le pair et l'authentificateur DOIVENT utiliser une seule méthode d'authentification (Type 4 ou supérieur) dans une conversation EAP, après quoi l'authentificateur DOIT envoyer un paquet Success ou Failure.

Une fois qu'un pair a envoyé une Response du même Type que la requête initiale, un authentificateur NE DOIT PAS envoyer une requête d'un Type différent avant l'achèvement du tour final d'une méthode donnée (à l'exception d'une Notification-Request) et NE DOIT PAS envoyer une requête pour une méthode supplémentaire de tout Type après l'achèvement de la méthode d'authentification initiale ; un pair recevant de telles requêtes DOIT les traiter comme invalides et les ignorer silencieusement. En conséquence, Identity Requery n'est pas pris en charge.

Un pair NE DOIT PAS envoyer un Nak (legacy ou expanded) en réponse à une requête après l'envoi d'une Response non-Nak initiale. Étant donné que des paquets EAP Request usurpés peuvent être envoyés par un attaquant, un authentificateur recevant un Nak inattendu DEVRAIT le rejeter et enregistrer l'événement.

Plusieurs méthodes d'authentification au sein d'une conversation EAP ne sont pas prises en charge en raison de leur vulnérabilité aux attaques de l'homme du milieu (voir section 7.4) et de l'incompatibilité avec les implémentations existantes.

Lorsqu'une seule méthode d'authentification EAP est utilisée, mais que d'autres méthodes sont exécutées à l'intérieur (une méthode "tunnelisée"), l'interdiction contre plusieurs méthodes d'authentification ne s'applique pas. De telles méthodes "tunnelisées" apparaissent comme une seule méthode d'authentification pour EAP. La compatibilité descendante peut être fournie, puisqu'un pair ne supportant pas une méthode "tunnelisée" peut répondre à la EAP-Request initiale avec un Nak (legacy ou expanded). Pour résoudre les vulnérabilités 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 (EAP Multiplexing Model)

Conceptuellement, les implémentations EAP se composent des composants suivants :

[a] Couche inférieure (Lower layer). La couche inférieure est responsable de la transmission et de la réception de trames EAP entre le pair et l'authentificateur. EAP a été exécuté sur une variété de couches inférieures, y compris PPP, les LAN IEEE 802 câblés [IEEE-802.1X], les LAN 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é dans la section 3.

[b] Couche EAP (EAP layer). La couche EAP reçoit et transmet des paquets EAP via la couche inférieure, implémente la détection de doublons et la retransmission, et délivre et reçoit des messages EAP vers et depuis les couches pair et authentificateur EAP.

[c] Couches pair et authentificateur EAP (EAP peer and authenticator layers). Sur la base du champ Code, la couche EAP démultiplexe les paquets EAP entrants vers les couches pair et authentificateur EAP. Typiquement, une implémentation EAP sur un hôte donné supportera soit la fonctionnalité pair soit authentificateur, mais il est possible pour un hôte d'agir à la fois comme pair EAP et authentificateur. Dans une telle implémentation, les couches pair et authentificateur EAP seront présentes.

[d] Couches de méthode EAP (EAP method layers). Les méthodes EAP implémentent les algorithmes d'authentification et reçoivent et transmettent des messages EAP via les couches pair et authentificateur EAP. Étant donné que le support de fragmentation n'est pas fourni par EAP lui-même, c'est la responsabilité des méthodes EAP, qui sont discutées dans la section 5.

Le modèle de multiplexage EAP est illustré dans la figure 1 ci-dessous. Notez qu'il n'y a aucune exigence qu'une implémentation se conforme à ce modèle, tant que le comportement sur le fil est cohérent avec celui-ci.

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

Figure 1 : Modèle de Multiplexage EAP

Dans EAP, le champ Code fonctionne un peu comme un numéro de protocole dans IP. Il est supposé que la couche EAP démultiplexe les paquets EAP entrants selon le champ Code. Les paquets EAP reçus avec Code=1 (Request), 3 (Success) et 4 (Failure) sont livrés par la couche EAP à la couche pair EAP, si implémentée. Les paquets EAP avec Code=2 (Response) sont livrés à la couche authentificateur EAP, si implémentée.

Dans EAP, le champ Type fonctionne un peu comme un numéro de port dans UDP ou TCP. Il est supposé que les couches pair et authentificateur EAP démultiplexent les paquets EAP entrants selon leur Type, et les livrent uniquement à la méthode EAP correspondant à ce Type. Une implémentation de méthode EAP sur un hôte peut s'enregistrer pour recevoir des paquets des couches pair ou authentificateur, ou des deux, selon le(s) rôle(s) qu'elle supporte.

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

Une Notification Response est uniquement utilisée comme confirmation que le pair a reçu la Notification Request, pas qu'il l'a traitée ou affiché le message à l'utilisateur. On ne peut pas supposer que le contenu de la Notification Request ou Response soit disponible pour une autre méthode. Le Type Notification est discuté dans la section 5.2.

Nak (Type 3) ou Expanded Nak (Type 254) sont utilisés à des fins de négociation de méthode. Les pairs répondent à une EAP Request initiale pour un Type inacceptable avec une Nak Response (Type 3) ou Expanded Nak Response (Type 254). On ne peut pas supposer que le contenu de(s) Nak Response(s) soit disponible pour une autre méthode. Le(s) Type(s) Nak sont discutés dans la section 5.3.

Les paquets EAP avec des Codes de Success ou Failure n'incluent pas de champ Type et ne sont pas livrés à une méthode EAP. Success et Failure sont discutés dans 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 à être livrées à d'autres méthodes EAP.

2.3. Comportement Pass-Through

Lors du fonctionnement en tant qu'"authentificateur pass-through", un authentificateur effectue des vérifications sur les champs Code, Identifier et Length comme décrit dans la section 4.1. Il transmet les paquets EAP reçus du pair et destinés à sa couche authentificateur au serveur d'authentification backend ; les paquets reçus du serveur d'authentification backend destinés au pair sont transmis à celui-ci.

Un hôte recevant un paquet EAP ne peut faire qu'une des trois choses avec : agir dessus, le rejeter ou le transmettre. La décision de transmission est typiquement basée uniquement sur l'examen des champs Code, Identifier et Length. Une implémentation d'authentificateur pass-through DOIT être capable de transmettre les paquets EAP reçus du pair avec Code=2 (Response) au serveur d'authentification backend. Elle DOIT également être capable de recevoir des paquets EAP du serveur d'authentification backend et de transmettre des paquets EAP de Code=1 (Request), Code=3 (Success) et Code=4 (Failure) au pair.

Sauf si l'authentificateur implémente localement une ou plusieurs méthodes d'authentification qui supportent le rôle d'authentificateur, les champs d'en-tête de couche de méthode EAP (Type, Type-Data) ne sont pas examinés dans le cadre de la décision de transmission. Lorsque l'authentificateur supporte des méthodes d'authentification locales, il PEUT examiner le champ Type pour déterminer s'il doit agir sur le paquet lui-même ou le transmettre. Les implémentations d'authentificateur pass-through conformes DOIVENT par défaut transmettre les paquets EAP de tout 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 livrés à la couche pair. Par conséquent, à moins qu'un hôte n'implémente une couche pair EAP, ces paquets seront silencieusement rejetés. De même, les paquets EAP reçus avec Code=2 (Response) sont démultiplexés par la couche EAP et livrés à la couche authentificateur. Par conséquent, à moins qu'un hôte n'implémente une couche authentificateur EAP, ces paquets seront silencieusement rejetés. Le comportement d'un "pair pass-through" est indéfini dans cette spécification et n'est pas pris en charge par les protocoles AAA tels que RADIUS [RFC3579] et Diameter [DIAM-EAP].

Le modèle de transmission est illustré dans la figure 2.

Pair Authentificateur Pass-Through Serveur d'Authentification

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

Figure 2 : Authentificateur Pass-Through

Pour les sessions dans lesquelles l'authentificateur agit comme 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 d'un paquet EAP envoyé avec l'indication Accept/Reject, ou l'absence d'un tel paquet EAP encapsulé.

2.4. Opération Pair-à-Pair (Peer-to-Peer Operation)

Étant donné qu'EAP est un protocole pair-à-pair, une authentification indépendante et simultanée peut avoir lieu dans la direction inverse (selon les capacités de la couche inférieure). Les deux extrémités du lien peuvent agir comme authentificateurs et pairs en même temps. Dans ce cas, il est nécessaire que les deux extrémités implémentent les couches authentificateur et pair EAP. De plus, les implémentations de méthode EAP sur les deux pairs doivent supporter la fonctionnalité authentificateur et pair.

Bien qu'EAP supporte l'opération pair-à-pair, certaines implémentations EAP, méthodes, protocoles AAA et couches de liaison peuvent ne pas le supporter. Certaines méthodes EAP peuvent supporter l'authentification asymétrique, avec un type d'identifiant requis pour le pair et un autre type pour l'authentificateur. Les hôtes supportant l'opération pair-à-pair avec une telle méthode devraient être provisionnés avec les deux types d'identifiants.

Par exemple, EAP-TLS [RFC2716] est un protocole client-serveur dans lequel des profils de certificat distincts sont généralement utilisés pour le client et le serveur. Cela implique qu'un hôte supportant l'authentification pair-à-pair avec EAP-TLS devrait implémenter les couches pair et authentificateur EAP, supporter les rôles pair et authentificateur dans l'implémentation EAP-TLS, et provisionner des certificats appropriés pour chaque rôle.

Les protocoles AAA tels que RADIUS/EAP [RFC3579] et Diameter EAP [DIAM-EAP] ne supportent que l'opération "authentificateur pass-through". Comme noté dans [RFC3579] Section 2.6.2, un serveur RADIUS répond à une Access-Request encapsulant un paquet EAP-Request, Success ou Failure avec un Access-Reject. Il n'y a donc pas de support pour l'opération "pair pass-through".

Même lorsqu'une méthode est utilisée qui supporte l'authentification mutuelle et les indications de résultat, plusieurs considérations peuvent dicter que deux authentifications EAP (une dans chaque direction) sont requises. Celles-ci incluent :

[1] Support pour la dérivation de clé de session bidirectionnelle dans la couche inférieure. Les couches inférieures telles que IEEE 802.11 peuvent ne supporter que la dérivation unidirectionnelle et le transport de clés de session transitoires. Par exemple, l'échange de clé de groupe défini dans [IEEE-802.11i] est unidirectionnel, puisqu'en mode infrastructure IEEE 802.11, seul le point d'accès (AP) envoie du trafic multicast/broadcast. En mode ad hoc IEEE 802.11, où l'un ou l'autre pair peut envoyer du trafic multicast/broadcast, deux échanges de clé de groupe unidirectionnels sont requis. En raison des limitations de conception, cela implique également la nécessité de dérivations de clé unicast et d'échanges de méthode EAP dans chaque direction.

[2] Support pour le tie-breaking dans la couche inférieure. Les couches inférieures telles que IEEE 802.11 ad hoc ne supportent pas le "tie-breaking" dans lequel deux hôtes initiant l'authentification l'un avec l'autre ne procéderont qu'à une seule authentification. Cela implique que même si 802.11 devait supporter un échange de clé de groupe bidirectionnel, deux authentifications, une dans chaque direction, pourraient toujours se produire.

[3] Satisfaction de la politique du pair. Les méthodes EAP peuvent supporter des indications de résultat, permettant au pair d'indiquer au serveur EAP dans la méthode qu'il a authentifié avec succès le serveur EAP, ainsi que pour le serveur d'indiquer qu'il a authentifié le pair. Cependant, un authentificateur pass-through ne sera pas conscient que le pair a accepté les identifiants offerts par le serveur EAP, à moins que cette information ne soit fournie à l'authentificateur via le protocole AAA. L'authentificateur DEVRAIT interpréter la réception d'un attribut de clé dans un paquet Accept comme une indication que le pair a authentifié avec succès le serveur.

Cependant, il est possible que la politique d'accès du pair EAP n'ait pas été satisfaite lors de l'échange EAP initial, même si une authentification mutuelle s'est produite. Par exemple, l'authentificateur EAP peut ne pas avoir démontré l'autorisation d'agir à la fois dans les rôles pair et authentificateur. En conséquence, le pair peut exiger une authentification supplémentaire dans la direction inverse, même si le pair a fourni une indication que le serveur EAP s'est authentifié avec succès auprès de lui.