Zum Hauptinhalt springen

3.16. EAP-Payload

3.16. EAP-Payload​

Der EAP-Payload (Extensible Authentication Protocol) wird verwendet, um EAP-Nachrichten in IKEv2 zu transportieren, um die Authentifizierung auf Basis von EAP-Methoden (wie EAP-TLS, EAP-SIM usw.) zu unterstützen.

Das Format des EAP-Payloads ist wie folgt:

                 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 des EAP-Payloads

o EAP Message (variable Länge) - Inhalt der EAP-Nachricht, wie in RFC 3748 definiert.

Bei der Verwendung von EAP in IKEv2 ist der Authentifizierungsprozess wie folgt:

  1. Der Initiator sendet einen leeren EAP-Payload (oder einen AUTH-Payload ohne EAP) in der IKE_AUTH-Anfrage.
  2. Der Responder sendet die erste EAP-Nachricht (üblicherweise EAP-Request/Identity) in der IKE_AUTH-Antwort.
  3. Der Initiator sendet die EAP-Response-Nachricht in einem späteren INFORMATIONAL-Austausch.
  4. Dieser Prozess setzt sich fort, bis die EAP-Methode abgeschlossen ist.
  5. Sobald EAP erfolgreich abgeschlossen ist, MUSS der antwortende Initiator in einer INFORMATIONAL-Nachricht mit einem AUTH-Payload (falls AUTH verwendet wird) bestätigen.

Hinweis: EAP-Methoden werden verwendet, um während des IKEv2-Authentifizierungsprozesses einen zusätzlichen Authentifizierungsfaktor bereitzustellen. Der AUTH-Payload des Initiators (der nach Abschluss von EAP gesendet wird) schützt jedoch die EAP-Methode selbst vor Man-in-the-Middle-Angriffen.

Implementierungen MÜSSEN den Empfang und die Verarbeitung von EAP-Payloads unterstützen. Implementierungen SOLLTEN mindestens eine EAP-Methode unterstützen.