Internet Key Exchange (IKE) ist ein IPsec-Standardprotokoll (Internet Protocol Security), das für mehr Sicherheit in Virtuellen Privaten Netzwerken (VPNs) und beim Remote-Zugriff auf entfernte Server und andere Netzwerkressourcen sorgt. IKE wurde in RFC 2409 festgelegt und definiert die automatische Verbindungsaufnahme und Authentifizierung bei IPsec-Sicherheitsverbindungen (Englisch: Security Associations bzw. abgekürzt SA). Security Associations sind spezielle Richtlinien, die für die Kommunikation zwischen zwei oder mehr Parteien festgelegt werden. Die Verbindung zwischen den Parteien wird mit einem Schlüssel gesichert. Das IKE-Protokoll sorgt für die Sicherheit bei SA-Verbindungen, ohne dass dafür spezielle Konfigurationen benötigt werden. Später wurde es als IKEv2 in den RFCs 4306, 4718, 5996 und 7296 erweitert.
Als Hybrid-Protokoll verbindet IKE die beiden früheren Security-Protokolle Oakley und ISAKMP (Internet Security Association and Key Management Protocol) in einem TCP/IP-basierten Framework. ISAKMP spezifiziert den Austausch von Schlüsseln und zur Authentifizierung, während das Oakley-Protokoll den Ablauf beim Schlüsselaustausch und die dazugehörigen Dienste beschreibt (beispielsweise zum Identitätsschutz und zur Authentifizierung). Obwohl IKE nicht zwangsläufig zur IPsec-Konfiguration benötigt wird, bietet es doch eine Reihe von Vorteilen wie automatische Verbindungsaufnahme und Authentifizierung, Anti-Replay-Dienste, Unterstützung von Zertifizierungsstellen und die Fähigkeit, kryptografische Schlüssel während einer IPsec-Sitzung auszutauschen.
IKE Phase 1
Der Hauptzweck von IKE Phase 1 besteht darin, einen sicheren Tunnel einzurichten, den wir für IKE Phase 2 verwenden können. Wir können Phase 1 in drei einfache Schritte unterteilen:
Verhandlung
Der Peer, dessen Datenverkehr geschützt werden sollte, initiiert die IKE-Phase-1-Aushandlung. Die beiden Peers werden über folgende Punkte verhandeln:
Hashing: Wir verwenden einen Hashing-Algorithmus, um die Integrität zu überprüfen. Wir verwenden hierfür MD5 oder SHA.
Authentifizierung: Jeder Peer muss nachweisen, wer er ist. Zwei häufig verwendete Optionen sind ein Pre-Shared Key oder digitale Zertifikate.
DH-Gruppe (Diffie Hellman): Die DH-Gruppe bestimmt die Stärke des Schlüssels, der im Schlüsselaustauschprozess verwendet wird. Die höheren Gruppennummern sind sicherer, die Berechnung dauert jedoch länger.
Lebensdauer: Wie lange hält der IKE-Phase-1-Tunnel? Je kürzer die Lebensdauer, desto sicherer ist sie, denn für den Wiederaufbau müssen wir auch neues Schlüsselmaterial verwenden. Jeder Anbieter verwendet eine andere Lebensdauer. Ein üblicher Standardwert ist 86400 Sekunden (1 Tag).
Verschlüsselung: Welchen Algorithmus verwenden wir zur Verschlüsselung? Zum Beispiel DES, 3DES oder AES.
DH-Schlüsselaustausch
Sobald die Verhandlung erfolgreich war, wissen die beiden Peers, welche Richtlinie sie anwenden müssen. Sie werden nun die von ihnen ausgehandelte DH-Gruppe nutzen, um Schlüsselmaterial auszutauschen. Das Endergebnis wird sein, dass beide Peers einen gemeinsamen Schlüssel haben. Siehe Diffie Hellman Key Exchange.
Authentifizierung
Der letzte Schritt besteht darin, dass sich die beiden Peers gegenseitig mithilfe der Authentifizierungsmethode authentifizieren, auf die sie sich in der Verhandlung geeinigt haben. Wenn die Authentifizierung erfolgreich ist, haben wir die IKE-Phase 1 abgeschlossen. Das Endergebnis ist ein IKE-Phase-1-Tunnel (auch bekannt als ISAKMP-Tunnel), der bidirektional ist. Das bedeutet, dass beide Peers auf diesem Tunnel senden und empfangen können.
Die drei oben genannten Schritte können in zwei verschiedenen Modi ausgeführt werden:
Hauptmodus
Aggressiver Modus
Der Hauptmodus verwendet sechs Nachrichten, während der aggressive Modus nur drei Nachrichten verwendet**.
Messages
Main Mode
The first packet is sent from the initiator of the IPSec tunnel to its remote endpoint, this packet contains the ISAKMP policy
The second packet is sent from the remote endpoint back to the initiator, this packet will be the exact same information matching the ISAKMP policy sent by the initiator.
The third packet is sent from the initiator to the remote endpoint, this packet contains the Key Exchange payload and the Nonce payload, the purpose of this packet is generate the information for the DH secret key
This fourth packet as you would expect comes from the remote endpoint back to initiator and contains the remote endpoints Key Exchange and Nonce payload.
The fifth packet is from the initiator back to the remote endpoint with identity and hash payloads, the identity payload has the device’s IP Address in, and the hash payload is a combination of keys (including a PSK, if PSK authentication is used)
The sixth packet from the remote endpoint to the initiator contains the corresponding hash payloads to verify the exchange.
Aggressive Mode
The first packet from the initiator contains enough information for the remote endpoint to generate its DH secret, so this one packet is equivalent to the first four packets in main mode.
The second packet from the remote endpoint back to the initiator contains its DH secret
The third packet from the initiator includes identity and hash payloads. After the remote endpoint receives this packet it simply calculates its hash payload and verifies it matches, if it matches then phase one is established.
IKE Phase 2
Der IKE-Phase-2-Tunnel (IPsec-Tunnel) wird eigentlich zum Schutz der Benutzerdaten verwendet. Es gibt nur einen Modus zum Aufbau des IKE-Phase-2-Tunnels, der als Schnellmodus bezeichnet wird.
Genau wie in IKE-Phase 1 werden unsere Kollegen über eine Reihe von Punkten verhandeln:
IPsec-Protokoll: Verwenden wir AH oder ESP?
Kapselungsmodus: Transport- oder Tunnelmodus?
Verschlüsselung: Welchen Verschlüsselungsalgorithmus verwenden wir? DES, 3DES oder AES?
Authentifizierung: Welchen Authentifizierungsalgorithmus verwenden wir? MD5 oder SHA?
Lebensdauer: Wie lange ist der IKE-Phase-2-Tunnel gültig? Wenn der Tunnel bald abläuft, aktualisieren wir das Schlüsselmaterial.
DH-Austausch (Optional): Wird für PFS (Perfect Forward Secrecy) verwendet.
Messages