2.15. Authentication of the IKE SA (Authentisierung der IKE SA)

2.15. Authentication of the IKE SA (Authentisierung der IKE SA)

Ohne erweiterbare Authentisierung (Abschnitt 2.16) authentifizieren sich die Peers durch Signatur (oder MAC mit aufgepolstertem Shared Secret als Schlüssel, siehe unten) über einen Datenblock. IDi' und IDr' sind die vollständigen ID-Nutzlasten ohne festen Header. Beim 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 der letzten Nutzlast. Für die Signatur werden angehängt: die Nonce Ni des Initiators (nur der Wert) und prf(SK_pr, IDr'). Weder Ni noch prf(SK_pr, IDr') werden übertragen. Der Initiator signiert die erste Nachricht (IKE_SA_INIT-Anfrage) vom ersten SPI-Oktett bis zum letzten Nutzlast-Oktett und hängt Nr und prf(SK_pi, IDi') an. Für die Sicherheit MUSS jede Seite die Nonce der anderen signieren.

InitiatorSignedOctets:

InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR =  SPIi | SPIr |  . . . | Length
RealMessage1 = RealIKEHDR | RestOfMessage1
NonceRPayload = PayloadHeader | NonceRData
InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload
RestOfInitIDPayload = IDType | RESERVED | InitIDData
MACedIDForI = prf(SK_pi, RestOfInitIDPayload)

ResponderSignedOctets:

ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR =  SPIi | SPIr |  . . . | Length
RealMessage2 = RealIKEHDR | RestOfMessage2
NonceIPayload = PayloadHeader | NonceIData
ResponderIDPayload = PayloadHeader | RestOfRespIDPayload
RestOfRespIDPayload = IDType | RESERVED | RespIDData
MACedIDForR = prf(SK_pr, RestOfRespIDPayload)

Alle Nutzlasten einschließlich nicht in diesem Dokument definierter Typen fallen unter die Signatur. Wird die erste Nachricht mehrfach gesendet (Cookie, andere DH-Gruppe), gilt die letzte Version für die Signatur.

Optional DÜRFEN Nachrichten 3 und 4 ein Zertifikat oder eine Kette enthalten, die belegt, dass der Signaturschlüssel zum Namen in der ID-Nutzlast gehört. Signatur oder MAC verwenden die vom Schlüsseltyp des Signierenden vorgegebenen Algorithmen und das Auth-Method-Feld der Authentication-Nutzlast. Es ist nicht erforderlich, dass Initiator und Responder dieselben kryptografischen Algorithmen verwenden. Die Wahl hängt vom jeweiligen Schlüsseltyp ab; der Initiator kann ein Shared Secret nutzen, der Responder einen öffentlichen Signaturschlüssel und ein Zertifikat. Bei Shared-Secret-Authentisierung ist es oft (nicht erforderlich), denselben Schlüssel in beide Richtungen zu verwenden.

Häufig, aber typischerweise unsicher, ist ein Shared Secret nur aus einem nutzergewählten Passwort ohne weitere Zufälligkeit. Nutzerpasswörter haben selten genug Unvorhersehbarkeit gegen Wörterbuchangriffe; diese Methode verhindert solche Angriffe nicht. (Anwendungen mit passwortbasierter Authentisierung zum Bootstrap der IKE SA sollten die Methode aus Abschnitt 2.16 verwenden, die Offline-Wörterbuchangriffe erschwert.) Das PSK muss so viel Unvorhersehbarkeit enthalten wie der stärkste ausgehandelte Schlüssel. Bei PSK wird AUTH berechnet als:

Initiator:

AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
                 <InitiatorSignedOctets>)

Responder:

AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
                 <ResponderSignedOctets>)

Die Zeichenkette „Key Pad for IKEv2“ hat 17 ASCII-Zeichen ohne Nullterminierung. Das Shared Secret kann variabel lang sein. Die Pad-Zeichenkette ermöglicht, dass bei Ableitung aus einem Passwort die IKE-Implementierung das Passwort nicht im Klartext speichern muss, sondern prf(Shared Secret,"Key Pad for IKEv2"), das für andere Protokolle als IKEv2 kein Passwort-Äquivalent ist. Wie erwähnt ist Ableitung nur aus dem Passwort unsicher; diese Konstruktion wird dennoch erwartet. Die Verwaltungsschnittstelle MUSS ASCII-Strings von mindestens 64 Oktetten akzeptieren und DARF keinen Nullterminator vor Nutzung als Secret hinzufügen. Sie MUSS auch Hex-Kodierung akzeptieren und KANN andere Kodierungen akzeptieren, wenn der Übersetzungsalgorithmus zur Binärzeichenkette spezifiziert ist.

Es gibt zwei Arten der EAP-Authentisierung (Abschnitt 2.16); jede verwendet andere Werte in den AUTH-Berechnungen oben. Ist die EAP-Methode schlüsselerzeugend, wird die Master Session Key (MSK) statt des Shared Secret eingesetzt. Bei nicht schlüsselerzeugenden Methoden werden SK_pi bzw. SK_pr statt des Shared Secret in den beiden AUTH-Berechnungen verwendet.