Zusammenfassung

  • RFC 3961 trennte den Basis- oder Protokollschlüssel vom konkreten Operationsschlüssel und verlangte eine von null verschiedene 32-Bit-Nutzungsnummer als Kontext.
  • Im vereinfachten Profil erzeugten Nutzungsnummer und Kennbyte getrennte Schlüssel für Prüfsumme, Verschlüsselung und Integrität; ein Erfolg belegte diese Kombination, nicht die nachgelagerte Berechtigung.

Die wichtigste Zahl in RFC 3961 war kein geheimer Wert. Sie durfte jedem Angreifer bekannt sein. Dennoch entschied sie, welcher Schlüssel aus demselben Ausgangsmaterial entstand. Das ist die historische Pointe der Kerberos-Nutzungsnummer: Sicherheit kam hier nicht aus Geheimhaltung des Kontextes, sondern aus seiner eindeutigen Benennung.

Das 2005 veröffentlichte Dokument löste Kryptosysteme aus der eigentlichen Kerberos-Protokollbeschreibung. Frühere Regeln stammten aus RFC 1510; RFC 4120 ersetzte später diesen Protokollstandard und verwies für Kryptofunktionen auf das eigene Rahmenwerk. Ein Verschlüsselungstyp musste Schlüssel- und Zustandsformat, String-to-Key, Random-to-Key, Ableitung, Ver- und Entschlüsselung, Integrität und PRF vollständig festlegen. Die etype-Nummer war nur sein Bezeichner.

Drei Funktionen, drei abgeleitete Schlüssel

RFC 3961 hielt Mehrfachnutzung desselben Schlüssels für riskant. Das konsumierende Protokoll sollte daher jeder Operation eine eigene vorzeichenlose 32-Bit-Zahl zuweisen; null war unzulässig. Das Kryptosystem erhielt Basisschlüssel und Nutzung, ohne dass die Anwendung die interne Schlüsselstruktur kennen musste.

Im vereinfachten Profil folgte auf die vier Byte der Nutzung ein Kennbyte. 0x99 leitete Kc für eigenständige Prüfsummen ab, 0xAA Ke für Verschlüsselung und 0x55 Ki für die Integritätsprüfung verschlüsselter Daten. Der Basisschlüssel sollte nur der Ableitung dienen. So wurde aus einer gemeinsamen Sitzung nicht eine gemeinsame Vollmacht für jede Nachrichtenart.

Die Sicherheitsbetrachtung nennt den Grund: Manche Implementierungen verwendeten dieselben Schlüssel für Kerberos v4 und v5. Eine Verschlüsselungsfunktion der älteren Version konnte dadurch zum Orakel gegen die neuere werden. Zufällige Confounder machten vorhersagbaren Klartext weniger brauchbar; Nutzungstrennung begrenzte die Übertragbarkeit einer Operation. Das RFC dokumentiert den Mechanismus, keine konkrete Schadensserie.

Was eine erfolgreiche Prüfung nicht sagte

Eine Entschlüsselung musste den Integritätstag prüfen und fehlerhafte Daten verwerfen. Erfolg bedeutete, dass Chiffrat, abgeleiteter Schlüssel, Nutzungsnummer und Tag zusammenpassten. Er bewies nicht selbst, wem der Basisschlüssel zustand, ob die Anwendung die normative Nutzung gewählt hatte, ob ein Ticket frisch war oder ob die angeforderte Handlung erlaubt wurde.

RFC 6113 setzte das Rahmenwerk später für allgemeine Präauthentisierung ein. Auch dort blieben Präauthentisierung, Ticketausgabe und Anwendungsentscheidung getrennt. Eine belastbare Spur verbindet Nachrichtentyp, angebotenen und gewählten etype, nicht geheime Schlüsselversion, Nutzung samt Spezifikationsstelle, Objekthash, Bibliotheksversion, Integritäts- und Replay-Ergebnis sowie Autorisierung und beobachtete Leistung.

Der Rahmen blieb, Algorithmen wechselten

RFC 3962 definierte AES-Typen nach diesem Modell. RFC 4537 trennte unterstützte Liste, lokale Auswahl und tatsächlich erzeugten Unterschlüssel. Das IANA-Register belegt Zuweisungen und Referenzen, nicht Einsatz oder Auswahl.

RFC 6649 verwarf Single-DES; RFC 8429 aktualisierte RFC 3961 und stufte weitere alte Verfahren herab. RFC 8009 blieb dem allgemeinen Rahmen treu, verließ aber das vereinfachte Profil, um Chiffrat vor der Entschlüsselung zu authentisieren. Die Schnittstelle überlebte ihre erste empfohlene Konstruktion.

Der RFC-Editor-Eintrag und die Datatracker-Akte belegen Status und Verlauf. Die Errata enthalten eine bestätigte Unicode-Korrektur, eine für Aktualisierung zurückgehaltene DES-Frage und einen abgelehnten Vorschlag. Kein Status ist allein Beleg eines Produktionsfehlers.

RFC 3961 machte damit aus „derselbe Schlüssel“ keine pauschale Aussage mehr. Erst Schlüssel, Nutzungsnummer, Profil und Nachricht ergaben einen kryptographischen Beleg. Über die Handlung danach entschied weiterhin die zuständige Anwendung.

Quellen