entwickler.de

In dieser und der nächsten Folge wird der Einsatz von IKEv2 und IPsec an einem Beispiel beschrieben. Um das Ganze abzukürzen, erfolgt die Beschreibung zum größten Teil umgangssprachlich und beschränkt sich auf die für den Betrieb interessanten Punkte.

Die Ausgangslage: Ein System A will zu einem anderen System B eine IPsec-Verbindung aufbauen. Ob dies ein Site-to-Site-, Site-to-End- oder Host-to-Host-VPN werden soll, ist dabei unerheblich: Der prinzipielle Ablauf ist immer gleich.

Schritt 1: IKE_SA_INIT

Der erste Meldungsaustausch dient der Initialisierung der IPsec-Verbindung:

 Initiator Responder
 (System A) (System B)

 HDR, SAi1, KEi, Ni -->

Der Initiator (System A) listet seine Vorschläge für die auszuhandelnde IKE_SA in so genannte Proposal Substructures der Security Association Payload auf (zu deren Definition wie auch die aller anderen Payloads siehe RFC 4306). Eine Proposal Substructure gilt immer für genau eines der Protokolle AH, ESP oder IKE.

Der Initiator könnte für IKE z.B. folgende Verfahren in SAi1 vorschlagen, aus denen der Responder die für ihn passenden auswählen muss:
AES-128, AES-256, 3DES, SHA1
Außerdem schickt er seinen öffentlichen Diffie-Hellman-Wert (siehe About Security #101) KEi und seinen Zufallswert Ni mit.

 <-- HDR, SAr1, KEr, Nr

Der Responder wählt aus den Vorschlägen in SAi1 die für ihn passenden Verfahren aus und teilt diese Auswahl dem Initiator in SAr1 mit:
AES256, SHA1
Außerdem schickt er seinen öffentlichen Diffie-Hellman-Wert KEr und seinen Zufallswert Nr mit.

Damit haben sich die beiden Systeme darauf festgelegt, die folgenden IKE-Nachrichten mit AES256 zu verschlüsseln und mit SHA1 zu signieren. Auf Grundlage der ausgetauschten öffentlichen Diffie-Hellman- und der Zufallswerte können die im Folgenden benötigten Schlüssel berechnet werden.

Schritt 2: IKE_AUTH

Im zweiten Meldungsaustausch müssen sich die Kommunikationspartner authentifizieren und eine erste CHILD_SA aushandeln.

 HDR, {IDi, AUTH, SAi2, TSi, TSr} -->

Der Initiator sendet in IDi seine Identität, z.B. seine IP-Adresse a.b.c.d. Die Authentication Payload AUTH enthält entweder eine RSA- oder DSS-Signatur oder einen MAC auf Grundlage eines vorher ausgetauschten Geheimwerts (Preshared Secret).

SAi2 enthält die Vorschläge des Initiators für die auszuhandelnde CHILD_SA, z.B.
ESP mit AES-128, 3DES, SHA1
AH mit MD5, SHA1
AH mit SHA1 und ESP mit AES-128, AES-256, 3DES, SHA1

Die Traffic Selectors in TSi definieren die für ausgehende Pakete möglichen Quelladressen und die für eingehende Pakete möglichen Zieladressen. Die Traffic Selectors in TSr definieren die möglichen Zieladressen für ausgehende Pakete und die möglichen Quelladressen für eingehende Pakete. Für den Responder gilt dasselbe mit vertauschten Rollen für TSi und TSr.

Jeder Traffic Selector enthält Protokoll, IP-Adressbereich und Ports. Ein Beispiel für TSi:

Der Initiator erlaubt den Zugriff auf alle seine lokalen Rechner mit den IP-Adressen 192.168.1.10 bis 192.168.1.254 auf beliebigen TCP- und UDP-Ports, außerdem den FTP-Zugriff auf den Rechner mit der IP-Adresse 192.168.1.3 und den Telnet-Zugriff auf den Rechner mit der IP-Adresse 192.168.1.5. Zugriff haben alle in TSr definierten Rechner.

Ein Beispiel für TSr:

Der Initiator möchte auf alle lokalen Rechner des Responders zugreifen können und erlaubt seinerseits den Zugriff von beliebigen lokalen Rechnern des Responders.

 <-- HDR, {IDr, AUTH,
 SAr2, TSi, TSr}

Der Responder antwortet mit einer Nachricht, die seine Identität und Authentifizierungsdaten enthält. Außerdem teilt er dem Initiator mit, welche SA und Traffic Selectors er aus dessen Vorschlägen akzeptiert. Für SAr2 fällt die Wahl auf
ESP mit AES-128, SHA1
AH mit SHA1 und ESP mit AES-256 und SHA1

Bei den Traffic Selectors ist der Responder mit einigen Vorschlägen nicht einverstanden. Er streicht aus den TSi die FTP-Verbindung und schränkt den Port-Bereich für UDP ein:

Aus dem Vorschlag für TSr wird ein Teil der IP-Adressen gestrichen:

Ist der Initiator mit dieser Auswahl einverstanden, wird eine entsprechende CHILD_SA eingerichtet.

In der nächsten Folge wird dieses Beispiel mit Anwendung der IPsec-Protokolle fortgesetzt.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema "VPN - Virtuelle Private Netze"

• About Security #88: Virtuelle Private Netze – Grundlagen
• About Security #89: Virtuelle Private Netze – IPsec (1)
• About Security #90: Virtuelle Private Netze – IPsec (2)
• About Security #91: Virtuelle Private Netze – IKEv2 (1)
• About Security #92: Virtuelle Private Netze – IKEv2 (2)
• About Security #93: Virtuelle Private Netze – IKEv2 (3)
• About Security #94: Virtuelle Private Netze - Beispiel IKEv2
• About Security #95: Virtuelle Private Netze – IPsec anschaulich
• About Security #96: Virtuelle Private Netze – PPTP
• About Security #97: Virtuelle Private Netze – TLS
• About Security #98: Virtuelle Private Netze – OpenVPN
• About Security #99: Virtuelle Private Netze – Fazit