Mittwoch, 6. Juni 2012


Topthema

Donnerstag, 8. Februar 2007 | Topthema

About Security #92: Virtuelle Private Netze — IKEv2 (2)

(Link zum Artikel: http://www.entwickler.de/php/kolumnen/034202)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

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.

About Security: Die komplette Serie

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!

Carsten Eilers

About Security � �bersicht zum aktuellen Thema "VPN � Virtuelle Private Netze"

Kommentare

Folgende Links könnten Sie auch interessieren