IPsec
aus Wikipedia, der freien Enzyklopädie
IPsec (Kurzform für IP Security) 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. IPsec soll die Schutzziele Vertraulichkeit, Authentizität und Integrität gewährleisten. Daneben soll es vor so genannten Replay-Angriffen bzw. einer Replay-Attacke schützen – das heißt, ein Angreifer kann nicht durch Abspielen eines vorher mitgeschnittenen Dialogs die Gegenstelle zu einer wiederholten Aktion verleiten.
Der RFC 2401 bildet das Hauptdokument zu IPsec, er beschreibt die Architektur von IPsec. Von dort aus werden die unten genannten RFCs referenziert. Wesentliche Inhalte von IPsec sind die Protokolle Authentication Header (AH) und Encapsulated Security Payload (ESP) sowie Internet Key Exchange (IKE) zum Austausch der Schlüssel.
Im Gegensatz zu anderen Verschlüsselungsprotokollen wie etwa SSH arbeitet IPsec auf der Vermittlungsschicht (Schicht 3) des OSI-Referenzmodells.
Inhaltsverzeichnis |
[Bearbeiten] Standards
IPsec entstand im Zuge der Entwicklung von IPv6 und ist in verschiedenen RFCs spezifiziert:
- RFC 2401
- Sicherheitsarchitektur für das Internetprotokoll
- RFC 2402
- Authentication Header
- RFC 2407
- IPsec Domain of Interpretation (IPsec DoI)
- RFC 2408
- Internet Security Association and Key Management Protocol (ISAKMP)
- RFC 2409
- Internet Key Exchange (IKE)
- RFC 3830
- Multimedia Internet Keying (MIKEY)
- RFC 4301 (löst RFC 2401 ab)
- Security Architecture for the Internet Protocol
- RFC 4302 (löst RFC 2402 ab)
- Authentication Header
- RFC 4303 (löst RFC 2406 ab)
- Encapsulating Security Payload
- RFC 4306 (löst RFC 2407, RFC 2408 und RFC 2409 ab)
- Internet Key Exchange (IKEv2) Protocol
[Bearbeiten] Abkürzungen
[Bearbeiten] IPSec-Protokolle
Abk. | Bedeutung | RFC -------+------------------------------------------------------------+----- IPSec | IP Security Protocol Suite | AH | Authentication Header (Prot-ID: 51) | 2402 ISAKMP | Internet Security Association and Key Management Protocol | 2408 Oakley | | 2412 IKE | Internet Key Exchange (=ISAKMP) | 2409 DES | Data Encryption Standard (ECB oder CBC Mode) | 3DES | 3-fach Data Encryption Standard (ECB oder CBC Mode) | ECB | Electronic Code Book (DES / 3DES) | CBC | Cipher Block Chaining (DES / 3DES) | CFB | Cipher Feedback Mode (DES / 3DES) for streaming Data | OFB | Output-Feedback Mode (DES / 3DES) for streaming Data | MD5 | Message-Digest Algorithm April 1992 | 2403 SHA | Advanced Encryption Standard (128,192,256 bit) | 2404 HMAC | Hashing Message AuthentiCation Mode Algorithm | DH | Diffie Hellman Group (1: 768 bit, 2: 1024 bit, 5: 1536 bit)| ESP | Encapsulating Security Payload (Prot-ID: 50) | 2406 PCP | Payload Compression Protocol | RSA | Rivest, Shamir, Adelman Algorithm | PKI | Public Key Infrastructure | PFS | Perfect Forwarding Secrecy |
[Bearbeiten] Log-/Debug-Auswertung
Abk. | Bedeutung | Phase -------+------------------------------------------------------------+----- AM | Aggressive Mode | 1 MM | Main Mode | 1 OAK | Oakley | 1 VID | Vendor ID | 1 NON | 'Nonce', 'nonsense' random value used in Diffie Hellman | 1 KE | Diffie Hellman Key Exchange | 1 -------+------------------------------------------------------------+----- QM | Qick Mode | 2 FSM | Finit State Machine | 2 SPI | Secure Policy (Parameter) Index | 2 SA | Security Association | 2 SADB | Security Association DataBase | 2
[Bearbeiten] IPSec-Ports und Protokolle
Service Protocol Number Source Port Destination Port ---------------------------------------------------------------------------- ISAKMP/IPSec Key Management 17 (UDP) 500 500 IPSec Tunnel Encapsulation 50 (ESP) N/A N/A Authentication Header 51 (AH) N/A N/A IPSec NAT Transparency 17 (UDP) 10000 (default) 10000 (default)
[Bearbeiten] Verbindungsaufbau
[Bearbeiten] Schlüsselaustausch
[Bearbeiten] Manual Keying
Die Schlüssel, die für IPsec verwendet werden, werden beim "Manual Keying" vorab ausgetauscht und auf beiden Tunnelendpunkten fest konfiguriert. Von dieser Methode ist jedoch abzuraten, da manuell erzeugte Schlüssel in der Regel einfach zu erraten sind. Besser ist die Verwendung von ISAKMP, auch als IKE bezeichnet. Bei diesem Protokoll wird der Schlüssel für IPsec automatisch erzeugt (und in regelmäßigen Abständen geändert).
[Bearbeiten] IKEs
Das Internet Key Exchange (IKE) 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 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 Protocol (ISAKMP, RFC 2408), der IPsec Domain of Interpretation (DOI, RFC 2407), OAKLEY (RFC 2412) und SKEME.
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 authentifizieren und sich auf die zu verwendenden Schlüssel Algorithmen einigen. Hierfür ist IKE gedacht. Zur Authentifizierung 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, stimmt dies nicht mehr! Bei den meisten IPSec Implementierungen wird in diesem Fall Port 4500/UDP verwendet (NAT-Traversal).Um das Problem mit IPsec-Verbindungen hinter Masquerading-Firewalls zu lösen, wurden mehrere Vorschläge eingereicht. Keiner der Vorschläge schaffte jedoch die Standardisierung, weshalb der Betrieb einer IPsec-Verbindung von einem Host hinter einer Firewall 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:
- Aushandlung einer SA (Security Association) für ISAKMP entweder über den Aggressive Mode (Aggressiver Modus) oder Main Mode (Hauptmodus)
- 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:
- Identifikation (entweder per PSK oder Zertifikate)
- 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 Authentifizierung erforderlich ist
- Zeitraum, nachdem der IPsec Schlüssel erneuert werden muss
[Bearbeiten] Phase 1
[Bearbeiten] Main Mode
Der Main Mode (dem Aggressive Mode vorzuziehen) wird in der ersten Phase der Verschlüsselungsvereinbarung und Authentifizierung (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:
- der Initiator sendet mehrere (zur Not auch einen) Vorschläge mit Authentifizierungs- und Verschlüsselungsalgorithmen
- der Responder wählt aus den angebotenen und den von ihm unterstützten den sichersten Algorithmus aus
- 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 im Schritt 5 der Authentifizierung.
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. Dieser wird auch für die Erzeugung eines weiteren Schlüssels genutzt, der für die Authentifikation verwendet wird.
Schritt 5 ist die Authentifizierung. Dabei müssen sich beide Beteiligten als zugriffsberechtigt ausweisen. Hierbei kommen zwei unterschiedliche Verfahren zum Einsatz:
- die Authentifizierung mittels vereinbarter Geheimnisse (im englischen Pre-Shared-Keys, PSK) und
- zertifikatsbasiert.
Die zertifikatsbasierte Authentifizierung verwendet X.509 Zertifikate und ist im wesentlichen eine Public-Key Infrastructure 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 Authentifikationsmethoden 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, den ausgehandelten Kryptoverfahren sowie den bisher versandten Nachrichten (genauer gesagt, werden in der Literatur manchmal Cookies erwähnt: ein Hashwert über ein erzeugtes Geheimnis, IP-Adresse und Zeitmarke) gebildet, verschlüsselt und versendet. 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 ihn sowie die versandten Nachrichten (genauer gesagt auch hier wieder die Cookies).
[Bearbeiten] PSK-Authentifizierung
Bei diesem Verfahren erfolgt die Authentifizierung aufgrund eines einzigen gemeinsamen Geheimnisses. Es kann angewendet werden, wenn eine überschaubare Menge von Teilnehmern an das IPsec-VPN angeschlossen ist. Der wesentliche Nachteil ist: erhält jemand unberechtigtes Zugriff auf diesen Schlüssel, müssen auf allen beteiligten Hosts die Schlüssel ausgetauscht werden, um die Sicherheit wieder herzustellen. Soll ein Netzwerk wachsen, ist dieses Verfahren auch dann abzulehnen, wenn zuerst nur wenige Knoten beteiligt sind. Der Mehraufwand für die zertifikatsbasierte Authentifizierung amortisiert sich in der Regel bereits nach kurzer Zeit.
[Bearbeiten] Zertifikatsbasierte Authentifizierung
Diese Authentifizierung 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 von diesen 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 authentifiziert werden können. Leider ist dies in der Praxis nicht so leicht, weil weitere Parameter (z. B. Netzwerkadressen) eine Rolle spielen und diese mit bereits bestehenden VPN-Verbindungen kollidieren können. Es hat sich daher durchgesetzt, eine private PKI einzusetzen. Mit einer eigenen PKI sollen aber nur bekannte und vertrauenswürdige Hosts Zugriff auf das VPN haben.
Die zertifikatsbasierte Authentifizierung erfolgt wie die PSK-Authentifizierung. Der Unterschied ist: 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 Authentifizierung: 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-Authentifizierung ist dagegen der Austausch aller Schlüssel erforderlich.
[Bearbeiten] 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 vom Responder a priori nicht 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 Policies des Responders hinlänglich bekannt sind (z. B. Angestellter will über die Ferne auf das Firmennetzwerk zugreifen - Richtlinien (z. B. Verschlüsselung mit AES, Hashing mit SHA und Authentifizierung mit RSA Signaturen, die durch die Zertifizierungsstelle der Firma signiert wurden) sind soweit bekannt).
[Bearbeiten] Phase 2
[Bearbeiten] Quick Mode
Der Quick Mode wird in der zweiten Phase von IKE zur Anwendung gebracht (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. Dieser wird 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 (PFS). Dies wird erreicht, indem ein zusätzlicher Diffie-Hellman Austausch stattfindet. Die Geheimnisse zur Schlüsselbildung werden nicht beibehalten, 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.
[Bearbeiten] Authentication Header (AH)
Der Authentication Header (AH) soll die Authentizität der übertragenen Pakete sicherstellen und den Sender authentifizieren. Weiterhin existiert hier ein Schutz gegen Replay-Angriffe. AH versucht alle möglichen, invarianten Felder eines IP-Datagramms zu schützen. Es werden lediglich Felder ausgeschlossen, die sich auf dem Weg eines IP-Pakets durch ein IP-Netz durch die Router verändern können.
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
- 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) welcher sich aus einem Hash des übrigen Paketes ergibt
[Bearbeiten] Encapsulating Security Payload (ESP)
Encapsulating Security Payload (ESP) soll die Authentifizierung, Integrität und Vertraulichkeit von IP-Paketen sicherstellen. Im Unterschied zum AH wird der Kopf des IP-Paketes vom ICV nicht berücksichtigt. Jedoch werden die Nutzdaten verschlüsselt übertragen.
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 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)
[Bearbeiten] IPsec im Transportmodus
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 v. A. für Host-zu-Host oder Host-zu-Router Verbindungen verwendet z. B. zu Netzwerk-Management-Zwecken.
[Bearbeiten] IPsec im Tunnelmodus
Im Tunnelmodus wird das ursprüngliche Paket gekapselt und die Sicherheitsdienste von IPsec auf das komplette 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 in einem 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.
[Bearbeiten] 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)
- (Deutsch: 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))
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 IPsec das ursprüngliche IP zur Zeit am besten absichert.
Wenn man 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.
[Bearbeiten] Literatur
- Naganand Doraswamy / Dan Harkins: IPSec, The New Security Standard for the Internet, Intranets, and Virtual Private Networks. Second Edition, Prentice Hall, 2003, ISBN 013046189X
[Bearbeiten] Weblinks
- IPsec-Evaluation von Schneier
- Übersicht über IPSec mit Linux
- Kostenloser IPSec VPN Client für Windows 2000 und XP
- Schritt für Schritt Anleitung IPsec unter Windows 2000
- Portbeschränkung unter Windows 2000 Server via IPSec (Vor- & Nachteile + HowTo)
- An illustrated guide to IPSec (englisch)
- A minimal IPsec implementation for embedded systems (english)
