2.16. Méthodes du protocole d'authentification extensible

2.16. Méthodes du protocole d'authentification extensible

En plus de l'authentification utilisant des signatures à clé publique et des secrets partagés, IKE supporte l'authentification utilisant les méthodes définies dans la RFC 3748 [EAP]. Typiquement, ces méthodes sont asymétriques (conçues pour un utilisateur s'authentifiant auprès d'un serveur), et elles peuvent ne pas être mutuelles. Pour cette raison, ces protocoles sont typiquement utilisés pour authentifier l'initiateur auprès du répondeur et DOIVENT être utilisés conjointement avec une authentification basée sur signature à clé publique du répondeur auprès de l'initiateur. Ces méthodes sont souvent associées à des mécanismes appelés mécanismes d'« authentification héritée » (Legacy Authentication).

Bien que ce document référence [EAP] dans l'intention que de nouvelles méthodes puissent être ajoutées à l'avenir sans mettre à jour cette spécification, certaines variations plus simples sont documentées ici. [EAP] définit un protocole d'authentification nécessitant un nombre variable de messages. L'authentification extensible est implémentée dans IKE comme des échanges IKE_AUTH supplémentaires qui DOIVENT être complétés afin d'initialiser la IKE SA.

Un initiateur indique le désir d'utiliser EAP en omettant le payload AUTH du premier message de l'échange IKE_AUTH. (Notez que le payload AUTH est requis pour l'authentification non-EAP, et n'est donc pas marqué comme optionnel dans le reste de ce document.) En incluant un payload IDi mais pas un payload AUTH, l'initiateur a déclaré une identité mais ne l'a pas prouvée. Si le répondeur est disposé à utiliser une méthode EAP, il placera un payload EAP (Extensible Authentication Protocol) dans la réponse de l'échange IKE_AUTH et différera l'envoi de SAr2, TSi, et TSr jusqu'à ce que l'authentification de l'initiateur soit complétée dans un échange IKE_AUTH ultérieur. Dans le cas d'une méthode EAP minimale, l'établissement initial de la SA apparaîtra comme suit :

Initiator Responder

HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP } HDR, SK {EAP} --> <-- HDR, SK {EAP (success)} HDR, SK {AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr }

Comme décrit dans la section 2.2, lorsque EAP est utilisé, le numéro de message de chaque paire de messages de configuration initiale IKE SA sera incrémenté ; la première paire de messages AUTH aura un ID de 1, la seconde sera 2, et ainsi de suite.

Pour les méthodes EAP qui créent une clé partagée comme effet secondaire de l'authentification, cette clé partagée DOIT être utilisée par l'initiateur et le répondeur pour générer les payloads AUTH dans les messages 7 et 8 en utilisant la syntaxe pour les secrets partagés spécifiée dans la section 2.15. La clé partagée provenant d'EAP est le champ de la spécification EAP nommé MSK. Cette clé partagée générée pendant un échange IKE NE DOIT PAS être utilisée à aucune autre fin.

Les méthodes EAP qui n'établissent pas de clé partagée NE DEVRAIENT PAS être utilisées, car elles sont sujettes à un certain nombre d'attaques de l'homme du milieu [EAPMITM] si ces méthodes EAP sont utilisées dans d'autres protocoles qui n'utilisent pas un tunnel authentifié par serveur. Veuillez voir la section Considérations de sécurité pour plus de détails. Si des méthodes EAP ne générant pas de clé partagée sont utilisées, les payloads AUTH dans les messages 7 et 8 DOIVENT être générés en utilisant respectivement SK_pi et SK_pr.

L'initiateur d'une IKE SA utilisant EAP doit être capable d'étendre l'échange de protocole initial à au moins dix échanges IKE_AUTH dans l'éventualité où le répondeur envoie des messages de notification et/ou réessaye l'invite d'authentification. Une fois l'échange de protocole défini par la méthode d'authentification EAP choisie terminé avec succès, le répondeur DOIT envoyer un payload EAP contenant le message Success. De même, si la méthode d'authentification a échoué, le répondeur DOIT envoyer un payload EAP contenant le message Failure. Le répondeur PEUT à tout moment terminer l'échange IKE en envoyant un payload EAP contenant le message Failure.

Suite à un tel échange étendu, les payloads EAP AUTH DOIVENT être inclus dans les deux messages suivant celui contenant le message EAP Success.

Lorsque l'authentification de l'initiateur utilise EAP, il est possible que le contenu du payload IDi soit utilisé uniquement à des fins de routage d'Authentification, Autorisation et Comptabilité (AAA) et de sélection de la méthode EAP à utiliser. Cette valeur peut être différente de l'identité authentifiée par la méthode EAP. Il est important que les recherches de politique et les décisions de contrôle d'accès utilisent l'identité réellement authentifiée. Souvent, le serveur EAP est implémenté dans un serveur AAA séparé qui communique avec le répondeur IKEv2. Dans ce cas, l'identité authentifiée, si différente de celle dans le payload IDi, doit être envoyée du serveur AAA au répondeur IKEv2.