Thomas.will: /* IKEv2 Verbindungsaufbau */

2022-12-06T12:15:40Z

IKEv2 Verbindungsaufbau

Thomas.will: Die Seite wurde neu angelegt: „ =IKEv2 Header= {{#drawio:ikev2-2}} =SPI des Initiators (8 Oktette)= Ein vom Initiator gewählter Wert Identifiziert eine eindeutige IKE-Sicherheitszuordnu…“

2022-12-06T12:15:14Z

Die Seite wurde neu angelegt: „ =IKEv2 Header= {{#drawio:ikev2-2}} =SPI des Initiators (8 Oktette)= *Ein vom Initiator gewählter Wert *Identifiziert eine eindeutige IKE-Sicherheitszuordnu…“

Neue Seite

=IKEv2 Header=
{{#drawio:ikev2-2}}
=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==
{{#drawio:ikev2--prinzip}}
==Austausch==
{{#drawio:ikev2-1}}

=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=
{{#drawio:ikev2-2}}
=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==
{{#drawio:ikev2--prinzip}}
==Austausch==
{{#drawio:ikev2-1}}

=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=
*https://www.heise.de/hintergrund/Einfacher-VPN-Tunnelbau-dank-IKEv2-270056.html
*https://www.cisco.com/c/de_de/support/docs/security-vpn/ipsec-negotiation-ike-protocols/115936-understanding-ikev2-packet-exch-debug.html

*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=
*https://www.heise.de/hintergrund/Einfacher-VPN-Tunnelbau-dank-IKEv2-270056.html
*https://www.cisco.com/c/de_de/support/docs/security-vpn/ipsec-negotiation-ike-protocols/115936-understanding-ikev2-packet-exch-debug.html

@@ Zeile 80: / Zeile 80: @@
 =IKEv2 Verbindungsaufbau=
 ==Austausch==
 {{#drawio:ikev2-1}}

IKEv2 ausführlich - Versionsgeschichte

Thomas.will: /* IKEv2 Verbindungsaufbau */

Thomas.will: Die Seite wurde neu angelegt: „ =IKEv2 Header= {{#drawio:ikev2-2}} =SPI des Initiators (8 Oktette)= *Ein vom Initiator gewählter Wert *Identifiziert eine eindeutige IKE-Sicherheitszuordnu…“

Thomas.will: Die Seite wurde neu angelegt: „ =IKEv2 Header= {{#drawio:ikev2-2}} =SPI des Initiators (8 Oktette)= Ein vom Initiator gewählter Wert Identifiziert eine eindeutige IKE-Sicherheitszuordnu…“