2.15. Authentifizierung der IKE SA

Wenn keine erweiterbare Authentifizierung verwendet wird (siehe Abschnitt 2.16), werden die Peers authentifiziert, indem jede Seite einen Datenblock signiert (oder einen MAC unter Verwendung eines aufgefüllten gemeinsamen Schlüssels als Schlüssel berechnet, wie später in diesem Abschnitt beschrieben). In diesen Berechnungen sind IDi' und IDr' die gesamten ID-Payloads ohne den festen Header. Für den Responder beginnen die zu signierenden Oktette mit dem ersten Oktett des ersten SPI im Header der zweiten Nachricht (IKE_SA_INIT-Antwort) und enden mit dem letzten Oktett des letzten Payloads der zweiten Nachricht. Hieran angehängt (für die Berechnung der Signatur) sind der Nonce Ni des Initiators (nur der Wert, nicht der ihn enthaltende Payload) und der Wert prf(SK_pr, IDr'). Beachten Sie, dass weder der Nonce Ni noch der Wert prf(SK_pr, IDr') übertragen werden. Ebenso signiert der Initiator die erste Nachricht (IKE_SA_INIT-Anfrage), beginnend mit dem ersten Oktett des ersten SPI im Header und endend mit dem letzten Oktett des letzten Payloads. Hieran angehängt (für die Berechnung der Signatur) sind der Nonce Nr des Responders und der Wert prf(SK_pi, IDi'). Es ist für die Sicherheit des Austauschs entscheidend, dass jede Seite den Nonce der Gegenseite signiert.

Die vom Initiator signierten Oktette lassen sich wie folgt beschreiben:

Die vom Responder signierten Oktette lassen sich wie folgt beschreiben:

Beachten Sie, dass alle Payloads unter der Signatur eingeschlossen sind, einschließlich aller in diesem Dokument nicht definierten Payload-Typen. Wird die erste Nachricht des Austauschs mehrmals gesendet (etwa mit einem Responder-Cookie und/oder einer anderen Diffie-Hellman-Gruppe), so ist die letzte Version der Nachricht die signierte.

Optional können die Nachrichten 3 und 4 ein Zertifikat oder eine Zertifikatskette enthalten (MAY), die den Beweis erbringt, dass der zur Berechnung einer digitalen Signatur verwendete Schlüssel zum Namen im ID-Payload gehört. Die Signatur oder der MAC wird unter Verwendung der durch den vom Signierenden verwendeten Schlüsseltyp vorgegebenen und im Authentifizierungs-Payload durch das Auth-Method-Feld angegebenen Algorithmen berechnet. Es wird nicht verlangt (REQUIRED), dass Initiator und Responder mit denselben kryptographischen Algorithmen signieren. Die Wahl der kryptographischen Algorithmen hängt vom Typ des jeweils vorhandenen Schlüssels ab. Insbesondere kann der Initiator einen gemeinsamen Schlüssel verwenden, während der Responder einen öffentlichen Signaturschlüssel und ein Zertifikat besitzt. Es ist üblich (aber nicht erforderlich), dass bei Verwendung eines gemeinsamen Schlüssels für die Authentifizierung derselbe Schlüssel in beiden Richtungen genutzt wird.

Beachten Sie, dass es eine verbreitete, aber typischerweise unsichere Praxis ist, einen gemeinsamen Schlüssel zu verwenden, der ausschließlich aus einem vom Benutzer gewählten Passwort abgeleitet ist, ohne eine andere Quelle von Zufälligkeit einzubeziehen. Dies ist typischerweise unsicher, weil vom Benutzer gewählte Passwörter voraussichtlich nicht über genügend Unvorhersehbarkeit verfügen, um Wörterbuchangriffen zu widerstehen, und diese Angriffe bei dieser Authentifizierungsmethode nicht verhindert werden. (Anwendungen, die passwortbasierte Authentifizierung für Bootstrapping und IKE-SA verwenden, sollten die Authentifizierungsmethode in Abschnitt 2.16 verwenden, die darauf ausgelegt ist, Offline-Wörterbuchangriffe zu verhindern.) Der vorab geteilte Schlüssel muss ebenso viel Unvorhersehbarkeit enthalten wie der stärkste ausgehandelte Schlüssel. Im Fall eines vorab geteilten Schlüssels wird der AUTH-Wert wie folgt berechnet:

Für den Initiator: AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), ) Für den Responder: AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), )

wobei die Zeichenkette "Key Pad for IKEv2" 17 ASCII-Zeichen ohne Null-Terminierung ist. Der gemeinsame Schlüssel kann variabel lang sein. Die Pad-Zeichenkette wird hinzugefügt, damit, falls der gemeinsame Schlüssel aus einem Passwort abgeleitet ist, die IKE-Implementierung das Passwort nicht im Klartext speichern muss, sondern stattdessen den Wert prf(Shared Secret,"Key Pad for IKEv2") speichern kann, der nicht als passwortäquivalent für andere Protokolle als IKEv2 verwendet werden könnte. Wie oben bemerkt, ist die Ableitung des gemeinsamen Schlüssels aus einem Passwort unsicher. Diese Konstruktion wird verwendet, weil erwartet wird, dass Menschen sie ohnehin tun werden. Die Verwaltungsschnittstelle, über die der gemeinsame Schlüssel bereitgestellt wird, MUSS ASCII-Zeichenketten von mindestens 64 Oktetten akzeptieren und DARF vor deren Verwendung als gemeinsame Schlüssel kein Null-Terminierung hinzufügen. Sie MUSS ebenfalls eine hexadezimale Kodierung des gemeinsamen Schlüssels akzeptieren. Die Verwaltungsschnittstelle KANN andere Kodierungen akzeptieren, sofern der Algorithmus zur Übersetzung der Kodierung in eine Binärzeichenkette angegeben ist.

Es gibt zwei Arten von EAP-Authentifizierung (in Abschnitt 2.16 beschrieben), und jede Art verwendet unterschiedliche Werte in den oben gezeigten AUTH-Berechnungen. Wenn die EAP-Methode schlüsselerzeugend ist, ersetzen Sie den Master Session Key (MSK) durch den gemeinsamen Schlüssel in der Berechnung. Für nicht schlüsselerzeugende Methoden ersetzen Sie in den beiden AUTH-Berechnungen jeweils den gemeinsamen Schlüssel durch SK_pi bzw. SK_pr.

2.15. Authentifizierung der IKE SA​

2.15. Authentifizierung der IKE SA