Aller au contenu principal

2.16. Extensible Authentication Protocol Methods (Méthodes EAP)

2.16. Extensible Authentication Protocol Methods (Méthodes EAP)​

Outre l'authentification par signature à clé publique et secrets partagés, IKE prend en charge les méthodes définies dans RFC 3748 [EAP]. Souvent asymétriques (utilisateur vers serveur), elles peuvent ne pas être mutuelles. Elles servent typiquement à authentifier l'initiateur vers le répondant et DOIVENT être combinées avec une authentification du répondant vers l'initiateur par signature à clé publique. On parle souvent de mécanismes d'« authentification héritée ».

Ce document référence [EAP] pour permettre de nouvelles méthodes sans mise à jour; des variantes simples sont documentées ici. [EAP] exige un nombre variable de messages. L'authentification extensible dans IKE s'implémente par des échanges IKE_AUTH supplémentaires qui DOIVENT être menés à bien pour initialiser l'IKE SA.

L'initiateur signale EAP en omettant la charge AUTH du premier message IKE_AUTH. (Pour l'authentification non-EAP, AUTH est requise.) Avec IDi mais sans AUTH, l'identité est déclarée mais non prouvée. Si le répondant accepte EAP, il place une charge EAP dans la réponse IKE_AUTH et retarde SAr2, TSi, TSr jusqu'à l'authentification ultérieure. Établissement minimal:

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 en section 2.2, avec EAP chaque paire de messages d'établissement incrémente les numéros; la première paire IKE_AUTH a l'ID 1, la seconde 2, etc.

Pour les méthodes EAP créant une clé partagée, celle-ci DOIT être utilisée par les deux pour générer les AUTH des messages 7 et 8 selon la section 2.15. La clé est le champ MSK de la spécification EAP. Cette clé générée pendant l'échange IKE NE DOIT PAS servir à autre chose.

Les méthodes EAP sans clé partagée ne DEVRAIENT PAS être utilisées: elles sont vulnérables aux attaques homme-du-milieu [EAPMITM] dans d'autres protocoles sans tunnel authentifié par le serveur. Voir les considérations de sécurité. Si de telles méthodes sont utilisées, les AUTH des messages 7 et 8 DOIVENT utiliser SK_pi et SK_pr respectivement.

L'initiateur avec EAP DOIT pouvoir étendre l'échange initial à au moins dix échanges IKE_AUTH si le répondant envoie des notifications ou réessaie l'invite d'authentification. Après succès de la méthode EAP, le répondant DOIT envoyer une charge EAP Success; en cas d'échec, Failure. Le répondant PEUT à tout moment terminer par une charge EAP Failure.

Après un tel échange étendu, les AUTH EAP DOIVENT figurer dans les deux messages suivant celui qui contient EAP Success.

Avec EAP, le contenu de IDi peut servir uniquement au routage AAA et au choix de la méthode EAP, et différer de l'identité authentifiée par EAP. Les décisions de politique et d'accès DOIVENT utiliser l'identité réellement authentifiée. Souvent le serveur EAP est sur un serveur AAA séparé; l'identité authentifiée, si différente de IDi, DOIT être transmise de l'AAA au répondant IKEv2.

Dernière mise à jour le