Aller au contenu principal

3.16. Payload EAP

3.16. Payload EAP​

Le payload EAP (Extensible Authentication Protocol) est utilisé pour transporter des messages EAP dans IKEv2, afin de prendre en charge l'authentification basée sur des méthodes EAP (telles que EAP-TLS, EAP-SIM, etc.).

Le format du payload EAP est le suivant :

                 1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ EAP Message ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 21 : Format du payload EAP

o EAP Message (longueur variable) - Contenu du message EAP, tel que défini dans la RFC 3748.

Lors de l'utilisation d'EAP dans IKEv2, le processus d'authentification est le suivant :

  1. L'initiateur envoie un payload EAP vide (ou un payload AUTH sans EAP) dans la requête IKE_AUTH.
  2. Le répondeur envoie le premier message EAP (généralement EAP-Request/Identity) dans la réponse IKE_AUTH.
  3. L'initiateur envoie le message EAP-Response dans un échange INFORMATIONAL ultérieur.
  4. Ce processus continue jusqu'à ce que la méthode EAP soit terminée.
  5. Une fois l'EAP terminé avec succès, l'initiateur répondant DOIT confirmer dans un message INFORMATIONAL contenant un payload AUTH (si AUTH est utilisé).

Note : les méthodes EAP sont utilisées pour fournir un facteur d'authentification supplémentaire lors du processus d'authentification IKEv2. Cependant, le payload AUTH de l'initiateur (envoyé après l'achèvement de l'EAP) protège la méthode EAP elle-même contre les attaques de l'homme du milieu.

Les implémentations DOIVENT prendre en charge la réception et le traitement des payloads EAP. Les implémentations DEVRAIENT prendre en charge au moins une méthode EAP.