5. Security Considerations (Sicherheitsüberlegungen)
5. Security Considerations (Sicherheitsüberlegungen)
Obwohl dieses Protokoll so ausgelegt ist, dass die Offenlegung von Konfigurationsinformationen gegenüber nicht authentifizierten Peers minimiert wird, ist eine gewisse Offenlegung unvermeidlich. Einer der Peers muss sich zuerst identifizieren und seine Identität zuerst beweisen. Um Sondierung (Probing) zu vermeiden, muss der Initiator eines Austauschs sich zuerst identifizieren und in der Regel sich zuerst authentifizieren. Der Initiator kann jedoch erfahren, dass der Responder IKE unterstützt und welche kryptografischen Protokolle er anbietet. Der Responder (oder jemand, der sich als Responder ausgibt) kann nicht nur den Initiator nach seiner Identität sondieren, sondern mithilfe von CERTREQ-Nutzlasten möglicherweise feststellen, welche Zertifikate der Initiator einsetzen würde.
Die Verwendung von EAP-Authentifizierung ändert die Sondierungsmöglichkeiten etwas. Bei EAP beweist der Responder seine Identität vor dem Initiator; ein Initiator, der den Namen eines gültigen Initiators kennte, könnte den Responder nach Namen und Zertifikaten sondieren.
Wiederholtes Rekeying mit CREATE_CHILD_SA ohne zusätzliche Diffie-Hellman-Austausche macht alle SAs anfällig für Kryptoanalyse eines einzelnen Schlüssels. Implementierer sollten dies berücksichtigen und eine Grenze für CREATE_CHILD_SA-Austausche zwischen Exponentiationen setzen. Dieses Dokument schreibt eine solche Grenze nicht vor.
Die Stärke eines aus einem Diffie-Hellman-Austausch mit einer der hier definierten Gruppen abgeleiteten Schlüssels hängt von der inhärenten Stärke der Gruppe, der Größe des verwendeten Exponenten und der vom Zufallszahlengenerator gelieferten Entropie ab. Aufgrund dieser Faktoren ist es schwierig, die Stärke eines Schlüssels für die definierten Gruppen zu bestimmen. Diffie-Hellman-Gruppe Nummer zwei wird bei starkem Zufallszahlengenerator und einem Exponenten von mindestens 200 Bit häufig mit 3DES verwendet. Gruppe fünf bietet mehr Sicherheit als Gruppe zwei. Gruppe eins dient nur historischen Zwecken und bietet keine ausreichende Stärke außer für DES, das ebenfalls nur historisch ist. Implementierungen sollten diese Schätzungen bei der Richtlinienfestlegung und der Verhandlung von Sicherheitsparametern beachten.
Diese Einschränkungen betreffen die Diffie-Hellman-Gruppen selbst. In IKE ist nichts verboten, stärkere Gruppen zu verwenden, und nichts schwächt die aus stärkeren Gruppen gewonnene Stärke ab (begrenzt durch die Stärke der anderen verhandelten Algorithmen einschließlich der PRF (Pseudorandom Function)). Tatsächlich ermutigt das erweiterbare Rahmenwerk von IKE zur Definition weiterer Gruppen; elliptische Kurven können die Stärke bei viel kleineren Zahlen stark erhöhen.
Es wird angenommen, dass alle Diffie-Hellman-Exponenten nach Gebrauch aus dem Speicher gelöscht werden.
Die Austausche IKE_SA_INIT und IKE_AUTH erfolgen, bevor der Initiator authentifiziert ist. Daher muss eine Implementierung dieses Protokolls in jedem unsicheren Netz vollständig robust sein. Implementierungsschwachstellen, insbesondere DoS-Angriffe (Denial of Service), können von nicht authentifizierten Peers ausgenutzt werden. Dies ist besonders problematisch wegen der unbegrenzten Nachrichtenzahl bei EAP-basierter Authentifizierung.
Die Stärke aller Schlüssel ist durch die Ausgabegröße der verhandelten PRF begrenzt. Aus diesem Grund DARF eine PRF, deren Ausgabe kleiner als 128 Bit ist (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 Zufallsquelle oder ordnungsgemäß gesätem Pseudozufall erzeugt werden (siehe [RANDOMNESS]). Implementierer sollten darauf achten, dass der Einsatz von Zufallszahlen für Schlüssel und Nonces die Sicherheit der Schlüssel nicht untergräbt.
Zur Begründung vieler kryptografischer Designentscheidungen in diesem Protokoll siehe [SIGMA] und [SKEME]. Obwohl die Sicherheit verhandelter Child-SAs nicht von der Stärke der in der IKE-SA verhandelten Verschlüsselung und Integritätsschutz abhängt, DÜRFEN Implementierungen NONE nicht als IKE-Integritätsschutzalgorithmus und ENCR_NULL nicht als IKE-Verschlüsselungsalgorithmus aushandeln.
Bei vorab geteilten Schlüsseln ist entscheidend, wie die Zufälligkeit dieser Geheimnisse sichergestellt wird. Best Practice ist, dass jeder vorab geteilte Schlüssel mindestens so viel Zufälligkeit enthält wie der stärkste verhandelte Schlüssel. Die Ableitung eines gemeinsamen Geheimnisses aus Passwort, Namen oder einer anderen Quelle mit geringer Entropie ist nicht sicher. Solche Quellen sind unter anderem Wörterbuch- und Social-Engineering-Angriffen ausgesetzt.
Die NAT_DETECTION_*_IP-Benachrichtigungen enthalten einen Hash von Adressen und Ports, um interne IP-Adressen hinter einem NAT zu verbergen. Da der IPv4-Adressraum nur 32 Bit groß und meist sehr dünn besetzt ist, könnte ein Angreifer die hinter dem NAT verwendete interne Adresse ermitteln, indem er alle IP-Adressen durchprobiert und den passenden Hash sucht. Die Portnummern sind normalerweise auf 500 festgelegt, und die SPIs lassen sich aus dem Paket extrahieren. Dadurch sinkt die Zahl der Hash-Berechnungen auf 2^32. Mit einer informierten Annahme über private Adressräume ist die Zahl der Hash-Berechnungen viel kleiner. Designer sollten daher nicht davon ausgehen, dass die Nutzung von IKE keine internen Adressinformationen preisgibt.
Wird eine EAP-Authentifizierungsmethode verwendet, die keinen gemeinsamen Schlüssel zum Schutz einer nachfolgenden AUTH-Nutzst erzeugt, sind bestimmte Man-in-the-Middle- und Server-Impersonation-Angriffe möglich [EAPMITM]. Diese Schwachstellen treten auf, wenn EAP auch in Protokollen ohne sicheren Tunnel genutzt wird. Da EAP ein allgemeines Authentifizierungsprotokoll ist, das oft für Single-Sign-on genutzt wird, kann eine eingesetzte IPsec-Lösung, die auf eine EAP-Methode ohne Schlüsselerzeugung (nicht schlüsselerzeugende EAP-Methode) angewiesen ist, durch die Bereitstellung einer völlig unabhängigen Anwendung kompromittiert werden, die dieselbe nicht schlüsselerzeugende EAP-Methode ungeschützt nutzt. Diese Schwachstelle beschränkt sich nicht nur auf EAP, sondern kann auch in anderen Szenarien mit wiederverwendeter Authentifizierungsinfrastruktur auftreten. Wenn der von IKEv2 genutzte EAP-Mechanismus beispielsweise einen Token-Authentifikator verwendet, könnte ein Man-in-the-Middle-Angreifer den Webserver imitieren, den Token-Austausch abfangen und damit eine IKEv2-Verbindung starten. Aus diesem Grund SOLLTE die Verwendung nicht schlüsselerzeugender EAP-Methoden nach Möglichkeit vermieden werden. Wo sie eingesetzt werden, ist es äußerst wichtig, dass alle Nutzungen dieser EAP-Methoden einen geschützten Tunnel verwenden SOLLEN, in dem der Initiator das Zertifikat des Responders validiert, bevor die EAP-Authentifizierung beginnt. Implementierer SOLLEN die Risiken nicht schlüsselerzeugender EAP-Methoden in der Dokumentation ihrer Implementierungen beschreiben, damit Administratoren von IPsec-Lösungen diese Gefahren kennen.
Eine Implementierung, die EAP nutzt, MUSS außerdem vor Beginn der EAP-Authentifizierung eine public-key-basierte Authentifizierung des Servers gegenüber dem Client durchführen, selbst wenn die EAP-Methode gegenseitige Authentifizierung bietet. Dies vermeidet zusätzliche IKEv2-Protokollvarianten und schützt die EAP-Daten vor aktiven Angreifern.
Sind IKEv2-Nachrichten so lang, dass IP-Fragmentierung nötig ist, können Angreifer den Austausch dadurch verhindern, dass sie die Reassembly-Puffer erschöpfen. Die Wahrscheinlichkeit lässt sich verringern, indem Hash- und URL-Kodierungen statt dem Senden von Zertifikaten genutzt werden (Abschnitt 3.6). Weitere Maßnahmen werden in [DOSUDPPROT] diskutiert.
Zugangskontrolle (Admission Control) ist für die Protokollsicherheit entscheidend. Beispielsweise sollten Vertrauensanker zur Identifikation von IKE-Peers wahrscheinlich andere sein als solche für andere Vertrauensformen, etwa für öffentliche Webserver. Außerdem ist es unerlässlich für eine sichere Implementierung, eine ausdrückliche Sicherheitsrichtlinie für die Identität, die Anmeldedaten und deren Zusammenhang für einen vertrauenswürdigen Peer zu definieren, auch wenn IKE hier große Freiheiten lässt.