IKEv2 ausführlich

Aus xinux.net
Zur Navigation springen Zur Suche springen


IKEv2 Header

SPI des Initiators (8 Oktette)

  • Ein vom Initiator gewählter Wert
  • Identifiziert eine eindeutige IKE-Sicherheitszuordnung.
  • Dieser Wert darf NICHT Null sein.

SPI des Responders (8 Oktette)

  • Ein vom Responder gewählter Wert
  • Identifiziert eine eindeutige IKE-Sicherheitszuordnung.
  • Dieser Wert MUSS Null in der ersten Nachricht eines anfänglichen IKE-Austausch sein.

Nächste Nutzlast (1 Oktett)

  • Zeigt die Art der Nutzlast an, die folgt direkt auf die Überschrift.
  • Das Format und der Wert von jedem Nutzlast sind unten definiert.

Hauptversion (4 Bits)

  • Zeigt die Hauptversion des IKE an Protokoll im Einsatz.
  • Implementierungen, die auf dieser Version von IKE basieren MUSS die Hauptversion auf 2 setzen.
  • Implementierungen basieren auf Frühere Versionen von IKE und ISAKMP MÜSSEN die Hauptversion auf 1 setzen
  • Implementierungen auf Basis dieser Version von IKE MÜSSEN bzw. ablehnen
  • Ignoriert Nachrichten mit einer Versionsnummer größer als 2 mit einem INVALID_MAJOR_VERSION-Benachrichtigungsmeldung

Nebenversion (4 Bits)

  • Zeigt die Nebenversion des IKE an Protokoll im Einsatz.
  • Implementierungen, die auf dieser Version von IKE basieren MUSS die Nebenversion auf 0 setzen.
  • Sie MÜSSEN die Nebenversion ignorieren Versionsnummer der empfangenen Nachrichten.

Austauschtyp (1 Oktett)

  • Zeigt den Typ des Austauschs an, der genutzt wird.
  • Dies schränkt die Nutzlasten ein, die in jeder Nachricht in einer gesendet werden können.
  • Die Werte in der folgenden Tabelle sind von RFC 4306.
  • Andere Werte könnten seitdem hinzugefügt worden sein.
  • Leser sollten sich auf [IKEV2IANA] beziehen, um die neuesten Informationen über diese Werte zu erhalten.
  • Austauschtypwert
    • IKE_SA_INIT 34
    • IKE_AUTH 35
    • CREATE_CHILD_SA 36
    • INFORMATION 37

Flags (1 Oktett)

  • Zeigt bestimmte Optionen an, die für eingestellt sind Nachricht.
  • Das Vorhandensein von Optionen wird durch das entsprechende Bit angezeigt

im Flags-Feld gesetzt. Die Bits sind wie folgt: 

       +-+-+-+-+-+-+-+-+
       |X|X|R|V|I|X|X|X|
       +-+-+-+-+-+-+-+-+
  • In der folgenden Beschreibung bedeutet ein Bit, das "gesetzt" ist, dass sein Wert "1" ist, während "gelöscht" bedeutet, dass sein Wert "0" ist.
  • 'X'-Bits MÜSSEN gelöscht werden beim Senden und MÜSSEN beim Empfang ignoriert werden.
     * R (Antwort) – Dieses Bit zeigt an, dass diese Nachricht a ist
        Antwort auf eine Nachricht mit derselben Nachrichten-ID. Dieses bisschen
        MUSS in allen Anforderungsnachrichten gelöscht und MUSS in allen gesetzt werden
        Antworten. Ein IKE-Endpunkt DARF KEINE Antwort auf a generieren
        Nachricht, die als Antwort markiert ist (mit einer Ausnahme;
        siehe Abschnitt 2.21.2).

     * V (Version) – Dieses Bit zeigt an, dass der Sender ist
        in der Lage, eine höhere Hauptversionsnummer der zu sprechen
        Protokoll als das in der Hauptversionsnummer angegebene
        aufstellen. Implementierungen von IKEv2 MÜSSEN dieses Bit löschen, wenn
        Senden und MUSS es in eingehenden Nachrichten ignorieren.

     * I (Initiator) - Dieses Bit MUSS in Nachrichten gesetzt werden, die von gesendet werden
        ursprünglicher Initiator der IKE SA und MUSS eingeräumt werden
        Nachrichten, die vom ursprünglichen Responder gesendet wurden. Es wird von der verwendet
        Empfänger, um festzustellen, welche acht Oktetts der SPI waren
        vom Empfänger generiert. Dieses Bit ändert sich, um widerzuspiegeln, wer
        hat die letzte Schlüsselerneuerung der IKE SA initiiert.


Nachrichten-ID (4 Oktette, Ganzzahl ohne Vorzeichen)

  • Verwendete Nachrichtenkennung um die erneute Übertragung verlorener Pakete und den Abgleich von Anforderungen zu steuern und Antworten.
  • Es ist wesentlich für die Sicherheit des Protokolls, weil es verwendet wird, um Nachrichtenwiedergabeangriffe zu verhindern.

Länge (4 Oktette, Ganzzahl ohne Vorzeichen)

  • Länge der gesamten Nachricht (Header + Payloads) in Oktetts.

IKEv2 Verbindungsaufbau

Austausch

IKEv2 verfügt im Prinzip nur über zwei anfängliche Verhandlungsphasen

  • IKE_SA_INIT-Exchange
  • IKE_AUTH-Exchange

IKE_SA_INIT-Exchange

  • IKE_SA_INIT ist der erste Austausch, bei dem die Peers einen sicheren Kanal einrichten.
  • Nach Abschluss des ersten Austauschs werden alle weiteren Austauschvorgänge verschlüsselt.
  • Der Datenaustausch enthält nur zwei Pakete, da er alle Informationen enthält, die normalerweise in MM1-4 in IKEv1 ausgetauscht werden.
  • Das Ergebnis ist, dass der Responder das IKE_SA_INIT-Paket rechnerisch verarbeiten muss und das erste Paket verarbeiten kann.
  • Es lässt das Protokoll einem DOS-Angriff von gefälschten Adressen offen.
  • Zum Schutz vor solchen Angriffen verfügt IKEv2 über einen optionalen Austausch innerhalb von IKE_SA_INIT, um Spoofing-Angriffe zu verhindern.
  • Wenn ein bestimmter Grenzwert für unvollständige Sitzungen erreicht wird, verarbeitet der Responder das Paket nicht weiter
  • Sondern sendet stattdessen eine Antwort mit einem Cookie an den Initiator.
  • Damit die Sitzung fortgesetzt werden kann, muss der Initiator das IKE_SA_INIT-Paket erneut senden und das von ihm empfangene Cookie einfügen.
  • Der Initiator sendet das ursprüngliche Paket zusammen mit der Benachrichtigungs-Payload vom Responder erneut, um zu belegen, dass der ursprüngliche Austausch nicht gesaugt wurde.
  • Im folgenden Diagramm wird der Austausch IKE_SA_INIT mit Cookie-Herausforderung dargestellt:

understanding-ikev2-packet-exch-debug-02.gif

IKE_AUTH-Exchange

  • Nach Abschluss des IKE_SA_INIT-Austauschs wird die IKEv2 SA verschlüsselt.
  • Der Remote-Peer wurde jedoch nicht authentifiziert.
  • Der IKE_AUTH-Austausch dient zur Authentifizierung des Remote-Peers und zur Erstellung der ersten IPsec-SA.
  • Der Austausch enthält die ISAKMP-ID (Internet Security Association and Key Management Protocol) sowie eine Authentifizierungs-Payload.
  • Der Inhalt der Authentifizierungs-Payload hängt von der Authentifizierungsmethode ab
  • Pre-Shared Key (PSK), RSA-Zertifikate (RSA-SIG), Elliptic Curve Digital Signature Algorithm Certificates (ECDSA-SIG) oder EAP sein kann.
  • Zusätzlich zu den Authentifizierungs-Payloads enthält der Austausch die SA- und Traffic Selector-Payloads, die die zu erstellende IPsec SA beschreiben.
Spätere IKEv2-Austausche

REATE_CHILD_SA Exchange

  • Wenn zusätzliche untergeordnete SAs erforderlich sind oder wenn die IKE SA oder eine der untergeordneten SAs neu codiert werden muss
    • erfüllt sie dieselbe Funktion wie der Quick-Mode-Austausch in IKEv1.
  • Wie in diesem Diagramm gezeigt, befinden sich in diesem Austausch nur zwei Pakete.
  • Der Austausch wiederholt sich jedoch für jeden Schlüssel oder jede neue SA:

understanding-ikev2-packet-exch-debug-03.gif

Informationsaustausch

  • Wie bei allen IKEv2-Austauschen erwartet jede Anforderung des Informationsaustauschs eine Antwort.
  • Drei Arten von Payloads können in einem INFORMATIONALEN Austausch enthalten sein.
  • Es können beliebig viele verschiedene Kombinationen von Payloads enthalten werden, wie im folgenden Diagramm gezeigt:

understanding-ikev2-packet-exch-debug-04.gif


IKEv2 Header

SPI des Initiators (8 Oktette)

  • Ein vom Initiator gewählter Wert
  • Identifiziert eine eindeutige IKE-Sicherheitszuordnung.
  • Dieser Wert darf NICHT Null sein.

SPI des Responders (8 Oktette)

  • Ein vom Responder gewählter Wert
  • Identifiziert eine eindeutige IKE-Sicherheitszuordnung.
  • Dieser Wert MUSS Null in der ersten Nachricht eines anfänglichen IKE-Austausch sein.

Nächste Nutzlast (1 Oktett)

  • Zeigt die Art der Nutzlast an, die folgt direkt auf die Überschrift.
  • Das Format und der Wert von jedem Nutzlast sind unten definiert.

Hauptversion (4 Bits)

  • Zeigt die Hauptversion des IKE an Protokoll im Einsatz.
  • Implementierungen, die auf dieser Version von IKE basieren MUSS die Hauptversion auf 2 setzen.
  • Implementierungen basieren auf Frühere Versionen von IKE und ISAKMP MÜSSEN die Hauptversion auf 1 setzen
  • Implementierungen auf Basis dieser Version von IKE MÜSSEN bzw. ablehnen
  • Ignoriert Nachrichten mit einer Versionsnummer größer als 2 mit einem INVALID_MAJOR_VERSION-Benachrichtigungsmeldung

Nebenversion (4 Bits)

  • Zeigt die Nebenversion des IKE an Protokoll im Einsatz.
  • Implementierungen, die auf dieser Version von IKE basieren MUSS die Nebenversion auf 0 setzen.
  • Sie MÜSSEN die Nebenversion ignorieren Versionsnummer der empfangenen Nachrichten.

Austauschtyp (1 Oktett)

  • Zeigt den Typ des Austauschs an, der genutzt wird.
  • Dies schränkt die Nutzlasten ein, die in jeder Nachricht in einer gesendet werden können.
  • Die Werte in der folgenden Tabelle sind von RFC 4306.
  • Andere Werte könnten seitdem hinzugefügt worden sein.
  • Leser sollten sich auf [IKEV2IANA] beziehen, um die neuesten Informationen über diese Werte zu erhalten.
  • Austauschtypwert
    • IKE_SA_INIT 34
    • IKE_AUTH 35
    • CREATE_CHILD_SA 36
    • INFORMATION 37

Flags (1 Oktett)

  • Zeigt bestimmte Optionen an, die für eingestellt sind Nachricht.
  • Das Vorhandensein von Optionen wird durch das entsprechende Bit angezeigt

im Flags-Feld gesetzt. Die Bits sind wie folgt: 

       +-+-+-+-+-+-+-+-+
       |X|X|R|V|I|X|X|X|
       +-+-+-+-+-+-+-+-+
  • In der folgenden Beschreibung bedeutet ein Bit, das "gesetzt" ist, dass sein Wert "1" ist, während "gelöscht" bedeutet, dass sein Wert "0" ist.
  • 'X'-Bits MÜSSEN gelöscht werden beim Senden und MÜSSEN beim Empfang ignoriert werden.
     * R (Antwort) – Dieses Bit zeigt an, dass diese Nachricht a ist
        Antwort auf eine Nachricht mit derselben Nachrichten-ID. Dieses bisschen
        MUSS in allen Anforderungsnachrichten gelöscht und MUSS in allen gesetzt werden
        Antworten. Ein IKE-Endpunkt DARF KEINE Antwort auf a generieren
        Nachricht, die als Antwort markiert ist (mit einer Ausnahme;
        siehe Abschnitt 2.21.2).

     * V (Version) – Dieses Bit zeigt an, dass der Sender ist
        in der Lage, eine höhere Hauptversionsnummer der zu sprechen
        Protokoll als das in der Hauptversionsnummer angegebene
        aufstellen. Implementierungen von IKEv2 MÜSSEN dieses Bit löschen, wenn
        Senden und MUSS es in eingehenden Nachrichten ignorieren.

     * I (Initiator) - Dieses Bit MUSS in Nachrichten gesetzt werden, die von gesendet werden
        ursprünglicher Initiator der IKE SA und MUSS eingeräumt werden
        Nachrichten, die vom ursprünglichen Responder gesendet wurden. Es wird von der verwendet
        Empfänger, um festzustellen, welche acht Oktetts der SPI waren
        vom Empfänger generiert. Dieses Bit ändert sich, um widerzuspiegeln, wer
        hat die letzte Schlüsselerneuerung der IKE SA initiiert.


Nachrichten-ID (4 Oktette, Ganzzahl ohne Vorzeichen)

  • Verwendete Nachrichtenkennung um die erneute Übertragung verlorener Pakete und den Abgleich von Anforderungen zu steuern und Antworten.
  • Es ist wesentlich für die Sicherheit des Protokolls, weil es verwendet wird, um Nachrichtenwiedergabeangriffe zu verhindern.

Länge (4 Oktette, Ganzzahl ohne Vorzeichen)

  • Länge der gesamten Nachricht (Header + Payloads) in Oktetts.

IKEv2 Verbindungsaufbau

Prinzip

Austausch

IKEv2 verfügt im Prinzip nur über zwei anfängliche Verhandlungsphasen

  • IKE_SA_INIT-Exchange
  • IKE_AUTH-Exchange

IKE_SA_INIT-Exchange

  • IKE_SA_INIT ist der erste Austausch, bei dem die Peers einen sicheren Kanal einrichten.
  • Nach Abschluss des ersten Austauschs werden alle weiteren Austauschvorgänge verschlüsselt.
  • Der Datenaustausch enthält nur zwei Pakete, da er alle Informationen enthält, die normalerweise in MM1-4 in IKEv1 ausgetauscht werden.
  • Das Ergebnis ist, dass der Responder das IKE_SA_INIT-Paket rechnerisch verarbeiten muss und das erste Paket verarbeiten kann.
  • Es lässt das Protokoll einem DOS-Angriff von gefälschten Adressen offen.
  • Zum Schutz vor solchen Angriffen verfügt IKEv2 über einen optionalen Austausch innerhalb von IKE_SA_INIT, um Spoofing-Angriffe zu verhindern.
  • Wenn ein bestimmter Grenzwert für unvollständige Sitzungen erreicht wird, verarbeitet der Responder das Paket nicht weiter
  • Sondern sendet stattdessen eine Antwort mit einem Cookie an den Initiator.
  • Damit die Sitzung fortgesetzt werden kann, muss der Initiator das IKE_SA_INIT-Paket erneut senden und das von ihm empfangene Cookie einfügen.
  • Der Initiator sendet das ursprüngliche Paket zusammen mit der Benachrichtigungs-Payload vom Responder erneut, um zu belegen, dass der ursprüngliche Austausch nicht gesaugt wurde.
  • Im folgenden Diagramm wird der Austausch IKE_SA_INIT mit Cookie-Herausforderung dargestellt:

understanding-ikev2-packet-exch-debug-02.gif

IKE_AUTH-Exchange

  • Nach Abschluss des IKE_SA_INIT-Austauschs wird die IKEv2 SA verschlüsselt.
  • Der Remote-Peer wurde jedoch nicht authentifiziert.
  • Der IKE_AUTH-Austausch dient zur Authentifizierung des Remote-Peers und zur Erstellung der ersten IPsec-SA.
  • Der Austausch enthält die ISAKMP-ID (Internet Security Association and Key Management Protocol) sowie eine Authentifizierungs-Payload.
  • Der Inhalt der Authentifizierungs-Payload hängt von der Authentifizierungsmethode ab
  • Pre-Shared Key (PSK), RSA-Zertifikate (RSA-SIG), Elliptic Curve Digital Signature Algorithm Certificates (ECDSA-SIG) oder EAP sein kann.
  • Zusätzlich zu den Authentifizierungs-Payloads enthält der Austausch die SA- und Traffic Selector-Payloads, die die zu erstellende IPsec SA beschreiben.
Spätere IKEv2-Austausche

REATE_CHILD_SA Exchange

  • Wenn zusätzliche untergeordnete SAs erforderlich sind oder wenn die IKE SA oder eine der untergeordneten SAs neu codiert werden muss
    • erfüllt sie dieselbe Funktion wie der Quick-Mode-Austausch in IKEv1.
  • Wie in diesem Diagramm gezeigt, befinden sich in diesem Austausch nur zwei Pakete.
  • Der Austausch wiederholt sich jedoch für jeden Schlüssel oder jede neue SA:

understanding-ikev2-packet-exch-debug-03.gif

Informationsaustausch

  • Wie bei allen IKEv2-Austauschen erwartet jede Anforderung des Informationsaustauschs eine Antwort.
  • Drei Arten von Payloads können in einem INFORMATIONALEN Austausch enthalten sein.
  • Es können beliebig viele verschiedene Kombinationen von Payloads enthalten werden, wie im folgenden Diagramm gezeigt:

understanding-ikev2-packet-exch-debug-04.gif

  • Die Notify Payload (N) wurde bereits in Verbindung mit Cookies erkannt.
  • Es gibt auch mehrere andere Typen. Sie enthalten Fehler- und Statusinformationen wie in IKEv1.
  • Die Delete Payload (D) informiert den Peer, dass der Absender eine oder mehrere seiner eingehenden SAs gelöscht hat.
  • Der Responder muss diese SAs löschen und normalerweise die Payloads löschen, die für die SAs in der anderen Richtung in der Antwortnachricht übereinstimmen.
  • Die Configuration Payload (CP) dient zur Aushandlung von Konfigurationsdaten zwischen den Peers.
  • Ein wichtiger Zweck des CP besteht darin, eine Adresse in einem Netzwerk anzufordern (anzufordern) und zuzuweisen (zu antworten), das durch ein Sicherheits-Gateway geschützt ist.
  • In der Regel richtet ein mobiler Host ein Virtual Private Network (VPN) mit einem Sicherheits-Gateway im Heimnetzwerk ein und fordert, dass ihm eine IP-Adresse im Heimnetzwerk zugewiesen wird.


Links

  • Die Notify Payload (N) wurde bereits in Verbindung mit Cookies erkannt.
  • Es gibt auch mehrere andere Typen. Sie enthalten Fehler- und Statusinformationen wie in IKEv1.
  • Die Delete Payload (D) informiert den Peer, dass der Absender eine oder mehrere seiner eingehenden SAs gelöscht hat.
  • Der Responder muss diese SAs löschen und normalerweise die Payloads löschen, die für die SAs in der anderen Richtung in der Antwortnachricht übereinstimmen.
  • Die Configuration Payload (CP) dient zur Aushandlung von Konfigurationsdaten zwischen den Peers.
  • Ein wichtiger Zweck des CP besteht darin, eine Adresse in einem Netzwerk anzufordern (anzufordern) und zuzuweisen (zu antworten), das durch ein Sicherheits-Gateway geschützt ist.
  • In der Regel richtet ein mobiler Host ein Virtual Private Network (VPN) mit einem Sicherheits-Gateway im Heimnetzwerk ein und fordert, dass ihm eine IP-Adresse im Heimnetzwerk zugewiesen wird.


Links

Abgerufen von „https://xinux.net/index.php?title=IKEv2_ausführlich&oldid=38691“