IPsec

IPsec im TCP/IP‑Protokollstapel:

Anwendung	HTTP	IMAP	SMTP	DNS	…
Transport	TCP			UDP
Internet	IPsec
Netzzugang	Ethernet	Token Bus	Token Ring	FDDI	…

Dieser Artikel wurde aufgrund von inhaltlichen Mängeln auf der Qualitätssicherungsseite der Redaktion Informatik eingetragen. Dies geschieht, um die Qualität der Artikel aus dem Themengebiet Informatik auf ein akzeptables Niveau zu bringen. Hilf mit, die inhaltlichen Mängel dieses Artikels zu beseitigen und beteilige dich an der Diskussion! (+)
Begründung: Der Artikel ist zu wenig allgemeinverständlich (schon bei manchen Zwischenüberschriften dürften viele Leser aussteigen), zeigt die praktische Anwendung nicht hinreichend auf und IKEv2 ist als lückenhaft gekennzeichnet.

IPsec (Kurzform für Internet Protocol Security) ist ein Sicherheitsprotokoll, das für die Kommunikation über IP-Netze die Schutzziele Vertraulichkeit, Authentizität und Integrität gewährleisten soll. Es kann zum Aufbau virtueller privater Netzwerke (VPN) verwendet werden.

Im Gegensatz zu anderen Verschlüsselungsprotokollen wie etwa SSL arbeitet IPsec direkt auf der Vermittlungsschicht (Internet layer) des TCP/IP-Protokollstapels (entspricht Schicht 3 des OSI-Modells).

RFC 2401 bzw. RFC 4301 (neu) beschreiben die Architektur von IPsec. Von dort aus wird auf die unten genannten RFCs verwiesen, die wesentliche Teile von IPsec beschreiben: die Protokolle Authentication Header (AH), Encapsulated Security Payload (ESP) sowie Internet Key Exchange (IKE) zum Austausch der Schlüssel.

Verbindungsaufbau

SPD und SAD

IPsec verwaltet Verbindungen und kann auf Anforderung hin sowohl Verschlüsselung als auch Datenintegrität garantieren.

Der "transport mode" stellt Punkt-zu-Punkt-Kommunikation zwischen zwei Endpunkten her, während der "tunnel mode" zwei Subnetze über zwei Router verbindet. Dazu unten mehr.

Wir ignorieren bei der folgenden Betrachtung den "tunnel mode", um die Darstellung nicht noch zusätzlich zu verkomplizieren. Allerdings sind sich beide Modi in Bezug auf die zu erstellenden "Security Associations" recht ähnlich.

Wenn ein IP-Paket versendet werden soll, dann werden zwei lokale Datenbanken verwendet:

• SPD (security policy database)

  In der SPD ist beispielsweise hinterlegt, wie die Verbindung zwischen den Kommunikationsendpunkten mit den IP-Adressen 80.16.36.1 und 89.1.26.17 gesichert werden soll. Als Sicherungsverfahren werden dann AH, ESP oder beide eingesetzt. Zum Erstellen der Schlüssel wird meist IKE verwendet. Die SPD ist im Vergleich zur SAD (s. u.) eher von statischer Natur, da ein Eintrag in der SPD „zustandslos“ ist.

• SAD (security association database)

  

  SAs zwischen zwei hosts

  In der SAD werden Security Associations (SA) verwaltet. Diese besitzen einen Zustand (engl. "stateful") und ändern sich im Vergleich zu Einträgen in der SPD recht oft. SA-Einträge enthalten u.a. die Schlüssel für das verwendete Protokoll, und sie haben eine begrenzte Gültigkeit. Für AH und ESP existieren jeweils eigene SA-Einträge in der SAD. Eine SA wird meist über das IKE-Protokoll angelegt und wird nur in eine Richtung verwendet: Beim Sender gibt sie das Verschlüsselungsverfahren und den Schlüssel vor, beim Empfänger das passende Entschlüsselungsverfahren. Das Entschlüsseln erfolgt bei der Verwendung von symmetrischer Verschlüsselung mit demselben Schlüssel, der zur Verschlüsselung verwendet wurde. Wenn zwei Hosts AH und ESP verwenden, dann sind je Host vier SA-Einträge notwendig. Im Bild wird dies veranschaulicht.

Bei IPsec müssen alle Endpunkte vorkonfiguriert sein, da sonst keine Vertrauensbeziehung aufgebaut werden kann.

Damit zwei Endpunkte eine Vertrauensbeziehung aufbauen können, wird ein Schlüsselaustauschverfahren benötigt.

• manuelle Schlüsselkonfiguration

hier werden statische Schlüssel zwischen Endpunkten vergeben

• automatische Schlüsselkonfiguration

  hier werden Sitzungsschlüssel automatisch über Zertifikate ausgehandelt

  • via IKEv1 (alt)
  • via IKEv2 (neu)

Manuelle Schlüsselkonfiguration

Die Schlüssel, die für IPsec verwendet werden, werden beim „Manual Keying“ vorab ausgetauscht und auf beiden Endpunkten fest konfiguriert. Ein Nachteil im Vergleich zu ISAKMP (auch als IKE bezeichnet) ist, dass dort der Schlüssel für IPsec automatisch erzeugt und in regelmäßigen Abständen geändert wird.

Internet Key Exchange (IKEv1)

Das Internet-Key-Exchange-Protokoll dient der automatischen Schlüsselverwaltung für IPsec. Es verwendet den Diffie-Hellman-Schlüsselaustausch für einen sicheren Austausch von Schlüsseln über ein unsicheres Rechnernetz und ist wohl der komplexeste Teil von IPsec. Internet Key Exchange war ursprünglich im RFC 2409 spezifiziert und basierte auf dem Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408), der IPsec Domain of Interpretation (DOI, RFC 2407), OAKLEY (RFC 2412) und SKEME. Die RFCs 2407, 2408 und 2409 sind in der aktuellen Version IKEv2 im RFC 4306 zusammengefasst und damit obsolet.

IKE definiert, wie Sicherheitsparameter vereinbart und gemeinsame Schlüssel (shared keys) ausgetauscht werden. Was ausgetauscht wird, ist Aufgabe eines DOI-Dokuments.

Vor dem eigentlichen Start einer verschlüsselten Verbindung mit IPsec müssen sich beide Seiten gegenseitig authentisieren und sich auf die zu verwendenden Schlüssel-Algorithmen einigen. Hierfür ist IKE gedacht. Zur Authentisierung werden die Verfahren Pre Shared Keying (PSK) und Certificate eingesetzt. IPsec arbeitet mit verschiedenen symmetrischen wie asymmetrischen Schlüsseln.

IKE basiert auf UDP und nutzt standardmäßig den Port 500 als Quell- und Ziel-Port. Wird IKE und IPsec jedoch hinter einer Masquerading-Firewall betrieben, wird von den meisten IPsec-Implementierungen in diesem Fall UDP-Port 4500 verwendet. Um das Problem mit IPsec-Verbindungen hinter Masquerading-Firewalls zu lösen, wurden mehrere Vorschläge eingereicht. Keiner der Vorschläge wurde jedoch als Standard anerkannt, weshalb der Betrieb einer IPsec-Verbindung von einem Host über eine Firewall hinweg sehr unzuverlässig ist. Die beste Lösung ist eine Non-Masquerading-Firewall mit einer angeschlossenen DMZ. In der DMZ steht dann der Endpunkt der IPsec-Verbindung.

IKE arbeitet in zwei Phasen:

1. Aushandlung einer SA (Security Association) für ISAKMP entweder über den Aggressive Mode (Aggressiver Modus) oder Main Mode (Hauptmodus)
2. Erzeugung einer SA für IPsec mittels Quick Mode (Schnellmodus)

Eine Security Association (SA) ist eine Vereinbarung zwischen den beiden kommunizierenden Seiten und besteht aus den Punkten:

1. Identifikation (entweder per PSK oder Zertifikat)
2. Festlegung des zu verwendenden Schlüsselalgorithmus für die IPsec-Verbindung
3. von welchem (IP-) Netz die IPsec-Verbindung erfolgt
4. zu welchem (IP-) Netz die Verbindung bestehen soll
5. Zeiträume, in denen eine erneute Authentisierung erforderlich ist
6. Zeitraum, nach dem der IPsec-Schlüssel erneuert werden muss

Phase 1 - Main Mode

Der Main Mode (dem Aggressive Mode vorzuziehen) wird in der ersten Phase der Verschlüsselungsvereinbarung und Authentisierung (Internet Key Exchange) genutzt. Hierbei handeln der Initiator (derjenige, der die Verbindung aufnehmen will) und der Antwortende (der Responder) miteinander eine ISAKMP-SA aus. Diese „Verhandlung“ geschieht in folgenden Schritten:

1. Der Initiator sendet einen Vorschlag (zur Not auch mehrere) mit Authentisierungs- und Verschlüsselungsalgorithmen.
2. Der Responder wählt aus der Schnittmenge der angebotenen und der von ihm unterstützten Algorithmen den sichersten aus und sendet das Auswahlergebnis an den Initiator.
3. Der Initiator sendet seinen öffentlichen Teil vom Diffie-Hellman-Schlüsselaustausch und einen zufälligen Wert (die Nonce).
4. Der Responder sendet ebenfalls seinen öffentlichen Teil vom Diffie-Hellman-Schlüsselaustausch und einen zufälligen Wert. Dieser Wert dient in Schritt 5 der Authentisierung.

Da nun beide (der Responder und der Initiator) die öffentlichen Teile für den Diffie-Hellman-Schlüsselaustausch kennen, wird dieses Verfahren genutzt, um den geheimen Schlüssel zu berechnen. Dieser wird dann für die Verschlüsselung nach dem vereinbarten Schlüsselverfahren für die folgenden Schritte verwendet. Der berechnete (Diffie-Hellman-)Schlüssel wird auch für die Erzeugung eines weiteren Schlüssels genutzt, der für die Authentifikation verwendet wird.

Schritt 5 ist die Authentisierung. Dabei müssen sich beide Beteiligten als zugriffsberechtigt ausweisen. Hierbei kommen zwei unterschiedliche Verfahren zum Einsatz:

1. die Authentisierung mittels vereinbartem Geheimnis (im englischen Pre-Shared-Keys, PSK) oder
2. zertifikatsbasiert.

Die zertifikatsbasierte Authentisierung verwendet X.509-Zertifikate und ist im Wesentlichen eine Public-Key-Infrastruktur, wie sie auch für SSL und S/MIME verwendet wird. PGP-Zertifikate sind ein anderer Ansatz und können hierfür nicht verwendet werden.

Die Authentisierungsmethoden unterscheiden sich zwar, jedoch ist die grundsätzliche Vorgehensweise immer die gleiche: Es wird immer ein Hashwert über das mit dem Diffie-Hellman-Schlüsselaustausch erzeugte Geheimnis, die Identität, die ausgehandelten Kryptoverfahren sowie die bisher versandten Nachrichten gebildet, verschlüsselt und versendet. (In der Literatur werden manchmal Cookies erwähnt: ein Hashwert über ein erzeugtes Geheimnis, IP-Adresse und Zeitmarke.) Der Schlüssel, der hier für die Verschlüsselung genutzt wird, ist jedoch nicht der aus dem Diffie-Hellman-Schlüsselaustausch, sondern ein Hashwert über diesen sowie die versandten Nachrichten.

PSK-Authentisierung (Pre Shared Keying):

Bei diesem Verfahren erfolgt die Authentisierung anhand eines einzigen gemeinsamen Geheimnisses. Es kann angewendet werden, wenn eine überschaubare Teilnehmermenge an das IPsec-VPN angeschlossen ist. Der wesentliche Nachteil ist: Erhält jemand unberechtigten Zugriff auf diesen Schlüssel, müssen auf allen beteiligten Hosts die Schlüssel ausgetauscht werden, um die Sicherheit wiederherzustellen. Soll ein Rechnernetz wachsen, ist dieses Verfahren auch dann abzulehnen, wenn zuerst nur wenige Knoten beteiligt sind. Der Mehraufwand für die zertifikatsbasierte Authentisierung amortisiert sich in der Regel bereits nach kurzer Zeit.

Zertifikatsbasierte Authentisierung:

Diese Authentisierung hat einen anderen Ansatz. Dabei werden X.509-Zertifikate verwendet. Dieses System basiert auf vertrauenswürdigen CAs (Certification Authorities, z. B. mit eTrust) oder einer Hierarchie aus diesen. Das Prinzip hierbei ist, dass jeder einzelne Endpunkt seine CAs (Vertrauensstellen) kennt und alle Zertifikate, die durch diese Vertrauensstellen signiert sind, als gültig anerkennt. In der Praxis bedeutet dies, dass alle Zertifikate von vertrauenswürdigen CAs eingespielt werden und somit alle von diesen CAs ausgestellten Zertifikaten Zugriff haben. Zertifikate können von bekannten CAs bezogen werden (VeriSign, eTrust uvm.). Damit kann gewährleistet werden, dass auch unbekannte VPN-Partner authentisiert werden können. Leider ist dies in der Praxis nicht so leicht, weil weitere Parameter (z. B. Rechnernetzadressen) eine Rolle spielen und diese mit bereits bestehenden VPN-Verbindungen kollidieren können. Es hat sich daher durchgesetzt, eine private PKI (Public Key Infrastructure) einzusetzen. Mit einer eigenen PKI sollen aber nur bekannte und vertrauenswürdige Hosts Zugriff auf das VPN haben.

Die zertifikatsbasierte Authentisierung erfolgt wie die PSK-Authentisierung, mit einem Unterschied: Je nach Verbindung kann ein anderes Zertifikat zum Einsatz kommen, und wer sein CA-Zertifikat nicht veröffentlicht, kann gezielt steuern, wer zugreifen darf.

Ein weiterer Vorteil einer zertifikatsbasierten Authentisierung: Die CA darf einzelne Zertifikate widerrufen. In der sogenannten CRL (Certificate Revocation List) werden alle Zertifikate, die irgendwie ungültig geworden sind, gesperrt. Bei einer PSK-Authentisierung ist dagegen der Austausch aller Schlüssel erforderlich.

Phase 1 - Aggressive Mode

Im "Aggressive Mode" werden die obigen Schritte auf drei zusammengefasst. Hierbei fällt dann die Verschlüsselung des obigen fünften Schrittes weg. Stattdessen werden die Hashwerte der PSKs im Klartext übertragen. Die Sicherheit des Verfahrens ist eng mit der Stärke des "pre shared keys" und des Hashverfahrens gekoppelt. Ein guter Schlüssel ist eine zufällige Wertefolge in der maximalen Schlüssellänge. Da in der Praxis gute Schlüssel oft aus Bequemlichkeit nicht gewählt werden, sollte man diesen Modus mit Vorsicht einsetzen.

Ein Grund für den Einsatz dieses Modus kann jedoch gegeben sein, wenn die Adresse des Initiators dem Responder a priori nicht bekannt ist, und beide Seiten Pre-shared Keys zur Authentisierung einsetzen wollen. Weitere Anwendungsszenarien sind gegeben, wenn ein schnellerer Verbindungsaufbau gewünscht ist und die „policies“ des Responders hinlänglich bekannt sind. Beispiel: Angestellter will aus der Ferne auf das Firmennetz zugreifen – Richtlinien (z. B. Verschlüsselung mit AES, Hashing mit SHA und Authentisierung mit RSA Signaturen, die durch die Zertifizierungsstelle der Firma signiert wurden) sind soweit bekannt.

Phase 2 - Quick Mode

Der "Quick Mode" wird in der zweiten Phase von IKE verwendet (Schutz durch die IKE SA). Die gesamte Kommunikation in dieser Phase erfolgt verschlüsselt. Wie in der ersten Phase wird zunächst ein Vorschlag (Proposal) gemacht und zusammen mit einem Hashwert und dem Nonce übertragen. Später werden die Schlüssel neu berechnet, und es fließen keinerlei Informationen aus den zuvor generierten SAs ein. Dies stellt sicher, dass niemand von den zuvor generierten Schlüsseln auf die neuen schließen kann (Perfect Forward Secrecy). Dies wird erreicht, indem ein zusätzlicher Diffie-Hellman-Austausch stattfindet. Die Geheimnisse zur Schlüsselbildung werden verworfen, sobald der Austausch abgeschlossen ist.

Mehrere "Quick Modes" können zur gleichen Zeit stattfinden und durch die gleiche IKE SA geschützt sein. Um die verschiedenen Wechsel unterscheiden zu können, wird das Message-ID-Feld des ISAKMP-Headers herangezogen. Der Status eines solchen Austausches wird durch die Cookies identifiziert.

Internet Key Exchange (IKEv2)

IKEv1 Das IKE-Protokoll (Internet Key Exchange) wird während der IPSec-Sicherheitszuordnung zur Aushandlung der verwendeten Verschlüsselungsprotokolle und zum Austausch von Signierungs- oder Verschlüsselungsschlüsseln verwendet. IKE definiert, wie die Peers Richtlinieninformationen kommunizieren und wie Authentifizierungsnachrichten aufgebaut sind und ausgetauscht werden. Es setzt sich aus drei anderen Protokollen zusammen (ISAKMP, Oakley und SKEME) und ist für die Anforderungen von IPSec geradezu ideal.

Da IKEv1 recht komplex ist, wurden viele Implementationen von IPsec inkompatibel zueinander. IKEv1 ist bei Verwendung von dynamischen IP-Adressen, wie bei DSL-Anschlüssen üblich ist, wenig geeignet. IKEv2 behebt diese Probleme.

Bei IKEv2 wurde die von IKEv1 bekannten Phasen grundlegend verändert. Um eine SA zu erstellen, benötigt man nun nur noch vier UDP-Nachrichten.^[1]

Authentication Header (AH)

Der Authentication Header (AH) soll die Authentizität und Integrität der übertragenen Pakete sicherstellen und den Sender authentisieren. Weiterhin schützt er gegen Replay-Angriffe. AH schützt die invarianten Teile eines IP-Datagramms; IP-Header-Felder, die auf dem Weg durch ein IP-Netz von Routern verändert werden können (z. B. TTL), werden nicht berücksichtigt. Werden auf dem Weg durch das Netz Router mit aktivierter Network Address Translation (NAT) passiert, so ändern diese die eigentlich invarianten Teile eines IP-Datagramms ab, folglich ist eine Authentisierung nicht mehr möglich - NAT und AH sind folglich designbedingt inkompatibel - lediglich eine Kombination von NAT und ESP (siehe RFC 3948 – UDP Encapsulation of IPsec ESP Packets) ist möglich. Die Nutzdaten werden bei AH nicht verschlüsselt und sind damit für jeden lesbar. AH basiert direkt auf IP und verwendet die IP-Protokoll Nummer 51.

Ein AH-Paket sieht folgendermaßen aus:

Byte 0								Byte 1								Byte 2								Byte 3
Bit 0	1	2	3	4	5	6	7	Bit 0	1	2	3	4	5	6	7	Bit 0	1	2	3	4	5	6	7	Bit 0	1	2	3	4	5	6	7
Nächster Header								Nutzdaten-Länge								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. Enthält den Wert, der bei ungeschützen IP-Datagrammen im IP-Header angegeben wird, bei Verwendung von AH aber durch den Wert 51 (= AH) ersetzt worden ist.

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 Security Association (SA)

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), welcher sich aus einem Hash des übrigen Paketes ergibt

Encapsulating Security Payload (ESP)

Encapsulating Security Payload (ESP) soll die Authentisierung, Integrität und Vertraulichkeit von IP-Paketen sicherstellen. Im Unterschied zum AH wird der Kopf des IP-Paketes vom ICV (Integrity check value) nicht berücksichtigt, jedoch werden die Nutzdaten verschlüsselt übertragen. ESP basiert direkt auf IP und verwendet die IP-Protokoll Nummer 50.

Ein ESP-Paket sieht folgendermaßen aus:

Byte 0								Byte 1								Byte 2								Byte 3
Bit 0	1	2	3	4	5	6	7	Bit 0	1	2	3	4	5	6	7	Bit 0	1	2	3	4	5	6	7	Bit 0	1	2	3	4	5	6	7
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 Security Association (SA)

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. Enthält den Wert, der bei ungeschützen IP-Datagrammen im IP-Header angegeben wird, bei Verwendung von ESP aber durch den Wert 50 (= ESP) ersetzt worden ist.

Authentizitätsdaten (authentication data) 

enthält den Wert des Integritätstests (integrity check value, ICV).

Tunnel- / Transport mode

Transport- vs. Tunnel-Mode

IPsec verbindet entweder zwei Endpunkte miteinander (transport mode), oder es verbindet zwei Subnetze über zwei Router miteinander (tunnel mode).

IPsec im Transportmodus

IPsec AH-Header im Transport- und Tunnelmodus

IPsec ESP-Header im Transport- und Tunnelmodus

Im Transportmodus wird der IPsec-Header zwischen dem IP-Header und den Nutzdaten eingefügt. Der IP-Header bleibt unverändert und dient weiterhin zum Routing des Pakets vom Sender zum Empfänger. Der Transportmodus wird verwendet, wenn die „kryptographischen Endpunkte“ auch die „Kommunikations-Endpunkte“ sind. Nach dem Empfang des IPsec-Paketes werden die ursprünglichen Nutzdaten (TCP/UDP-Pakete) ausgepackt und an die höherliegende Schicht weitergegeben. Der Transportmodus wird vor allem für Host-zu-Host- oder Host-zu-Router-Verbindungen verwendet, z.B. für die Netzwerkverwaltung.

IPsec im Tunnelmodus

Im Tunnelmodus wird das ursprüngliche Paket gekapselt und die Sicherheitsdienste von IPsec auf das gesamte Paket angewandt. Der neue (äußere) IP-Header dient dazu, die Tunnelenden (also die kryptografischen Endpunkte) zu adressieren, während die Adressen der eigentlichen Kommunikationsendpunkte im inneren IP-Header stehen. Der ursprüngliche (innere) IP-Header stellt für Router usw. auf dem Weg zwischen den Tunnelenden nur Nutzlast (Payload) dar und wird erst wieder verwendet, wenn das empfangende Security-Gateway (das Tunnelende auf der Empfangsseite) die IP-Kapselung entfernt hat und das Paket dem eigentlichen Empfänger zustellt.

Im Tunnelmodus sind Gateway-zu-Gateway- oder auch Peer-zu-Gateway-Verbindungen möglich. Da an jeweils einer Seite Tunnelende und Kommunikationsendpunkt auf demselben Rechner zusammenfallen können, sind auch im Tunnelmodus Peer-zu-Peer-Verbindungen möglich. Ein Vorteil des Tunnelmodus ist, dass bei der Gateway-zu-Gateway-Verbindung nur in die Gateways (Tunnelenden) IPsec implementiert und konfiguriert werden muss. Angreifer können dadurch nur die Tunnelendpunkte des IPsec-Tunnels feststellen, nicht aber den gesamten Weg der Verbindung.

Keepalives

Keepalives sind nur bedingt bidirektional, da es aufgrund mangelhafter Asymmetrie im IP-Header häufig zu Kollisionen im ISAKMP-Protokoll kommt.

ISAKMP-Keepalive (DPD)

Dead Peer Detection (DPD) wurde im Februar 2004 verabschiedet. Durch den Einsatz von DPD kann erkannt werden, ob eine IPsec-Verbindung (insbesondere der ISAKMP-Tunnel) unbeabsichtigt und unvorhergesehen abgebrochen wurde. Im Fehlerfall bauen die Gegenstellen die SAs (Security Associations) ab, um einen Neuaufbau des ISAKMP-Tunnels und der ESP-/AH-Tunnel zu ermöglichen. Ohne den Einsatz von DPD wird der Endpunkt mit noch bestehendem Tunnel den Neuaufbau abwehren, da die SPIs (Security Payload Identifier) nicht mehr passen. Ein Neuaufbau der Tunnel ist ansonsten erst nach Ablauf der Re-Keying-Timer möglich.

DPD wird als Notify-Message im ISAKMP-Protokoll (UDP:500) übertragen (Message-Values: R-U-THERE – 36136/R-U-THERE-ACK – 36137). Die DPD-Funktion dagegen gewährleistet eine kontinuierliche Überprüfung der Verbindung zur Gegenstelle und leistet einen automatischen Wiederaufbau bei ungewolltem Verbindungsabbruch. Die Spezifikation ist festgelegt im RFC 3706 und wird auch ISAKMP-Keepalive genannt.

UDP-Keepalive

Es verhindert den (bei NAT-Traversal) von NAT üblicherweise automatisch eingeleiteten Time-out bei längeren Zeitverzögerungen in der Dateneingabe. Die Spezifikation ist im RFC 3519 festgelegt und wird auch NAT-Keepalive genannt.

Kritik an IPsec

Konzeptionelles

“ 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. ”

„IPsec war eine große Enttäuschung für uns. In Anbetracht der Qualifikation der Leute, die daran gearbeitet haben, und der Zeit, die dafür aufgebracht wurde, haben wir ein viel besseres Ergebnis erwartet.“

– Bruce Schneier, Niels Ferguson : A Cryptographic Evaluation of IPsec (S. 1, Abs. 2)

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 stellten beide auch fest, dass IPsec das ursprüngliche IP zur Zeit am besten absichert.

Backdoor in OpenBSD

Im Dezember 2010 behauptete Gregory Perry, dass in der IPSEC Implementierung in OpenBSD (sowie einiger Derivate) finanziert durch das FBI Backdoors und Seitenkanal-Attacken eingebaut worden seien, die einen nicht autorisierten Zugriff bzw. das Erlangen des Schlüssels ermöglichen könnten. Technische Details wurden nicht genannt und die beschuldigten Entwickler bestreiten die Vorwürfe.^[2] Die OpenBSD-Entwickler konnten bei einem ersten Code-Review keine Anzeichen für Backdoors feststellen.^[3]

Relevante RFCs

IPsec entstand im Zuge der Entwicklung von IPv6 und ist in verschiedenen aktuellen RFCs spezifiziert:

• RFC 2367 – PF_KEY Interface
• RFC 2403 – The Use of HMAC-MD5-96 within ESP and AH
• RFC 2405 – The ESP DES-CBC Cipher Algorithm With Explicit IV
• RFC 2410 – The NULL Encryption Algorithm and Its Use With IPsec
• RFC 2411 – IP Security Document Roadmap
• RFC 2412 – The OAKLEY Key Determination Protocol
• RFC 2451 – The ESP CBC-Mode Cipher Algorithms
• RFC 2857 – The Use of HMAC-RIPEMD-160-96 within ESP and AH
• RFC 3526 – More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
• RFC 3602 – The AES-CBC Cipher Algorithm and Its Use with IPsec
• RFC 3686 – Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)
• RFC 3706 – A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
• RFC 3715 – IPsec-Network Address Translation (NAT) Compatibility Requirements
• RFC 3947 – Negotiation of NAT-Traversal in the IKE
• RFC 3948 – UDP Encapsulation of IPsec ESP Packets
• RFC 4106 – The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
• RFC 4301 – Security Architecture for the Internet Protocol
• RFC 4302 – IP Authentication Header
• RFC 4303 – IP Encapsulating Security Payload (ESP)
• RFC 4304 – Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
• RFC 4306 – Internet Key Exchange (IKEv2) Protocol
• RFC 4307 – Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
• RFC 4308 – Cryptographic Suites for IPsec
• RFC 4309 – Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
• RFC 4478 – Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
• RFC 4543 – The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
• RFC 4555 – IKEv2 Mobility and Multihoming Protocol (MOBIKE)
• RFC 4621 – Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
• RFC 4718 – IKEv2 Clarifications and Implementation Guidelines
• RFC 4806 – Online Certificate Status Protocol (OCSP) Extensions to IKEv2
• RFC 4809 – Requirements for an IPsec Certificate Management Profile
• RFC 4835 – Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
• RFC 4945 – The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX

Literatur

• Naganand Doraswamy, Dan Harkins: IPSec. The new security standard for the internet, intranets, and virtual private networks. 2nd edition. Prentice Hall PTR, Upper Saddle River NJ 2003, ISBN 0-13-046189-X.

Weblinks

• IPsec-Evaluation von Schneier (englisch)
• An illustrated guide to IPsec (englisch)
• Portbeschränkung unter Windows 2000 Server via IPSec (Vor- und Nachteile sowie HowTo)

Einzelnachweise

1. ↑ heise: IPSec-VPNs werden einfacher und flexibler dank IKEv2. 3. Januar 2008, abgerufen am 26. März 2009 (deutsch). 
2. ↑ Daniel Bachfeld: Artikel bei Heise zur angeblichen OpenBSD Backdoor. 15. Dezember 2010, abgerufen am 4. Januar 2011. 
3. ↑ Daniel Bachfeld: Artikel bei Heise zur angeblichen OpenBSD Backdoor. 23. Dezember 2010, abgerufen am 4. Januar 2011.