Internet Key Exchange
Einführung in IKE
Internet Key Exchange (IKE) ist ein sicheres Schlüsselverwaltungsprotokoll, das zum Einrichten eines sicheren, authentifizierten Kommunikationskanals zwischen zwei Geräten verwendet wird.
IKE macht Folgendes:
Aushandeln und Verwalten von IKE- und IPsec-Parametern
Authentifiziert den sicheren Schlüsselaustausch
Bietet gegenseitige Peer-Authentifizierung mittels gemeinsamer geheimer Schlüssel (keine Kennwörter) und öffentlichen Schlüsseln
Bietet Identitätsschutz (im Hauptmodus)
Verwendet Diffie-Hellman-Methoden und ist in IPsec optional (die gemeinsam genutzten Schlüssel können manuell an den Endpunkten eingegeben werden).
IKE-Versionen
Es stehen zwei Versionen der IKE-Standards zur Verfügung:
IKE Version 1 – IKE-Protokoll definiert in RFC 2409.
IKE Version 2 - IKE Version 2 (IKEv2) ist die neueste Version des in RFC 7296 definierten IKE-Protokolls.
Internet Key Exchange Version 2 (IKEv2) ist die neueste Version des Internet Key Exchange (IKE)-Protokolls, das in RFC 7296 definiert ist. Ein VPN-Peer ist entweder als IKEv1 oder IKEv2 konfiguriert. Wenn ein Peer als IKEv2 konfiguriert ist, kann er nicht auf IKEv1 zurückgreifen, wenn sein Remotepeer die IKEv1-Aushandlung initiiert.
Die Vorteile der Verwendung von IKEv2 gegenüber IKEv1 sind wie folgt:
Ersetzt acht anfängliche Austauschvorgänge durch einen einzigen Austausch mit vier Nachrichten.
Verringert die Latenz für die Einrichtung der IPsec-Sicherheitszuordnung und erhöht die Geschwindigkeit des Verbindungsaufbaus.
Erhöht die Robustheit gegen DOS-Angriffe.
Verbessert die Zuverlässigkeit durch die Verwendung von Sequenznummern, Bestätigungen und Fehlerkorrektur.
Verbessert die Zuverlässigkeit, da es sich bei allen Nachrichten um Anforderungen oder Antworten handelt. Der Initiator ist für die erneute Übertragung verantwortlich, wenn er keine Antwort erhält.
Interaktion zwischen IKE und IPSec
IPsec kann ein VPN auf eine der folgenden Arten einrichten:
Internet Key Exchange (IKE)-Protokoll – IPsec unterstützt die automatisierte Generierung und Aushandlung von Schlüsseln und Sicherheitszuordnungen unter Verwendung des IKE-Protokolls. Die Verwendung von IKE zur Aushandlung von VPNs zwischen zwei Endpunkten bietet mehr Sicherheit als der manuelle Schlüsselaustausch.
Manueller Schlüsselaustausch: IPsec unterstützt die manuelle Verwendung und den Austausch von Schlüsseln (Beispiel: Telefon oder E-Mail) auf beiden Seiten, um ein VPN einzurichten.
IKEv1-Nachrichtenaustausch
Die IKE-Verhandlung umfasst zwei Phasen:
Phase 1 – Verhandeln Sie über den Austausch von Vorschlägen zur Authentifizierung und Sicherung des Kanals.
Phase 2 – Aushandeln von Sicherheitszuordnungen (Security Associations, SAs), um die Daten zu schützen, die den IPsec-Tunnel durchlaufen.
Phase 1 der IKE-Tunnelverhandlungen
Phase 1 einer AutoKey Internet Key Exchange (IKE)-Tunnelaushandlung besteht aus dem Austausch von Vorschlägen zur Authentifizierung und Sicherung des Kanals. Die Teilnehmer tauschen Vorschläge für akzeptable Sicherheitsdienste aus, wie z.B.:
Verschlüsselungsalgorithmen: Data Encryption Standard (DES), Triple Data Encryption Standard (3DES) und Advanced Encryption Standard (AES). (Siehe IPsec – Übersicht.)
Authentifizierungsalgorithmen: Message Digest 5 (MD5) und Secure Hash Algorithm (SHA). (Siehe IPsec – Übersicht.)
Diffie-Hellman (DH) Gruppe. (Siehe IPsec – Übersicht.)
Preshared Key oder RSA/DSA-Zertifikate. (Siehe IPsec – Übersicht.)
Eine erfolgreiche Phase-1-Verhandlung endet, wenn sich beide Enden des Tunnels darauf einigen, mindestens einen Satz der vorgeschlagenen Phase-1-Sicherheitsparameter zu akzeptieren und diese dann zu verarbeiten. Geräte von Juniper Networks unterstützen bis zu vier Vorschläge für Phase-1-Aushandlungen, sodass Sie festlegen können, wie restriktiv eine Reihe von Sicherheitsparametern für die Schlüsselaushandlung ist, die Sie akzeptieren. Junos OS bietet vordefinierte standardmäßige, kompatible und grundlegende Phase-1-Angebotssätze. Sie können auch benutzerdefinierte Phase-1-Vorschläge definieren.
Der Austausch in Phase 1 kann entweder im Hauptmodus oder im aggressiven Modus stattfinden. Sie können Ihren Modus während der Konfiguration der IKE-Richtlinie auswählen.
Dieses Thema umfasst die folgenden Abschnitte:
Hauptmodus
Im Hauptmodus senden Initiator und Empfänger drei bidirektionale Austauschvorgänge (insgesamt sechs Nachrichten), um die folgenden Dienste auszuführen:
Erster Austausch (Nachrichten 1 und 2): Schlägt die Verschlüsselungs- und Authentifizierungsalgorithmen vor und akzeptiert sie.
Zweiter Austausch (Nachrichten 3 und 4): Führt einen DH-Austausch aus, wobei der Initiator und der Empfänger jeweils eine Pseudozufallszahl angeben.
Dritter Austausch (Nachrichten 5 und 6): Sendet und überprüft die Identitäten des Initiators und des Empfängers.
Die Informationen, die im dritten Nachrichtenaustausch übertragen werden, werden durch den Verschlüsselungsalgorithmus geschützt, der in den ersten beiden Austauschvorgängen festgelegt wurde. Somit werden die Identitäten der Teilnehmer verschlüsselt und somit nicht "im Klartext" übertragen.
Aggressiver Modus
Im aggressiven Modus erreichen Initiator und Empfänger die gleichen Ziele wie im Hauptmodus, jedoch in nur zwei Austauschvorgängen mit insgesamt drei Nachrichten:
Erste Nachricht: Der Initiator schlägt die Sicherheitszuordnung (Security Association, SA) vor, initiiert einen DH-Austausch und sendet eine Pseudozufallszahl und ihre IKE-Identität.
Wenn Sie den aggressiven Modus mit mehreren Vorschlägen für Phase-1-Verhandlungen konfigurieren, verwenden Sie in allen Vorschlägen dieselbe DH-Gruppe, da die DH-Gruppe nicht ausgehandelt werden kann. Es können bis zu vier Vorschläge konfiguriert werden.
Zweite Nachricht: Der Empfänger akzeptiert die SA. authentifiziert den Initiator; und sendet eine Pseudozufallszahl, ihre IKE-Identität und, bei Verwendung von Zertifikaten, das Zertifikat des Empfängers.
Dritte Nachricht: Der Initiator authentifiziert den Empfänger, bestätigt den Austausch und sendet bei Verwendung von Zertifikaten das Zertifikat des Initiators.
Da die Identitäten der Teilnehmer im Klartext (in den ersten beiden Nachrichten) ausgetauscht werden, bietet der aggressive Modus keinen Identitätsschutz.
Die Modi "Main" und "Aggressiv" gelten nur für das IKEv1-Protokoll. Das IKEv2-Protokoll handelt nicht mit den Hauptmodi und aggressiven Modi aus.
Siehe auch
Phase 2 der IKE-Tunnelverhandlungen
Nachdem die Teilnehmer einen sicheren und authentifizierten Kanal eingerichtet haben, durchlaufen sie Phase 2, in der sie Sicherheitszuordnungen (Security Associations, SAs) aushandeln, um die Daten zu sichern, die durch den IPsec-Tunnel übertragen werden sollen.
Ähnlich wie bei Phase 1 tauschen die Teilnehmer Vorschläge aus, um zu bestimmen, welche Sicherheitsparameter in der SA eingesetzt werden sollen. Ein Phase-2-Vorschlag umfasst auch ein Sicherheitsprotokoll – entweder Encapsulating Security Payload (ESP) oder Authentication Header (AH) – sowie ausgewählte Verschlüsselungs- und Authentifizierungsalgorithmen. Der Vorschlag kann auch eine Diffie-Hellman-Gruppe (DH) angeben, wenn Perfect Forward Secrecy (PFS) gewünscht wird.
Unabhängig davon, welcher Modus in Phase 1 verwendet wird, arbeitet Phase 2 immer im Schnellmodus und beinhaltet den Austausch von drei Nachrichten.
Dieses Thema umfasst die folgenden Abschnitte:
Proxy-IDs
In Phase 2 tauschen die Peers Proxy-IDs aus. Eine Proxy-ID besteht aus einem Präfix für eine lokale und eine Remote-IP-Adresse. Die Proxy-ID für beide Peers muss übereinstimmen, was bedeutet, dass die für einen Peer angegebene lokale IP-Adresse mit der für den anderen Peer angegebenen Remote-IP-Adresse identisch sein muss.
Perfekte Vorwärts-Geheimhaltung
PFS ist eine Methode zum Ableiten von Phase-2-Schlüsseln, die unabhängig von den vorhergehenden Schlüsseln sind und mit diesen in keinem Zusammenhang stehen. Alternativ erstellt der Phase-1-Vorschlag den Schlüssel (den SKEYID_d-Schlüssel), von dem alle Phase-2-Schlüssel abgeleitet werden. Der SKEYID_d-Schlüssel kann Phase-2-Schlüssel mit einem Minimum an CPU-Verarbeitung generieren. Wenn sich ein Unbefugter Zugriff auf den SKEYID_d Schlüssel verschafft, sind leider alle Ihre Verschlüsselungsschlüssel kompromittiert.
PFS begegnet diesem Sicherheitsrisiko, indem es für jeden Phase-2-Tunnel einen neuen DH-Schlüsselaustausch erzwingt. Die Verwendung von PFS ist daher sicherer, auch wenn das Verfahren zur erneuten Schlüsselerstellung in Phase 2 bei aktiviertem PFS etwas länger dauern kann.
Replay-Schutz
Ein Replay-Angriff liegt vor, wenn eine nicht autorisierte Person eine Reihe von Paketen abfängt und diese später verwendet, um entweder das System zu überfluten, wodurch ein Denial of Service (DoS) ausgelöst wird, oder um sich Zugang zum vertrauenswürdigen Netzwerk zu verschaffen. Junos OS bietet eine Replay-Schutzfunktion, mit der Geräte jedes IPsec-Paket überprüfen können, um festzustellen, ob es zuvor empfangen wurde. Wenn Pakete außerhalb eines bestimmten Sequenzbereichs eingehen, werden sie von Junos OS zurückgewiesen. Die Verwendung dieser Funktion erfordert keine Aushandlung, da Pakete immer mit Sequenznummern gesendet werden. Sie haben lediglich die Möglichkeit, die Sequenznummern zu überprüfen oder nicht.
Siehe auch
IKEv2-Nachrichtenaustausch
IKE Version 2 ist der Nachfolger der IKEv1-Methode. Es stellt einen sicheren VPN-Kommunikationskanal zwischen Peer-VPN-Geräten bereit und definiert die Aushandlung und Authentifizierung für IPsec-Sicherheitszuordnungen (SAs) auf geschützte Weise.
IKEv2 enthält nicht die Phasen 1 und 2 ähnlich wie IKEv1, aber es gibt vier Nachrichtenaustausche, um einen IPsec-Tunnel mit IKEv2 auszuhandeln. Der Nachrichtenaustausch in IKEv2 ist:
Aushandeln der Sicherheitsattribute zum Einrichten des IPsec-Tunnels. Dazu gehört der Austausch der verwendeten Protokolle/Parameter und Diffie-Hellman-Gruppen.
Jeder Peer stellt seine Identität her oder authentifiziert sie, während der IPsec-Tunnel eingerichtet wird.
Peers, um zusätzliche Sicherheitszuordnungen untereinander zu erstellen.
Peers führen eine Lebendigkeitserkennung durch, entfernen SA-Beziehungen und melden Fehlermeldungen.
- IKEv2-Konfigurationsnutzlast
- IKEv2 Erneute Schlüsselerstellung und erneute Authentifizierung
- IKEv2-Fragmentierung
- Datenverkehrsselektoren für IKEv2
IKEv2-Konfigurationsnutzlast
Die Konfigurationsnutzlast ist eine IKEv2-Option, die angeboten wird, um Bereitstellungsinformationen von einem Responder an einen Initiator weiterzugeben. Die IKEv2-Konfigurationsnutzlast wird nur mit routenbasierten VPNs unterstützt.
RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2), definiert 15 verschiedene Konfigurationsattribute, die vom Responder an den Initiator zurückgegeben werden können.
IKEv2 Erneute Schlüsselerstellung und erneute Authentifizierung
Bei IKEv2 sind die erneute Schlüsselerstellung und die erneute Authentifizierung getrennte Prozesse.
Durch die erneute Schlüsselerstellung werden neue Schlüssel für die IKE-Sicherheitszuordnung (Security Association, SA) erstellt und Nachrichten-ID-Leistungsindikatoren zurückgesetzt, die Peers werden jedoch nicht erneut authentifiziert.
Bei der erneuten Authentifizierung wird überprüft, ob VPN-Peers ihren Zugriff auf Authentifizierungsanmeldeinformationen behalten. Bei der erneuten Authentifizierung werden neue Schlüssel für die IKE-Sicherheitszuordnung und die untergeordneten Sicherheitszuordnungen erstellt. Neuschlüssel einer ausstehenden IKE-SA oder untergeordneten SA werden nicht mehr benötigt. Nachdem die neue IKE und die untergeordneten Sicherheitszuordnungen erstellt wurden, werden die alte IKE und die untergeordneten Sicherheitszuordnungen gelöscht.
Die erneute IKEv2-Authentifizierung ist standardmäßig deaktiviert. Sie aktivieren die erneute Authentifizierung, indem Sie einen Wert für die Häufigkeit der erneuten Authentifizierung zwischen 1 und 100 konfigurieren. Die Häufigkeit der erneuten Authentifizierung ist die Anzahl der erneuten IKE-Schlüssel, die vor der erneuten Authentifizierung erfolgen. Wenn z. B. die konfigurierte Häufigkeit der erneuten Authentifizierung 1 ist, erfolgt die erneute Authentifizierung jedes Mal, wenn ein IKE-Neuschlüssel erfolgt. Wenn die konfigurierte Häufigkeit der erneuten Authentifizierung 2 ist, erfolgt die erneute Authentifizierung bei jedem zweiten erneuten IKE-Schlüssel. Wenn die konfigurierte Häufigkeit der erneuten Authentifizierung 3 beträgt, erfolgt die erneute Authentifizierung bei jedem dritten erneuten IKE-Schlüssel usw.
IKEv2-Fragmentierung
Wenn zertifikatbasierte Authentifizierung verwendet wird, können IKEv2-Pakete die Pfad-MTU überschreiten, wenn mehrere Zertifikate übertragen werden. Wenn die IKE-Nachrichtengröße die Pfad-MTU überschreitet, werden die Nachrichten auf IP-Ebene fragmentiert. Einige Netzwerkgeräte, wie z. B. NAT-Geräte, lassen IP-Fragmente nicht durch, wodurch die Einrichtung von IPsec-Tunneln verhindert wird.
Die IKEv2-Nachrichtenfragmentierung, wie in RFC 7383, Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation, beschrieben, ermöglicht IKEv2 den Betrieb in Umgebungen, in denen IP-Fragmente blockiert werden können und Peers keine IPsec-Sicherheitszuordnung (Security Association, SA) einrichten können. Bei der IKEv2-Fragmentierung wird eine große IKEv2-Nachricht in eine Gruppe kleinerer Nachrichten aufgeteilt, sodass es keine Fragmentierung auf IP-Ebene gibt. Die Fragmentierung findet statt, bevor die ursprüngliche Nachricht verschlüsselt und authentifiziert wird, sodass jedes Fragment separat verschlüsselt und authentifiziert wird. Auf dem Empfänger werden die Fragmente gesammelt, verifiziert, entschlüsselt und mit der ursprünglichen Nachricht zusammengeführt.
Datenverkehrsselektoren für IKEv2
Sie können Datenverkehrsselektoren in IKEv2 konfigurieren, die während der IKE-Aushandlung verwendet werden. Ein Datenverkehrsselektor ist eine Vereinbarung zwischen IKE-Peers, um Datenverkehr durch einen VPN-Tunnel zuzulassen, wenn der Datenverkehr mit einem bestimmten Paar von lokalen und Remoteadressen übereinstimmt. Nur der Datenverkehr, der einem Datenverkehrsselektor entspricht, wird über die zugeordnete Sicherheitszuordnung (Security Association, SA) zugelassen. Datenverkehrsselektoren werden während der Tunnelerstellung verwendet, um den Tunnel einzurichten und zu bestimmen, welcher Datenverkehr durch den Tunnel gelassen wird.
Proxy-ID
Eine Proxy-ID wird während Phase 2 der VPN-Verhandlungen (Virtual Private Network) von Internet Key Exchange (IKE) verwendet. An beiden Enden eines VPN-Tunnels wurde entweder eine Proxy-ID manuell konfiguriert (routenbasiertes VPN) oder es wird einfach eine Kombination aus Quell-IP, Ziel-IP und Service in einer Tunnelrichtlinie verwendet. Wenn Phase 2 von IKE ausgehandelt wird, vergleicht jedes Ende die konfigurierte lokale und Remote-Proxy-ID mit der tatsächlich empfangenen ID.
Traffic-Selektoren
Die Proxy-ID wird sowohl für routenbasierte als auch für richtlinienbasierte VPNs unterstützt. Die Multi-Proxy-ID wird jedoch nur für routenbasierte VPNs unterstützt. Die Multi-Proxy-ID wird auch als Datenverkehrsselektor bezeichnet. Ein Datenverkehrsselektor ist eine Vereinbarung zwischen IKE-Peers, um Datenverkehr durch einen Tunnel zuzulassen, wenn der Datenverkehr mit einem bestimmten Paar von lokalen und Remoteadressen übereinstimmt. Sie definieren einen Datenverkehrsselektor innerhalb eines bestimmten routenbasierten VPNs, was zu mehreren IPsec-Sicherheitszuordnungen der Phase 2 führen kann. Nur Datenverkehr, der einem Datenverkehrsselektor entspricht, wird über eine Sicherheitszuordnung zugelassen. Die Datenverkehrsauswahl ist in der Regel erforderlich, wenn es sich bei Remote-Gateway-Geräten um Geräte handelt, die nicht von Juniper Networks stammen.
Network Address Translation-Traversal (NAT-T)
Network Address Translation-Traversal (NAT-T) ist eine Methode zur Umgehung von Problemen bei der Übertragung von IP-Adressen, die auftreten, wenn durch IPsec geschützte Daten zur Adressübersetzung durch ein NAT-Gerät geleitet werden.
Jede Änderung an der IP-Adresse, die die Funktion von NAT ist, führt dazu, dass IKE Pakete verwirft. Nach der Erkennung eines oder mehrerer NAT-Geräte entlang des Datenpfads während des Phase-1-Austauschs fügt NAT-T IPsec-Paketen eine UDP-Kapselungsschicht (User Datagram Protocol) hinzu, damit sie nach der Adressübersetzung nicht verworfen werden. NAT-T kapselt sowohl IKE- als auch ESP-Datenverkehr innerhalb von UDP, wobei Port 4500 sowohl als Quell- als auch als Zielport verwendet wird. Da NAT-Geräte veraltete UDP-Übersetzungen veraltet machen, sind Keepalive-Nachrichten zwischen den Peers erforderlich.
Der Standort eines NAT-Geräts kann so sein, dass:
Nur der IKEv1- oder IKEv2-Initiator befindet sich hinter einem NAT-Gerät. Hinter separaten NAT-Geräten können sich mehrere Initiatoren befinden. Initiatoren können sich auch über mehrere NAT-Geräte mit dem Responder verbinden.
Nur der IKEv1- oder IKEv2-Responder befindet sich hinter einem NAT-Gerät.
Sowohl der IKEv1- oder IKEv2-Initiator als auch der Responder befinden sich hinter einem NAT-Gerät.
Suite B und PRIME Cryptographic Suites
Suite B ist eine Reihe kryptografischer Algorithmen, die von der U.S. National Security Agency (NSA) entwickelt wurden, um kommerziellen Produkten den Schutz von Datenverkehr zu ermöglichen, der als geheim oder streng geheim eingestuft ist. Suite B-Protokolle sind in RFC 6379, Suite B Cryptographic Suites for IPsec, definiert. Die kryptografischen Suiten der Suite B bieten ESP-Integrität und Vertraulichkeit (Encapsulating Security Payload) und sollten verwendet werden, wenn sowohl ESP-Integritätsschutz als auch Verschlüsselung erforderlich sind. Protocol Requirements for IP Modular Encryption (PRIME), ein IPsec-Profil, das für Netzwerke des öffentlichen Sektors im Vereinigten Königreich definiert wurde, basiert auf der kryptografischen Suite B, verwendet jedoch AES-GCM anstelle von AES-CBC für IKEv2-Aushandlungen.
Die folgenden kryptografischen Suites werden unterstützt:
Suite-B-GCM-128
ESP: AES-Verschlüsselung (Advanced Encryption Standard) mit 128-Bit-Schlüsseln und 16-Oktett-Integritätsprüfwert (ICV) im Galois-Counter-Modus (GCM).
IKE: AES-Verschlüsselung mit 128-Bit-Schlüsseln im CBC-Modus (Cipher Block Chaining), Integrität mit SHA-256-Authentifizierung, Schlüsselaufbau mit Diffie-Hellman (DH)-Gruppe 19 und Authentifizierung mit Elliptic Curve Digital Signature Algorithm (ECDSA) 256-Bit-Signaturen für elliptische Kurven.
Suite-B-GCM-256
ESP: AES-Verschlüsselung mit 256-Bit-Schlüsseln und 16-Oktett-ICV in GCM für ESP.
IKE: AES-Verschlüsselung mit 256-Bit-Schlüsseln im CBC-Modus, Integrität mit SHA-384-Authentifizierung, Schlüsselaufbau mit DH-Gruppe 20 und Authentifizierung mit ECDSA 384-Bit-Signaturen mit elliptischen Kurven.
PRIME-128
ESP: AES-Verschlüsselung mit 128-Bit-Schlüsseln und 16-Oktett-ICV in GCM.
IKE: AES-Verschlüsselung mit 128-Bit-Schlüsseln in GCM, Schlüsselaufbau mit DH-Gruppe 19 und Authentifizierung mit ECDSA 256-Bit-Signaturen mit elliptischen Kurven.
PRIME-256
ESP: AES-Verschlüsselung mit 256-Bit-Schlüsseln und 16-Oktett-ICV in GCM für ESP.
IKE: AES-Verschlüsselung mit 256-Bit-Schlüsseln in GCM, Schlüsselaufbau mit DH-Gruppe 20 und Authentifizierung mit ECDSA 384-Bit-Signaturen mit elliptischen Kurven.
Suite-B-Kryptografie-Suites unterstützen IKEv1 und IKEv2. PRIME-Verschlüsselungssuiten unterstützen nur IKEv2.