3. Lower Layer Behavior

3.1. Exigences de la couche inférieure

EAP fait les hypothèses suivantes sur la couche inférieure :

[1] Transport non fiable. Dans EAP, l'authenticateur retransmet les Request pour lesquelles aucune Response n'a été reçue, donc EAP ne suppose pas que la couche inférieure est fiable. Étant donné qu'EAP définit son propre comportement de retransmission, lorsque EAP fonctionne sur une couche inférieure fiable, il est possible (bien que peu recommandé) que des retransmissions se produisent à la fois dans la couche inférieure et dans la couche EAP.

Notez que les paquets EAP Success et Failure ne sont pas retransmis. Sans couche inférieure fiable et avec un taux d'erreur non négligeable, ces paquets peuvent être perdus, entraînant un délai d'attente. Par conséquent, il est souhaitable que les implémentations augmentent leur résilience à la perte des paquets EAP Success ou Failure comme décrit à la section 4.2.

[2] Détection d'erreur de la couche inférieure. Bien qu'EAP ne suppose pas que la couche inférieure est fiable, il dépend de la détection d'erreur de la couche inférieure (telle que CRC, Checksum, MIC, etc.). Les méthodes EAP peuvent ne pas inclure de MIC, ou même si elles le font, peuvent ne pas le calculer sur tous les champs du paquet EAP (comme les champs Code, Identifier, Length ou Type). Par conséquent, sans détection d'erreur de la couche inférieure, des erreurs non détectées pourraient s'infiltrer dans les champs d'en-tête de la couche EAP ou de la méthode EAP, entraînant un échec d'authentification.

Par exemple, EAP TLS [RFC2716] calcule son MIC uniquement sur le champ Type-Data et traite l'échec de validation du MIC comme une erreur fatale. Sans détection d'erreur de la couche inférieure, cette méthode et d'autres similaires ne fonctionneraient pas de manière fiable.

[3] Sécurité de la couche inférieure. EAP n'exige pas que la couche inférieure fournisse des services de sécurité tels que la confidentialité, l'authentification, l'intégrité et la protection contre les relectures par paquet. Cependant, lorsque ces services de sécurité sont fournis, les méthodes EAP prenant en charge la dérivation de clés (voir section 7.2.1) peuvent être utilisées pour fournir du matériel de clé dynamique. Cela permet de lier l'authentification EAP aux données ultérieures et d'empêcher leur modification, usurpation ou relecture. Voir section 7.1 pour plus de détails.

[4] MTU minimum. EAP peut fonctionner sur une couche inférieure fournissant une taille MTU EAP d'au moins 1020 octets.

EAP ne prend pas en charge la découverte du MTU du chemin, et la fragmentation et la réassemblage ne sont pas prises en charge par EAP, ni par les méthodes définies dans ce document : les types Identity (1), Notification (2), Nak Response (3), MD5-Challenge (4), One Time Password (5), Generic Token Card (6) et expanded Nak Response (254).

En général, l'homologue EAP obtient des informations sur le MTU EAP à partir de la couche inférieure et définit la taille des trames EAP à une valeur appropriée. Lorsque l'authenticateur fonctionne en mode pass-through, le serveur d'authentification n'a aucun moyen direct de déterminer le MTU EAP et s'appuie donc sur l'authenticateur pour lui fournir cette information, par exemple via l'attribut Framed-MTU, comme décrit dans [RFC3579] section 2.4.

Bien que des méthodes comme EAP-TLS [RFC2716] prennent en charge la fragmentation et la réassemblage, les méthodes EAP initialement conçues pour être utilisées dans PPP (où une MTU de 1500 octets est garantie pour les trames de contrôle, voir [RFC1661] section 6.1) peuvent ne pas avoir de fonctionnalité de fragmentation et de réassemblage.

En l'absence d'autres informations, une méthode EAP peut supposer un MTU EAP minimum de 1020 octets. Si la charge utile d'une méthode EAP est susceptible d'être supérieure à ce MTU EAP minimum, elle DEVRAIT inclure la prise en charge de la fragmentation et de la réassemblage.

EAP étant un protocole "pas à pas" (lock step), il y a une certaine inefficacité dans le traitement de la fragmentation et de la réassemblage. Par conséquent, si la couche inférieure prend en charge la fragmentation et la réassemblage (comme lorsque EAP est transporté sur IP), il peut être préférable que la fragmentation et la réassemblage se produisent dans la couche inférieure plutôt que dans EAP. Cela peut être réalisé en fournissant un MTU EAP artificiellement plus grand à EAP, de sorte que la fragmentation et la réassemblage soient traitées dans la couche inférieure.

[5] Doublons possibles. Dans le cas d'une couche inférieure fiable, elle fournira à la couche EAP un flux de paquets sans doublons. Cependant, bien que la fourniture de paquets sans doublons soit souhaitable, ce n'est pas une exigence. Le champ Identifier fournit aux homologues et aux authenticateurs la capacité de détecter les doublons.

[6] Garanties d'ordonnancement. EAP n'exige pas que Identifier soit strictement croissant, et s'appuie donc sur les garanties d'ordonnancement de la couche inférieure pour fonctionner correctement. EAP a été initialement défini pour fonctionner sur PPP, et [RFC1661] section 1 comporte une exigence d'ordonnancement :

"Le Point-to-Point Protocol est conçu pour des liaisons simples entre deux pairs. Ces liaisons fournissent un fonctionnement bidirectionnel simultané en duplex intégral et supposent la livraison des paquets dans l'ordre."

Le transport de la couche inférieure EAP DOIT maintenir l'ordre entre la source et la destination à une priorité donnée (garanties d'ordonnancement fournies par [IEEE-802]).

Si une réorganisation se produit, cela entraînera généralement un échec d'authentification EAP, provoquant une nouvelle exécution de l'authentification EAP. Par conséquent, dans les environnements où une réorganisation peut se produire, les échecs d'authentification EAP sont censés être courants. Il est recommandé d'exécuter EAP uniquement sur des couches inférieures fournissant des garanties d'ordonnancement ; l'exécution de EAP sur un transport IP ou UDP brut N'EST PAS RECOMMANDÉE. L'encapsulation de EAP dans RADIUS [RFC3579] satisfait l'exigence d'ordonnancement, car RADIUS est un protocole "pas à pas" livrant les paquets dans l'ordre.

3.2. Utilisation de EAP dans PPP

Pour établir la communication sur une liaison point à point, chaque extrémité de la liaison PPP envoie d'abord des paquets LCP pour configurer la liaison de données pendant la phase d'établissement de liaison. Après l'établissement de la liaison, PPP fournit une phase d'authentification facultative avant d'entrer dans la phase du protocole de couche réseau.

Par défaut, l'authentification n'est pas obligatoire. Si l'authentification de la liaison est requise, l'implémentation DOIT spécifier l'option de configuration du protocole d'authentification pendant la phase d'établissement de liaison.

Si l'identité de l'homologue est déterminée pendant la phase d'authentification, le serveur peut utiliser cette identité dans le choix des options de négociation de la couche réseau ultérieure.

Lorsqu'il est implémenté dans PPP, EAP ne sélectionne pas de mécanisme d'authentification spécifique pendant la phase de contrôle de liaison, mais le diffère à la phase d'authentification. Cela permet à l'authenticateur de demander plus d'informations avant de déterminer un mécanisme d'authentification spécifique. Cela permet également l'utilisation d'un serveur "backend" qui implémente réellement divers mécanismes, l'authenticateur PPP se contentant de relayer l'échange d'authentification. La phase d'établissement de liaison et d'authentification PPP, ainsi que l'option de configuration du protocole d'authentification, sont définies dans le Point-to-Point Protocol (PPP) [RFC1661].

3.2.1. Format de l'option de configuration PPP

Le format de l'option de configuration du protocole d'authentification PPP utilisée pour négocier EAP est résumé ci-dessous. Les champs sont transmis de gauche à droite.

Exactement un paquet EAP est encapsulé dans le champ Information de la trame de la couche liaison de données PPP, où le champ Protocole indique le type hex C227 (PPP EAP).

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Authentication Protocol

C227 (hexadécimal) pour le Extensible Authentication Protocol (EAP)

3.3. Utilisation de EAP dans IEEE 802

L'encapsulation de EAP dans IEEE 802 est définie dans [IEEE-802.1X]. L'encapsulation de EAP par IEEE 802 n'implique pas PPP, et IEEE 802.1X ne contient pas de prise en charge de la négociation de liaison ou de couche réseau. Par conséquent, dans IEEE 802.1X, il n'est pas possible de négocier des mécanismes d'authentification non EAP, tels que PAP ou CHAP [RFC1994].

3.4. Indications de la couche inférieure

La fiabilité et la sécurité des indications de la couche inférieure dépendent de la couche inférieure. Étant donné que EAP est indépendant du support, la présence ou l'absence de sécurité de la couche inférieure n'est pas prise en compte lors du traitement des messages EAP.

Pour améliorer la fiabilité, si l'homologue reçoit une indication de succès de la couche inférieure telle que définie à la section 7.2, il PEUT conclure qu'un paquet Success a été perdu et agir comme s'il avait réellement reçu le paquet Success. Cela inclut l'ignorance du Success dans certains cas comme décrit à la section 4.2.

Une discussion sur certains problèmes de fiabilité et de sécurité des indications de la couche inférieure dans PPP, les réseaux filaires IEEE 802 et les réseaux locaux sans fil IEEE 802.11 se trouve dans les considérations de sécurité, section 7.12.

Après l'achèvement de l'authentification EAP, l'homologue transmet généralement des données via l'authenticateur. Il est attendu qu'il y ait une garantie que l'entité transmettant et recevant les données est la même que celle qui a complété avec succès l'authentification EAP. Pour ce faire, il est nécessaire que la couche inférieure fournisse une intégrité, une authentification et une protection contre les relectures par paquet, et lie ces services par paquet aux clés dérivées pendant l'authentification EAP. Sinon, le trafic de données ultérieur pourrait être modifié, usurpé ou rejoué.

Lorsque le matériel de clé du suite cryptographique de la couche inférieure est fourni par EAP lui-même, la négociation de la suite cryptographique et l'activation de la clé sont contrôlées par la couche inférieure. Dans PPP, la suite cryptographique est négociée dans ECP, donc il est impossible d'utiliser les clés dérivées de l'authentification EAP avant la fin d'ECP. Par conséquent, l'échange EAP initial ne peut pas être protégé par la suite cryptographique PPP, bien que la ré-authentification EAP puisse l'être.

Dans les supports IEEE 802, l'activation de la clé initiale se produit également généralement après l'achèvement de l'authentification EAP. Par conséquent, l'échange EAP initial ne peut généralement pas être protégé par la suite cryptographique de la couche inférieure, bien que l'échange de ré-authentification ou de pré-authentification EAP puisse l'être.