|
|
| Zeile 1: |
Zeile 1: |
| '''Internet Protocol Security''' ('''IPsec''') - Ermöglicht gesicherte Kommunikation über unsichere Netze | | '''Internet Protocol Security''' ('''IPsec''') - Ermöglicht gesicherte Kommunikation über unsichere Netze |
|
| |
|
| = TMP = | | == Beschreibung == |
| ; IPsec arbeitet direkt auf der Vermittlungsschicht ("''Internet Layer"'', entspricht OSI Layer 3) des [[DoD-Schichtenmodell|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 [[Informationssicherheit#Motivation und Ziele der Informationssicherheit|Schutzziele]] [[Vertraulichkeit]], [[Authentizität]] und [[Integrität (Informationssicherheit)|Integrität]] zu erfüllen.
| |
| * Dazu werden verschiedene Mechanismen eingesetzt, etwa [[Verschlüsselung]] einzelner [[IP-Paket]]e und Einfügen eines zusätzlichen Paket-[[Header]]s mit einem [[Message Authentication Code]].
| |
| * IPsec kann zum Aufbau [[Virtual Private Network|virtueller privater Netzwerke]] (VPN) verwendet werden oder zum Schutz vor [[Replay-Angriff]]en 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 [[Request for Comments|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 == | |
| [[Datei:Ipsec nachricht versenden SAD SPD.png|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
| |
| * ''[[Tunnel (Rechnernetz)|Tunnelmodus]]'' zwei Netze über zwei Router verbindet.
| |
| | |
| ; Beide Modi sind in Bezug auf die zu erstellenden ''[[Security Association]]s'' 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)|AH]], [[#Encapsulating Security Payload (ESP)|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)''
| |
| : [[Datei:Ipsec SAs.svg|mini|SAs zwischen zwei Hosts]] In der SAD werden [[Security Association]]s (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.
| |
| | |
| === 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 über IKEv1 ===
| |
| ; Das ''Internet-Key-Exchange''-Protokoll dient der automatischen Schlüsselverwaltung für IPsec.
| |
| * Es verwendet den [[Diffie-Hellman-Schlüsselaustausch]] für einen [[Schlüsselaustausch|sicheren Austausch]] von [[Schlüssel (Kryptologie)|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'' ([[Internet Security Association and Key Management Protocol|ISAKMP]], RFC 2408), der IPsec ''Domain of Interpretation'' ([[Domain of Interpretation|DOI]], RFC 2407), [[OAKLEY]] (RFC 2412) und [[Internet Security Association and Key Management Protocol|SKEME]].
| |
| * Die RFCs 2407, 2408 und 2409 sind in der aktuellen Version IKEv2 im RFC 4306 und im aktuellen RFC 5996 zusammengefasst und damit obsolet.
| |
| | |
| ; IKE definiert, ''wie'' Sicherheitsparameter vereinbart und gemeinsame Schlüssel (shared keys) ausgetauscht werden. ''Was'' ausgetauscht wird, ist Aufgabe eines [[Domain of Interpretation|DOI]]-Dokuments.
| |
| | |
| ; Vor dem eigentlichen Start einer [[Verschlüsselung|verschlüsselten]] [[Nachrichtenverbindung|Verbindung]] mit IPsec müssen sich beide Seiten gegenseitig authentisieren und sich auf die zu verwendenden [[Schlüssel (Kryptologie)|Schlüssel]]-[[Algorithmus|Algorithmen]] einigen.
| |
| * Hierfür ist IKE gedacht.
| |
| * Zur Authentisierung werden die Verfahren ''[[Pre-shared key|Pre Shared Keying]] (PSK)'' und ''Certificate'' eingesetzt.
| |
| * IPsec arbeitet mit verschiedenen [[Symmetrischer Verschlüsselungsalgorithmus|symmetrischen]] wie [[Asymmetrischer Verschlüsselungsalgorithmus|asymmetrischen]] Schlüsseln.
| |
| | |
| ; IKE basiert auf [[User Datagram Protocol|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 [[Demilitarisierte Zone (Informatik)|Demilitarisierten Zone]] (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 ''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 [[Pre-shared key|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 (engl.
| |
| * Proposal) 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. [[Pretty Good Privacy|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 [[Zertifizierungsstelle|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 [[Public-Key-Infrastruktur|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 [[Zertifikatsperrliste|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-Variante) ====
| |
| ; 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 key]]s 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 [[Advanced Encryption Standard|AES]], Hashing mit [[Secure Hash Algorithm|SHA]] und Authentisierung mit [[RSA-Kryptosystem|RSA]] Signaturen, die durch die Zertifizierungsstelle der Firma signiert wurden) sind bekannt.
| |
| | |
| ==== Phase 2 ====
| |
| ; In der zweiten Phase von IKE 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.
| |
| | |
| === Unterschied zwischen IKEv1 und IKEv2 ===
| |
| {{Lückenhaft|Abschnitt über IKE ist wesentlich für IPsec, aber derzeit unvollständig.}}
| |
| | |
| ; 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 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.<ref>{{Internetquelle |url=https://www.heise.de/security/artikel/Einfacher-VPN-Tunnelbau-dank-IKEv2-270056.html |titel=IPSec-VPNs werden einfacher und flexibler dank IKEv2 |werk= |hrsg=heise |datum=2008-01-03 |sprache=de |abruf=2009-03-26}}</ref> Gleichwohl unterstützen die in Deutschland am weitesten verbreiteten DSL-Router des deutschen Herstellers [[AVM (Unternehmen)|AVM]] (Fritz-Box) bislang nur IKEv1 und nicht IKEv2 (Stand Juli 2020).<ref>[https://avm.de/service/fritzbox/fritzbox-7490/wissensdatenbank/publication/show/3331_FRITZ-Box-mit-einem-Firmen-VPN-verbinden/ FRITZ!Box mit einem Firmen-VPN verbinden], unter ''Voraussetzungen / Einschränkungen'', Auszug aus der AVM Wissensdatenbank, abgerufen am 11.
| |
| * Juli 2020</ref>
| |
| | |
| ; 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.
| |
| | |
| == Authentication Header (AH) ==
| |
| ; Der '''Authentication Header''' (AH) soll die Authentizität und [[Integrität (Informationssicherheit)|Integrität]] der übertragenen Pakete sicherstellen und den Sender authentifizieren.
| |
| * Weiterhin schützt er gegen [[Replay-Angriff]]e.
| |
| * 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. [[Time to Live|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.
| |
| | |
| === Paketaufbau ===
| |
| {| class="wikitable"
| |
| |-
| |
| |colspan="8" style="text-align:left"| Byte 0
| |
| |colspan="8" style="text-align:left"| Byte 1
| |
| |colspan="8" style="text-align:left"| Byte 2
| |
| |colspan="8" style="text-align:left"| Byte 3
| |
| |- style="background:#E8E8E8;"
| |
| | 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
| |
| |-
| |
| |style="text-align:center;" colspan="8" | Nächster Header
| |
| |style="text-align:center;" colspan="8" | Nutzdaten-Länge
| |
| |colspan="16" style="text-align:center;" | reserviert
| |
| |-
| |
| |colspan="32" style="text-align:center;" | Security Parameters Index (SPI)
| |
| |-
| |
| |colspan="32" style="text-align:center;" | Feld mit Sequenznummer
| |
| |-
| |
| |colspan="32" style="text-align:center;" |
| |
| Authentizitätsdaten (variabel)
| |
| |}
| |
| | |
| ==== Felder ====
| |
| ; Nächster Header (next header): identifiziert das [[Protokoll (IP)|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
| |
| | |
| === Schutz vor Replay-Angriffen ===
| |
| Zum Schutz vor [[Replay-Angriff]]en 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).<ref>Sorge, Gruschka, Lo Iacono: ''Sicherheit in Kommunikationsnetzen'' 2013, S. 153f.</ref>
| |
| | |
| == Encapsulating Security Payload (ESP) ==
| |
| | |
| ; '''Encapsulating Security Payload''' (ESP) stellt Mechanismen zur Sicherstellung der Authentizität, Integrität und Vertraulichkeit der übertragenen [[Internet Protocol|IP]]-Pakete bereit.
| |
| * 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 Internet-Protokoll Nummer 50.
| |
| | |
| === ESP-Paket ===
| |
| {| class="wikitable"
| |
| |- style="background:#D0D0D0;"
| |
| |style="text-align:left;" colspan="8" | Byte 0
| |
| |style="text-align:left;" colspan="8" | Byte 1
| |
| |style="text-align:left;" colspan="8" | Byte 2
| |
| |style="text-align:left;" colspan="8" | Byte 3
| |
| |- style="background:#E8E8E8;"
| |
| | 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
| |
| |-
| |
| |colspan="32" style="text-align:center;" | Security Parameters Index (SPI)
| |
| |-
| |
| |colspan="32" style="text-align:center;" | Sequenznummer
| |
| |-
| |
| |colspan="32" style="text-align:center;border-bottom:none;" |
| |
| Nutzdaten * (variabel)
| |
| |-
| |
| |style="border-top:none;" colspan="8" |
| |
| |colspan="24" style="text-align:center;border-bottom:none;" | Füllung (0–255 bytes)
| |
| |-
| |
| |style="border-right:none;" colspan="8" |
| |
| |style="border-left:none;border-top:none;" colspan="8" |
| |
| |style="text-align:center;" colspan="8" | Länge Füllung
| |
| |style="text-align:center;" colspan="8" | Nächster Header
| |
| |-
| |
| |colspan="32" style="text-align:center;" |
| |
| Authentizitätsdaten (variabel)
| |
| |}
| |
| | |
| ==== 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 [[Byte]]s für Padding
| |
| ; Nächster Header (next header): identifiziert das [[Protokoll (IP)|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.
| |
| | |
| == Transport- und Tunnelmodus ==
| |
| [[Datei:Ipsec-modes.svg|mini|Vergleich zwischen Transport- und Tunnelmodus]]
| |
| ; 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.
| |
| | |
| === IPsec im Transportmodus ===
| |
| [[Datei:IPSec Packet Authentication Header.svg|mini|IPsec-AH-Header im Transport- und Tunnelmodus]]
| |
| [[Datei:IPSec Packet ESP Header.svg|mini|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ö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 [[Netzmanagement|Netzwerkverwaltung]].
| |
| | |
| === IPsec im Tunnelmodus ===
| |
| ; Im Tunnelmodus wird das ursprüngliche Paket [[Datenkapselung (Netzwerktechnik)|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 ==
| |
| ; Sicherzustellen, dass die Verbindung zwischen den Endpunkten wischenzeitlich nicht 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 ===
| |
| ; 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 und wird auch ISAKMP-Keepalive genannt.
| |
| | |
| === UDP-Keepalive ===
| |
| ; Verhindert den (bei NAT-Traversal) von NAT üblicherweise automatisch eingeleiteten [[Timeout (Netzwerktechnik)|Timeout]] 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 ===
| |
| | |
| {{Zitat
| |
| |Text=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.
| |
| |Sprache=en
| |
| |Autor=[[Niels Ferguson]], [[Bruce Schneier]]
| |
| |Quelle=A Cryptographic Evaluation of IPsec
| |
| |Übersetzung=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.
| |
| |ref=<ref>[https://www.schneier.com/wp-content/uploads/2016/02/paper-ipsec.pdf ''A Cryptographic Evaluation of IPsec''.] (PDF; 222 kB) S. 1, Abs. 2</ref>}}
| |
| | |
| Die [[Kryptographie|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 [[Internet Protocol|IP]] zum Zeitpunkt ihrer Untersuchungen am besten absicherte.
| |
| | |
| == Normen und Standards ==
| |
| IPsec entstand im Zuge der Entwicklung von [[IPv6]] und ist in verschiedenen aktuellen [[Request for Comments|RFCs]] spezifiziert.
| |
| | |
| Als Einstieg dienen nach RFC 5406 (Guidelines for Specifying the Use of IPsec):
| |
| * IPsec Version 1: RFC 1825 (veraltet aus dem Jahre 1995).
| |
| * IPsec Version 2: RFC 2401 (veraltet aus dem Jahre 1998).
| |
| * IPsec Version 3: RFC 4301 (aus dem Jahre 2005).
| |
| | |
| Weitere relevante RFC's:
| |
| * RFC 2367 – PF_KEY Interface
| |
| * RFC 2403 – The Use of HMAC-MD5-96 within ESP and AH
| |
| * RFC 2405 – The ESP [[Data Encryption Standard|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 [[Public-Key-Infrastruktur|PKI]] Profile of IKEv1/ISAKMP, IKEv2, and [[PKIX]]
| |
| * RFC 7296 – Internet Key Exchange Protocol Version 2 (IKEv2)
| |
| | |
| == Literatur ==
| |
| * {{Literatur
| |
| |Autor=Daniel Bachfeld, Andreas Steffen
| |
| |Titel=VPN-Knigge. VPN-Protokolle und Standards.
| |
| |Sammelwerk=[[c't]]
| |
| |Nummer=7
| |
| |Datum=2006
| |
| |Seiten=114-121
| |
| |Kommentar=IPSec Version 2, auch leicht gekürzt [https://www.heise.de/security/artikel/VPN-Knigge-270796.html kostenlos]
| |
| |Online=https://shop.heise.de/katalog/vpn-knigge
| |
| |Abruf=2019-07-20}}
| |
| * 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.
| |
| | |
| == Weblinks ==
| |
| # https://de.wikipedia.org/wiki/IPsec
| |
| # Schneier: [https://www.schneier.com/academic/archives/2003/12/a_cryptographic_eval.html IPsec-Evaluation.] (englisch)
| |
| # [http://www.unixwiz.net/techtips/iguide-ipsec.html An illustrated guide to IPsec.] (englisch)
| |
| | |
| == Einzelnachweise ==
| |
| <references />
| |
| | |
| [[Kategorie:Internet Protocol]]
| |
| [[Kategorie:Virtual Private Network]]
| |
| [[Kategorie:Verschlüsselungsprotokoll]]
| |
| [[Kategorie:Kryptologischer Standard]]
| |
| [[Kategorie:Abkürzung]]
| |
| | |
| == Installation == | | == Installation == |
| == Anwendungen == | | == Anwendungen == |