2.16. Extensible Authentication Protocol Methods (EAP-Methoden)

2.16. Extensible Authentication Protocol Methods (EAP-Methoden)

Neben öffentlichen Schlüsselsignaturen und Shared Secrets unterstützt IKE Methoden aus RFC 3748 [EAP]. Diese sind oft asymmetrisch (Nutzer gegenüber Server) und nicht notwendig gegenseitig. Daher authentisieren sie typischerweise den Initiator gegenüber dem Responder und MÜSSEN mit einer öffentlichen-Signatur-Authentisierung des Responders gegenüber dem Initiator kombiniert werden.

Dieses Dokument verweist auf [EAP], damit neue Methoden ohne Aktualisierung hinzugefügt werden können; einfachere Varianten werden hier skizziert. [EAP] definiert ein Protokoll mit variabler Nachrichtenzahl. Erweiterbare Authentisierung in IKE erfolgt durch zusätzliche IKE_AUTH-Austausche, die zur Initialisierung der IKE SA abgeschlossen sein MÜSSEN.

Der Initiator signalisiert EAP durch Weglassen der AUTH-Nutzlast in der ersten IKE_AUTH-Nachricht. Mit IDi ohne AUTH wird eine Identität deklariert, aber nicht bewiesen. Akzeptiert der Responder EAP, setzt er eine EAP-Nutzlast in die IKE_AUTH-Antwort und verschiebt SAr2, TSi, TSr bis nach abgeschlossener Initiator-Authentisierung. Minimalbeispiel:

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}

Wie in Abschnitt 2.2 erhöht sich bei EAP die Nachrichtennummer je Paar; erstes IKE_AUTH-Paar ID 1, zweites 2, usw.

Erzeugt eine EAP-Methode ein Shared Secret als Nebeneffekt, MUSS dieses von beiden für AUTH in Nachrichten 7 und 8 nach Abschnitt 2.15 verwendet werden. Das Feld heißt in der EAP-Spezifikation MSK. Dieses während IKE erzeugte Secret DARF zu keinem anderen Zweck dienen.

EAP-Methoden ohne Shared Secret sollten nicht verwendet werden; sie sind anfällig für Man-in-the-Middle [EAPMITM] in anderen Protokollen ohne server-authentifizierten Tunnel. Siehe Sicherheitsbetrachtungen. Werden sie dennoch genutzt, MÜSSEN AUTH in 7 und 8 mit SK_pi bzw. SK_pr erzeugt werden.

Der Initiator einer IKE SA mit EAP MUSS den anfänglichen Austausch auf mindestens zehn IKE_AUTH-Austausche erweitern können (Benachrichtigungen, erneute Authentisierungsaufforderung). Nach erfolgreichem EAP MUSS der Responder EAP Success senden; bei Fehler Failure. Der Responder KANN jederzeit mit EAP Failure abbrechen.

Nach solchem erweiterten Austausch MÜSSEN die EAP-AUTH-Nutzlasten in den zwei Nachrichten nach der mit EAP Success stehen.

Bei EAP kann IDi nur für AAA-Routing und EAP-Methodenwahl dienen und von der EAP-authentisierten Identität abweichen. Richtlinien und Zugriffskontrolle MÜSSEN die tatsächlich authentisierte Identität verwenden. Oft liegt der EAP-Server auf einem separaten AAA-Server; dann MUSS die authentisierte Identität ggf. vom AAA zum IKEv2-Responder übermittelt werden.