Aller au contenu principal

7. Security Considerations

7. Security Considerations​

Cette section définit un modèle de menace général, ainsi que les revendications de sécurité des méthodes EAP qui atténuent ces menaces.

Il est prévu que le modèle de menace général et les revendications de sécurité correspondantes soient utilisés pour définir les exigences des méthodes EAP utilisées dans des environnements spécifiques. Un exemple d'une telle analyse d'exigences est fourni dans [IEEE-802.11i-req]. Une section sur les revendications de sécurité est requise dans les spécifications de méthodes EAP, afin que les méthodes EAP puissent être évaluées par rapport aux exigences.

7.1. Modèle de menace​

EAP a été développé pour être utilisé avec PPP [RFC1661], puis adapté pour être utilisé avec les réseaux filaires IEEE 802 [IEEE-802] dans [IEEE-802.1X]. Par la suite, EAP a été proposé pour une utilisation dans les réseaux LAN sans fil et sur Internet. Dans tous ces cas, un attaquant a la possibilité d'accéder à la liaison sur laquelle les paquets EAP sont transportés. Par exemple, [DECEPTION] documente des attaques contre l'infrastructure téléphonique.

Un attaquant ayant accès à la liaison peut lancer de multiples attaques, notamment :

[1] L'attaquant peut tenter de découvrir l'identité de l'utilisateur en écoutant le trafic d'authentification.

[2] L'attaquant peut tenter de modifier ou d'usurper les paquets EAP.

[3] L'attaquant peut lancer une attaque par déni de service en usurpant les indications de la couche inférieure ou les paquets Success/Failure, en rejouant les paquets EAP, ou en générant des paquets avec des Identifier chevauchants.

[4] L'attaquant peut tenter de récupérer une phrase secrète en lançant une attaque par dictionnaire hors ligne.

[5] L'attaquant peut tenter de convaincre le peer de se connecter à un réseau non fiable en lançant une attaque de l'homme du milieu.

[6] L'attaquant peut tenter de compromettre la négociation EAP, afin de provoquer la sélection d'une méthode d'authentification plus faible.

[7] L'attaquant peut tenter d'exploiter des techniques de dérivation de clés faibles utilisées au sein de la méthode EAP pour récupérer des clés.

[8] L'attaquant peut tenter d'exploiter des suites cryptographiques faibles utilisées ultérieurement après l'achèvement de la session EAP.

[9] L'attaquant peut tenter de lancer une attaque par rétrogradation sur la négociation de suite cryptographique de la couche inférieure, afin de garantir l'utilisation ultérieure d'une suite cryptographique plus faible après l'authentification EAP.

[10] Un attaquant agissant comme authenticator peut fournir des informations incorrectes au peer EAP et/ou au serveur via un mécanisme hors bande (par exemple via AAA ou un protocole de couche inférieure). Cela inclut l'usurpation de l'identité d'un autre authenticator, ou la fourniture d'informations incohérentes au peer et au serveur EAP.

Selon la couche inférieure, ces attaques peuvent être menées sans nécessiter de proximité physique. Lorsque EAP est utilisé pour les réseaux sans fil, les paquets EAP peuvent être transférés par un authenticator (par exemple une pré-authentification), de sorte qu'un attaquant n'a pas besoin d'être dans la portée de l'authenticator pour l'attaquer ou attaquer son peer. Lorsque EAP est utilisé sur Internet, les attaques peuvent être lancées à une plus grande distance.

7.2. Revendications de sécurité​

Afin d'élucider clairement la sécurité fournie par une méthode EAP, la spécification de la méthode EAP DOIT inclure une section sur les revendications de sécurité, comprenant les revendications suivantes :

[a] Mécanisme. Il s'agit d'un énoncé sur la technique d'authentification : certificats, clé pré-partagée, mot de passe, carte à jeton, etc.

[b] Revendications de sécurité. Il s'agit d'un énoncé sur les propriétés de sécurité revendiquées par la méthode, en utilisant la terminologie définie à la section 7.2.1 : authentification mutuelle, protection de l'intégrité, protection contre le rejeu, confidentialité, dérivation de clés, résistance aux attaques par dictionnaire, reconnexion rapide, liaison cryptographique. La section sur les revendications de sécurité de la spécification de la méthode EAP DEVRAIT fournir une justification pour les revendications faites. Cela peut être accompli en incluant une preuve en annexe, ou en incluant une référence à une preuve.

[c] Force de la clé. Si la méthode dérive des clés, alors la force de clé effective DOIT être estimée. Cette estimation est destinée à permettre aux utilisateurs potentiels de la méthode de déterminer si les clés résultantes sont suffisamment fortes pour l'application prévue.

La force de clé effective devrait être exprimée en nombre de bits, définie comme suit : si la force de clé effective est de N bits, alors la meilleure méthode connue de récupération de clé (avec une probabilité non négligeable) nécessite en moyenne un effort équivalent à 2^(N-1) opérations de chiffrement par blocs typiques. Cet énoncé devrait être accompagné d'une brève justification expliquant comment ce nombre a été obtenu. Cette explication devrait inclure les paramètres nécessaires, basés sur les connaissances actuelles des algorithmes, pour atteindre la force de clé indiquée.

(Note : bien qu'il soit difficile de définir précisément la signification de « effort équivalent » et de « chiffrement par blocs typique », une approximation raisonnable suffit ici. Pour plus de discussion, voir par exemple [SILVERMAN].)

La force de la clé dépend de la méthode utilisée pour dériver la clé. Par exemple, si la clé est dérivée d'un secret partagé (tel qu'un mot de passe ou une clé à long terme) et éventuellement de quelques informations publiques (telles qu'un nonce), alors la force de clé effective est limitée par la force de la clé à long terme (en supposant que le processus de dérivation est simple sur le plan calcul). Encore un autre exemple, lors de l'utilisation d'algorithmes à clé publique, la force de la clé symétrique dépend de la force de la clé publique utilisée.

[d] Description de la hiérarchie de clés. Les méthodes EAP qui dérivent des clés DOIVENT fournir une référence à la spécification de la hiérarchie de clés, ou décrire comment la clé de session maîtresse (MSK) et la clé de session maîtresse étendue (EMSK) doivent être dérivées.

[e] Indication de vulnérabilité. En plus des revendications de sécurité faites, la spécification DOIT indiquer lesquelles des revendications de sécurité décrites à la section 7.2.1 ne sont pas faites.

7.2.1. Terminologie des revendications de sécurité pour les méthodes EAP​

Ces termes sont utilisés pour décrire les propriétés de sécurité des méthodes EAP :

Négociation de suite cryptographique protégée

Cela fait référence à la capacité d'une méthode EAP à négocier la suite cryptographique utilisée pour protéger la session EAP, ainsi qu'à protéger l'intégrité de la négociation. Cela ne fait pas référence à la capacité de négocier la suite cryptographique utilisée pour protéger les données.

Authentification mutuelle

Il s'agit d'une méthode EAP dans laquelle l'authenticator authentifie le peer et le peer authentifie l'authenticator, dans un échange imbriqué. Deux méthodes unidirectionnelles distinctes, exécutées en sens inverse, ne fournissent pas l'authentification mutuelle définie ici.

Protection de l'intégrité

Il s'agit de la fourniture de l'authentification de la source de données ainsi que de la protection contre la modification non autorisée des informations des paquets EAP (y compris les requêtes et réponses EAP). Lorsque cette revendication est faite, la spécification de la méthode DOIT décrire les paquets EAP protégés et les champs au sein des paquets EAP.

Protection contre le rejeu

Il s'agit de la protection contre le rejeu de la méthode EAP ou de ses messages (y compris les indications de résultat de succès et d'échec).

Confidentialité

Il s'agit du chiffrement des messages EAP (y compris les requêtes et réponses EAP, ainsi que les indications de résultat de succès et d'échec). Les méthodes faisant cette revendication DOIVENT prendre en charge la protection de l'identité (voir section 7.3).

Dérivation de clés

Il s'agit de la capacité d'une méthode EAP à dériver du matériel de clé exportable (telle que la clé de session maîtresse (MSK) et la clé de session maîtresse étendue (EMSK)). La MSK est utilisée uniquement pour une dérivation de clé ultérieure, et n'est pas utilisée directement pour protéger la session EAP ou les données ultérieures. L'utilisation de l'EMSK est réservée.

Force de la clé

Si la force de clé effective est de N bits, alors la meilleure méthode connue de récupération de clé (avec une probabilité non négligeable) nécessite en moyenne un effort équivalent à 2^(N-1) opérations de chiffrement par blocs typiques.

Résistance aux attaques par dictionnaire

Dans le cas de l'authentification par mot de passe, les mots de passe sont généralement choisis dans un petit ensemble (par rapport à l'ensemble des clés de N bits), ce qui soulève des préoccupations concernant les attaques par dictionnaire. Une méthode peut être dite fournir une protection contre les attaques par dictionnaire si, lorsqu'elle utilise le mot de passe comme clé, elle n'autorise pas une attaque hors ligne avec un facteur de travail basé sur le nombre de mots de passe dans le dictionnaire de l'attaquant.

Reconnexion rapide

Capacité de créer une nouvelle association de sécurité ou d'en rafraîchir une, de manière plus efficace ou avec moins d'allers-retours, lorsqu'une association de sécurité a déjà été établie.

Liaison cryptographique

Capacité du peer EAP à prouver au serveur EAP qu'une seule entité a agi comme peer EAP pour toutes les méthodes exécutées au sein de la méthode de tunnel. La liaison peut également impliquer que le serveur EAP prouve au peer qu'une seule entité a agi comme serveur EAP pour toutes les méthodes exécutées au sein de la méthode de tunnel. Si elle est correctement exécutée, la liaison contribue à atténuer la vulnérabilité de l'homme du milieu.

Indépendance de session

Preuve qu'une attaque passive (telle que la capture d'une session EAP) ou une attaque active (y compris la divulgation de la MSK ou de l'EMSK) ne compromettra pas les MSK ou EMSK ultérieures ou précédentes.

Fragmentation

Il s'agit de savoir si la méthode EAP prend en charge la fragmentation et le réassemblage. Comme indiqué à la section 3.1, si un paquet EAP peut dépasser le MTU minimal de 1020 octets, la méthode EAP devrait prendre en charge la fragmentation et le réassemblage.

Liaison de canal

Communication au sein de la méthode EAP d'attributs de canal protégés par intégrité (tels que des identificateurs de point de terminaison), qui peuvent être comparés aux valeurs communiquées via un mécanisme hors bande (tel que via AAA ou un protocole de couche inférieure).

Note : cette liste de revendications de sécurité n'est pas exhaustive. D'autres propriétés (telles qu'une protection supplémentaire contre le déni de service) peuvent également être pertinentes.

7.3. Protection de l'identité​

L'échange d'identité est facultatif dans la session EAP. Par conséquent, l'échange d'identité peut être omis complètement, ou un échange d'identité spécifique à la méthode peut être utilisé après l'établissement d'un canal protégé.

Cependant, dans les cas où le roaming est pris en charge comme décrit dans [RFC2607], il peut être nécessaire de localiser le serveur d'authentification backend approprié avant que la session d'authentification puisse continuer. La partie domaine du Network Access Identifier (NAI) [RFC2486] est généralement incluse dans EAP-Response/Identity, afin de permettre le routage de l'échange d'authentification vers le serveur d'authentification backend approprié. Par conséquent, bien que la partie nom du peer du NAI puisse être omise dans EAP-Response/Identity en présence de proxys ou de relais, la partie domaine peut être requise.

L'identité dans la réponse d'identité a le potentiel d'être différente de l'identité authentifiée par la méthode EAP. Dans le cas de la confidentialité de l'identité, cela peut être intentionnel. Les méthodes EAP DEVRAIENT utiliser l'identité authentifiée lors de la prise de décisions de contrôle d'accès.

7.4. Attaques de l'homme du milieu​

Lorsque EAP est tunnelisé dans un autre protocole qui omet l'authentification du peer, il existe une vulnérabilité potentielle aux attaques de l'homme du milieu. Pour plus de détails, voir [BINDING] et [MITM].

Comme décrit à la section 2.1, EAP n'autorise pas les séquences de méthodes d'authentification non tunnelisées. Si une séquence de méthodes d'authentification EAP était autorisée, le peer pourrait ne pas avoir de preuve qu'une seule entité a agi comme authenticator pour toutes les méthodes EAP de la séquence. Par exemple, un authenticator pourrait terminer une méthode EAP, puis transférer la méthode suivante de la séquence à une autre partie sans que le peer le sache ou l'approuve. De même, l'authenticator pourrait ne pas avoir de preuve qu'une seule entité a agi comme peer pour toutes les méthodes EAP de la séquence.

Le tunnelage d'EAP dans un autre protocole rend possible une attaque où un authenticator EAP malveillant tunnelise EAP vers un serveur légitime. Dans le cas où le protocole de tunnel est utilisé pour l'établissement de clés mais n'exige pas l'authentification du peer, un attaquant qui convainc un peer légitime de se connecter à lui sera capable de tunneliser les paquets EAP vers le serveur légitime, de s'authentifier avec succès et d'obtenir des clés. Cela permet à l'attaquant de s'établir avec succès comme homme du milieu, d'obtenir l'accès au réseau, et la capacité de déchiffrer le trafic de données entre le peer légitime et le serveur.

Cette attaque peut être atténuée par :

[a] L'exigence d'une authentification mutuelle au sein du mécanisme de tunnel EAP.

[b] L'exigence d'une liaison cryptographique entre le protocole de tunnel EAP et la méthode EAP tunnelisée. Lorsque la liaison cryptographique est prise en charge, un mécanisme pour empêcher les attaques par rétrogradation qui la contourneraient est également requis. Pour plus de détails sur la liaison cryptographique, voir [BINDING].

[c] La limitation des méthodes EAP autorisées à être utilisées sans protection, sur la base des politiques du peer et de l'authenticator.

[d] L'évitement de l'utilisation de tunnels lorsqu'une seule méthode forte est disponible.

7.5. Attaques par modification de paquets​

Bien que les méthodes EAP puissent prendre en charge l'authentification de la source de données par paquet, l'intégrité et la protection contre le rejeu, aucune prise en charge n'est fournie au sein de la couche EAP.

Étant donné que l'Identifier n'est qu'un seul octet, il est facile à deviner, permettant à un attaquant d'injecter ou de rejouer avec succès des paquets EAP. Un attaquant peut également modifier les en-têtes EAP non protégés (Code, Identifier, Length, Type) dans les paquets EAP. Cela peut entraîner le rejet ou la mauvaise interprétation inappropriée des paquets.

Pour protéger les paquets EAP contre la modification, l'usurpation ou le rejeu, il est recommandé d'utiliser des méthodes qui prennent en charge la négociation de suite cryptographique protégée, l'authentification mutuelle, la dérivation de clés, ainsi que la protection de l'intégrité et contre le rejeu. Pour les définitions de ces revendications de sécurité, voir la section 7.2.1.

Une protection peut être fournie en utilisant un MIC spécifique à la méthode. Si un MIC par paquet est adopté au sein de la méthode EAP, le peer, le serveur d'authentification et l'authenticator qui ne fonctionnent pas en mode pass-through DOIVENT valider le MIC. Un échec de validation du MIC DEVRAIT être journalisé. S'il s'agit d'une erreur fatale ou non est décidé par la spécification de la méthode EAP.

Il est recommandé que les méthodes fournissant une protection de l'intégrité des paquets EAP incluent une couverture de tous les champs d'en-tête EAP (y compris les champs Code, Identifier, Length, Type et Type-Data).

Étant donné que les messages EAP de types Identity, Notification et Nak ne contiennent pas leur propre MIC, il peut être souhaitable que le MIC de la méthode EAP couvre les informations contenues dans ces messages, ainsi que l'en-tête de chaque message EAP.

Pour fournir une protection, EAP peut également être encapsulé dans un canal protégé créé par des protocoles tels que ISAKMP [RFC2408], comme cela est fait dans [IKEv2], ou au sein de TLS [RFC2246]. Cependant, comme décrit à la section 7.4, le tunnelage EAP peut entraîner des vulnérabilités de l'homme du milieu.

Les méthodes EAP existantes définissent un message integrity check (MIC) couvrant plusieurs paquets EAP. Par exemple, EAP-TLS [RFC2716] définit un MIC pour les enregistrements TLS qui peuvent être fragmentés en plusieurs fragments ; au sein du message FINISHED, le MIC est calculé sur les messages précédents. Lorsque le MIC couvre plusieurs paquets EAP, un échec de validation du MIC est généralement considéré comme une erreur fatale.

Dans EAP-TLS [RFC2716], un échec de validation du MIC est considéré comme une erreur fatale, car cela est spécifié dans TLS [RFC2246]. Cependant, il est également possible de développer des méthodes EAP prenant en charge un MIC par paquet et de répondre à un échec de validation en rejetant silencieusement le paquet incriminé.

Dans ce document, la description du traitement des messages EAP suppose que, là où une validation de MIC par paquet se produit, elle est effectuée efficacement comme si elle était exécutée avant l'envoi de toute réponse ou la modification de l'état de l'hôte recevant le paquet.

7.6. Attaques par dictionnaire​

Il est connu que les algorithmes d'authentification par mot de passe tels que EAP-MD5, MS-CHAPv1 [RFC2433] et Kerberos V [RFC1510] sont vulnérables aux attaques par dictionnaire. Les vulnérabilités de MS-CHAPv1 sont documentées dans [PPTPv1] ; les vulnérabilités de MS-CHAPv2 dans [PPTPv2] ; les vulnérabilités de Kerberos dans [KRBATTACK], [KRBLIM] et [KERB4WEAK].

Pour empêcher les attaques par dictionnaire, il est recommandé d'utiliser des méthodes d'authentification résistant aux attaques par dictionnaire (comme défini à la section 7.2.1).

Si un algorithme d'authentification connu comme vulnérable aux attaques par dictionnaire est utilisé, la session peut être tunnelisée dans un canal protégé pour fournir une protection supplémentaire. Cependant, comme décrit à la section 7.4, le tunnelage EAP peut entraîner des vulnérabilités de l'homme du milieu, donc une méthode résistant aux attaques par dictionnaire est préférable.

7.7. Connexion à un réseau non fiable​

Pour les méthodes EAP prenant en charge l'authentification unidirectionnelle (telle que EAP-MD5), le peer n'authentifie pas l'authenticator, rendant le peer vulnérable aux attaques d'un authenticator malveillant. Les méthodes prenant en charge l'authentification mutuelle (comme défini à la section 7.2.1) résolvent cette vulnérabilité.

Dans EAP, il n'est pas exigé que l'authentification soit full-duplex, ni que le même protocole soit utilisé dans les deux directions. L'utilisation de protocoles différents dans chaque direction est parfaitement acceptable. Bien sûr, cela dépendra des protocoles spécifiques négociés. Cependant, en général, l'achèvement d'une seule authentification mutuelle unifiée est préférable à deux authentifications unidirectionnelles (une dans chaque direction). Cela est dû au fait que des authentifications distinctes qui ne sont pas liées cryptographiquement pour prouver qu'elles font partie de la même session sont vulnérables aux attaques de l'homme du milieu discutées à la section 7.4.

7.8. Attaques de négociation​

Dans une attaque de négociation, un attaquant tente de convaincre le peer et l'authenticator de négocier une méthode EAP moins sécurisée. EAP ne fournit pas de protection pour les paquets de réponse Nak, bien que les méthodes puissent inclure une couverture de la réponse Nak dans un MIC spécifique à la méthode.

Au sein ou associé à chaque authenticator, il n'est pas prévu qu'un peer nommé spécifiquement prenne en charge un choix de plusieurs méthodes. Cela rendrait le peer vulnérable à une attaque consistant à négocier la méthode la moins sécurisée parmi un ensemble de méthodes. Au contraire, pour chaque peer nommé, il DEVRAIT y avoir une indication indiquant exactement la méthode unique utilisée pour authentifier ce nom de peer. Si le peer a besoin d'utiliser différentes méthodes d'authentification dans différentes circonstances, il DEVRAIT adopter des identités différentes, chacune identifiant exactement une méthode d'authentification.

7.9. Idiosyncrasies d'implémentation​

L'interaction d'EAP avec les couches inférieures telles que PPP et IEEE 802 dépend fortement de l'implémentation.

Par exemple, en cas d'échec d'authentification, certaines implémentations PPP ne terminent pas la liaison, mais limitent le trafic dans les protocoles de couche réseau à un sous-ensemble filtré, ce qui donne au peer l'occasion de mettre à jour les clés ou d'envoyer un courriel à l'administrateur réseau pour indiquer le problème. De même, bien que dans [IEEE-802.1X] un échec d'authentification entraîne le refus de l'accès au port contrôlé, un trafic limité peut être autorisé sur le port non contrôlé.

Dans EAP, il n'y a aucune disposition pour les nouvelles tentatives en cas d'échec d'authentification. Cependant, dans PPP, la machine à états LCP peut renégocier le protocole d'authentification à tout moment, permettant de nouvelles tentatives. De même, dans IEEE 802.1X, le supplicant ou l'authenticator peuvent réauthentifier à tout moment. Il est recommandé que tout compteur utilisé pour l'échec d'authentification ne soit pas réinitialisé jusqu'à ce qu'une authentification réussisse ou que la liaison défaillante soit ultérieurement terminée.

7.10. Dérivation de clés​

Il est possible que le peer et le serveur EAP s'authentifient mutuellement et dérivent des clés. Afin de fournir du matériel de clé pour les suites cryptographiques négociées ultérieurement, les méthodes EAP prenant en charge la dérivation de clés DOIVENT exporter au moins une clé de session maîtresse (MSK) de 64 octets et au moins une clé de session maîtresse étendue (EMSK) de 64 octets. Les méthodes EAP dérivant des clés DOIVENT fournir une authentification mutuelle entre le peer EAP et le serveur EAP.

La MSK et l'EMSK NE DOIVENT PAS être utilisées directement pour protéger les données ; cependant, elles sont de taille suffisante pour dériver la AAA-Key utilisée ultérieurement pour dériver les clés de session temporaires (TSK) à partir de la suite cryptographique sélectionnée. Chaque suite cryptographique est responsable de la spécification de la manière de dériver les TSK à partir de la AAA-Key.

La AAA-Key est dérivée du matériel de clé exporté par la méthode EAP (MSK et EMSK). Cette dérivation se produit sur le serveur AAA. Dans de nombreux protocoles existants utilisant EAP, la AAA-Key et la MSK sont équivalentes, mais des mécanismes plus complexes peuvent exister (voir [KEYFRAME] pour plus de détails).

Les méthodes EAP dérivant des clés DEVRAIENT garantir la fraîcheur de la MSK et de l'EMSK, même dans les cas où l'une des parties peut ne pas avoir de générateur de nombres aléatoires de haute qualité. La méthode recommandée consiste à ce que chaque partie fournisse un nonce d'au moins 128 bits, utilisé dans la dérivation de la MSK et de l'EMSK.

Les méthodes EAP dérivant des clés les exportent (MSK et EMSK) mais n'exportent pas de clés de session temporaires, afin de permettre à la méthode EAP d'être indépendante des suites cryptographiques et des médias. Le matériel de clé exporté par les méthodes EAP DOIT être indépendant de la suite cryptographique négociée pour protéger les données.

Selon la couche inférieure, la méthode EAP peut s'exécuter avant ou après la négociation de la suite cryptographique, donc la suite cryptographique sélectionnée peut être inconnue de la méthode EAP. En fournissant du matériel de clé utilisable avec n'importe quelle suite cryptographique, la méthode EAP peut être utilisée avec une variété de suites cryptographiques et de médias.

Pour maintenir l'indépendance des algorithmes, les méthodes EAP dérivant des clés DEVRAIENT prendre en charge (et documenter) la négociation protégée de la suite cryptographique utilisée entre le peer et le serveur pour protéger la session EAP. Cela diffère de la suite cryptographique négociée entre le peer et l'authenticator pour protéger les données.

La force des clés de session temporaires (TSK) utilisées pour protéger les données dépend en fin de compte de la force des clés générées par la méthode EAP. Si la méthode EAP ne peut pas produire un matériel de clé d'une force suffisante, les TSK peuvent subir des attaques par force brute. Pour prendre en charge les déploiements nécessitant des clés fortes, les méthodes EAP prenant en charge la dérivation de clés DEVRAIENT être capables de générer des MSK et EMSK, chacune ayant une force de clé effective d'au moins 128 bits.

Les méthodes prenant en charge la dérivation de clés DOIVENT démontrer la séparation cryptographique entre les branches MSK et EMSK de la hiérarchie de clés EAP. Sans violer les hypothèses cryptographiques fondamentales (telles que l'irréversibilité des fonctions à sens unique), un attaquant récupérant la MSK ou l'EMSK NE DOIT PAS être en mesure de récupérer l'autre quantité avec un effort inférieur à une attaque par force brute.

Comme défini à la section 7.2.1, les sous-chaînes non chevauchantes de la MSK DOIVENT être cryptographiquement séparées les unes des autres. C'est-à-dire que, sans briser certaines hypothèses cryptographiques difficiles, la connaissance d'une sous-chaîne NE DOIT PAS aider à récupérer une autre sous-chaîne. Cela est requis car certaines suites cryptographiques existantes forment les TSK en divisant simplement la AAA-Key en fragments de longueur appropriée. De même, les sous-chaînes non chevauchantes de l'EMSK DOIVENT être cryptographiquement séparées les unes des autres et par rapport aux sous-chaînes de la MSK.

L'EMSK est réservée pour un usage futur, DOIT être conservée sur le peer EAP et le serveur EAP qui l'ont dérivée ; NE DOIT PAS être transmise ou partagée avec des parties supplémentaires, ni utilisée pour dériver d'autres clés. (Dans les documents futurs spécifiant l'utilisation de l'EMSK, cette restriction sera levée.)

Puisque EAP ne fournit pas de négociation explicite de la durée de vie des clés, le peer EAP, l'authenticator et le serveur d'authentification DOIVENT être préparés pour le cas où une partie rejette l'état de clé qui reste valide sur une autre partie.

Cette spécification ne fournit pas de conseils détaillés sur la manière dont les méthodes EAP dérivent la MSK et l'EMSK, comment la AAA-Key est dérivée de la MSK et/ou de l'EMSK, ou comment les TSK sont dérivées de la AAA-Key.

Le développement et la validation d'algorithmes de dérivation de clés sont difficiles, donc les méthodes EAP DEVRAIENT réutiliser des mécanismes de dérivation de clés bien établis et analysés (tels que ceux spécifiés dans IKE [RFC2409] ou TLS [RFC2246]) plutôt que d'en inventer de nouveaux. Les méthodes EAP DEVRAIENT également exploiter des mécanismes de dérivation de MSK et d'EMSK bien établis et analysés. Pour plus de détails sur la dérivation de clés EAP, voir [KEYFRAME].

7.11. Suites cryptographiques faibles​

Si, après l'authentification EAP initiale, les paquets de données envoyés ne bénéficient pas d'une authentification, d'une intégrité et d'une protection contre le rejeu par paquet, un attaquant ayant accès au média peut injecter des paquets, « retourner des bits » dans les paquets existants, rejouer des paquets, ou même détourner complètement la session. Sans confidentialité par paquet, l'écoute clandestine des paquets est possible.

Pour empêcher la modification, l'usurpation ou l'écoute clandestine des données, il est recommandé d'utiliser des méthodes EAP prenant en charge l'authentification mutuelle et la dérivation de clés (comme défini à la section 7.2.1), ainsi qu'une couche inférieure fournissant confidentialité, authentification, intégrité et protection contre le rejeu par paquet.

De plus, si la couche inférieure effectue une négociation de suite cryptographique, il doit être compris que EAP lui-même ne fournit pas de protection d'intégrité pour cette négociation. Par conséquent, pour éviter les attaques par rétrogradation aboutissant à l'utilisation d'une suite cryptographique plus faible, les clients implémentant la négociation de suite cryptographique de couche inférieure DEVRAIENT empêcher la rétrogradation de la négociation.

Cela peut être accompli en permettant à l'utilisateur de configurer quelles suites cryptographiques sont acceptables en tant que politique de sécurité, ou la négociation de suite cryptographique PEUT être authentifiée à l'aide du matériel de clé dérivé de l'authentification EAP et d'un algorithme MIC pré-convenu avec le peer de couche inférieure.

Les indications de couche de liaison dans PPP, IEEE 802 LAN et IEEE 802.11 LAN sans fil présentent des problèmes de fiabilité et de sécurité :

[a] PPP. Dans PPP, les indications de couche de liaison telles que LCP-Terminate (indication d'échec de liaison) et NCP (indication de succès de liaison) ne sont ni authentifiées ni protégées par intégrité. Par conséquent, un attaquant ayant accès à la liaison peut les usurper.

[b] IEEE 802. Les trames EAPOL-Start et EAPOL-Logoff de IEEE 802.1X ne sont ni authentifiées ni protégées par intégrité. Par conséquent, un attaquant ayant accès à la liaison peut les usurper.

[c] IEEE 802.11. Dans IEEE 802.11, les indications de couche de liaison incluent les trames Disassociate et Deauthenticate (indication d'échec de liaison), ainsi que le premier message de la poignée de main à 4 voies (indication de succès de liaison). Ces messages ne sont ni authentifiés ni protégés par intégrité, et bien qu'ils ne soient pas transférables, un attaquant à portée peut les usurper.

Dans IEEE 802.11, les trames de données IEEE 802.1X peuvent être envoyées en tant que trames de données unicast de classe 3, et sont donc transférables. Cela signifie que bien que les messages EAPOL-Start et EAPOL-Logoff puissent être authentifiés et protégés par intégrité, lorsque la « pré-authentification » est activée, un attaquant authentifié éloigné de la cible peut les usurper.

Dans IEEE 802.11, l'indication « liaison interrompue » est une indication non fiable d'échec de liaison, car la force du signal sans fil peut apparaître et disparaître, et peut être affectée par l'interférence radiofréquence générée par un attaquant. Pour éviter les réinitialisations inutiles, il est recommandé d'atténuer ces indications plutôt que de les transmettre directement à EAP. Puisque EAP prend en charge la retransmission, il est robuste aux pertes de connexion transitoires.

7.13. Séparation de l'authenticator et du serveur d'authentification backend​

Il est possible que le peer EAP et le serveur EAP s'authentifient mutuellement et dérivent la AAA-Key pour la suite cryptographique utilisée pour protéger le trafic de données ultérieur. Cela ne pose pas de problème sur le peer, car le peer et le client EAP résident sur la même machine ; tout ce qui est nécessaire est que le client dérive la AAA-Key de la MSK et de l'EMSK exportées par la méthode EAP, puis transmette les clés de session temporaires (TSK) au module de suite cryptographique.

Cependant, dans les cas où l'authenticator et le serveur d'authentification résident sur des machines différentes, il y a plusieurs implications pour la sécurité :

[a] L'authentification se déroulera entre le peer et le serveur d'authentification, et non entre le peer et l'authenticator. Cela signifie qu'avec EAP seulement, il est impossible pour le peer de vérifier l'identité de l'authenticator avec lequel il communique.

[b] Comme décrit dans [RFC3579], l'authenticator s'appuie sur le protocole AAA pour connaître le résultat de la session d'authentification, et n'examine pas les paquets EAP encapsulés (le cas échéant) pour déterminer le résultat. En pratique, cela signifie que le protocole AAA utilisé entre l'authenticator et le serveur d'authentification DOIT prendre en charge l'authentification par paquet, l'intégrité et la protection contre le rejeu.

[c] Après l'achèvement de la session EAP, les services de sécurité de couche inférieure tels que la confidentialité, l'authentification, l'intégrité et la protection contre le rejeu par paquet étant activés, un protocole d'association de sécurité DEVRAIT s'exécuter entre le peer et l'authenticator, fournissant une authentification mutuelle entre le peer et l'authenticator, garantissant la fraîcheur des clés de session temporaires, fournissant une négociation de capacités et de suite cryptographique protégée pour les données ultérieures, et synchronisant l'utilisation des clés.

[d] La AAA-Key dérivée de la MSK et/ou de l'EMSK négociées entre le peer et le serveur d'authentification PEUT être transmise à l'authenticator. Par conséquent, il est nécessaire de fournir un mécanisme pour transmettre la AAA-Key du serveur d'authentification à l'authenticator qui en a besoin. La spécification de la dérivation, de la transmission et de l'encapsulation de la AAA-Key n'entre pas dans le champ d'application de ce document. Pour plus de détails sur la dérivation de la AAA-Key, voir [KEYFRAME].

7.14. Mots de passe en clair​

Cette spécification ne définit pas de mécanisme d'authentification par mot de passe en clair. Cette omission est intentionnelle. L'utilisation de mots de passe en clair permettrait à un attaquant ayant accès à la liaison sur laquelle les paquets EAP sont transportés de capturer le mot de passe.

Étant donné que les protocoles encapsulant EAP (tels que RADIUS [RFC3579]) peuvent ne pas fournir de confidentialité, les paquets EAP peuvent ensuite être encapsulés pour être transportés sur Internet, où ils peuvent être capturés par un attaquant.

Par conséquent, les mots de passe en clair ne peuvent pas être utilisés en sécurité dans EAP, à moins d'être encapsulés dans un tunnel protégé avec authentification du serveur. Certains des mêmes risques définis à la section 7.2.1 s'appliquent également aux méthodes EAP sans résistance aux attaques par dictionnaire. Pour plus de détails, voir la section 7.6.

7.15. Liaison de canal​

Un authenticator EAP compromis ou mal implémenté a la possibilité de communiquer des informations incorrectes au peer EAP et/ou au serveur. Cela peut permettre à l'authenticator d'usurper l'identité d'un autre authenticator, ou de communiquer des informations incorrectes via un mécanisme hors bande (tel que via AAA ou un protocole de couche inférieure).

Lors de l'utilisation d'EAP en mode pass-through, le peer EAP ne vérifie généralement pas l'identité de l'authenticator pass-through, il vérifie uniquement que l'authenticator pass-through est approuvé par le serveur EAP. Cela crée une vulnérabilité de sécurité potentielle.

La section 4.3.7 de [RFC3579] décrit comment détecter un authenticator pass-through EAP agissant comme client AAA s'il tente d'usurper l'identité d'un autre authenticator (par exemple, en envoyant des attributs NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] ou NAS-IPv6-Address [RFC3162] incorrects via le protocole AAA). Cependant, un authenticator pass-through agissant comme client AAA a la possibilité de fournir des informations correctes au serveur AAA tout en communiquant des informations trompeuses au peer EAP via le protocole de couche inférieure.

Par exemple, un authenticator compromis a la possibilité d'utiliser le Called-Station-Id ou le NAS-Identifier d'un autre authenticator lors de la communication avec le peer EAP via le protocole de couche inférieure, ou un authenticator pass-through agissant comme client AAA a la possibilité de fournir un peer Calling-Station-Id [RFC2865][RFC3580] incorrect au serveur AAA via le protocole AAA.

Pour résoudre cette vulnérabilité, les méthodes EAP PEUVENT prendre en charge l'échange protégé d'attributs de canal (tels que des identificateurs de point de terminaison), y compris, sans s'y limiter : Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] et NAS-IPv6-Address [RFC3162].

En utilisant un tel échange protégé, les attributs de canal fournis par l'authenticator via un mécanisme hors bande peuvent être mis en correspondance avec les attributs échangés au sein de la méthode EAP. Lorsque des divergences sont découvertes, elles DEVRAIENT être journalisées ; d'autres actions PEUVENT également être prises, telles que le refus d'accès.

7.16. Indications de résultat protégées​

Dans EAP, les paquets Success et Failure ne sont ni acquittés ni protégés par intégrité. Lorsque EAP s'exécute sur une couche inférieure qui ne prend pas en charge la retransmission ou la synchronisation de l'état authentifié, les indications de résultat améliorent la résilience à la perte des paquets Success et Failure. Sur des médias fournissant la retransmission ainsi qu'une synchronisation de l'état authentifié via la poignée de main à 4 voies définie dans [IEEE-802.11i] (tels que IEEE 802.11), la résilience supplémentaire est généralement d'un bénéfice limité.

Selon la méthode et la situation, les indications de résultat peuvent être usurpées par un attaquant. Une méthode est dite fournir des indications de résultat protégées si elle prend en charge les indications de résultat ainsi que les revendications « protection de l'intégrité » et « protection contre le rejeu ». Les méthodes prenant en charge des indications de résultat protégées DOIVENT indiquer quelles indications de résultat sont protégées et lesquelles ne le sont pas.

Les indications de résultat protégées n'exigent pas de protection contre un authenticator malveillant. Dans une méthode d'authentification mutuelle, exiger que le serveur authentifie le peer avant que le peer n'accepte un paquet Success peut empêcher un attaquant d'agir comme authenticator malveillant.

Cependant, après que le serveur a authentifié le peer, mais avant que le peer n'ait authentifié le serveur, un attaquant a la possibilité d'usurper un paquet Success. Si le peer accepte le paquet Success usurpé et tente d'accéder au réseau alors qu'il ne s'est pas encore authentifié avec succès auprès du serveur, une attaque par déni de service contre le peer peut être lancée. Après une telle attaque, si la couche inférieure prend en charge une indication d'échec, l'authenticator peut synchroniser l'état avec le peer en fournissant une indication d'échec de couche inférieure. Voir la section 7.12 pour plus de détails.

Si le serveur authentifie le peer et envoie un paquet Success avant de déterminer si le peer a authentifié l'authenticator, un dépassement de temps d'inactivité peut se produire si l'authenticator n'est pas authentifié par le peer. Là où la couche inférieure le prend en charge, l'authenticator percevant l'absence du peer peut libérer des ressources.

Dans les méthodes prenant en charge les indications de résultat, un peer ayant authentifié le serveur ne considère pas l'authentification comme réussie tant qu'il n'a pas reçu une indication que le serveur l'a authentifié avec succès. De même, un serveur ayant authentifié avec succès le peer ne considère pas l'authentification comme réussie tant qu'il n'a pas reçu une indication que le peer a authentifié le serveur.

Pour éviter des problèmes de synchronisation, avant d'envoyer une indication de résultat de succès, il est préférable que l'expéditeur vérifie qu'il existe une autorisation suffisante pour accorder l'accès, mais comme indiqué ci-dessous, cela n'est pas toujours possible.

Bien que les indications de résultat puissent réaliser la synchronisation des résultats d'authentification entre le peer et le serveur, cela ne garantit pas que le peer et l'authenticator se synchroniseront sur l'autorisation, ni qu'aucun dépassement de temps ne se produira. Par exemple, le serveur EAP peut ne pas connaître les décisions d'autorisation prises par un proxy AAA ; le serveur AAA peut vérifier l'autorisation uniquement après l'achèvement réussi de l'authentification, pour découvrir qu'il ne peut pas accorder l'autorisation, ou le serveur AAA peut accorder l'accès, mais l'authenticator peut ne pas être en mesure de le fournir en raison d'un manque temporaire de ressources. Dans ces cas, la synchronisation ne peut être réalisée que via des indications de résultat de couche inférieure.

Une indication de succès peut être explicite ou implicite. Par exemple, dans les méthodes prenant en charge les messages d'erreur, une indication de succès implicite peut être définie comme la réception d'un message spécifique sans message d'erreur précédent. L'échec est généralement indiqué explicitement. Comme décrit à la section 4.2, le peer rejette silencieusement un paquet Failure reçu à un point où l'envoi de ce paquet n'est pas explicitement autorisé par la méthode. Par exemple, une méthode fournissant ses propres messages d'erreur peut exiger que le peer reçoive un message d'erreur avant d'accepter un paquet Failure.

L'authentification par paquet, l'intégrité et la protection contre le rejeu des indications de résultat empêchent l'usurpation. Puisque les indications de résultat protégées nécessitent l'utilisation de clés pour l'authentification et la protection de l'intégrité par paquet, les méthodes prenant en charge des indications de résultat protégées DOIVENT également prendre en charge les revendications « dérivation de clés », « authentification mutuelle », « protection de l'intégrité » et « protection contre le rejeu ».

Les indications de résultat protégées résolvent certaines vulnérabilités de déni de service résultant de l'usurpation des paquets Success et Failure, bien que pas toutes. Les méthodes EAP ne peuvent généralement fournir des indications de résultat protégées que dans certaines circonstances. Par exemple, une erreur peut se produire avant la dérivation de clé, donc il peut ne pas être possible de protéger toutes les indications d'échec. Il est également possible que les indications de résultat ne soient pas prises en charge dans les deux directions, ou que la synchronisation ne soit pas réalisable dans tous les modes de fonctionnement.

Par exemple, dans EAP-TLS [RFC2716], dans la poignée de main d'authentification du client, le serveur authentifie le peer, mais ne reçoit pas d'indication protégée que le peer l'a authentifié. Au contraire, le peer authentifie le serveur et sait si le serveur l'a authentifié. Dans la poignée de main de reprise de session, le peer authentifie le serveur, mais ne reçoit pas d'indication protégée que le serveur l'a authentifié. Dans ce mode, le serveur authentifie le peer et sait si le peer l'a authentifié.