Zum Hauptinhalt springen

1.2. The Initial Exchanges (Die ersten Austausche)

1.2 The Initial Exchanges (Die ersten Austausche)​

IKE-Kommunikation beginnt immer mit IKE_SA_INIT und IKE_AUTH (in IKEv1 Phase 1). Diese initialen Austausche haben meist vier Nachrichten, können aber wachsen. Alles ist Anfrage/Antwort. Zuerst der Basisaustausch, dann Varianten. Das erste Paar (IKE_SA_INIT) handelt Algorithmen aus, tauscht Nonces und führt Diffie-Hellman [DH] aus.

Das zweite Paar (IKE_AUTH) authentifiziert die vorherigen Nachrichten, tauscht Identitäten und Zertifikate und richtet die erste Child SA ein. Teile sind mit Schlüsseln aus IKE_SA_INIT verschlüsselt und integritätsgeschützt; Identitäten sind vor Mithörern verborgen; alle Felder authentifiziert. Schlüsselerzeugung: Abschnitt 2.14. (Ein Man-in-the-Middle ohne abgeschlossenes IKE_AUTH sieht dennoch die Identität des Initiators.)

Alle Nachrichten nach dem initialen Austausch sind kryptografisch mit den in IKE_SA_INIT vereinbarten Algorithmen und Schlüsseln geschützt. Syntax der Encrypted-Payload (Abschnitt 3.14), Schlüsselableitung Abschnitt 2.14. Alle folgenden Nachrichten enthalten Encrypted, auch wenn im Text „leer“. Bei CREATE_CHILD_SA, IKE_AUTH oder INFORMATIONAL ist der Nachrichtenkörper nach dem Header verschlüsselt; die gesamte Nachricht inklusive Header integritätsgeschützt mit den für die IKE SA vereinbarten Algorithmen.

Jede IKE-Nachricht enthält eine Message ID im festen Header zur Zuordnung und Retransmissionserkennung.

Die Nutzlasten werden wie folgt benannt.

NotationPayload
AUTHAuthentication
CERTCertificate
CERTREQCertificate Request
CPConfiguration
DDelete
EAPExtensible Authentication
HDRIKE header (not a payload)
IDiIdentification - Initiator
IDrIdentification - Responder
KEKey Exchange
Ni, NrNonce
NNotify
SASecurity Association
SKEncrypted and Authenticated
TSiTraffic Selector - Initiator
TSrTraffic Selector - Responder
VVendor ID

Inhalt der Payloads: Abschnitt 3. Optionale Payloads in eckigen Klammern, z. B. [CERTREQ].

Initiale Austausche:

Initiator                         Responder
-------------------------------------------------------------------
HDR, SAi1, KEi, Ni  -->

HDR enthält SPIs, Versionsnummern, Exchange Type, Message ID und Flags. SAi1 listet Algorithmen des Initiators für die IKE SA. KE sendet den Diffie-Hellman-Wert des Initiators. Ni ist die Nonce des Initiators.

                               <--  HDR, SAr1, KEr, Nr, [CERTREQ]

Der Responder wählt eine Suite, drückt sie in SAr1 aus, beendet DH mit KEr und sendet Nr in Nr.

Jetzt kann jede Seite SKEYSEED erzeugen (Abschnitt 2.14), woraus alle Schlüssel der IKE SA folgen. Folgende Nachrichten sind bis auf Header vollständig verschlüsselt und integritätsgeschützt. Schlüssel aus SKEYSEED: SK_e und SK_a (Abschnitte 2.13, 2.14). Pro Richtung eigene SK_e/SK_a. Zusätzlich SK_d für weiteres Schlüsselmaterial der Child SAs. Die Notation SK { ... } bedeutet Verschlüsselung und Integrität mit SK_e und SK_a dieser Richtung.

HDR, SK {IDi, [CERT,] [CERTREQ,]
    [IDr,] AUTH, SAi2,
    TSi, TSr}  -->

Der Initiator behauptet IDi, beweist das Geheimnis und schützt die erste Nachricht mit AUTH (Abschnitt 2.15). Optional CERT und CERTREQ. Enthält CERT, MUSS das erste Zertifikat den öffentlichen Schlüssel für AUTH enthalten.

Optionales IDr wählt die Identität des Responders bei mehreren Identitäten auf einer IP. Unakzeptables IDr kann der Responder anders wählen; der Initiator kann die SA schließen, wenn er das nicht akzeptiert.

Traffic Selectors TSi/TSr: Abschnitt 2.9.

SAi2 startet Child-SA-Verhandlung; Felder ab SAi2 siehe CREATE_CHILD_SA.

                               <--  HDR, SK {IDr, [CERT,] AUTH,
                                        SAr2, TSi, TSr}

Der Responder behauptet IDr, sendet optional Zertifikate (AUTH-Schlüssel zuerst), authentifiziert mit AUTH und schließt die Child SA wie bei CREATE_CHILD_SA ab. Beide Parteien MÜSSEN Signaturen und MACs prüfen. Bei Shared Secret MÜSSEN ID-Namen zum AUTH-Schlüssel passen.

Der Initiator muss die DH-Gruppe raten. Bei Fehler antwortet der Responder mit INVALID_KE_PAYLOAD. Der Initiator MUSS IKE_SA_INIT mit korrigierter Gruppe wiederholen und MUSS wieder alle akzeptablen Suites vorschlagen, da die Ablehnung unauthentifiziert war.

Scheitert die Child SA in IKE_AUTH, entsteht die IKE SA dennoch. Notify-Typen, die das nicht verhindern, u. a. NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, FAILED_CP_REQUIRED.

Scheitert die IKE SA (z. B. AUTHENTICATION_FAILED), wird keine IKE SA erzeugt. Trotz Verschlüsselung: Notify vor vollständiger Authentifizierung vorsichtig behandeln; bei gültigem MAC ist der Sender der IKE_SA_INIT-Responder, die Identität aber nicht garantiert.

IKE_AUTH enthält keine KEi/KEr oder Ni/Nr. SA-Payloads dürfen Transform Type 4 nicht außer NONE setzen. Implementierungen SOLLTEN die Transform-Substruktur weglassen statt NONE zu senden.

Letztes Update am