IPsec
Das IPsec-Protokoll wurde 1998 entwickelt, um die Schwächen des Internetprotokolls (IP) zu beheben. Es stellt eine Sicherheitsarchitektur für die Kommunikation über IP-Netzwerke zur Verfügung. Das Protokoll soll Vertraulichkeit, Authentizität und Integrität gewährleisten. Daneben soll es vor so genannten Replay-Angriffen schützen - das heißt, ein Angreifer kann nicht durch Abspielen eines vorher mitgeschnittenen Dialogs die Gegenstelle zu einer wiederholten Aktion verleiten.
IPsec entstand im Zuge der Entwicklung von IPv6 und ist in verschiedenen RFCs spezifiziert:
- RFC 2401
- Sicherheitsarchitektur für das Internetprotokoll (RFC 2401)
- RFC 2402
- Authentication Header (RFC 2402)
- RFC 2406
- Encapsulating Security Payload (RFC 2406)
- RFC 2407
- IPsec Domain of Interpration (IPsec DoI, RFC 2407)
- RFC 2408
- Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408)
- RFC 2409
- Internet Key Exchange (IKE, RFC 2409)
Der RFC 2401 bildet das Hauptdokument zu IPsec. Von dort aus werden die oben genannten RFCs referenziert. Wesentliche Inhalte von IPsec sind das Authentication Header Protokoll (AH) und das Encapsulated Security Payload Protokoll (ESP) sowie das Protokoll zum Austausch der Schlüssel.
Im Gegensatz zu anderen Verschlüsselungsprotokollen wie etwa SSH arbeitet IPsec auf der Netzwerkschicht (Schicht 3) des OSI-Referenzmodells.
Schlüsselverwaltung (IKE)
Das Internet Key Exchange (IKE) Protokoll dient der automatischen Schlüsselverwaltung für IPSec. Es arbeitet nach dem Diffie-Hellman Verfahren für einen sicheren Austausch von Schlüsseln über ein unsichers Netzwerk und ist wohl der komplexeste Teil von IPSec. IKE ist in RFC 2409 spezifiziert und basiert auf dem Internet Security Association and Key Management Protokoll (ISAKMP, RFC 2408), der IPsec Domain of Interpretation (DOI, RFC 2407), OAKLEY (RFC 2412) und SKEME.
Vor dem eigentlichen Start einer verschlüsselten Verbindung muss man sich auf die zu verwendenden Schlüssel und Algorithmen einigen. Hierfür ist IKE gedacht. IPsec arbeitet mit verschiedenen symmetrischen wie asymmetrischen Schlüsseln. Schlüssel können manuell oder automatisch ausgehandelt werden.
IKE basiert auf UDP und nutzt standardmäßig den Port 500. Es arbeitet in zwei Phasen:
- Aushandlung einer Security Association (SA) für ISAKMP mittels Aggresive Modus oder Main Modus
- Erzeugung einer SA für IPsec mittels Quick Modus
Eine Security Association ist ein Vertrag zwischen den kommunizierenden Stellen. Hierin wird festgelegt, welche Authentifizierungs- und Verschlüsselungsalgorithmen genutzt werden sollen.
Main Modus (1. Phase)
Der Main Modus kann in der ersten Phase der Internet Key Exchange genutzt werden. Hierbei handeln der Initiator (derjenige, der die Verbindung aufnehmen will) und der Antwortende miteinander SAs für ISAKMP aus. Diese "Verhandlung" geschieht in folgenden sechs Schritten:
- Initiator sendet einen oder mehrere Vorschläge mit Authentifizierungs- und Verschlüsselungsalgorithmen
- Antwortender wählt einen Vorschlag aus und bestätigt
- Initiator sendet öffentlichen Teil der Diffie-Hellmann-Schlüsselvereinbarung und einen zufälligen Wert (Nonce)
- Antwortender schickt ebenfalls öffentlichen Teil der Diffie-Hellmann-Schlüsselvereinbarung und einen zufälligen Wert (Nonce)
- Initiator berechnet Signatur und sendet diese mit seiner Identität an Antwortenden. Diese Daten werden mit einem symmetrischen Schlüssel verschlüsselt.
- Antwortender schickt gleiche Daten von seiner Seite an den Initiator
Aggressive Modus (1. Phase)
Im Aggressive Modus werden die obigen Schritte auf drei zusammengefasst. Hierbei fällt dann die Verschlüsselung des obigen fünften Schrittes weg. Stattdessen werden die Werte im Klartext übertragen. Daher sollte man diesen Modus nach Möglichkeit nicht verwenden.
Quick Modus (2. Phase)
Der Quick Modus wird in der zweiten Phase von IKE zur Anwendung gebracht. Die gesamte Kommunikation in dieser Phase erfolgt verschlüsselt. Wie in der ersten Phase wird zunächst ein Vorschlag (Proposal) gemacht. Dieser wird zusammen mit einem Hashwert und der Nonce übertragen. Später werden die Schlüssel neu berechnet und es gehen keinerlei Informationen aus den zuvor generierten SAs ein. Dies stellt sicher, dass niemand von der zuvor generierten Schlüsseln auf die neuen schließen kann.
Authentication Header
Der Authentication Header (AH) soll die Integrität und Authentizität der übertragenen Pakete sicherstellen. Weiterhin existiert hier ein Schutz gegen Replay-Angriffe. AH versucht alle möglichen Felder eines IP-Datagramms zu schützen. Es werden lediglich Felder ausgeschlossen, die sich während des Laufes eines IP-Paketes ändern können.
Ein AH-Paket sieht folgendermaßen aus:
| 0 | 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 |
| Nächster Header | Nutzerdaten | reserviert | |
| Security Parameters Index (SPI) | |||
| Feld mit Sequenznummern | |||
|
Authentizitätsdaten (variabel) | |||
Bedeutung der Felder:
- Nächster Header (next header)
- identifiziert das Protokoll, der im Paket übertragenen Daten
- Nutzdaten Länge (payload length)
- Größe des AH-Paketes
- reserviert (RESERVED)
- reserviert für zukünftige Nutzung
- Security Parameters Index (SPI)
- identifiziert in Verbindung mit der IP-Adresse und dem Sicherheitsprotokoll die Sicherheitsassoziation
- Feld mit Sequenznummern (sequence number)
- ansteigende Nummer, die vom Absender gesetzt wird, soll Schutz vor Replay-Angriff bieten
- Authentizitätsdaten (authentication data)
- enthält den Wert des Integritätstests (integrity check value, ICV)
Encapsulated Security Payload (ESP)
Encapsulating Security Payload (ESP) soll die Authentifizierung, Integrität und Vertraulichkeit von IP-Paketen sicher stellen. Im Unterschied zu AH wird der Kopf des IP-Paketes nicht mit berücksichtigt.
Ein ESP-Paket sieht folgendermaßen aus:
| 0 | 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 | ||||||||
| Security Parameters Index (SPI) | |||||||||||||||||||||||||||||||||||||||
| Sequenznummer | |||||||||||||||||||||||||||||||||||||||
|
Nutzdaten * (variabel) | |||||||||||||||||||||||||||||||||||||||
| Füllung (0-255 bytes) | |||||||||||||||||||||||||||||||||||||||
| Länge Füllung | Nächster Header | ||||||||||||||||||||||||||||||||||||||
|
Authentizitätsdaten (variabel) | |||||||||||||||||||||||||||||||||||||||
Bedeutung der Felder:
- Security Parameters Index (SPI)
- identifiziert in Verbindung mit der IP-Adresse und dem Sicherheitsprotokoll die Sicherheitsassoziation
- Sequenznummern (sequence number)
- ansteigende Nummer, die vom Absender gesetzt wird, soll Schutz vor Replay-Angriff bieten
- Nutzdaten (payload data)
- enthält die Datenpakete
- Füllung (padding)
- wird für eingesetzte Blockchiffre genutzt, um Daten bis zur vollen Größe des Blocks aufzufüllen
- Länge Füllung (pad length)
- enthält Anzahl der eingefügten Bits für Padding
- Nächster Header (next header)
- identifiziert das Protokoll, der im Paket übertragenen Daten
- Authentizitätsdaten (authentication data)
- enthält den Wert des Integritätstests (integrity check value, ICV)
Kritik an IPsec
- IPsec was a great disappointment to us. Given the quality of the people that worked on it and the time that was spent on it, we expected a much better result. (Bruce Schneier)
Die Experten für Kryptographie Bruce Schneier und Niels Ferguson evaluierten mehrfach das IPsec-Protokoll und fanden mehrere Kritikpunkte. Neben der Art wie es entstand, wird vor allem die hohe Komplexität und damit Fehleranfälligkeit kritisiert. Allerdings stellen beide auch fest, dass es das beste derzeit erhältliche IP-Sicherheits-Protokoll ist.
Beim Lesen der RFCs stellt man fest, dass es keinerlei Angaben gibt, was man mit IPsec erreichen wollte. Weiterhin gibt es in den RFCs z.T. widersprüchliche Angaben.
Wenn man sich beide Modi Tunnel und Transport betrachtet, stellt man fest, dass der Transportmodus eine Teilmenge des Tunnelmodus ist. Mit kleinen Erweiterungen könnte man mit dem Tunnelmodus alles abdecken.