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.
N E U ! Security
aktuell
Täglich aktuelle Security-Infos!
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.
| Paket des Initiators | |
| HDR | Header des IKE-Protokolls |
| IDi | Identität des Initiators, z.B. seine IP- oder E-Mail-Adresse |
| CERT |
Optional ein oder mehrere Zertifikate, falls Zertifikate für die
Authentifizierung verwendet werden. Werden Zertifikate mitgeschickt, muss das erste Zertifikat den öffentlichen Schlüssel für die Prüfung des AUTH-Feldes enthalten. |
| CERTREQ | Optionale Anforderung(en) eines Zertifikats, genauer: die Angabe, welchen CAs der Initiator vertraut. |
| IDr | Optionale Angabe darüber, mit welcher Identität des Responders der Initiator kommunizieren möchte. Dies ist z.B. dann notwendig, wenn mehrere Domains (d.h. Identitäten) unter der gleichen IP-Adresse gehostet werden. |
| AUTH | Signatur, entweder mit dem zuvor berechneten Signaturschlüssel oder passend zum öffentlichen Schlüssel des ersten mitgeschickten Zertifikats im CERT-Feld. |
| SAi2 | startet die Aushandlung der CHILD_SA und enthält Angaben über die gewünschten Eigenschaften der SA wie Algorithmen etc. |
| TSi |
Gewünschte Traffic Selectors auf Seiten des Initiators, d.h. die
IP-Adressen bzw. Adressbereiche, Port bzw. Portbereiche und Protokolle
(in Form von IDs), für die die auszuhandelnde SA gelten soll. TSi definiert die Quelladressen, TSr entsprechend die Zieladressen. |
| TSr | Gewünschte Traffic Selectors auf Seiten des Responders |
| Paket des Responders | |
| HDR | Header des IKE-Protokolls |
| IDr | Identität des Responders, z.B. seine IP- oder E-Mail-Adresse |
| CERT |
Ggf. ein oder mehrere Zertifikate, falls Zertifikate für die
Authentifizierung verwendet werden. Werden Zertifikate mitgeschickt, muss das erste Zertifikat den öffentlichen Schlüssel für die Prüfung des AUTH-Feldes enthalten. |
| AUTH | Signatur, entweder mit dem zuvor berechneten Signaturschlüssel oder passend zum öffentlichen Schlüssel des ersten mitgeschickten Zertifikats im CERT-Feld. |
| SAr2 | Vom Responder aus den Vorschlägen des Initiators ausgewählte Eigenschaften für die SA |
| TSi | Aus den Vorschlägen des Initiators ausgewählte Traffic Selectors auf Seiten des Initiators |
| TSr | Aus den Vorschlägen des Initiators ausgewählte Traffic Selectors auf Seiten des Responders |
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.
Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!
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
Kommentare