Zusammenfassung

  • Der zwölf Bit breite Kohärenzzähler aus RFC 3078 konnte verlorene oder falsch gereihte MPPE-Pakete anzeigen. Er stellte weder den fehlenden Chiffretext wieder her noch bewies er die Zustellung von Klartext an die Anwendung.
  • Im zustandslosen Modus ließ sich der Schlüssel um die beobachtete Lücke weiterdrehen. Im zustandsbehafteten Modus musste der Empfänger verwerfen, CCP Reset-Request senden und bis zu einem FLUSHED-Paket warten.

Das aufschlussreiche Paket war selbst nicht nutzbar

Der Empfänger erwartete einen Zählerstand und erhielt einen anderen. Damit wusste er, dass seine lokale Geschichte unvollständig war. Der Sender konnte jedoch bereits eine Schlüsselgrenze überschritten haben, die der Empfänger nie gesehen hatte. Der neue Zähler lieferte nicht automatisch den passenden RC4-Zustand.

RFC 3078 verlangte im zustandsbehafteten Modus eine strenge Reaktion. Das Paket wurde verworfen, ein CCP Reset-Request ohne Daten zurückgesendet, und weitere Pakete sollten still verworfen werden, bis FLUSHED erschien. Der Sender initialisierte nach der Anfrage seine RC4-Tabellen neu und markierte das nächste Paket. Ein eigener Reset-Ack war nicht nötig; das veränderte Verhalten war die Quittung.

Der Ablauf trennte Diagnose, kryptografische Fortsetzbarkeit und Dienstwirkung. Der Zählersprung bewies den Bruch. FLUSHED errichtete einen neuen gemeinsamen Zustand. Der verlorene Inhalt blieb verloren.

Vor der Verschlüsselung lagen mehrere Entscheidungen

RFC 3078 erschien im März 2001 als Informational RFC. Er beschrieb Microsoft Point-to-Point Encryption für PPP und aktualisierte die mit MPPC aus RFC 2118 geteilte Option. Er war kein Internet Standard.

MPPE wurde über Option 18 des Compression Control Protocol ausgehandelt. Der Initiator bot seine Möglichkeiten an; der Antwortende sollte üblicherweise eine von 128, 56 oder 40 Bit auswählen. Ein getrenntes Bit verlangte den zustandslosen Modus. Ohne Verhandlungsversuch blieb die Voreinstellung unverschlüsselt. Scheiterte ein begonnener Versuch, sollte die Verbindung beendet werden.

Vor MPPE-Daten musste PPP die Network-Layer-Protocol-Phase und CCP den Zustand Opened erreichen. Erfolgreiche Authentifizierung war nicht Opened. Ein gelieferter Schlüssel war keine Moduswahl. Das Angebot von 128 Bit bewies nicht deren Annahme. Eine Richtlinie mit „Verschlüsselung erforderlich“ schützte nicht selbst das erste Nutzpaket.

Die Begleitdokumente teilten diese Kette auf. RFC 2548 transportierte richtungsabhängige MPPE-Schlüssel in RADIUS. RFC 3079 beschrieb ihre Ableitung. RFC 1962 stellte CCP-Verhandlung und Reset bereit, RFC 1661 die PPP-Phasen. RFC 3078 regelte den laufenden Paket- und Chiffrezustand.

Zwölf Bit bewahrten Position, nicht Inhalt

Der Kohärenzzähler stieg mit jedem Paket und sprang nach 4095 auf null. Der Empfänger verglich Beobachtung und Erwartung, um Lücken, Reihenfolge und notwendige Schlüsseländerungen zu bestimmen.

Im Feld lag keine Kopie des fehlenden Pakets. Es authentifizierte auch die Ursache nicht. Warteschlange, Filter, physischer Verlust, Umordnung oder aktive Manipulation konnten ähnliche Signale liefern. Selbst eine lückenlose Folge bewies nicht, dass die Anwendung jeden Klartext angenommen hatte.

RFC 3078 sagte, MPPE benötige keine zuverlässige Verbindung; der Reliable-Transmission-Mechanismus aus RFC 1663 bringe für die Synchronisierung meist nur zusätzlichen Aufwand. Das machte verlorene Daten nicht harmlos. Die Chiffremaschine konnte weiterlaufen, während höhere Schichten die Lücke noch reparieren mussten.

Nur ein festgelegter Bereich von PPP-Protokollen wurde verschlüsselt. Auch das Encrypted-Data-Bit war kein integritätsgeschützter Beweis. Eine Beobachtung „MPPE gesehen“ beantwortete weder, was geschützt werden sollte, noch ob der Klartext angekommen war.

Zustandslos hieß Schlüssel nachholen

Im zustandslosen Modus änderte sich der Sitzungsschlüssel bei jeder Zähleränderung, gewöhnlich also pro Paket. Der Sender änderte ihn vor dem Verschlüsseln, der Empfänger nach dem Lesen des Zählers und vor dem Entschlüsseln. Jedes verschlüsselte Paket trug FLUSHED.

Folgte auf zwei unmittelbar fünf, vollzog der Empfänger drei Schlüsseländerungen. Danach konnte er Paket fünf versuchen, ohne einen Reset anzufordern. Paket drei und vier wurden dadurch nicht rekonstruiert.

„Zustandslos“ bedeutete nicht, dass es keinen gemeinsamen Zustand gab. Anfangsschlüssel, Änderungsfunktion, Zählersemantik und Modus mussten übereinstimmen. Jedes Paket enthielt lediglich genug Grenzinformation, um den aktuellen Punkt lokal wieder aufzubauen.

Zustandsbehaftet machte den Rückweg zur Voraussetzung

Im zustandsbehafteten Modus änderte sich der Schlüssel an Paketen, deren niederwertiges Zähleroktett 0xFF betrug. Ging gerade dieses Flag-Paket verloren, wechselte der Sender, während der Empfänger zurückblieb. Ein späterer Zähler deckte die Abweichung auf, ohne sicheren Klartext zu liefern.

Reset-Request machte den Rückkanal zum Bestandteil der Erholung des Hinverkehrs. Eine einseitige Messung konnte Lücke und späteres FLUSHED sehen, aber nicht die konkrete Anfrage dieses Empfängers beweisen. Die Anfrage allein bewies weder Antwort noch ersten gültigen Klartext. Beide Richtungen und das Entschlüsselungsergebnis gehörten zusammen.

Der RFC warnte außerdem, dass die zustandsbehaftete Neuinitialisierung zwei Pakete mit demselben Schlüssel erzeugen könne. Daher sollte dieser Modus nicht in verlustreichen Umgebungen wie Layer-2-Tunneln über das Internet eingesetzt werden. Das war eine präzise Mechanismuswarnung, keine Einsatzstatistik.

Die Aushandlung selbst war nicht integritätsgeschützt

Ein aktiver Angreifer konnte die Supported Bits verändern und die scheinbare Stärke beeinflussen. Lokale Konfiguration konnte unerwünschte Modi ablehnen, machte den Austausch aber nicht authentisch.

Auch ein manipulierter Kohärenzzähler konnte die Peers desynchronisieren; das Umdrehen des Datenbits ermöglichte einen Denial of Service. Headerfelder waren Eingaben in die Zustandsmaschine, keine vertrauenswürdigen Auditbelege.

Historisch ist ebenso wenig aus „128 Bit“ eine moderne Empfehlung abzuleiten. RFC 4345 beschrieb später verbesserte Arcfour-Modi für SSH, also eine andere Konstruktion. Er zeigt, dass Schlüssellänge allein keine Sicherheitsbewertung ist, belegt aber keine MPPE-Migration oder heutige Verbreitung.

Der Beleg muss die ganze Kette erhalten

Zu bewahren sind PPP-Sitzung und Peers, Authentifizierung, Herkunft und Generation des Anfangsschlüssels ohne das Geheimnis, CCP-Angebote und Antworten, gewählte Stärke und Modus sowie Opened. Pro Richtung folgen erwarteter und beobachteter Zähler, Umlauf nach 4095, Lücken, FLUSHED, 0xFF-Grenzen, Verwerfungen, Reset-Request, Warteintervall und erster erfolgreicher Klartext.

Danach zählt die obere Schicht: Sequenz, Wiederholung, Bestätigung und Wirkung. Synchronisierte RC4-Tabellen brachten eine verlorene Nachricht nicht zurück.

Lu Hengs Trennung der Realitätsebenen hilft hier: Authentifizieren, Ableiten, Transportieren, Aushandeln, Empfangen, Verlust erkennen, Zustand herstellen, Entschlüsseln und Zustellen sind verschiedene Tatsachen. Laufender Code muss die Übergänge tatsächlich vollziehen.

Quellen