Home
IPSec

e-Mail an mich
Das Internet Key Management Protocol

Das Internet Key Management Protocol

Grundsätzlich bietet IPSec die Möglichkeit, die Schlüsselverwaltung manuell oder automatisch zu gestalten. Bei der manuellen Schlüsselverwaltung richtet der Systemadministrator die symmetrischen Schlüssel und alle erforderlichen Parameter von Hand ein. Diese Arbeit sollte man in großen Systemen jedoch eher dem Key Management überlassen, da man auf Grund der Anzahl der Schlüssel leicht den Überblick verlieren kann. Außerdem müssen die Schlüssel nach einem gewissen Zeitraum ausgetauscht werden, um nicht zum Sicherheitsrisiko zu werden. Der administrative Aufwand hierfür ist in einem größeren System enorm.

Das Internet Key Management Protocol IKMP dient dem automatischen Schlüsselaustausch. Es ist der wohl komplexeste Bereich von IPSec. Zu IKMP gehören die Spezifikationen Internet Security Association and Key Management Protocol ISAKMP [rfc2408], IP Security Domain of Interpretation for ISAKMP (ISAKMP DOI) [rfc2407], Internet Key Exchange IKE [rfc2409] und OAKLEY [rfc2412]. Dabei ist in ISAKMP festgehalten, wie die Aushandlung der Security Association SA stattzufinden hat, welche Meldungen geschickt werden und wie die Datenpakete inklusive Header aussehen sollen. In der ISAKMP DOI ist definiert, welche Chiffren und Hashverfahren benutzt werden können und wie die einzelnen Elemente von IPSec zusammenspielen. Das Dokument zu OAKLEY definiert den Schlüsselaustausch, der auf dem Verfahren Diffie-Hellman basiert und IKE stellt die Zusammenfassung von OAKLEY und ISAKMP zu einem Protokoll mit Schlüsselaustausch dar.

Die Security Association SA ist der wichtigste Bestandteil von ISAKMP. Die SA kann als eine Art Vertrag zwischen den Kommunikationspartnern betrachtet werden, in dem festgelegt ist, welche Chiffre verwendet wird und wie die Nachrichtenauthentifizierung zu gewährleisten ist. Außerdem sind in der SA die Schlüssel für Verschlüsselung und Authentifizierung, die Lebensdauer der Schlüssel, die Lebensdauer der SA und der Initiator der SA festgelegt. Die Nachrichten, die nach ISAKMP definiert sind, besitzen einen festen Header, der die folgenden Felder enthält:

  • Initiator Cookie (8 Byte): Cookie der Person oder des Gerätes, das den Aufbau, die Übertragung oder die Löschung einer SA initiiert hat. Als Cookie wird in der Computerbranche eine kleine, temporäre Datei bezeichnet, in der spezielle Daten gespeichert sind, die für die Verbindung benötigt werden.
  • Responder Cookie (8 Byte): Cookie der Person oder des Gerätes, das auf die Anfrage nach Aufbau, Übertragung oder Löschung einer SA antwortet.
  • Next Payload (1 Byte): Dieses Byte zeigt die Art der Daten an, die das ISAKMP Paket enthält. Mögliche Arten des Payloads sind z.B. Security Association, Key Exchange, Signature oder Notification.
  • Major Version (4 Bit): Dieses Feld zeigt die Hauptversion  des ISAKMP Protokolls an. Ist ISAKMP nach [rfc2408] realisiert, so muss dieses Feld eine 1 enthalten, bei früheren Versionen muss das Feld eine 0 enthalten.
  • Minor Version (4 Bit): Dieses Feld zeigt die Unterversion des ISAKMP Protokolls an. Ist ISAKMP nach [rfc2408] realisiert, so muss dieses Feld eine 0 enthalten, bei früheren Versionen muss das Feld eine 1 enthalten.
  • Exchange Type (1 Byte): In diesem Feld ist die Art des Nachrichtenaustauschs festgelegt. Zwei Beispiele sind die Modi Identity Protection und Aggressive. In IKE ist der Modus Identity Protection als Main Mode bezeichnet und der Modus Aggressive ist als Aggressive Mode bezeichnet.
  • Flags (1 Byte): Dieses Feld enthält die drei Flags Encryption, Commit und Authentication Only. Ein Flag ist eine Ein-Bit-Variable, die anzeigt, ob ein bestimmter Zustand gegeben ist oder nicht. Das Bit Encryption zeigt an, ob die Daten, die nach dem Header kommen, verschlüsselt sind. Das Bit Commit stellt sicher, dass keine Daten verschlüsselt werden, solange die SA noch nicht ausgehandelt ist. Das Bit Authentication Only zeigt an, dass der Payload – also die zu übertragenen Daten – zwar durch Authentifizierung geschützt werden, aber nicht verschlüsselt sind.
  • Message ID (4 Byte): Nummer, die der eindeutigen Identifizierung dieser Nachricht dient.
  • Length (4 Byte): Länge der gesamten Nachricht mit Header und allen Payloads in Byte.

Jeder Payload, der in einem ISAKMP Paket übertragen wird, erhält einen eigenen generischen Header. Werden in einem Paket verschiedene Payloads übertragen, so sind diese durch ihre generischen Header voneinander abgegrenzt. Dieser generische Header hat folgende Felder:

  • Next Payload (1 Byte): Dieses Feld zeigt an, welcher Payload auf diesen Payload folgt. Ist der aktuelle Payload der letzte Payload des Paketes, so enthält dieses Feld den Wert 0.
  • Reserved (1 Byte): Dieses Feld wird zur Zeit nicht benutzt und ist daher permanent auf 0 gesetzt.
  • Payload Lenght (2 Byte): Hier ist die Länge des aktuellen Payloads inklusive des generischen Headers in Byte angegeben.

Die so definierten Pakete werden in einem Schlüsselaustausch nach IKE genutzt. IKE unterscheidet zwei Phasen. In Phase 1 wird eine neue Verbindung zwischen zwei Kommunikationspartnern aufgebaut. Dabei werden zwei Modi unterschieden – der Main Mode und der Aggressive Mode. Im Main Mode werden mehr Nachrichten ausgetauscht als im Aggressive Mode. Dadurch wird im Main Mode eine Verschleierung der Identität der Kommunikationspartner erreicht, die im Aggressive Mode nicht gegeben ist. Das liegt daran, dass die Zertifikate der Kommunikationspartner im Main Mode verschlüsselt übertragen werden, während sie im Aggressive Mode im Klartext übertragen werden.

Im Main Mode schickt der Initiator zunächst den ISAKMP Header, gefolgt von den gewünschten Parametern der SA, die den Payload des ISAKMP Pakets darstellen. Der Antwortende schickt seinerseits ein ISAKMP Paket, in dem er die Parameter der SA bestätigt. Nun schickt der Initiator ein Paket, das die Payloads Key Exchange KE und Ni enthält. In KE sind alle benötigten Diffie-Hellman Parameter enthalten und Ni ist ein vom Initiator ermittelter Zufallswert. Daraufhin schickt auch der Antwortende seine Diffie-Hellman Parameter und den Wert Nr, der der von ihm ermittelten Zufallszahl entspricht. Das nun folgende Paket des Initiators ist bereits entsprechend der SA mit dem gerade ausgehandelten Schlüssel verschlüsselt. Es enthält die Identifikationsnummer IDii des Initiators, gegebenenfalls sein Zertifikat und seine Signatur. Die Signatur wird aus beiden Zufallswerten, den öffentlichen Schlüsseln und den Cookies der beiden Kommunikationspartner, dem Ergebnis der Berechnung nach Diffie-Hellman (Shared Secret), der SA und der Identifikationsnummer IDii des Initiators gebildet. Zur Bestätigung schickt der Antwortende ein ebenfalls verschlüsseltes ISAKMP Paket, das die Identifikationsnummer IDir des Antwortenden, gegebenenfalls sein Zertifikat und seine Signatur enthält. Die Signatur wird wie beim Initiator berechnet, nur dass die Identifikationsnummer IDir statt IDii benutzt wird.

Beim Aggressive Mode werden diese Payloads in nur drei Paketen übertragen, weswegen hier auch die Verschlüsselung des Zertifikats wegfällt. Daher bietet der Aggressive Mode keine Verschleierung der Identität der Kommunikationspartner.

In Phase 2, dem sogenannten Quick Mode, wird die SA erneuert oder ausgetauscht. Der Sitzungsschlüssel, der zur Verschlüsselung und zur Authentifizierung benutzt wird, kann dabei ausgetauscht oder beibehalten werden. Der aktuelle Sitzungsschlüssel schützt hierbei die Erneuerung der SA, so dass die Identität der verhandelnden Partner verschleiert wird. Zunächst schickt der Initiator die Payloads Hash(1), SA, Ni, gegebenenfalls KE und IDci und IDcr in verschlüsselter Form. Der Hashwert Hash(1) berechnet sich aus den bisherigen Zufallswerten Ni und Nr, dem Shared Secret, den Cookies der beiden Kommunikationspartner, dem Wert 1, der Message ID und den Payloads der Nachricht. Die Payloads IDci und IDcr sind die Client Identifikationsnummern, falls die Übertragung der Daten im Tunnelmodus stattfindet und eine gesonderte SA für zwei miteinander verbundene Clients geschaffen werden soll. Im Anschluss an die erste Nachricht schickt der Antwortende die Payloads Hash(2), SA, Nr, gegebenenfalls KE und IDci und IDcr, ebenfalls in verschlüsselter Form. Der Wert Hash(2) unterscheidet sich von Hash(1) nur durch das Hinzufügen des Zufallswertes Nr und das Weglassen des generischen Headers von Ni. Abschließend schickt der Initiator den Payload Hash(3), der sich aus den bisherigen Zufallswerten Ni und Nr, dem Shared Secret, den Cookies der beiden Kommunikationspartner, den Werten 1 und 0, der Message ID und den gerade ausgetauschten Zufallswerten Ni und Nr ohne deren Header berechnet.

Der Ansatz, Cookies beim Verbindungsaufbau zu verwenden, entstammt dem Dokument zu OAKLEY [rfc2412]. Die Cookies sollen verhindern, dass ein Angreifer durch viele Verbindungsanfragen einen Server so beschäftigt, dass dieser seinen eigentlichen Aufgaben nicht mehr nachkommen kann. Diese Art von Angriff wird Denial of Service Angriff, oder kurz DoS Attacke, genannt. Zu diesen Angriffen gehört auch das sogenannte SYN Flooding. Der Schlüsselaustausch basiert auf dem Verfahren nach Diffie-Hellman.

[Home] [IPSec] [SSL] [AES-Kandidaten] [Über mich] [Links] [Gästebuch]