5. Sicherheitsüberlegungen
Obwohl dieses Protokoll darauf ausgelegt ist, die Offenlegung von Konfigurationsinformationen an eine nicht authentifizierte Gegenstelle so gering wie möglich zu halten, ist ein Teil dieser Offenlegung unvermeidlich. Die eine oder die andere Partei muss sich zuerst identifizieren und zuerst ihre Identität nachweisen. Um das Sondieren zu vermeiden, wird vom Initiator des Austauschs verlangt, dass er sich zuerst identifiziert, und in der Regel wird verlangt, dass er sich zuerst authentifiziert. Der Initiator kann jedoch erfahren, dass der Responder IKE unterstützt und welche kryptografischen Protokolle er unterstützt. Der Responder (oder jemand, der sich als Responder ausgibt) kann über den CERTREQ-Payload nicht nur die Identität des Initiators sondieren, sondern möglicherweise auch ermitteln, welche Zertifikate der Initiator verwenden möchte.
Die Verwendung von EAP-Authentifizierung ändert die Möglichkeiten des Sondierens etwas. Wenn EAP-Authentifizierung verwendet wird, weist der Responder seine Identität vor dem Initiator nach, sodass ein Initiator, der einen gültigen Initiatornamen kennt, sowohl den Namen als auch das Zertifikat des Responders sondieren kann.
Wiederholtes Rekeying mittels CREATE_CHILD_SA ohne zusätzlichen Diffie-Hellman-Austausch macht alle SAs für kryptoanalytische Angriffe gegen einen einzelnen Schlüssel anfällig. Implementierer sollten sich dieses Umstands bewusst sein und eine Begrenzung der Anzahl von CREATE_CHILD_SA-Austauschen zwischen Exponentiationen vorsehen. Dieses Dokument schreibt eine solche Begrenzung nicht vor.
Die Stärke der aus einem Diffie-Hellman-Austausch mit einer der hier definierten Gruppen abgeleiteten Schlüssel hängt von der inhärenten Stärke der Gruppe selbst, der Größe der verwendeten Exponenten und der vom verwendeten Zufallszahlengenerator bereitgestellten Entropie ab. Aufgrund dieser Eingaben ist es schwierig, die Schlüsselstärke für irgendeine definierte Gruppe zu bestimmen. In Kombination mit einem starken Zufallszahlengenerator und einem Exponenten von mindestens 200 Bit wird die Diffie-Hellman-Gruppe 2 üblicherweise mit 3DES verwendet. Gruppe 5 bietet höhere Sicherheit als Gruppe 2. Gruppe 1 dient nur historischen Zwecken und bietet keine ausreichende Stärke, außer in Verbindung mit DES, das ebenfalls nur historischen Zwecken dient. Implementierer sollten bei der Festlegung von Richtlinien und der Aushandlung von Sicherheitsparametern diese Abschätzungen beachten.
Beachten Sie, dass sich diese Einschränkungen auf die Diffie-Hellman-Gruppe selbst beziehen. Nichts in IKE verbietet die Verwendung einer stärkeren Gruppe oder schwächt die aus einer stärkeren Gruppe gewonnene Stärke ab (vorbehaltlich der Stärke der anderen ausgehandelten Algorithmen, einschließlich der PRF). Tatsächlich fördert das erweiterbare Rahmenwerk von IKE die Definition weiterer Gruppen; die Verwendung von elliptischen Kurven kann die Stärke mit viel kleineren Zahlen erheblich erhöhen.
Es wird angenommen, dass alle Diffie-Hellman-Exponenten nach der Verwendung aus dem Speicher gelöscht werden.
Die Austausche IKE_SA_INIT und IKE_AUTH finden statt, bevor der Initiator authentifiziert ist. Daher müssen Implementierungen dieses Protokolls, die in einem beliebigen unsicheren Netzwerk eingesetzt werden, vollständig robust sein. Implementierungsfehler, insbesondere DoS-Angriffe, könnten von einer nicht authentifizierten Gegenstelle ausgenutzt werden. Da die Anzahl der Nachrichten bei EAP-basierter Authentifizierung nicht begrenzt ist, ist dieses Problem besonders besorgniserregend.
Die Stärke aller Schlüssel ist durch die Ausgabegröße der ausgehandelten PRF begrenzt. Daher DARF eine PRF mit einer Ausgabe von weniger als 128 Bit (z. B. 3DES-CBC) nicht mit diesem Protokoll verwendet werden.
Die Sicherheit dieses Protokolls hängt entscheidend von der Zufälligkeit der zufällig gewählten Parameter ab. Diese sollten von einer starken Zufalls- oder korrekt gesetzten Pseudozufallsquelle erzeugt werden (siehe [RANDOMNESS]). Implementierer sollten sicherstellen, dass die für Schlüssel und Nonces verwendeten Zufallszahlen die Sicherheit der Schlüssel nicht beeinträchtigen.
Für die Begründung vieler kryptografischer Entwurfsentscheidungen dieses Protokolls siehe [SIGMA] und [SKEME]. Obwohl die Sicherheit einer ausgehandelten Child SA nicht von der Stärke der im IKE SA ausgehandelten Verschlüsselung und Integritätsschutz abhängt, DÜRFEN Implementierungen NICHT NONE als IKE-Integritätsschutzalgorithmus oder ENCR_NULL als IKE-Verschlüsselungsalgorithmus aushandeln.
Bei der Verwendung von vorab geteilten Schlüsseln ist die Sicherstellung der Zufälligkeit dieser Geheimnisse ein wesentlicher Aspekt. Der stärkste Ansatz besteht darin, sicherzustellen, dass ein vorab geteilter Schlüssel ebenso viel Zufälligkeit enthält wie der stärkste ausgehandelte Schlüssel. Die Ableitung eines gemeinsamen Geheimnisses aus Passwörtern, Namen oder anderen Quellen mit geringer Entropie ist unsicher. Diese Quellen sind anfällig für Wörterbuchangriffe und Social Engineering, unter anderem.
Die NAT_DETECTION_*_IP-Benachrichtigungen enthalten einen Hash der Adresse und des Ports, um die interne IP-Adresse hinter dem NAT zu verbergen. Da der IPv4-Adressraum nur 32 Bit umfasst und in der Regel sehr dünn besetzt ist, könnte ein Angreifer die hinter der NAT-Box verwendete interne Adresse entdecken, indem er alle möglichen IP-Adressen ausprobiert und nach einem passenden Hash sucht. Die Portnummer ist meist auf 500 festgelegt, und der SPI kann aus dem Paket extrahiert werden. Dies reduziert die Anzahl der Hash-Berechnungen auf 2^32. Durch gezielte Vermutung der Nutzung privater Adressräume ist die Zahl der Hash-Berechnungen viel geringer. Daher sollten Entwickler nicht annehmen, dass die Verwendung von IKE keine internen Adressinformationen preisgibt.
Werden EAP-Authentifizierungsmethoden verwendet, die keinen gemeinsamen Schlüssel zur Absicherung nachfolgender AUTH-Payloads erzeugen, können bestimmte Man-in-the-Middle-Angriffe und Server-Imitationen auftreten [EAPMITM]. Diese Schwachstellen treten auf, wenn EAP auch für nicht durch einen sicheren Tunnel geschützte Protokolle verwendet wird. Da EAP ein generisches Authentifizierungsprotokoll ist, das häufig zur Bereitstellung von Single-Sign-On-Funktionen genutzt wird, könnten bereitgestellte IPsec-Lösungen, die auf EAP-Authentifizierungsmethoden vertrauen, die keinen Schlüssel erzeugen (auch nicht schlüsselerzeugende EAP-Methoden genannt), durch die Bereitstellung einer völlig unzusammenhängenden Anwendung kompromittiert werden, die zufällig dieselbe nicht schlüsselerzeugende EAP-Methode verwendet, aber unzureichend geschützt betrieben wird. Beachten Sie, dass diese Schwachstelle nicht auf EAP beschränkt ist und auch in anderen Szenarien auftreten kann, in denen die Authentifizierungsinfrastruktur wiederverwendet wird. Wenn beispielsweise der von IKEv2 verwendete EAP-Mechanismus einen Token-Authentikator nutzt, könnte ein Man-in-the-Middle-Angreifer einen Webserver imitieren, den Token-Authentifizierungsaustausch abfangen und ihn nutzen, um eine IKEv2-Verbindung zu initiieren. Daher sollten nicht schlüsselerzeugende EAP-Methoden nach Möglichkeit vermieden werden. Bei ihrer Verwendung ist es äußerst wichtig, dass alle diese EAP-Methoden einen geschützten Tunnel nutzen, in dem der Initiator das Zertifikat des Responders vor Beginn der EAP-Authentifizierung verifiziert. Implementierer sollten in der Dokumentation ihrer Implementierung die Schwachstellen bei der Verwendung nicht schlüsselerzeugender EAP-Methoden beschreiben, damit Administratoren, die IPsec-Lösungen bereitstellen, diese Gefahren kennen.
Implementierungen, die EAP verwenden, MÜSSEN vor Beginn der EAP-Authentifizierung auch eine server-zu-client-basierte Public-Key-Authentifizierung verwenden, selbst wenn die EAP-Methode gegenseitige Authentifizierung bietet. Dies vermeidet zusätzliche IKEv2-Protokollvarianten und schützt die EAP-Daten vor aktiven Angreifern.
Wenn eine IKEv2-Nachricht so lang ist, dass eine IP-Ebene-Fragmentierung erforderlich wird, könnte ein Angreifer den Abschluss des Austauschs verhindern, indem er den Reassemblierungspuffer erschöpft. Durch die Verwendung der Hash-und-URL-Kodierung anstelle des Sendens von Zertifikaten (siehe Abschnitt 3.6) kann diese Möglichkeit minimiert werden. Weitere Gegenmaßnahmen werden in [DOSUDPPROT] erörtert.
Die Zugangskontrolle ist für die Sicherheit des Protokolls von entscheidender Bedeutung. Beispielsweise sollte die Vertrauensanker, die zur Identifizierung der IKE-Gegenstelle verwendet wird, wahrscheinlich von derjenigen abweichen, die für andere Formen des Vertrauens (z. B. zur Identifizierung öffentlicher Webserver) verwendet wird. Darüber hinaus bietet IKE zwar große Freiheit bei der Definition von Sicherheitsrichtlinien für die Identität, die Anmeldedaten und deren Zuordnung zwischen vertrauenswürdigen Gegenstellen, aber die explizite Definition solcher Sicherheitsrichtlinien ist für eine sichere Implementierung unerlässlich.