7. Considérations de Sécurité

Cette section définit un modèle de menace générique ainsi que les revendications de sécurité de la méthode EAP atténuant ces menaces.

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

7.1. Modèle de Menace (Threat Model)

EAP a été développé pour une utilisation avec PPP [RFC1661] et a ensuite été adapté pour une utilisation dans les réseaux IEEE 802 filaires [IEEE-802] dans [IEEE-802.1X]. Par la suite, EAP a été proposé pour une utilisation sur les réseaux LAN sans fil et sur Internet. Dans toutes ces situations, il est possible pour un attaquant d'obtenir un accès aux liens sur lesquels les paquets EAP sont transmis. Par exemple, les attaques sur l'infrastructure téléphonique sont documentées dans [DECEPTION].

Un attaquant avec accès au lien peut effectuer plusieurs attaques, notamment:

[1] Un attaquant peut essayer de découvrir les identités utilisateur en espionnant le trafic d'authentification.

[2] Un attaquant peut essayer de modifier ou d'usurper des paquets EAP.

[3] Un attaquant peut lancer des attaques par déni de service en usurpant des indications de couche inférieure ou des paquets Success/Failure, en rejouant des paquets EAP, ou en générant des paquets avec des identificateurs qui se chevauchent.

[4] Un attaquant peut tenter de récupérer la phrase de passe en montant une attaque par dictionnaire hors ligne.

[5] Un attaquant peut tenter de convaincre le pair de se connecter à un réseau non fiable en montant une attaque de l'homme du milieu.

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

[7] Un attaquant peut tenter de récupérer des clés en tirant parti de techniques de dérivation de clé faibles utilisées dans les méthodes EAP.

[8] Un attaquant peut tenter de tirer parti de suites de chiffrement faibles utilisées ultérieurement après la fin de la conversation EAP.

[9] Un attaquant peut tenter d'effectuer des attaques de dégradation sur la négociation de suite de chiffrement de couche inférieure afin de s'assurer qu'une suite de chiffrement plus faible est utilisée ultérieurement à l'authentification EAP.

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

Selon la couche inférieure, ces attaques peuvent être effectuées sans nécessiter de proximité physique. Lorsque EAP est utilisé sur des réseaux sans fil, les paquets EAP peuvent être transférés par des authentificateurs (par exemple, pré-authentification) de sorte que l'attaquant n'a pas besoin d'être dans la zone de couverture d'un authentificateur pour effectuer une attaque contre lui ou ses pairs. Lorsque EAP est utilisé sur Internet, les attaques peuvent être effectuées à une distance encore plus grande.

7.2. Revendications de Sécurité (Security Claims)

Afin d'articuler clairement la sécurité fournie par une méthode EAP, les spécifications de méthode EAP DOIVENT inclure une section de Revendications de Sécurité, incluant les déclarations suivantes:

[a] Mécanisme. Il s'agit d'une déclaration de la technologie d'authentification: certificats, clés pré-partagées, mots de passe, cartes à jeton, etc.

[b] Revendications de sécurité. Il s'agit d'une déclaration des propriétés de sécurité revendiquées de la méthode, utilisant les termes définis dans la Section 7.2.1: authentification mutuelle, protection d'intégrité, protection contre la relecture, confidentialité, dérivation de clé, résistance aux attaques par dictionnaire, reconnexion rapide, liaison cryptographique. La section Revendications de Sécurité d'une spécification de méthode EAP DEVRAIT fournir une justification pour les revendications qui sont faites. Cela peut être accompli en incluant une preuve dans une Annexe, ou en incluant une référence à une preuve.

[c] Force de 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 aux utilisateurs potentiels de la méthode pour déterminer si les clés produites sont suffisamment fortes pour l'application prévue.

La force de clé effective DEVRAIT être indiquée comme un nombre de bits, défini comme suit: Si la force de clé effective est de N bits, les meilleures méthodes actuellement connues pour récupérer la clé (avec une probabilité non négligeable) nécessitent, en moyenne, un effort comparable à 2^(N-1) opérations d'un chiffrement par blocs typique. La déclaration DEVRAIT être accompagnée d'une brève justification, expliquant comment ce nombre a été dérivé. Cette explication DEVRAIT inclure les paramètres requis pour atteindre la force de clé indiquée basée sur la connaissance actuelle des algorithmes.

(Note: Bien qu'il soit difficile de définir ce que signifient exactement "effort comparable" et "chiffrement par blocs typique", des approximations raisonnables sont suffisantes ici. Consultez par exemple [SILVERMAN] pour plus de discussion.)

La force de clé dépend des méthodes utilisées pour dériver les clés. Par exemple, si les clés sont dérivées d'un secret partagé (tel qu'un mot de passe ou un secret à long terme), et éventuellement d'informations publiques telles que des nonces, la force de clé effective est limitée par la force du secret à long terme (en supposant que la procédure de dérivation soit computationnellement simple). Pour prendre un autre exemple, lors de l'utilisation d'algorithmes à clé publique, la force de la clé symétrique dépend de la force des clés publiques utilisées.

[d] Description de la hiérarchie de clés. Les méthodes EAP dérivant des clés DOIVENT soit fournir une référence à une spécification de hiérarchie de clés, soit décrire comment les Master Session Keys (MSK) et les Extended Master Session Keys (EMSK) doivent être dérivées.

[e] Indication des vulnérabilités. En plus des revendications de sécurité qui sont faites, la spécification DOIT indiquer lesquelles des revendications de sécurité détaillées dans la Section 7.2.1 ne sont PAS faites.

7.2.1. Terminologie des Revendications de Sécurité

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

Négociation de suite de chiffrement protégée (Protected ciphersuite negotiation)

Cela fait référence à la capacité d'une méthode EAP à négocier la suite de chiffrement utilisée pour protéger la conversation 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 de chiffrement utilisée pour protéger les données.

Authentification mutuelle (Mutual authentication)

Cela fait référence à une méthode EAP dans laquelle, dans un échange verrouillé, l'authentificateur authentifie le pair et le pair authentifie l'authentificateur. Deux méthodes unidirectionnelles indépendantes, s'exécutant dans des directions opposées, ne fournissent pas d'authentification mutuelle telle que définie ici.

Protection d'intégrité (Integrity protection)

Cela fait référence à la fourniture d'une authentification d'origine de données et d'une protection contre la modification non autorisée d'informations pour les paquets EAP (incluant les Requêtes et Réponses EAP). Lors de cette revendication, une spécification de méthode DOIT décrire les paquets EAP et les champs dans le paquet EAP qui sont protégés.

Protection contre la relecture (Replay protection)

Cela fait référence à la protection contre la relecture d'une méthode EAP ou de ses messages, y compris les indications de résultat de succès et d'échec.

Confidentialité (Confidentiality)

Cela fait référence au chiffrement des messages EAP, y compris les Requêtes et Réponses EAP, et les indications de résultat de succès et d'échec. Une méthode faisant cette revendication DOIT supporter la protection d'identité (voir Section 7.3).

Dérivation de clé (Key derivation)

Cela fait référence à la capacité de la méthode EAP à dériver du matériel de clé exportable, tel que la Master Session Key (MSK) et l'Extended Master Session Key (EMSK). La MSK est utilisée uniquement pour une dérivation de clé ultérieure, pas directement pour la protection de la conversation EAP ou des données ultérieures. L'utilisation de l'EMSK est réservée.

Force de clé (Key strength)

Si la force de clé effective est de N bits, les meilleures méthodes actuellement connues pour récupérer la clé (avec une probabilité non négligeable) nécessitent, en moyenne, un effort comparable à 2^(N-1) opérations d'un chiffrement par blocs typique.

Résistance aux attaques par dictionnaire (Dictionary attack resistance)

Lorsque l'authentification par mot de passe est utilisée, les mots de passe sont couramment sélectionnés à partir d'un petit ensemble (par rapport à un ensemble de clés de N bits), ce qui soulève une préoccupation concernant les attaques par dictionnaire. Une méthode peut être dite fournir une protection contre les attaques par dictionnaire si, lorsqu'elle utilise un mot de passe comme secret, la méthode ne permet pas une attaque hors ligne qui a un facteur de travail basé sur le nombre de mots de passe dans le dictionnaire d'un attaquant.

Reconnexion rapide (Fast reconnect)

La capacité, dans le cas où une association de sécurité a été établie précédemment, de créer une nouvelle association de sécurité ou rafraîchie plus efficacement ou en un nombre réduit d'allers-retours.

Liaison cryptographique (Cryptographic binding)

La démonstration du pair EAP au serveur EAP qu'une seule entité a agi comme pair EAP pour toutes les méthodes exécutées dans une méthode tunnel. La liaison PEUT également impliquer que le serveur EAP démontre au pair qu'une seule entité a agi comme serveur EAP pour toutes les méthodes exécutées dans une méthode tunnel. Si elle est exécutée correctement, la liaison sert à atténuer les vulnérabilités de l'homme du milieu.

Indépendance de session (Session independence)

La démonstration que les attaques passives (telles que la capture de la conversation EAP) ou les attaques actives (y compris la compromission de la MSK ou de l'EMSK) ne permettent pas la compromission des MSK ou EMSK ultérieures ou antérieures.

Fragmentation (Fragmentation)

Cela fait référence à savoir si une méthode EAP supporte la fragmentation et le réassemblage. Comme indiqué dans la Section 3.1, les méthodes EAP devraient supporter la fragmentation et le réassemblage si les paquets EAP peuvent dépasser le MTU minimum de 1020 octets.

Liaison de canal (Channel binding)

La communication au sein d'une méthode EAP de propriétés de canal protégées en intégrité telles que des identificateurs de point terminal qui peuvent être comparés aux valeurs communiquées via des mécanismes hors bande (tels que via un protocole AAA ou de couche inférieure).

Note: Cette liste de revendications de sécurité n'est pas exhaustive. Des propriétés supplémentaires, telles qu'une protection supplémentaire contre le déni de service, peuvent également être pertinentes.

7.3. Protection de l'Identité

Un échange d'identité est optionnel dans la conversation EAP. Par conséquent, il est possible d'omettre complètement l'échange d'identité, ou d'utiliser un échange d'identité spécifique à la méthode une fois qu'un canal protégé a été établi.

Cependant, lorsque l'itinérance est supportée comme décrit dans [RFC2607], il peut être nécessaire de localiser le serveur d'authentification backend approprié avant que la conversation d'authentification puisse se poursuivre. La partie domaine du Network Access Identifier (NAI) [RFC2486] est typiquement incluse dans l'EAP-Response/Identity afin de permettre à l'échange d'authentification d'être acheminé vers le serveur d'authentification backend approprié. Par conséquent, bien que la partie nom de pair du NAI puisse être omise dans l'EAP-Response/Identity où des proxies ou des relais sont présents, la partie domaine peut être requise.

Il est possible que l'identité dans la réponse d'identité soit différente de l'identité authentifiée par la méthode EAP. Cela peut être intentionnel dans le cas de la confidentialité d'identité. Une méthode EAP DEVRAIT 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 tunnelé dans un autre protocole qui omet l'authentification du pair, il existe une vulnérabilité potentielle à une attaque de l'homme du milieu. Pour plus de détails, voir [BINDING] et [MITM].

Comme indiqué dans la Section 2.1, EAP ne permet pas de séquences non tunnelées de méthodes d'authentification. Si une séquence de méthodes d'authentification EAP était permise, le pair pourrait ne pas avoir la preuve qu'une seule entité a agi comme authentificateur pour toutes les méthodes EAP dans la séquence. Par exemple, un authentificateur pourrait terminer une méthode EAP, puis transférer la méthode suivante dans la séquence à une autre partie sans la connaissance ou le consentement du pair. De même, l'authentificateur pourrait ne pas avoir la preuve qu'une seule entité a agi comme pair pour toutes les méthodes EAP dans la séquence.

Le tunneling d'EAP dans un autre protocole permet une attaque par un authentificateur EAP malveillant tunnelant EAP vers un serveur légitime. Lorsque le protocole de tunneling est utilisé pour l'établissement de clé mais ne nécessite pas d'authentification du pair, un attaquant convainquant un pair légitime de se connecter à lui sera capable de tunneler des paquets EAP vers un serveur légitime, de s'authentifier avec succès et d'obtenir la clé. Cela permet à l'attaquant de s'établir avec succès comme homme du milieu, obtenant l'accès au réseau, ainsi que la capacité de déchiffrer le trafic de données entre le pair légitime et le serveur.

Cette attaque peut être atténuée par les mesures suivantes:

[a] Exiger une authentification mutuelle dans les mécanismes de tunneling EAP.

[b] Exiger une liaison cryptographique entre le protocole de tunneling EAP et les méthodes EAP tunnelées. Lorsque la liaison cryptographique est supportée, un mécanisme est également nécessaire pour protéger contre les attaques de dégradation qui la contourneraient. Pour plus de détails sur la liaison cryptographique, voir [BINDING].

[c] Limiter les méthodes EAP autorisées pour une utilisation sans protection, basé sur la politique du pair et de l'authentificateur.

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

7.5. Attaques de Modification de Paquet

Bien que les méthodes EAP puissent supporter l'authentification d'origine de données par paquet, l'intégrité et la protection contre la relecture, le support n'est pas fourni dans la couche EAP.

Puisque l'Identificateur 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 (Code, Identifier, Length, Type) dans les paquets EAP où l'en-tête n'est pas protégé. Cela pourrait entraîner l'élimination ou la mauvaise interprétation inappropriée des paquets.

Pour protéger les paquets EAP contre la modification, l'usurpation ou la relecture, les méthodes supportant la négociation de suite de chiffrement protégée, l'authentification mutuelle et la dérivation de clé, ainsi que l'intégrité et la protection contre la relecture, sont recommandées. Voir la Section 7.2.1 pour les définitions de ces revendications de sécurité.

Des MIC spécifiques à la méthode peuvent être utilisés pour fournir une protection. Si un MIC par paquet est employé dans une méthode EAP, alors les pairs, les serveurs d'authentification et les authentificateurs ne fonctionnant pas en mode pass-through DOIVENT valider le MIC. Les échecs de validation de MIC DEVRAIENT être enregistrés. Qu'un échec de validation de MIC soit considéré comme une erreur fatale ou non est déterminé par la spécification de la méthode EAP.

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

Puisque les messages EAP de Types Identity, Notification et Nak n'incluent pas leur propre MIC, il peut être souhaitable que le MIC de 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 dans TLS [RFC2246]. Cependant, comme indiqué dans la Section 7.4, le tunneling EAP peut entraîner une vulnérabilité de l'homme du milieu.

Les méthodes EAP existantes définissent des contrôles d'intégrité de message (MIC) qui couvrent plus d'un paquet EAP. Par exemple, EAP-TLS [RFC2716] définit un MIC sur un enregistrement TLS qui pourrait être divisé en plusieurs fragments; dans le message FINISHED, le MIC est calculé sur les messages précédents. Lorsque le MIC couvre plus d'un paquet EAP, un échec de validation de MIC est généralement considéré comme une erreur fatale.

7.6. Attaques par Dictionnaire

Les algorithmes d'authentification par mot de passe tels que EAP-MD5, MS-CHAPv1 [RFC2433] et Kerberos V [RFC1510] sont connus pour être 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 sont documentées dans [PPTPv2]; les vulnérabilités de Kerberos sont décrites dans [KRBATTACK], [KRBLIM] et [KERB4WEAK].

Afin de se protéger contre les attaques par dictionnaire, les méthodes d'authentification résistantes aux attaques par dictionnaire (comme défini dans la Section 7.2.1) sont recommandées.

Si un algorithme d'authentification est utilisé qui est connu pour être vulnérable aux attaques par dictionnaire, alors la conversation peut être tunnelée dans un canal protégé afin de fournir une protection supplémentaire. Cependant, comme indiqué dans la Section 7.4, le tunneling EAP peut entraîner une vulnérabilité de l'homme du milieu, et par conséquent, les méthodes résistantes aux attaques par dictionnaire sont préférées.

7.7. Connexion à un Réseau Non Fiable

Avec les méthodes EAP supportant l'authentification unidirectionnelle, telles que EAP-MD5, le pair n'authentifie pas l'authentificateur, rendant le pair vulnérable à une attaque par un authentificateur malveillant. Les méthodes supportant l'authentification mutuelle (comme défini dans la Section 7.2.1) abordent cette vulnérabilité.

Dans EAP, il n'y a aucune exigence que l'authentification soit full duplex ou que le même protocole soit utilisé dans les deux directions. Il est parfaitement acceptable que différents protocoles soient utilisés dans chaque direction. Cela dépendra, bien sûr, des protocoles spécifiques négociés. Cependant, en général, compléter une seule authentification mutuelle unitaire est préférable à deux authentifications unidirectionnelles, une dans chaque direction. Cela est dû au fait que des authentifications séparées qui ne sont pas liées cryptographiquement de manière à démontrer qu'elles font partie de la même session sont sujettes aux attaques de l'homme du milieu, comme discuté dans la Section 7.4.

7.8. Attaques de Négociation

Dans une attaque de négociation, l'attaquant tente de convaincre le pair et l'authentificateur 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 qu'il soit possible pour une méthode d'inclure la couverture des Réponses Nak dans un MIC spécifique à la méthode.

Dans ou associé à chaque authentificateur, il n'est pas anticipé qu'un pair nommé particulier supportera un choix de méthodes. Cela rendrait le pair vulnérable aux attaques qui négocient la méthode la moins sécurisée parmi un ensemble. Au lieu de cela, pour chaque pair nommé, il DEVRAIT y avoir une indication d'exactement une méthode utilisée pour authentifier ce nom de pair. Si un pair doit utiliser différentes méthodes d'authentification dans différentes circonstances, alors des identités distinctes DEVRAIENT être employées, chacune identifiant exactement une méthode d'authentification.

7.9. Particularités d'Implémentation

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

Par exemple, en cas d'échec de l'authentification, certaines implémentations PPP ne terminent pas le lien, limitant plutôt le trafic dans les protocoles de couche réseau à un sous-ensemble filtré, ce qui permet au pair d'avoir l'opportunité de mettre à jour les secrets ou d'envoyer un courrier à l'administrateur réseau indiquant un problème. De même, bien qu'un échec d'authentification entraînera un refus d'accès au port contrôlé dans [IEEE-802.1X], un trafic limité peut être permis sur le port non contrôlé.

Dans EAP, il n'y a aucune disposition pour les tentatives de nouvelle authentification échouée. Cependant, dans PPP, la machine d'état LCP peut renégocier le protocole d'authentification à tout moment, permettant ainsi une nouvelle tentative. De même, dans IEEE 802.1X, le Supplicant ou l'Authentificateur peut se réauthentifier à tout moment. Il est recommandé que tous les compteurs utilisés pour l'échec d'authentification ne soient pas réinitialisés avant une authentification réussie, ou une terminaison ultérieure du lien échoué.

7.10. Dérivation de Clé

Il est possible pour le pair et le serveur EAP de s'authentifier mutuellement et de dériver des clés. Afin de fournir du matériel de clé pour une utilisation dans une suite de chiffrement négociée ultérieurement, une méthode EAP supportant la dérivation de clé DOIT exporter une Master Session Key (MSK) d'au moins 64 octets, et une Extended Master Session Key (EMSK) d'au moins 64 octets. Les méthodes EAP dérivant des clés DOIVENT fournir une authentification mutuelle entre le pair 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 permettre la dérivation d'une AAA-Key ultérieurement utilisée pour dériver des Transient Session Keys (TSK) pour une utilisation avec la suite de chiffrement sélectionnée. Chaque suite de chiffrement est responsable de spécifier comment dériver les TSK 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 qui utilisent EAP, la AAA-Key et la MSK sont équivalentes, mais des mécanismes plus compliqués sont possibles (voir [KEYFRAME] pour plus de détails).

Les méthodes EAP DEVRAIENT assurer la fraîcheur de la MSK et de l'EMSK, même dans les cas où une partie peut ne pas avoir un générateur de nombres aléatoires de haute qualité. Une méthode RECOMMANDÉE est pour chaque partie de fournir un nonce d'au moins 128 bits, utilisé dans la dérivation de la MSK et de l'EMSK.

Les méthodes EAP exportent la MSK et l'EMSK, mais pas les Transient Session Keys afin de permettre aux méthodes EAP d'être indépendantes de la suite de chiffrement et du média. Le matériel de clé exporté par les méthodes EAP DOIT être indépendant de la suite de chiffrement négociée pour protéger les données.

Selon la couche inférieure, les méthodes EAP peuvent s'exécuter avant ou après la négociation de la suite de chiffrement, de sorte que la suite de chiffrement sélectionnée peut ne pas être connue de la méthode EAP. En fournissant du matériel de clé utilisable avec n'importe quelle suite de chiffrement, les méthodes EAP peuvent être utilisées avec une large gamme de suites de chiffrement et de médias.

Afin de préserver l'indépendance de l'algorithme, les méthodes EAP dérivant des clés DEVRAIENT supporter (et documenter) la négociation protégée de la suite de chiffrement utilisée pour protéger la conversation EAP entre le pair et le serveur. Ceci est distinct de la suite de chiffrement négociée entre le pair et l'authentificateur, utilisée pour protéger les données.

La force des Transient Session Keys (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 une méthode EAP ne peut pas produire de matériel de clé de force suffisante, alors les TSK peuvent être sujettes à une attaque par force brute. Afin de permettre des déploiements nécessitant des clés fortes, les méthodes EAP supportant la dérivation de clé DEVRAIENT être capables de générer une MSK et une EMSK, chacune avec une force de clé effective d'au moins 128 bits.

Les méthodes supportant la dérivation de clé DOIVENT démontrer une séparation cryptographique entre les branches MSK et EMSK de la hiérarchie de clés EAP. Sans violer une hypothèse cryptographique fondamentale (telle que la non-inversibilité d'une fonction à sens unique), un attaquant récupérant la MSK ou l'EMSK NE DOIT PAS être capable de récupérer l'autre quantité avec un niveau d'effort inférieur à la force brute.

Les sous-chaînes non superposées de la MSK DOIVENT être cryptographiquement séparées les unes des autres, comme défini dans la Section 7.2.1. C'est-à-dire que la connaissance d'une sous-chaîne NE DOIT PAS aider à récupérer une autre sous-chaîne sans casser une hypothèse cryptographique difficile. Ceci est requis car certaines suites de chiffrement existantes forment des TSK en divisant simplement la AAA-Key en morceaux de longueur appropriée. De même, les sous-chaînes non superposées de l'EMSK DOIVENT être cryptographiquement séparées les unes des autres, et des sous-chaînes de la MSK.

L'EMSK est réservée pour une utilisation future et DOIT rester sur le pair EAP et le serveur EAP où elle est dérivée; elle NE DOIT PAS être transportée vers, ou partagée avec, des parties supplémentaires, ou utilisée pour dériver d'autres clés. (Cette restriction sera assouplie dans un document futur qui spécifie comment l'EMSK peut être utilisée.)

Puisque EAP ne fournit pas de négociation explicite de durée de vie de clé, les pairs EAP, les authentificateurs et les serveurs d'authentification DOIVENT être préparés pour des situations dans lesquelles l'une des parties rejette l'état de clé, qui reste valide sur une autre partie.

Cette spécification ne fournit pas de guide détaillé sur la façon 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 des algorithmes de dérivation de clé sont difficiles, et en conséquence, les méthodes EAP DEVRAIENT réutiliser des mécanismes bien établis et analysés pour la dérivation de clé (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 utiliser des mécanismes bien établis et analysés pour la dérivation de MSK et d'EMSK. Plus de détails sur la Dérivation de Clé EAP sont fournis dans [KEYFRAME].

7.11. Suites de Chiffrement Faibles

Si après l'authentification EAP initiale, des paquets de données sont envoyés sans authentification par paquet, intégrité et protection contre la relecture, 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, il est possible d'espionner les paquets de données.

Pour se protéger contre la modification, l'usurpation ou l'espionnage de données, il est recommandé d'utiliser des méthodes EAP supportant l'authentification mutuelle et la dérivation de clé (comme défini dans la Section 7.2.1), ainsi que des couches inférieures fournissant la confidentialité, l'authentification, l'intégrité et la protection contre la relecture par paquet.

De plus, si la couche inférieure effectue une négociation de suite de chiffrement, il doit être compris qu'EAP ne fournit pas par lui-même de protection d'intégrité de cette négociation. Par conséquent, afin d'éviter les attaques de dégradation qui conduiraient à l'utilisation de suites de chiffrement plus faibles, les clients implémentant la négociation de suite de chiffrement de couche inférieure DEVRAIENT se protéger contre la dégradation de la négociation.

Cela peut être fait en permettant aux utilisateurs de configurer quelles suites de chiffrement sont acceptables en tant que question de politique de sécurité, ou la négociation de suite de chiffrement PEUT être authentifiée en utilisant du matériel de clé dérivé de l'authentification EAP et un algorithme MIC convenu à l'avance par les pairs de couche inférieure.

7.12. Couche Liaison

Il existe des problèmes de fiabilité et de sécurité avec les indications de couche liaison dans PPP, les LAN IEEE 802 et les LAN sans fil IEEE 802.11:

[a] PPP. Dans PPP, les indications de couche 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 en intégrité. Elles peuvent donc être usurpées par un attaquant ayant accès au lien.

[b] IEEE 802. Les trames EAPOL-Start et EAPOL-Logoff d'IEEE 802.1X ne sont ni authentifiées ni protégées en intégrité. Elles peuvent donc être usurpées par un attaquant ayant accès au lien.

[c] IEEE 802.11. Dans IEEE 802.11, les indications de couche liaison incluent les trames Disassociate et Deauthenticate (indications d'échec de liaison), et 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 en intégrité, et bien qu'ils ne soient pas transférables, ils peuvent être usurpés par un attaquant à portée.

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 implique que bien que les messages EAPOL-Start et EAPOL-Logoff puissent être authentifiés et protégés en intégrité, ils peuvent être usurpés par un attaquant authentifié éloigné de la cible lorsque la "pré-authentification" est activée.

Dans IEEE 802.11, une indication de "liaison interrompue" est une indication peu fiable d'échec de liaison, car la force du signal sans fil peut aller et venir et peut être influencée par des interférences de radiofréquence générées par un attaquant. Pour éviter des réinitialisations inutiles, il est conseillé d'amortir ces indications, plutôt que de les transmettre directement à l'EAP. Puisque EAP supporte la retransmission, il est robuste contre les pertes de connectivité transitoires.

7.13. Séparation de l'Authentificateur et du Serveur d'Authentification Backend

Il est possible pour le pair EAP et le serveur EAP de s'authentifier mutuellement et de dériver une AAA-Key pour une suite de chiffrement utilisée pour protéger le trafic de données ultérieur. Cela ne présente pas de problème sur le pair, car le pair et le client EAP résident sur la même machine; tout ce qui est requis est que le client dérive la AAA-Key de la MSK et de l'EMSK exportées par la méthode EAP, et transmette ensuite une Transient Session Key (TSK) au module de suite de chiffrement.

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

[a] L'authentification aura lieu entre le pair et le serveur d'authentification, pas entre le pair et l'authentificateur. Cela signifie qu'il n'est pas possible pour le pair de valider l'identité de l'authentificateur auquel il parle, en utilisant EAP seul.

[b] Comme discuté dans [RFC3579], l'authentificateur dépend du protocole AAA pour connaître le résultat d'une conversation d'authentification, et ne regarde pas le paquet EAP encapsulé (s'il est présent) pour déterminer le résultat. En pratique, cela implique que le protocole AAA parlé entre l'authentificateur et le serveur d'authentification DOIT supporter l'authentification par paquet, l'intégrité et la protection contre la relecture.

[c] Après l'achèvement de la conversation EAP, où des services de sécurité de couche inférieure tels que la confidentialité par paquet, l'authentification, l'intégrité et la protection contre la relecture seront activés, un protocole d'association sécurisée DEVRAIT être exécuté entre le pair et l'authentificateur afin de fournir une authentification mutuelle entre le pair et l'authentificateur, garantir la vivacité des clés de session transitoires, fournir une négociation de suite de chiffrement et de capacités protégée pour les données ultérieures, et synchroniser l'utilisation des clés.

[d] Une AAA-Key dérivée de la MSK et/ou de l'EMSK négociée entre le pair et le serveur d'authentification PEUT être transmise à l'authentificateur. Par conséquent, un mécanisme doit être fourni pour transmettre la AAA-Key du serveur d'authentification à l'authentificateur qui en a besoin. La spécification des mécanismes de dérivation, de transport et d'encapsulation de la AAA-Key est en dehors de la portée de ce document. Plus de détails sur la Dérivation de AAA-Key sont fournis dans [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. L'omission est intentionnelle. L'utilisation de mots de passe en clair permettrait au mot de passe d'être capturé par un attaquant ayant accès à un lien sur lequel les paquets EAP sont transmis.

Puisque les protocoles encapsulant EAP, tels que RADIUS [RFC3579], peuvent ne pas fournir de confidentialité, les paquets EAP peuvent être encapsulés ultérieurement pour le transport sur Internet où ils peuvent être capturés par un attaquant.

En conséquence, les mots de passe en clair ne peuvent pas être utilisés en toute sécurité dans EAP, sauf lorsqu'ils sont encapsulés dans un tunnel protégé avec authentification du serveur. Certains des mêmes risques s'appliquent aux méthodes EAP sans résistance aux attaques par dictionnaire, comme défini dans la Section 7.2.1. Pour plus de détails, voir la Section 7.6.

7.15. Liaison de Canal

Il est possible pour un authentificateur EAP compromis ou mal implémenté de communiquer des informations incorrectes au pair EAP et/ou au serveur. Cela peut permettre à un authentificateur d'usurper l'identité d'un autre authentificateur ou de communiquer des informations incorrectes via des mécanismes hors bande (tels que via un protocole AAA ou de couche inférieure).

Lorsque EAP est utilisé en mode pass-through, le pair EAP ne vérifie généralement pas l'identité de l'authentificateur pass-through, il vérifie seulement que l'authentificateur 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 un authentificateur pass-through EAP agissant comme client AAA peut être détecté s'il tente d'usurper l'identité d'un autre authentificateur (tel qu'en envoyant des attributs NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] ou NAS-IPv6-Address [RFC3162] incorrects via le protocole AAA). Cependant, il est possible pour un authentificateur pass-through agissant comme client AAA de fournir des informations correctes au serveur AAA tout en communiquant des informations trompeuses au pair EAP via un protocole de couche inférieure.

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

Afin d'aborder cette vulnérabilité, les méthodes EAP peuvent supporter un échange protégé de propriétés de canal telles que des identificateurs de point terminal, incluant (mais 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é, il est possible de faire correspondre les propriétés de canal fournies par l'authentificateur via des mécanismes hors bande contre celles échangées dans la méthode EAP. Lorsque des écarts sont trouvés, ceux-ci DEVRAIENT être enregistrés; des actions supplémentaires PEUVENT également être prises, telles que refuser l'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 en intégrité. Les indications de résultat améliorent la résilience à la perte de paquets Success et Failure lorsque EAP est exécuté sur des couches inférieures qui ne supportent pas la retransmission ou la synchronisation de l'état d'authentification. Dans les médias tels qu'IEEE 802.11, qui fournit une retransmission, ainsi qu'une synchronisation de l'état d'authentification via la poignée de main à 4 voies définie dans [IEEE-802.11i], la résilience supplémentaire est généralement d'un bénéfice marginal.

Selon la méthode et les circonstances, les indications de résultat peuvent être usurpables par un attaquant. Une méthode est dite fournir des indications de résultat protégées si elle supporte les indications de résultat, ainsi que les revendications de "protection d'intégrité" et de "protection contre la relecture". Une méthode supportant des indications de résultat protégées DOIT indiquer quelles indications de résultat sont protégées, et lesquelles ne le sont pas.

Les indications de résultat protégées ne sont pas requises pour se protéger contre les authentificateurs malveillants. Dans une méthode d'authentification mutuelle, exiger que le serveur s'authentifie au pair avant que le pair accepte un paquet Success empêche un attaquant d'agir comme authentificateur malveillant.

Cependant, il est possible pour un attaquant de falsifier un paquet Success après que le serveur se soit authentifié au pair, mais avant que le pair se soit authentifié au serveur. Si le pair acceptait le paquet Success falsifié et tentait d'accéder au réseau alors qu'il ne s'était pas encore authentifié avec succès au serveur, une attaque par déni de service pourrait être montée contre le pair. Après une telle attaque, si la couche inférieure supporte les indications d'échec, l'authentificateur peut synchroniser l'état avec le pair en fournissant une indication d'échec de couche inférieure. Voir la Section 7.12 pour plus de détails.

Si un serveur devait authentifier le pair et envoyer un paquet Success avant de déterminer si le pair a authentifié l'authentificateur, un délai d'inactivité peut se produire si l'authentificateur n'est pas authentifié par le pair. Lorsqu'il est supporté par la couche inférieure, un authentificateur détectant l'absence du pair peut libérer des ressources.

Dans une méthode supportant les indications de résultat, un pair qui a authentifié le serveur ne considère pas l'authentification réussie jusqu'à ce qu'il reçoive une indication que le serveur l'a authentifié avec succès. De même, un serveur qui a authentifié avec succès le pair ne considère pas l'authentification réussie jusqu'à ce qu'il reçoive une indication que le pair a authentifié le serveur.

Afin d'éviter les problèmes de synchronisation, avant d'envoyer une indication de résultat de succès, il est souhaitable pour l'expéditeur de vérifier qu'une autorisation suffisante existe pour accorder l'accès, bien que, comme discuté ci-dessous, cela ne soit pas toujours possible.

Bien que les indications de résultat puissent permettre la synchronisation du résultat d'authentification entre le pair et le serveur, cela ne garantit pas que le pair et l'authentificateur seront synchronisés en termes de leur autorisation ou que des délais d'attente ne se produiront pas. Par exemple, le serveur EAP peut ne pas être conscient d'une décision d'autorisation prise par un proxy AAA; le serveur AAA peut vérifier l'autorisation seulement après que l'authentification soit terminée avec succès, pour découvrir que l'autorisation ne peut pas être accordée, ou le serveur AAA peut accorder l'accès mais l'authentificateur peut ne pas être capable de le fournir en raison d'un manque temporaire de ressources. Dans ces situations, la synchronisation peut seulement être atteinte via des indications de résultat de couche inférieure.

Les indications de succès peuvent être explicites ou implicites. Par exemple, lorsqu'une méthode supporte des 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. Les échecs sont généralement indiqués explicitement. Comme décrit dans la Section 4.2, un pair rejette silencieusement un paquet Failure reçu à un point où la méthode ne permet pas explicitement cela d'être envoyé. Par exemple, une méthode fournissant ses propres messages d'erreur pourrait exiger que le pair reçoive un message d'erreur avant d'accepter un paquet Failure.

L'authentification par paquet, l'intégrité et la protection contre la relecture des indications de résultat protègent contre l'usurpation. Puisque les indications de résultat protégées nécessitent l'utilisation d'une clé pour l'authentification par paquet et la protection d'intégrité, les méthodes supportant des indications de résultat protégées DOIVENT également supporter les revendications de "dérivation de clé", "authentification mutuelle", "protection d'intégrité" et "protection contre la relecture".

Les indications de résultat protégées abordent certaines vulnérabilités de déni de service dues à l'usurpation de paquets Success et Failure, mais pas toutes. Les méthodes EAP peuvent généralement fournir des indications de résultat protégées uniquement dans certaines circonstances. Par exemple, des erreurs peuvent se produire avant la dérivation de clé, et il peut donc 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 supportées dans les deux directions ou que la synchronisation ne soit pas atteinte dans tous les modes d'opération.

Par exemple, dans EAP-TLS [RFC2716], dans la poignée de main d'authentification client, le serveur authentifie le pair, mais ne reçoit pas d'indication protégée indiquant si le pair l'a authentifié. En revanche, le pair authentifie le serveur et est conscient si le serveur l'a authentifié. Dans la poignée de main de reprise de session, le pair authentifie le serveur, mais ne reçoit pas d'indication protégée indiquant si le serveur l'a authentifié. Dans ce mode, le serveur authentifie le pair et est conscient si le pair l'a authentifié.