Zusammenfassung

  • Bei Abläufen mit Antwort bildet RFC 2025 die Context ID aus randSrc des Initiators und anschließend randTarg des Ziels. Beide Seiten tragen damit zur Abgrenzung des neuen Kontexts gegenüber alten Kontexten bei.
  • Einseitiges SPKM-2 besteht nur aus SPKM-REQ. Das Ziel liefert keinen Zufallswert und muss der Frischebehauptung des Initiators vertrauen oder den Kontext ablehnen. key-src-bind stärkt eine Bindung, erzeugt aber keinen Beitrag des Ziels.
  • Schutz gegen Wiederholung beim Kontextaufbau und die optionalen Replay-/Sequenzdienste für spätere Nachrichten sind getrennte Ebenen. Eine Context ID beweist weder Autorisierung noch Zustellung oder Geschäftserfolg.

Eine Quittung mit zählbaren Verfassern

RFC 2025 beschreibt den Simple Public-Key GSS-API Mechanism, SPKM. Die Token für den Kontextaufbau enthalten viele Felder. Besonders aufschlussreich ist jedoch die Konstruktion der Context ID: Der Initiator liefert randSrc. Gibt es eine Antwort, fügt das Ziel randTarg hinzu. Die Verkettung beider Werte kennzeichnet danach den Sicherheitskontext in weiteren Token.

Die Herkunft bleibt ablesbar. Der Initiator erkennt am neuen Zielwert, dass das Ziel an diesem Austausch beteiligt war. Das Ziel weiß umgekehrt, dass sein gerade erzeugter Wert gemeinsam mit dem Wert des Initiators in die Kennung eingegangen ist. randSrc || randTarg ist damit eine beidseitige Quittung für eine eng begrenzte Aussage: Dieser Kontext ist mit hoher Wahrscheinlichkeit von früheren Kontexten getrennt.

Die Zufallswerte müssen laut RFC 2025 nicht unvorhersagbar sein. Entscheidend ist die sehr hohe Wahrscheinlichkeit, dass sie noch nie verwendet wurden. Es geht um Nichtwiederverwendung zwischen Kontexten, nicht um Geheimhaltung. Ein vermeintlich stärkerer Zufallswert erweitert die Aussagekraft nicht.

Wo die Antwort fehlt

SPKM-1 sieht stets eine Antwort des Ziels vor. Die einseitige Authentisierung nutzt SPKM-REQ und SPKM-REP-TI; bei gegenseitiger Authentisierung kommt SPKM-REP-IT hinzu. Gegenseitiges SPKM-2 enthält ebenfalls eine Antwort. In all diesen Abläufen kann das Ziel randTarg beisteuern.

Einseitiges SPKM-2 ist anders. Es endet nach einem einzigen SPKM-REQ. Ohne Rücktoken gibt es keinen Platz für randTarg; die Context ID besteht nur aus dem Wert des Initiators. RFC 2025 benennt die Folge: Das Ziel muss darauf vertrauen, dass dieser Wert frisch ist, oder den Kontext ablehnen.

Das ist mehr als eine eingesparte Netzrunde. Bei Abläufen mit Antwort kann die annehmende Seite ihren eigenen Nichtwiederverwendungsbeitrag in die gemeinsame Kennung einbringen. Im einseitigen Fall bewertet das Ziel nur die Behauptung des Initiators. Die Context ID bleibt als Kennung brauchbar, dokumentiert aber keine gemeinsam erzeugte Frische.

Was key-src-bind bindet

Für einseitiges SPKM-2 gibt es eine zusätzliche Sicherung. Bindet der gewählte Schlüsselaustauschalgorithmus den Quellnamen nicht selbst an den Kontextschlüssel, muss SPKM-REQ ein key-src-bind enthalten. Es handelt sich um einen MD5-Digest aus codiertem Quellnamen und vorgeschlagenem Kontextschlüssel.

Der Wert hilft dem Ziel, behauptete Quelle, empfangenes Token und vorgeschlagenen Schlüssel als zusammengehörig zu prüfen. Die RFC beschreibt ihn auch als Hilfe für das Vertrauen in die Frische von Token und Schlüssel. Er entsteht jedoch weiterhin innerhalb der Anfrage des Initiators. Er fügt keine Antwort hinzu, erzeugt kein randTarg und zeigt keinen frischen Beitrag des Ziels.

Bindung, Herkunft der Frische und gegenseitige Authentisierung sind unterschiedliche Tatsachen. Ein Datensatz mit nur einem Feld „Kontext aufgebaut“ verschmilzt sie zu einer Behauptung, die das Protokoll nicht macht.

Zwei Ebenen gegen Wiederholung

SPKM kann nach dem Aufbau auch Wiederholung und Reihenfolge geschützter Nachrichten prüfen. Diese Dienste arbeiten auf Anfrage der Anwendung mit Sequenznummern. Sie folgen nicht automatisch aus den Zufallswerten der Context ID.

Die allgemeine GSS-API-Spezifikation RFC 2743 behandelt Replay und Sequence pro Nachricht als auswählbare Kontextmerkmale. Der Aufrufer fordert sie an, der Akzeptor meldet die verfügbaren Dienste. Eine Implementierung kann Duplikate oder falsche Reihenfolge durch Zusatzstatus kennzeichnen und die fragliche Nachricht dennoch an den Aufrufer geben. Auch der Transport der Token bleibt Aufgabe der Anwendung.

Ein Audit muss deshalb zwei Fragen trennen: Wurde dieser Aufbauversuch gegenüber alten Versuchen abgegrenzt? Wurden spätere Nachrichten innerhalb des angenommenen Kontexts auf Duplikate und Reihenfolge geprüft? Für die erste Frage liefert die Context ID Hinweise. Für die zweite braucht man ausgehandelte Flags, Sequenzzustand und einzelne Prüfergebnisse.

Standardsgeschichte ohne Einsatzbehauptung

Der RFC Editor führt RFC 2025 als Proposed Standard vom Oktober 1996; die Errata-Suche zeigte zum Prüfzeitpunkt keinen veröffentlichten Eintrag. Im SMI-Register der IANA sind weiterhin Objektkennungen für SPKM-1, SPKM-2, SPKM-3 und SPKM-GSS-Token verzeichnet. Das belegt Spezifikations- und Vergabegeschichte, nicht heutigen Einsatz.

RFC 2847 definierte später SPKM-3 mit genannten Änderungen als äquivalent zu SPKM-1. Diese Verwandtschaft ordnet die Mechanismen historisch ein, ändert aber die Beweisgrenze von RFC 2025 nicht: Eine Context ID ist nur zusammen mit ihrem Austauschmuster verständlich.

Die belastbare Aussage ist knapp. randSrc || randTarg dokumentiert beidseitige Frischebeiträge. Die Context ID des einseitigen SPKM-2 dokumentiert nur den Beitrag des Initiators, auch wenn key-src-bind vorhanden ist. Keine Variante beweist allein Zertifikatsautorisierung, Algorithmuswahl, Nachrichtenlieferung oder den Abschluss eines Vorgangs.

Quellen