Zusammenfassung

  • RFC 3526 dokumentiert Gruppe 5 mit 1536 Bit und definiert die MODP-Gruppen 14 bis 18 von 2048 bis 8192 Bit für IKE. Es verspricht keine direkte AES-Äquivalenz und verlangt getrennt, dass der Exponent nicht zum schwächsten Glied wird.
  • Ein belastbarer Beleg verbindet Parameterwahl mit lokaler Policy, frischer Entropie, Prüfung des Peer-Werts, Authentisierung, gesamter Suite, Schlüsselzyklus und beobachtetem Verkehr. Die Transform-ID beweist nur einen öffentlichen Parameterentscheid.

Öffentliche Parameter sind dauerhaft und bequem. Ihr Hash passt in ein Inventar, ihre ID in eine Tabellenzelle. Die Erzeugung des privaten Exponenten findet dagegen lokal statt und soll keine geheime Spur hinterlassen.

Genau deshalb braucht sie einen nicht geheimen Ausführungsbeleg. Ohne ihn übernimmt die sichtbare Gruppengröße die Rolle einer Sicherheitszusage, die sie nicht erfüllen kann.

RFC 3526 erschien im Mai 2003 auf dem Standards Track und wird als Proposed Standard geführt. Es ist ein Koordinationsdokument, kein Zertifikat für eine konkrete Maschine.

Der gemeinsame Name bindet gemeinsame Mathematik

Das Dokument standardisiert die bereits verwendete 1536-Bit-Gruppe 5 und weist den Größen 2048, 3072, 4096, 6144 und 8192 die Nummern 14 bis 18 zu. Die Primzahlen sind veröffentlicht, der Generator ist 2.

Ein Sender und Empfänger können damit denselben Parametersatz auswählen. Diagnose und Audit können die Nummer gegen eine kanonische Definition prüfen.

Die Nummer enthält jedoch weder privaten Exponenten noch Zufallsquelle, Eingabevalidierung, lokale Freigabe, Peer-Identität, übrige Algorithmen oder Anwendungserfolg.

Der enge Beleg lautet: Dieser öffentliche Satz wurde gewählt. Die Ausführung muss alles Weitere selbst nachweisen.

Keine einfache Umrechnung in AES-Stärke

Die Einleitung stellt unterschiedliche Schätzungen gegenüber, welche endlichen Gruppen den Stärken von AES-128, -192 und -256 entsprechen könnten. Gerade für die höheren Stufen weichen die Quellen erheblich voneinander ab.

Die Autoren entscheiden den Streit nicht mit einer bequemen Tabelle. Sie definieren mehrere Gruppen, ordnen aber keiner AES-Schlüssellänge eine verbindliche Gruppe zu. Mehr als 8192 Bit galten auf damaliger Hardware als unpraktisch.

Wer Gruppe 18 automatisch als „256-Bit-Sicherheit“ ausweist, fügt somit eine Aussage hinzu, die der RFC bewusst vermieden hat. Moduluslänge und symmetrische Schlüssellänge sind ohne Modell nicht austauschbar.

Angriffshorizont, Kryptoanalyse, restliche Suite und Gerätekosten bleiben Gegenstand einer versionierten Policy.

Ein breiter Exponent ist nicht gemessene Entropie

RFC 3526 verlangt, dass der Exponent zu den anderen Komponenten passt und nicht der schwächste Teil wird. Er soll mehr als die doppelte Zufälligkeit der angestrebten Stärke besitzen; für 128 Bit nennt das Beispiel mehr als 256 Bit Zufall.

Eine Speicherbreite beweist das nicht. Bias, Wiederholung oder fehlerhafte Initialisierung können einen langen, aber vorhersagbaren Wert liefern. Nachträgliches Formatieren erzeugt keine fehlende Unsicherheit.

Der geheime Wert gehört auch nicht ins Audit-Log. Ein solcher Beleg würde das Schutzgut offenlegen. Festgehalten werden genehmigte Generatorversion, Health-State, Längen- und Entropieregel, Freshness-Anforderung und geschützte Ereignisbindung.

Öffentliche Mathematik und privater Zufallsakt bilden zwei Kontrollflächen.

Der Peer-Wert braucht eine eigene Prüfung

RFC 6989 beschreibt Empfängertests für IKEv2. Bei Sophie-Germain-Prim-MODP-Gruppen, darunter RFC 3526, prüft der Empfänger strikt 1 < r < p-1.

Die Gruppen-ID wählt das Prüfprofil. Sie bescheinigt nicht, dass es lief. Ein Payload kann Gruppe 14 tragen und trotzdem eine zu verwerfende Eingabe enthalten.

Kleine Untergruppen aus anderen Definitionen und die Wiederverwendung privater Werte haben weitere Pfade. Frische Erzeugung und Reuse sind keine gleichwertigen Zustände.

Der Beleg hält Digest des empfangenen Werts, Profil, Implementierungsversion, Zweig und Ergebnis. „DH erfolgreich“ verwischt Erkennung, mathematische Gültigkeit und Policy.

Implementierungspflicht ist keine Betriebsfreigabe

RFC 7296 verlangt Management Controls für akzeptable IKEv2-Suites. Transform IDs werden gegen lokale Konfiguration verglichen; nicht autorisierte Angebote werden abgelehnt. MUST implement bedeutet nicht MUST enable.

Damit bleibt eine Registry Namensraum und wird nicht zur Policy-Instanz jedes Betreibers.

RFC 8247 hob Gruppe 14 bei Veröffentlichung auf MUST und setzte Gruppe 5 auf SHOULD NOT. Zugleich weist es auf die Rechenlast sehr großer Gruppen für VPN-Gateways und beschränkte Geräte hin.

Angebot, Reihenfolge, Auswahl, Policy-Version und Ablehnungen gehören in den Entscheidungsbeleg. Unterstützung ist Bestand, Zulassung ist Autorität, Erfolg ist ein späteres Ergebnis.

Der gemeinsame Wert benennt keinen Partner

Nicht authentisiertes Diffie-Hellman teilt einen Wert mit dem tatsächlichen Teilnehmer. IKE braucht zusätzliche Authentisierung, um ihn einer Identität zuzuordnen. RFC 3526 stellt nur Gruppen bereit.

Die Bitzahl prüft keine Zertifikatskette, PSK-Identität, EAP-Entscheidung oder Namensbindung. Ein grüner Handshake darf keine Organisation legitimieren, wenn der Identitätsbeleg fehlt.

Methode, Credential-Pfad, Validierungsregeln, behauptete und akzeptierte Identität sowie Binding bleiben getrennte Felder.

Sie gehören zur selben Episode, besitzen aber verschiedene Aussagekraft.

Die übrige Suite setzt weiter Grenzen

RFC 8247 betont Algorithmen, Schlüssel und Protokolltechnik gegen nicht kryptografische Umgehung. Eine große Gruppe repariert keine schwache PRF, fehlerhafte Authentisierung, offenen Schlüsselspeicher oder Bypass-Traffic.

Größe kostet Rechenleistung. Teure Modular Exponentiation vor Authentisierung kann Ressourcen belasten. Das rechtfertigt keine schwache Auswahl, sondern eine dokumentierte Reihenfolge und Begrenzung.

Die Suite ist ein Abhängigkeitsgraph. Ihre Zusage endet an relevanten Schwächen und Zusammensetzung, nicht am größten Zahlenfeld.

RFC 7919 definiert später andere FFDHE-Gruppen für TLS. Das ist Vergleich, keine rückwirkende IKE-Regel.

Eine Registry-Zeile ist keine Laufzeitmessung

IANA führt Gruppen 5 und 14–18 weiter und verweist auf RFC 3526 sowie RFC 6989. Die Zeile klärt Namen und Quellen.

Sie sieht weder frische Erzeugung noch Bereichstest, lokale Policy, Authentisierung, Erasure oder Verkehr.

RFC 9395 erklärte IKEv1 für deprecated und schloss dessen Registries. In seiner konkreten Liste wurden keine weiteren DH-Gruppen deprecated. Das ist keine pauschale Empfehlung aller verbliebenen Gruppen.

Dokumentstatus, Registry, Produktfähigkeit und Einsatzentscheidung antworten auf getrennte Fragen. Audit darf sie nicht zu einem Gütesiegel verschmelzen.

Ein Beleg ohne Speicherung des Geheimnisses

Er beginnt mit Protokollversion, RFC, Transform ID und Parameterhash. Danach folgen geordnetes Angebot, Auswahl, Downgrade-Kontext, Policy und Entscheidung.

Privat werden Generator, Zustand, Regel und Freshness attestiert, nicht der Exponent. Für Peer-Eingaben bleiben Digest, Test und Urteil.

Authentisierung dokumentiert Methode und Principal, Derivation die sicheren Metadaten, SA und Algorithmen. Lifecycle dokumentiert Rekey, Reuse und Löschung.

Am Ende stehen geschützte Pakete, Integritätsfehler, Selector, erwarteter Peer und Anwendungsvorgang. Der Handshake ist nicht deren Quittung.

Evidenzgrenze

Dieser Artikel nennt keine Implementierung, keinen Anbieter, Betreiber, VPN, Gateway, Peer, Nutzer, Flow, Vorfall, Angriff oder Bruch. Er misst keine aktuelle Verbreitung, Entropie, Validierung, Leistung oder Geschäftswirkung.

RFC 3526 wird als Standards-Track-Dokument vom Mai 2003 und heutiger Proposed Standard behandelt. Spätere RFCs behalten eigenen Zeitpunkt und Umfang und beweisen kein konkretes Runtime-Verhalten.

Heng Lus Authority- und Running-Code-Texte sind offengelegte redaktionelle Perspektiven. Sie sind keine Quelle für IETF-Absicht.

Die enge Aussage lautet: Eine größere Gruppe stärkt eine mathematische Komponente; die vollständige Sicherheitsbehauptung braucht die übrigen Belege.

Quellen