3. Comportement de la Couche Inférieure

3.1. Exigences de la Couche Inférieure (Lower Layer Requirements)

EAP fait les hypothèses suivantes sur les couches inférieures :

[1] Transport non fiable. Dans EAP, l'authentificateur retransmet les requêtes qui n'ont pas encore reçu de réponses, de sorte qu'EAP ne suppose pas que les couches inférieures sont fiables. Étant donné qu'EAP définit son propre comportement de retransmission, il est possible (bien qu'indésirable) que la retransmission se produise à la fois dans la couche inférieure et dans la couche EAP lorsque EAP est exécuté sur une couche inférieure fiable.

Notez que les paquets EAP Success et Failure ne sont pas retransmis. Sans une couche inférieure fiable et avec un taux d'erreur non négligeable, ces paquets peuvent être perdus, entraînant des délais d'expiration. Il est donc souhaitable que les implémentations améliorent leur résilience à la perte de paquets EAP Success ou Failure, comme décrit dans 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 s'appuie sur la détection d'erreur de la couche inférieure (par exemple, CRC, somme de contrôle, MIC, etc.). Les méthodes EAP peuvent ne pas inclure de MIC, ou si elles le font, il peut ne pas être calculé sur tous les champs du paquet EAP, tels que les champs Code, Identifier, Length ou Type. En conséquence, 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 couche de méthode EAP, entraînant des échecs d'authentification.

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

[3] Sécurité de la couche inférieure. EAP n'exige pas que les couches inférieures fournissent des services de sécurité tels que la confidentialité par paquet, l'authentification, l'intégrité et la protection contre la relecture. Cependant, lorsque ces services de sécurité sont disponibles, les méthodes EAP supportant la dérivation de clé (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 de protéger contre la modification, l'usurpation ou la relecture des données. Voir Section 7.1 pour plus de détails.

[4] MTU minimale. EAP est capable de fonctionner sur des couches inférieures qui fournissent une taille MTU EAP de 1020 octets ou plus.

EAP ne supporte pas la découverte de MTU de chemin, et la fragmentation et le réassemblage ne sont pas supportés par EAP, ni par les méthodes définies dans cette spécification : Identity (1), Notification (2), Nak Response (3), MD5-Challenge (4), One Time Password (5), Generic Token Card (6) et expanded Nak Response (254) Types.

Typiquement, le pair EAP obtient des informations sur la MTU EAP à partir des couches inférieures et définit la taille de trame EAP à une valeur appropriée. Lorsque l'authentificateur fonctionne en mode pass-through, le serveur d'authentification n'a pas de moyen direct de déterminer la MTU EAP, et s'appuie donc sur l'authentificateur pour lui fournir ces informations, par exemple via l'attribut Framed-MTU, comme décrit dans [RFC3579], Section 2.4.

Bien que des méthodes telles que EAP-TLS [RFC2716] supportent la fragmentation et le réassemblage, les méthodes EAP originellement conçues pour une utilisation dans PPP où une MTU de 1500 octets est garantie pour les trames de contrôle (voir [RFC1661], Section 6.1) peuvent manquer de fonctionnalités de fragmentation et de réassemblage.

Les méthodes EAP peuvent supposer une MTU EAP minimale de 1020 octets en l'absence d'autres informations. Les méthodes EAP DEVRAIENT inclure le support de la fragmentation et du réassemblage si leurs charges utiles peuvent être plus grandes que cette MTU EAP minimale.

EAP est un protocole lock-step, ce qui implique une certaine inefficacité lors de la gestion de la fragmentation et du réassemblage. Par conséquent, si la couche inférieure supporte la fragmentation et le réassemblage (comme lorsque EAP est transporté sur IP), il peut être préférable que la fragmentation et le réassemblage se produisent dans la couche inférieure plutôt que dans EAP. Cela peut être accompli en fournissant une MTU EAP artificiellement grande à EAP, provoquant la gestion de la fragmentation et du réassemblage au sein de la couche inférieure.

[5] Duplication possible. Lorsque la couche inférieure est fiable, elle fournira à la couche EAP un flux de paquets non dupliqués. Cependant, bien qu'il soit souhaitable que les couches inférieures prévoient la non-duplication, ce n'est pas une exigence. Le champ Identifier fournit au pair et à l'authentificateur la capacité de détecter les doublons.

[6] Garanties d'ordre. EAP n'exige pas que l'Identifier soit monotonement croissant, et s'appuie donc sur les garanties d'ordre de la couche inférieure pour un fonctionnement correct. EAP a été initialement défini pour fonctionner sur PPP, et [RFC1661] Section 1 a une exigence d'ordre :

"Le protocole point-à-point est conçu pour des liaisons simples qui transportent des paquets entre deux pairs. Ces liaisons fournissent une opération bidirectionnelle simultanée en duplex intégral et sont supposées livrer les paquets dans l'ordre."

Les transports de couche inférieure pour EAP DOIVENT préserver l'ordre entre une source et une destination à un niveau de priorité donné (la garantie d'ordre fournie par [IEEE-802]).

Le réordonnancement, s'il se produit, entraînera typiquement un échec d'authentification EAP, provoquant la réexécution de l'authentification EAP. Dans un environnement où le réordonnancement est probable, il est donc attendu que les échecs d'authentification EAP seront courants. Il est RECOMMANDÉ que EAP ne soit exécuté que sur des couches inférieures qui fournissent des garanties d'ordre ; l'exécution d'EAP sur un transport IP ou UDP brut n'est PAS RECOMMANDÉE. L'encapsulation d'EAP dans RADIUS [RFC3579] satisfait les exigences d'ordre, puisque RADIUS est un protocole "lock-step" qui livre les paquets dans l'ordre.

3.2. Utilisation d'EAP dans PPP (EAP Usage Within PPP)

Afin d'établir des communications 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 que la liaison a été établie, PPP prévoit une phase d'authentification optionnelle avant de passer à la phase de protocole de couche réseau.

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

Si l'identité du pair a été établie dans la phase d'authentification, le serveur peut utiliser cette identité dans la sélection d'options pour les négociations de couche réseau suivantes.

Lorsqu'il est implémenté dans PPP, EAP ne sélectionne pas un mécanisme d'authentification spécifique lors de la phase de contrôle de liaison PPP, mais reporte plutôt cela jusqu'à la phase d'authentification. Cela permet à l'authentificateur de demander plus d'informations avant de déterminer le mécanisme d'authentification spécifique. Cela permet également l'utilisation d'un serveur "backend" qui implémente réellement les divers mécanismes tandis que l'authentificateur PPP transmet simplement l'échange d'authentification. Les phases d'établissement de liaison et d'authentification PPP, ainsi que l'option de configuration du protocole d'authentification, sont définies dans le protocole point-à-point (PPP) [RFC1661].

3.2.1. Format d'Option de Configuration PPP (PPP Configuration Option Format)

Un résumé du format d'option de configuration du protocole d'authentification PPP pour négocier EAP suit. Les champs sont transmis de gauche à droite.

Exactement un paquet EAP est encapsulé dans le champ Information d'une trame de couche liaison de données PPP où le champ de 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 (Longueur)

Authentication Protocol (Protocole d'Authentification)

C227 (Hex) pour Extensible Authentication Protocol (EAP)

3.3. Utilisation d'EAP dans IEEE 802 (EAP Usage Within IEEE 802)

L'encapsulation d'EAP sur IEEE 802 est définie dans [IEEE-802.1X]. L'encapsulation IEEE 802 d'EAP n'implique pas PPP, et IEEE 802.1X n'inclut pas de support pour les négociations de couche liaison ou réseau. En conséquence, au sein d'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 (Lower Layer Indications)

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

Pour améliorer la fiabilité, si un pair reçoit une indication de succès de la couche inférieure telle que définie dans la Section 7.2, il PEUT conclure qu'un paquet Success a été perdu et se comporter comme s'il avait effectivement reçu un paquet Success. Cela inclut le choix d'ignorer le Success dans certaines circonstances comme décrit dans la Section 4.2.

Une discussion de certains problèmes de fiabilité et de sécurité avec les indications de couche inférieure dans PPP, les réseaux filaires IEEE 802 et les LAN sans fil IEEE 802.11 peut être trouvée dans les considérations de sécurité, Section 7.12.

Après que l'authentification EAP est terminée, le pair transmettra et recevra typiquement des données via l'authentificateur. Il est souhaitable de fournir l'assurance que les entités transmettant des données sont les mêmes que celles qui ont terminé avec succès l'authentification EAP. Pour accomplir cela, il est nécessaire que la couche inférieure fournisse l'intégrité par paquet, l'authentification et la protection contre la relecture, et lie ces services par paquet aux clés dérivées pendant l'authentification EAP. Sinon, il est possible que le trafic de données ultérieur soit modifié, usurpé ou rejoué.

Lorsque le matériel de clé pour la suite de chiffrement de la couche inférieure est lui-même fourni par EAP, la négociation de la suite de chiffrement et l'activation de la clé sont contrôlées par la couche inférieure. Dans PPP, les suites de chiffrement sont négociées dans ECP de sorte qu'il n'est pas possible d'utiliser les clés dérivées de l'authentification EAP avant l'achèvement d'ECP. Par conséquent, un échange EAP initial ne peut pas être protégé par une suite de chiffrement PPP, bien qu'une ré-authentification EAP puisse être protégée.

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