Der Meldungstyp IKE_AUTH wird vom von IPsec für den Schlüsselaustausch verwendeten Internet Key Exchange Protocol (IKEv2) nach erfolgreicher Initialisierung einer Verbindung durch IKE_SA_INIT für die Authentifizierung der Kommunikationspartner verwendet. Aus dem dabei durch den Diffie-Hellmann-Schlüsseltaustausch (siehe About Security #101) ausgetauschten Schlüssel (genannt SKEYSEED) werden alle weiteren benötigten Schlüssel, z.B. für die Verschlüsselungs- und Signaturalgorithmen, abgeleitet. Ab jetzt werden alle Daten mit Ausnahme der Header verschlüsselt und integritätsgeschützt übertragen.

IKE_AUTH

Der Austausch der IKE_AUTH-Meldungen dient der gegenseitigen Authentifizierung der Kommunikationspartner und dem Aushandeln einer ersten CHILD_SA für die folgende Kommunikation über die IPsec-Protokolle Authentication Header (AH) (siehe About Security #89) und/oder Encapsulating Security Payload (ESP) (siehe About Security #90).

 Initiator Responder
 
 HDR, {IDi, [CERT,] [CERTREQ,] 
 [IDr,] AUTH, SAi2, TSi, TSr} -->
 <-- HDR, {IDr, [CERT,] AUTH,
 SAr2, TSi, TSr}

{} markiert den verschlüsselten und integritätsgeschützten Teil der Nachrichten.

Traffic Selectors

Die Traffic Selectors erlauben den Austausch einiger Informationen aus der Security Policy Database (SPD, siehe About Security #90). Die Kommunikationspartner tauschen sich darüber aus, welche Pakete über die auszuhandelnde SA übertragen werden sollen.

Generell ist die Aktualisierung der SPD nicht die Aufgabe von IKE, sondern eigener Protokolle. Implementierungen können dies trotzdem in Verbindung mit IKE übernehmen. Die übertragenen Informationen können in diesem Fall zur Aktualisierung der SPD verwendet werden, ansonsten erlauben diese die Kontrolle der Übereinstimmung der SPD-Einträge.

Erfolgreicher Austausch

Wie bei IKE_SA_INIT reichen im Idealfall je eine Request- und Response-Nachricht aus. Danach wurden die Kommunikationspartner auf jeden Fall authentifiziert und die IKE_SA wurde vollständig aufgebaut. Ob die Aushandlung der CHILD_SA erfolgreich war, ist davon abhängig, ob sich die Kommunikationspartner über die Eigenschaften und Traffic Selectors einig wurden.

Nicht erfolgreicher Austausch

Schlägt die Authentifizierung des Initiators fehl oder kann der Responder keine der vorgeschlagene Eigenschaften oder Traffic Selectors akzeptieren, antwortet er mit einer IKE_SA_INIT-Response mit einer (verschlüsselten) Notify Payload. Diese enthält einen spezifischen Fehlercode, auf den der Initiator dann reagieren kann.
Schlägt die Authentifizierung des Responders fehl, bricht der Initiator die Kommunikation ab.

In der nächsten Folge wird die Beschreibung von IKEv2 mit den Meldungstypen CREATE_CHILD_SA und INFORMATIONAL abgeschlossen.

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