IPsec

IPsec im TCP/IP-Protokollstapel: Anwendung HTTP IMAP SMTP … Transport TCP UDP Internet IPsec Internet IPv4 IPv6 Netzzugang Ethernet …

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 bzw. im neueren RFC 4301 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.

Verbindungsaufbau mini|SPD und SAD

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

Authentisierung 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 ungültig geworden sind, gesperrt. Bei einer PSK-Authentisierung ist dagegen der Austausch aller Schlüssel erforderlich.

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

Automatische Schlüsselverwaltung 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 spezifiziert und basierte auf dem Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408), der IPsec Domain of Interpretation (RFC 2407), OAKLEY (RFC 2412) 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 ersetzt. Im Jahr 2023 erklärte die IETF IKEv1 als historisch.

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 IKEv1 arbeitet in zwei Phasen:

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

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

Phase 1 (Main Mode-Variante) 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:

Der Initiator sendet einen oder mehrere Vorschläge () mit Authentisierungs- und Verschlüsselungsalgorithmen. 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. Der Initiator sendet seinen öffentlichen Teil vom Diffie-Hellman-Schlüsselaustausch und einen zufälligen Wert (die Nonce). 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:

die Authentisierung mittels vereinbartem Geheimnis (im englischen Pre-Shared-Keys, PSK) oder 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.