Security auf dem Network Layer

ISAKMP Phase 1

Die folgenden Grafiken zeigen schematisch den Ablauf von Phase 1 einer ISAKMP-Verhandlung.

Message 1: Der Initiator konfrontiert den Responder mit einer Auswahl von verschiedenen Vorschlägen (Proposals), nach welchen Verschlüsselungs- und Authentifizierungsalgorithmen (Transform) die ISAKMP-SA ausgehandelt werden könnte. Im ISAKMP-Header wird das Feld Initiator-Cookie auf einen Pseudozufallswert C(i) gesetzt, der dann später zusammen mit dem Responder-Cookie C(r) den Nachrichtenfluss authentifiziert. Nachrichten innerhalb eines ISAKMP-Paketes können sich in langen Folgen aneinander reihen. Dabei gibt jede Nachricht über das Feld Next Payload an, ob noch weitere Nachrichten folgen. Dabei können mehrere Transform-Nachrichten zu einer Proposal-Nachricht und mehrere Proposal-Transform-Kombinationen zu einer SA gehören.

Message 2: Der Responder antwortet, indem er sich aus den Vorschlägen einen heraussucht. Das Rahmenformat ist identisch mit der Message 1. Im ISAKMP-Header setzt der Responder das Feld Responder-Cookie auf einen Pseudozufallswert C(r). Zusätzlich repliziert er auch C(i), so dass eine erste (schwache) Authentifizierung stattfindet. C(r) und C(i) bilden zusammen als SPI den Index für den Zugriff auf die Security Association Database mit den gemeinsamen Verbindungsparametern.

Message 3: Mit der dritten Nachricht beginnt nun der Austausch der kryptographischen Informationen. Der Initiator teilt seinen öffentlichen Diffie-Hellman-Schlüssel g(i) mit. Zudem liefert er eine pseudozufällige und große Zahl, die man als Nonce (engl. für Ad-hoc) N(i) bezeichnet.

Message 4: Der Responder antwortet mit seinem öffentlichen Diffie-Hellman-Schlüssel g(r) und seiner Nonce N(r). Aus diesen Informationen berechnen nun beide Stationen eine Reihe von unterschiedlichen Schlüsseln. Hierzu zählt insbesondere der Master-Key SKEYID. Aus diesem werden verschiedene weitere Schlüssel abgeleitet, die zur Verschlüsselung beim nachfolgenden Datentransfer zum Einsatz kommen. SKEYID_d ist der Schlüssel, der in der zweiten IKE-Phase zur Verschlüsselung von nicht-ISAKMP-konformen SAs eingesetzt wird. SKEYID_a wird zur Authentifizierung von ISAKMP-Nachrichten verwendet, SKEYID_e zur deren Verschlüsselung.

Nun haben beide Stationen die für die Übertragung benötigten Schlüssel generiert und überprüfen diesen Status mit den beiden letzten Nachrichten Message 5 und Message 6. Hierbei übertragen sie eine verschlüsselte Authentifizierung.