Zusammenfassung

  • RFC 3962 codierte die PBKDF2-Iterationszahl als vorzeichenlose Vier-Byte-Zahl in Big-Endian-Ordnung: Ein vorhandenes 00 00 00 00 bedeutete 4.294.967.296 Durchläufe, ein fehlendes Feld dagegen 4.096, nachdem der KDC es hätte liefern können.
  • Ein gefälschter hoher Wert konnte den Client auslasten, ein gefälschter niedriger Wert die Kennwortsuche verbilligen. Herkunft, Authentizität und lokale Grenzen waren deshalb ebenso wichtig wie der Zahlenwert.

Ein Decoder kann vier Nullbytes ohne Informationsverlust in die Zahl null verwandeln. In RFC 3962 wäre der nächste scheinbar harmlose Schritt gefährlich: null durch einen Standardwert zu ersetzen. Das Bitmuster war kein Platzhalter, sondern der teuerste darstellbare Auftrag.

Der String-to-Key-Parameter bestand aus vier Oktetten und stellte eine vorzeichenlose Big-Endian-Zahl dar. Diese Zahl gab die PBKDF2-Iterationen an. Für das vollständig leere Bitmuster definierte das Dokument 4.294.967.296 oder (2^{32}) Durchläufe. Damit war eins die kleinste ausdrückbare Zahl.

Fehlte das Feld, nachdem der KDC Gelegenheit gehabt hatte, es zu senden, galt 00 00 10 00, also 4.096. Diese Regel war weder eine allgemeine Empfehlung für die Kerberos-Datenbank noch ein Standard für optimistische Präauthentisierung. Sie beschrieb nur die Bedeutung einer Abwesenheit an dieser Protokollstelle.

Ein Datenmodell brauchte zwei Koordinaten

Der Datensatz bestand aus Anwesenheit und Inhalt. Frameworks, die null, leere Bytefolge, fehlende Eigenschaft und Zahlenwert null zusammenführen, veränderten hier das Verhalten um den Faktor 1.048.576. Ein Presence-Bit musste Parser, API, Cache und Persistenz überleben. Es war keine kosmetische Metainformation.

RFC 3962 erschien im Februar 2005 und setzte AES in den Rahmen von RFC 3961. Das Profil verwendete 128-Bit-Blöcke, Schlüssel mit 128 oder 256 Bit, CBC Ciphertext Stealing und HMAC-SHA1-96. Es erhielt die Verschlüsselungstypen 17 und 18 sowie die Prüfsummentypen 15 und 16. Das IANA-Register der Kerberos-Parameter führt sie bis heute. Eine Zuweisung belegt jedoch keine Aktivierung oder Auswahl in einem Realm.

PBKDF2 verarbeitete Kennwort und Salt zu einem temporären Schlüssel; danach leitete die RFC-3961-Funktion mit der Konstante kerberos den Protokollschlüssel ab. RFC 2898 lieferte die damalige PKCS-#5-Beschreibung, RFC 8018 später ihre Überarbeitung. Ein 256-Bit-Ausgabeschlüssel verleiht einem menschlichen Kennwort keine 256 Bit Entropie. Iterationen verteuern Versuche, ersetzen aber keine Unvorhersagbarkeit.

Der Regler ließ sich in beide Angriffsrichtungen drehen

Der Arbeitsfaktor multiplizierte den Aufwand des Angreifers und des rechtmäßigen Nutzers gleich. Wer ein Wörterbuch durchprobierte, zahlte mehr; wer das richtige Kennwort kannte, ebenfalls. Das machte die Zahl zu einer betrieblichen Abwägung statt zu einem einfachen Sicherheitsrang.

Ein Angreifer, der eine KDC-Antwort mit sehr hoher Zahl vortäuschte, konnte den Client lange eine falsche Ableitung berechnen lassen. RFC 3962 erlaubte zum Schutz vor diesem Denial of Service eine Obergrenze. Wenn es eine solche Grenze gab, sollte sie nicht unter 50.000 liegen. Für Milliarden Durchläufe blieb außerdem ein Abbruchmechanismus sinnvoll.

Mit einer künstlich niedrigen Zahl entstand der gegenteilige Vorteil. Der Angreifer konnte die Antwort des Clients beobachten und Kennwortkandidaten billiger prüfen. Das begründete eine Untergrenze. Die richtige Kontrolle bestand daher aus einem lokal verwalteten Intervall und einer Bewertung der Parameterquelle; weder blindes Akzeptieren noch maximales Hochdrehen reichte aus.

iterations=4096 ist für sich kein vollständiger Beleg. Der Wert kann aus einer authentisierten KDC-Nachricht, einer ungeschützten Fehlermeldung, einem Cache, lokaler Konfiguration oder der Abwesenheitsregel stammen. Ein Audit muss außerdem zeigen, dass die Grenzen vor dem Rechenbeginn geprüft wurden. Dieselbe Zahl kann Politik, Kompatibilität oder gegnerische Eingabe bedeuten.

Optimismus machte Aktualität zur Governance-Aufgabe

Bei optimistischer Präauthentisierung leitet der Client den Langzeitschlüssel ab und sendet einen geschützten Zeitstempel, bevor er aktuelle Parameter vom KDC abfragt. Stimmt die Annahme, spart er einen Umlauf. Ohne weitere Information kann er die Iterationszahl aber nur raten.

Selbst ein wenige Stunden zuvor für denselben Principal erfolgreicher Wert war nicht verlässlich. Das RFC erwartete, dass Betreiber den Arbeitsfaktor mit wachsender Rechenleistung anheben. Statt eine dauerhafte Universalzahl zu nennen, empfahl es deshalb standortbezogene Konfiguration innerhalb der Annahmegrenzen.

Die historische Aussage lautet nicht, dass 4.096 früher oder 50.000 heute richtig sei. Hardware und Angriffskosten wandern. Beständig bleibt die Zuständigkeit: Ein Wert braucht Eigentümer, Beobachtungszeit und Aktualisierungspfad. Wer die frische Abfrage optimiert, ersetzt Beobachtung durch Policy und muss diesen Tausch sichtbar machen.

Der fertige Schlüssel war noch kein erfolgreicher Login

Das Ende von PBKDF2 liefert Schlüsselmaterial. RFC 4120 definiert erst den weiteren Kerberos-V5-Ablauf mit Tickets, Authenticatoren, Frische und Replay-Behandlung. Eine Ableitung beweist weder das richtige Kennwort noch die Annahme durch den KDC, die Gültigkeit des Tickets oder die Berechtigung in einer Anwendung.

RFC 4537 trennte angebotene Verschlüsselungstypen von der serverseitigen Auswahl. RFC 6113 verallgemeinerte Präauthentisierung und Parametertransport. RFC 8009 definierte spätere AES/HMAC-SHA2-Profile, RFC 8429 stufte alte Verfahren herab. Keine dieser Änderungen machte eine Iterationszahl oder Ableitung zum Autorisierungsbeleg.

Ciphertext Stealing hatte noch eine getrennte Grenze. Weil kein zusätzliches Padding nötig war, verriet die Chiffratlänge die genaue Klartextlänge. Falls diese geheim bleiben sollte, musste eine höhere Schicht sie verschleiern. Mehr PBKDF2-Runden beseitigten dieses Leck nicht.

Eine belastbare Betriebsspur enthält Feldanwesenheit, Originalbytes, interpretierten Wert, Nachrichtenquelle und Authentizität, lokale Unter- und Obergrenze, Verschlüsselungstyp, Salt-Herkunft, Bibliotheksversion, Dauer, Ressourcen und Abbruch. Präauthentisierung, Ticket, Replay-Prüfung, Anwendungsfreigabe und Dienstergebnis folgen als getrennte Belege. Kennwort und Geheimschlüssel gehören nicht ins Protokoll.

Die RFC-Editor-Seite, die Datatracker-Historie und die Errata-Suche dokumentieren den Standard; bei der Erfassung lieferte die Suche keine Treffer. Das beschreibt den Aktenstand, nicht die Fehlerfreiheit jeder Implementierung.

Der auffällige Milliardenwert ist nicht die eigentliche Pointe. RFC 3962 zeigte, dass null, nicht vorhanden und Standard drei verschiedene Behauptungen sind. Wer sie normalisiert, verliert zugleich die Erklärung dafür, wer die Rechenlast aus welchem Grund angefordert hat.

Quellen