Einfacher VPN-Tunnelbau dank IKEv2
Seite 4: IKEv2-Protokoll im Detail
IKEv2-Protokoll im Detail
IKEv2 definiert vier Meldungstypen: IKE_SA_INIT für die Initialisierung einer IPSec-Verbindung, IKE_AUTH für die Authentifizierung der Kommunikationspartner, CREATE_CHILD_SA für Schlüsseländerungen und die Erstellung zusätzlicher CHILD_SA sowie INFORMATIONAL für den weiteren Informationsaustausch.
Bei IKEv2 sendet der Initiator in einem IKE_SA_INIT-Request seine Krypto-Vorschläge SA1i, seinen öffentlichen Diffie-Hellman-Key-Exchange-Faktor KEi sowie eine Zufallszahl Ni. Der Responder gibt im IKE_SA_INIT Response seine Krypto-Auswahl SA1r, seinen DH Faktor KEr sowie eine eigene Zufallszahl Nr zurück. Aus KEi, KEr, Ni und Nr leiten nun beide Endpunkte gemeinsame Session-Schlüssel für die Verschlüsselung und Authentisierung aller nachfolgenden IKE-Meldungen ab. Da die Berechnung eines Diffie-Hellman-Geheimnisses wegen der bis zu 2048 Bit großen Zahlen ziemlich aufwendig ist, könnte ein Angreifer durch Senden einer Vielzahl von IKE_SA_INIT-Requests mit ständig wechselnder Absenderadresse ein IPSec-Gateway gezielt in die Knie zwingen.
Hat der Responder den Verdacht, angegriffen zu werden (manifestiert durch viele IKE_SA_INIT-Meldungen, auf die kein weitergehender IKE_AUTH Request folgt), so kann er in seiner IKE_SA_INIT-Response einzig ein zufällig gewähltes Cookie zurücksenden und der Initiator muss seinen Request, ergänzt mit dem empfangenen Cookie, wiederholen.
Ist die erste Kontaktaufnahme erfolgreich verlaufen, so schiebt der Initiator einen IKE_AUTH Request mit seiner Identität IDi und seiner Authentifizierungs-Payload Authi nach, die auf PSK (Pre-Shared Keys) oder RSA beruhen kann. Optional kann noch die gewünschte Identität IDr angegeben werden, falls die Gegenstelle mehrere Identitäten besitzt. Beruht die Authentifizierung auf einer RSA-Signatur, so sendet das Endgerät optional entweder das eigene X.509- Zertifikat mit oder alternativ eine HTTP-URL.
Mit der IKE_AUTH-Meldung kann im gleichen Aufwasch direkt eine erste sogenannte Child Security Association (CHILD_SA) erstellt werden. Mit SA2i wird eine Krypto-Auswahl mitgesendet, die vorschlägt, wie ESP (Encapsulating Security Payload) oder AH (Authentication Header) IPSec-Pakete verschlüsselt, authentisiert und optional komprimiert werden sollen. Weiter werden mit den Traffic-Selektoren TSi und TSr ein eigener und ein fremder IP-Adressbereich vorgeschlagen, die miteinander gekoppelt werden sollen. Die Traffic-Selektoren können den Tunnelverkehr auch auf ein einzelnes IP-Protokoll wie TCP und einen Portbereich oder sogar einen einzelnen Port wie http einschränken.
Der Responder sendet in der IKE_AUTH-Response seine eigene Identität IDr und seine Auth-Payload Authr zurück. Betreffend der CHILD_SA trifft er eine ESP/AH-Krypto-Auswahl SA2r und hat neu die Möglichkeit mit den Traffic-Selektoren TSi und TSr die Subnetze einzuengen. Wünscht der Initiator zum Beispiel TSr=10.1.0.0/16, so kann der Responder mit TSr=10.1.0.0/24 das Subnetz verkleinern. Im Extremfall kann der Initiator mit dem Vorschlag TSr=0.0.0.0/0 die Wahl des entfernten Subnetzes ganz der Gegenstelle überlassen. Das Gleiche gilt entsprechend auch für den TSi-Selektor. Dieses "Narrowing" genannte Vorgehen gestaltet die IPSec-Konfiguration wesentlich schmerzloser als in der düsteren IKEv1-Vergangenheit. Aus langjähriger Erfahrung des Autors haben die vielen Anwender nur schwer verstehen können, dass ein Verbindungsaufbau nicht zustande kommen wollte, nur weil keine exakte Übereinstimmung der Selektoren gegeben war. (dab)
