IPsec

Internet Protocol Security (IPsec) ist eine Protokoll-Suite, die eine gesicherte Kommunikation über potentiell unsichere IP-Netze wie das Internet ermöglichen soll.

IPsec arbeitet direkt auf der Vermittlungsschicht (Internet Layer, entspricht OSI Layer 3) des DoD Models und ist eine Weiterentwicklung der IP-Protokolle. Das Ziel ist es, eine verschlüsselungsbasierte Sicherheit auf Netzwerkebene bereitzustellen. IPsec bietet durch die verbindungslose Integrität sowie die Zugangskontrolle und Authentifikation der Daten diese Möglichkeit an. Zudem wird durch IPsec die Vertraulichkeit sowie Authentizität der Paketreihenfolge durch Verschlüsselung gewährleistet.

Da im Internet die Datenpakete von einem Rechner zum nächsten weitergeleitet werden, kann jeder Rechner auf dem Weg eines Datenpakets dessen Inhalt lesen und sogar verändern. Ein Rechner kann auch Datenpakete im Namen eines anderen Rechners versenden, indem er dessen Adresse als „Absender“ einträgt (IP-Spoofing). IPsec soll es ermöglichen, in einem solchen IP-Netz die Schutzziele Vertraulichkeit, Authentizität und Integrität zu erfüllen. Dazu werden verschiedene Mechanismen eingesetzt, etwa Verschlüsselung einzelner IP-Pakete und Einfügen eines zusätzlichen Paket-Headers mit einem Message Authentication Code. IPsec kann zum Aufbau virtueller privater Netzwerke (VPN) verwendet werden oder zum Schutz vor Replay-Angriffen eingesetzt werden.

Die Internet Engineering Task Force schlägt in RFC 2401^[1] bzw. im neueren RFC 4301^[2] die Architektur von IPsec als Standard vor. Von diesen RFCs 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.

IPsec verwaltet Verbindungen und kann auf Anforderung hin sowohl Verschlüsselung als auch Datenintegrität garantieren. Dazu verwendet es einen von zwei Modi: Der Transportmodus stellt Punkt-zu-Punkt-Kommunikation zwischen zwei Endpunkten her, während der Tunnelmodus zwei Netze über zwei Router verbindet. Beide Modi sind in Bezug auf die zu erstellenden Security Associations recht ähnlich. Die folgende Darstellung betrachtet nur den Transportmodus.

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, die durch ihre IP-Adressen identifiziert sind, gesichert werden soll. Als Sicherungsverfahren werden dann Authentication Header (AH), Encapsulating Security Payload (ESP) oder beide eingesetzt. Zum Erstellen der Schlüssel wird meist der Internet Key Exchange (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)

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 Verfahren zum Austausch der Schlüssel benötigt. Der Austausch kann manuell oder automatisch erfolgen.

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 Zertifikate 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.

Die Schlüssel, die für IPsec verwendet werden, werden beim „Manual Keying“ vorab ausgetauscht und auf beiden Endpunkten fest konfiguriert.

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. IKEv1 wurde im RFC 2409^[3] spezifiziert und basierte auf dem Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408^[4]), der IPsec Domain of Interpretation (RFC 2407^[5]), OAKLEY (RFC 2412^[6]) und SKEME. IKEv1 wurde im Jahr 2005 obsolet, als der Nachfolger IKEv2 veröffentlicht wurde. Die RFCs 2407, 2408 und 2409 wurden bei IKEv2 durch ein zusammengefasstes Spezifikationsdokument RFC 4306^[7] ersetzt. Im Jahr 2023 erklärte die IETF IKEv1 als historisch.^[8]

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

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 IKEv1 gedacht. Zur Authentisierung werden die Verfahren Pre Shared Keying (PSK) und Certificate eingesetzt. IPsec arbeitet mit verschiedenen symmetrischen wie asymmetrischen Schlüsseln.

IKEv1 basiert auf UDP und nutzt standardmäßig den Port 500 als Quell- und Ziel-Port. Wird IKEv1 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 Demilitarisierten Zone (DMZ). In der DMZ steht dann der Endpunkt der IPsec-Verbindung.

IKEv1 arbeitet in zwei Phasen:

1. Aushandlung einer SA (Security Association) für ISAKMP entweder über den Main Mode (Hauptmodus, bevorzugt) oder den Aggressive Mode (Aggressiver Modus)
2. Erzeugung einer SA für IPsec im 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

Der Main Mode wird in der ersten Phase der Verschlüsselungsvereinbarung und Authentisierung (Internet Key Exchange) genutzt. Er sollte dem Aggressive Mode vorgezogen werden.

Im Main Mode 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 oder mehrere Vorschläge (englisch Proposal) 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.

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 Pre-shared keys im Klartext übertragen. Die Sicherheit des Verfahrens ist eng an die Stärke des Pre-shared Keys und des verwendeten Hashverfahrens gekoppelt. Da in der Praxis starke Schlüssel oft aus Bequemlichkeit nicht verwendet 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 nicht von vornherein bekannt ist, und beide Seiten Pre-shared Keys zur Authentifizierung einsetzen wollen.

Weitere Anwendungsszenarien sind gegeben, wenn ein schnellerer Verbindungsaufbau gewünscht ist und die Richtlinien (Policies) des Responders hinlänglich bekannt sind.

Beispiel: Ein Mitarbeiter will aus der Ferne auf das Firmennetz zugreifen. Die Richtlinien (z. B. Verschlüsselung mit AES, Hashing mit SHA und Authentisierung mit RSA Signaturen, die durch die Zertifizierungsstelle der Firma signiert wurden) sind bekannt.

In der zweiten Phase von IKEv1 wird der Quick Mode 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.

Wie auch bei IKEv1 läuft der Schlüsselaustausch bei IKEv2 in zwei Phasen ab:

Die IKE_SA_INIT-Phase bereitet die verschlüsselte, authentifizierte Verbindung durch Diffie-Hellman-Schlüsselaustausch und Austausch von Sicherheitsparametern vor. Die Parteien (Initiator und Responder) handeln die verwendeten Verschlüsselungs- und Authentifizierungsalgorithmen aus. Typischerweise werden Algorithmen für Verschlüsselung (z. B. AES), Integrität (z. B. HMAC-SHA2) und Diffie-Hellman-Gruppen (z. B. Gruppe 14 für 2048-Bit) verhandelt. Die erste Nachricht enthält die vorgeschlagenen Cipher-Suiten, aus denen der Responder die unterstützten auswählt. Initiator und Responder generieren jeweils ein Diffie-Hellman-Schlüsselmaterial (einen öffentlichen und einen privaten Schlüssel), das ausgetauscht wird. Durch das Diffie-Hellman-Verfahren wird ein gemeinsames Geheimnis (shared secret) errechnet, ohne dass dieses über das Netzwerk übertragen wird. Die Schlüsselerzeugung basiert auf einer sicheren modularen Exponentiation. Beide Parteien erzeugen zufällige, nur einmalig verwendete Zahlen (Nonces), die sie miteinander austauschen. Diese Nonces verhindern Replay-Angriffe und gewährleisten, dass das erzeugte Geheimnis für jede Session einzigartig ist. Mit dem gemeinsamen Geheimnis, den Nonces und den gewählten Algorithmen wird der sogenannte Session Key erzeugt. Dieser Schlüssel, auch als SK_d bekannt, bildet die Grundlage für die Sicherheit des weiteren Austauschs und schützt ab diesem Punkt alle nachfolgenden Nachrichten.

Insgesamt werden in der Phase 1 zwei Nachrichten zwischen Initiator und Responder ausgetauscht:

1. Der Initiator sendet folgende Informationen an den Responder:
   • Eine Liste der unterstützten Kryptografie-Algorithmen (z. B. für Verschlüsselung und Integritätsschutz).
   • Eine zufällig generierte Nonce (Ni), die dem Responder zur Berechnung des gemeinsamen Sitzungsschlüssels hilft.
   • Den Diffie-Hellman-Wert des Initiators (g^i mod p), der für die Berechnung des gemeinsamen Geheimnisses genutzt wird.
2. Der Responder antwortet mit:
   • Seiner Auswahl an Kryptografie-Algorithmen aus der Vorschlagsliste des Initiators.
   • Seiner eigenen zufällig generierten Nonce (Nr), die zusammen mit der Nonce des Initiators die Zufälligkeit des Schlüssels weiter erhöht.
   • Seinem Diffie-Hellman-Wert (g^r mod p), welcher zur Berechnung des gemeinsamen Geheimnisses beiträgt.

Am Ende dieser Phase steht eine Security Association, die die Kommunikationsparameter enthält. Der Sitzungsschlüssel sorgt für Verschlüsselung und Integritätsschutz aller zukünftigen Nachrichten.

Die IKE_AUTH-Phase dient der Authentifizierung der beiden Kommunikationsparteien und dem Aufbau der eigentlichen Security Association für die spätere Datenübertragung. Beide Parteien authentifizieren sich gegenseitig, beispielsweise durch digitale Zertifikate, Pre-Shared Keys (PSKs) oder eine Kombination aus Authentifizierungsmechanismen. Während der IKE_AUTH-Phase wird eine Security Association eingerichtet, die speziell für den Schutz des Datenverkehrs auf Anwendungsebene verwendet wird. Diese IPsec SA definiert Parameter wie die Lebensdauer der Verbindung, Verschlüsselungs- und Integritätsalgorithmen für die eigentliche Datenübertragung. Neben der Authentifizierung werden auch zusätzliche Informationen übermittelt, die sicherstellen, dass nur autorisierte Benutzer auf die VPN-Verbindung zugreifen können. Alle Nachrichten in dieser Phase sind durch die IKE SA gesichert. Das bedeutet, dass alle Authentifizierungsdaten verschlüsselt und in ihrer Integrität geschützt sind.

In der Phase 2 werden ebenfalls zwei Nachrichten zwischen den Parteien ausgetauscht:

1. Der Initiator sendet eine authentifizierte Nachricht an den Responder, die folgende Informationen enthält:
   • Eine Identifikationsnachricht (IDi), die den Initiator identifiziert. Das kann beispielsweise seine IP-Adresse oder ein Name sein.
   • Ein Authentifizierungsnachweis (z. B. eine Signatur, die mit dem zuvor abgeleiteten Schlüssel generiert wurde) zur Bestätigung der Identität.
   • Die erste IPsec-Security Association (IPsec SA), einschließlich der Parameter für den IPsec-Datenkanal (Verschlüsselungs- und Integritätsalgorithmen, Traffic-Selektoren usw.).
   • Optional können in dieser Nachricht auch EAP-Authentifizierungsnachrichten enthalten sein, falls eine zusätzliche Benutzerauthentifizierung erforderlich ist.
2. Der Responder authentifiziert sich beim Initiator und bestätigt den Aufbau der IPsec-SA:
   • Eine Identifikationsnachricht (IDr), die den Responder identifiziert.
   • Ein Authentifizierungsnachweis (z. B. eine Signatur oder ein MAC, der mit dem gemeinsamen Schlüssel erzeugt wurde), um die Identität des Responders zu bestätigen.
   • Bestätigung und Details zur IPsec-SA, einschließlich etwaiger Traffic-Selektoren und anderer ausgehandelter Parameter für den Datenkanal.

Nach Abschluss der IKE_SA_INIT- und IKE_AUTH-Phasen steht eine verschlüsselte, integritätsgeprüfte und authentifizierte Verbindung zur Verfügung, die für den sicheren Datentransfer verwendet werden kann.

Nachdem die sichere Verbindung über IKE_SA_INIT und IKE_AUTH eingerichtet wurde, können weitere Nachrichten zur Verwaltung der Sitzung ausgetauscht werden.

CREATE_CHILD_SA:

Für das Erneuern oder Erstellen zusätzlicher IPsec-Security Associations (Child SAs) können CREATE_CHILD_SA Nachrichten ausgetauscht werden. Typischerweise wird CREATE_CHILD_SA verwendet, um den Session Key zu erneuern, wenn die Lebensdauer der aktuellen IPsec-SA abgelaufen ist. Der Ablauf ist ähnlich wie der IKE_SA_INIT, wobei jedoch bereits bestehende Sicherheitsparameter genutzt werden und ein neuer Diffie-Hellman-Schlüsselaustausch stattfindet.

INFORMATIONAL:

INFORMATIONAL-Nachrichten ermöglichen die Verwaltung und Aufrechterhaltung der Sitzung, z. B. das Senden von Fehlermeldungen, das Löschen einer SA oder das Erkennen eines Verbindungsabbruchs. Diese Nachrichten enthalten keine neuen Sicherheitsparameter, sondern dienen rein der Kommunikation über den Status oder die Aufrechterhaltung oder Beendigung einer Verbindung.

Da IKEv1 recht komplex ist, wurden viele Implementationen von IPsec inkompatibel zueinander. Während IKEv1 noch in mehreren RFCs spezifiziert ist, wird IKEv2 komplett in RFC 7296^[9] beschrieben. Dieses bietet weniger Möglichkeiten für Missverständnisse und ist somit weniger fehleranfällig als die erste Version.

IKEv1 ist bei Verwendung von dynamischen IP-Adressen, wie sie bei DSL-Anschlüssen im Privatbereich üblich sind, wenig geeignet. IKEv2 behebt diese Probleme.^[10]

Bei IKEv2 wurden die von IKEv1 bekannten Phasen grundlegend verändert. Um einen Security Association (SA) zu erstellen, benötigt man statt neun nun nur noch vier UDP-Nachrichten. Dies ermöglicht einen schnelleren Verbindungsaufbau, was sich besonders bei Störungen positiv auswirken kann. Zusätzlich wird die Anzahl an möglichen Kombinationen für die Authentifizierung in Phase 1 von IKEv1 verringert. Statt acht Möglichkeiten wird nur noch eine Authentifizierung mittels Signaturen oder MACs erlaubt. Für effizientere Durchläufe wird ebenso bei IKEv2 bereits während Phase 1 ein Paar an SAs während des initialen IKE Austausches erstellt. Insbesondere wenn nur ein Paar benötigt wird, wird der Austausch beschleunigt.

Außerdem wird bei IKEv2 auf einen präventiven Cookie-Austausch verzichtet, da in den letzten Jahren nur vereinzelt Probleme mit Denial-of-Service-Attacken gegen VPN-Gateways auftraten.

Während bei IKEv1 die Verantwortlichkeiten bei Paketverlusten nicht geregelt waren, wurden unter IKEv2 die Zuständigkeiten der Peers klarer definiert. Dadurch konnte die Verbindungsstabilität verbessert werden. Zudem ist NAT-Traversal fester Bestandteil von IKEv2, wodurch auch Verbindungen über NAT-Router hinweg aufgebaut werden können.

Der Authentication Header (AH) soll die Authentizität und Integrität der übertragenen Pakete sicherstellen und den Sender authentifizieren. 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^[11]) 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:

Bedeutung der Felder:

Nächster Header (next header)

identifiziert das Protokoll der im Paket übertragenen Daten. Enthält den Wert, der bei ungeschützten 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-Headers

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 Sequenznummer (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

Zum Schutz vor Replay-Angriffen kann der Empfänger eines AH-Pakets sich nicht darauf verlassen, dass die Sequenznummer immer höher ist als beim vorangegangenen Paket. IP-Pakete können unterwegs auch vertauscht worden sein. Deshalb wird – ausgehend von der bisher höchsten empfangenen Sequenznummer – auch eine festgelegte Menge kleinerer Sequenznummern akzeptiert. Wird eine Sequenznummer innerhalb dieser Menge zum zweiten Mal empfangen, wird das entsprechende Paket verworfen. Das gilt ebenfalls für Pakete mit zu kleiner Sequenznummer (also unterhalb der festgelegten Menge kleinerer Sequenznummern).^[12]

Encapsulating Security Payload (ESP) stellt Mechanismen zur Sicherstellung der Authentizität, Integrität und Vertraulichkeit der übertragenen IP-Pakete bereit. Im Unterschied zum AH wird der Kopf des IP-Paketes vom Integrity check value (ICV) nicht berücksichtigt, jedoch werden die Nutzdaten verschlüsselt übertragen. ESP basiert direkt auf IP und verwendet die Internet-Protokoll Nummer 50.

Ein ESP-Paket sieht folgendermaßen aus:

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 Bytes für Padding

Nächster Header (next header)

identifiziert das Protokoll der im Paket übertragenen Daten. Enthält den Wert, der bei ungeschützten 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).

Der Schutz vor Replay-Angriffen entspricht dem Mechanismus von AH.

Im Transportmodus verbindet IPsec zwei Endpunkte direkt miteinander (Punkt-zu-Punkt), zum Beispiel über eine auf den Endpunkten installierte Software.

Im Tunnelmodus hingegen werden zwei IP-Netze miteinander verbunden. Die Endpunkte werden hier von zwei Routern bzw. VPN-Gateways gebildet, zwischen denen der Tunnel aufgebaut wird.

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öher liegende Schicht weitergegeben. Der Transportmodus wird vor allem für Host-zu-Host- oder Host-zu-Router-Verbindungen verwendet, z. B. für die Netzwerkverwaltung.

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.

Um sicherzustellen, dass die Verbindung zwischen den Endpunkten nicht zwischenzeitlich unterbrochen wurde, tauschen diese in regelmäßigen Abständen Keepalive-Nachrichten aus, die auch dazu dienen können, einen durch Verbindungsunterbrechung verlorenen Tunnel automatisch wieder aufzubauen.

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 ein Endpunkt mit einem noch bestehenden 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^[13] und wird auch ISAKMP-Keepalive genannt.

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

Die Kryptographen Niels Ferguson und Bruce Schneier 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 zum Zeitpunkt ihrer Untersuchungen am besten absicherte.

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

Als Einstieg dienen nach RFC 5406 (Guidelines for Specifying the Use of IPsec):^[16]

• IPsec Version 1: RFC 1825^[17]
• IPsec Version 2: RFC 2401^[1]
• IPsec Version 3: RFC 4301^[18]

Weitere relevante RFC’s:

• RFC2367 – PF_KEY Interface. (englisch).
• RFC2403 – The Use of HMAC-MD5-96 within ESP and AH. (englisch).
• RFC2405 – The ESP DES-CBC Cipher Algorithm With Explicit IV. (englisch).
• RFC2410 – The NULL Encryption Algorithm and Its Use With IPsec. (englisch).
• RFC2411 – IP Security Document Roadmap. (englisch).
• RFC2412 – The OAKLEY Key Determination Protocol. (englisch).
• RFC2451 – The ESP CBC-Mode Cipher Algorithms. (englisch).
• RFC2857 – The Use of HMAC-RIPEMD-160-96 within ESP and AH. (englisch).
• RFC3526 – More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE). (englisch).
• RFC3602 – The AES-CBC Cipher Algorithm and Its Use with IPsec. (englisch).
• RFC3686 – Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP). (englisch).
• RFC3706 – A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers. (englisch).
• RFC3715 – IPsec-Network Address Translation (NAT) Compatibility Requirements. (englisch).
• RFC3947 – Negotiation of NAT-Traversal in the IKE. (englisch).
• RFC3948 – UDP Encapsulation of IPsec ESP Packets. (englisch).
• RFC4106 – The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP). (englisch).
• RFC4301 – Security Architecture for the Internet Protocol. (englisch).
• RFC4302 – IP Authentication Header. (englisch).
• RFC4303 – IP Encapsulating Security Payload (ESP). (englisch).
• RFC4304 – Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP). (englisch).
• RFC4306 – Internet Key Exchange (IKEv2) Protocol. (englisch).
• RFC4307 – Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2). (englisch).
• RFC4308 – Cryptographic Suites for IPsec. (englisch).
• RFC4309 – Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP). (englisch).
• RFC4478 – Repeated Authentication in Internet Key Exchange (IKEv2) Protocol. (englisch).
• RFC4543 – The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH. (englisch).
• RFC4555 – IKEv2 Mobility and Multihoming Protocol (MOBIKE). (englisch).
• RFC4621 – Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol. (englisch).
• RFC4718 – IKEv2 Clarifications and Implementation Guidelines. (englisch).
• RFC4806 – Online Certificate Status Protocol (OCSP) Extensions to IKEv2. (englisch).
• RFC4809 – Requirements for an IPsec Certificate Management Profile. (englisch).
• RFC4835 – Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH). (englisch).
• RFC4945 – The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX. (englisch).
• RFC7296 – Internet Key Exchange Protocol Version 2 (IKEv2). (englisch).

• Daniel Bachfeld, Andreas Steffen: VPN-Knigge. VPN-Protokolle und Standards. In: c’t. Nr. 7, 2006, S. 114–121 (heise.de [abgerufen am 20. Juli 2019] IPSec Version 2, auch leicht gekürzt kostenlos). 
• 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.
• Christoph Sorge, Nils Gruschka, Luigi Lo Iacono: Sicherheit in Kommunikationsnetzen. Oldenbourg Wissenschaftsverlag, München 2013, ISBN 978-3-486-72016-7.

• Schneier: IPsec-Evaluation. schneier.com (englisch)
• An illustrated guide to IPsec. unixwiz.net (englisch)

1. ↑ ^{a b} RFC2401 – Security Architecture for the Internet Protocol. November 1998 (veraltet, englisch).
2. ↑ RFC4301 – Security Architecture for the Internet Protocol. (englisch).
3. ↑ RFC2409 – The Internet Key Exchange (IKE). November 1998 (englisch).
4. ↑ RFC2408 – Internet Security Association and Key Management Protocol (ISAKMP). November 1998 (englisch).
5. ↑ RFC2407 – The Internet IP Security Domain of Interpretation for ISAKMP. November 1998 (englisch).
6. ↑ RFC2412 – The OAKLEY Key Determination Protocol. (englisch).
7. ↑ RFC4306 – Internet Key Exchange (IKEv2) Protocol. (englisch).
8. ↑ RFC9395 – Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms. April 2023 (englisch).
9. ↑ ^{a b} RFC7296 – Internet Key Exchange Protocol Version 2 (IKEv2). (englisch).
10. ↑ IPSec-VPNs werden einfacher und flexibler dank IKEv2. heise, 3. Januar 2008, abgerufen am 26. März 2009. 
11. ↑ RFC3948 – UDP Encapsulation of IPsec ESP Packets. (englisch).
12. ↑ Sorge, Gruschka, Lo Iacono: Sicherheit in Kommunikationsnetzen 2013, S. 153 f.
13. ↑ RFC3706 – A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers. April 2003 (englisch).
14. ↑ RFC3519 – Mobile IP Traversal of Network Address Translation (NAT) Devices. (englisch).
15. ↑ A Cryptographic Evaluation of IPsec. (PDF; 222 kB) S. 1, Abs. 2
16. ↑ RFC5406 – Guidelines for Specifying the Use of IPsec. (englisch).
17. ↑ RFC1825 – Security Architecture for the Internet Protocol. August 1995 (veraltet, englisch).
18. ↑ RFC4301 – Security Architecture for the Internet Protocol. 2005 (englisch).