Zusammenfassung

  • Die Master-Werte in RFC 3079 dienten nur als Eingabe weiterer Ableitungen. Getrennte flüchtige Schlüssel initialisierten Sende- und Empfangskontexte.
  • Ein korrektes Testergebnis bewies die Rechnung, nicht dieselbe erste Authentisierung, komplementäre Richtungen, dieselbe MPPE-Stärke oder eine erfolgreiche Anwendungslieferung.

Ein Master-Wert ohne eigenen Datenverkehr

Der RFC sagt ausdrücklich, dass Master Session Keys niemals Daten ver- oder entschlüsseln. Bei MS-CHAP-2 erzeugten der doppelte Passwort-Hash und die NT-Response zunächst einen Master-Wert. GetAsymmetricStartKey wählte anhand von Senden/Empfangen und Client/Server einen Zweig. GetNewKeyFromSHA erzeugte danach den flüchtigen Schlüssel für den RC4-Kontext.

Ein Ereignis „Master Key erzeugt“ endete deshalb vor der entscheidenden Zuordnung. Es sagte weder, welcher Zweig gewählt wurde, noch wohin die Ausgabe gelangte. Beide Endpunkte konnten lokal erfolgreich rechnen und gemeinsam scheitern.

RFC 3079 erschien im März 2001 als Informational RFC, um Dritten eine offene Interoperabilitätsreferenz zu geben. CCP-Aushandlung, MPPE-Pakete und Schlüsselwechsel während der Sitzung gehörten zu RFC 3078. Veröffentlichung war weder Internetstandard noch Einsatznachweis.

Drei Quellen behalten ihre Herkunft

MS-CHAP-1 leitete 40 und 56 Bit aus dem LAN-Manager-Hash ab und 128 Bit aus dem Windows-NT-Hash samt Challenge. MS-CHAP-2 nutzte für alle Stärken den NT-Pfad und die NT-Response. EAP-TLS begann mit exportiertem TLS-Material.

Das gemeinsame Ziel MPPE machte diese Quellen nicht gleichwertig. Ein Beleg musste Authentisierungsfamilie, anrufenden Peer, erstes ausgewähltes Ereignis, Challenge/Response- oder TLS-Generation und Ziel-Link festhalten. Acht Oktette konnten 40 oder 56 Bit bedeuten; sechzehn konnten aus unterschiedlichen Sitzungen stammen.

RFC 2759 definierte die MS-CHAP-2-Werte, RFC 2433 das Vorgängerverfahren, RFC 2716 EAP-TLS in PPP. Sie beschrieben Eingaben, nicht CCP Opened.

Das erste Ereignis war Teil der Sitzungsidentität

Die Anfangsschlüssel beider Richtungen stammten von den Credentials des Peers, der den Anruf initiierte. Bei Challenges galt die erste Authentisierung. Das blieb bei beidseitiger Authentisierung und für jeden Link eines Multilink-Bündels so.

In verteilten Systemen kann gerade „erste“ verschwinden. Der Identitätsdienst speichert nur den jüngsten Erfolg, der Bündelkoordinator verwirft die ursprüngliche Challenge, ein Ersatzchassis übernimmt Benutzer und Erfolgsflag ohne Ableitungsgeneration. Die Formel bleibt korrekt und erzeugt deterministisch die falsche Ausgabe.

Für Multi-Chassis-Multilink machte der RFC die Implementierung verantwortlich, auf allen Maschinen die richtigen Schlüssel zu erzeugen. Der Sitzungsbegriff musste Authentisierungsereignis, Rolle, Link und Generation umfassen.

Senden hier hieß Empfangen dort

Die festen Labels von GetAsymmetricStartKey verbanden beide Seiten über Kreuz. Server-Senden entsprach Client-Empfangen und umgekehrt. Im EAP-TLS-Abschnitt heißt es direkt: Der Sendeschlüssel einer Seite ist der Empfangsschlüssel der anderen.

Ein Feld send_key durfte also nicht in das gleichnamige Feld des Peers kopiert werden. Der Name war lokal, die Beziehung bilateral. Der Nachweis muss Endpunkte, Rollen, lokale und entfernte Richtung sowie Fingerprints von Generation und flüchtigem Schlüssel verbinden, ohne Geheimnisse zu protokollieren.

Auch die Stärke entstand nicht nur durch Länge. 40 und 56 Bit nutzten acht Oktette; bei 40 Bit wurden drei Anfangsoktette, bei 56 Bit eines durch Konstanten ersetzt. 128 Bit nutzte sechzehn. EAP-TLS verlangte linksseitiges Auffüllen oder Abschneiden. Gleiche Endlänge bewies keine gleiche Herkunft.

Testvektoren prüften die Arithmetik, nicht die reale Übergabe oder Aushandlung. Der RFC warnte zudem, dass der 40-Bit-Anfangsschlüssel unter MS-CHAP-1 bei gleichen Credentials wiederkehrte. Diese historische Analyse empfiehlt weder RC4 noch ältere MS-CHAP-Verfahren heute.

Nach der Ableitung begann erst der Dienst

RFC 3078 verlangte die PPP-Phase Network-Layer Protocol und CCP Opened vor MPPE-Verkehr. RFC 2548 behandelte den RADIUS-Transport richtungsspezifischer Schlüssel und die Verwahrung durch Proxies. RFC 1661 trennte PPP-Phasen.

Authentisierung, Geheimnisübergabe, Link-Zuordnung, Richtungspaarung, CCP-Aushandlung, synchrones Entschlüsseln und Anwendungsverarbeitung waren verschiedene Belege. Lu Hengs Realitätsebenen verhindern, dass „Master“, „Send“, „authentisiert“ oder „128 Bit“ die tatsächlichen Übergänge ersetzen.

RFC 3079 machte die minimale gemeinsame Herkunft reproduzierbar. Ableitung war der Eintritt in die nächste Prüfung, nicht der Abschluss des Dienstnachweises.

Quellen