Zusammenfassung

  • draft-ietf-kitten-sasl-ht-02 beschreibt eine SASL-Familie mit zwei Nachrichten für schnelle Re-Authentisierung mittels kurzlebiger, ausschließlich ephemerer Shared Tokens.
  • Revision 02 ist ein aktiver KITTEN-Working-Group-Internet-Draft im WG Last Call, mit beabsichtigtem Status Proposed Standard und Ablauf am 24. Dezember 2026. Sie ist weder RFC noch Implementierungs- oder Deploymentnachweis.
  • Mindestens 128 Bit Entropie und korrekte HMACs belegen Eigenschaften des Tokens und seines Besitzes. Sie benennen nicht automatisch die richtige Anwendungssitzung, ihren Vorgängerzustand oder heutige Berechtigungen.
  • Belastbarer Betrieb hält Ausstellung, Mechanism Pin, TLS-Bindung, Initiator- und Responder-Beweis, Replay-Reservierung, Verbrauch, Widerruf, Autorisierung, Sitzungsgeneration und beobachtetes Ergebnis getrennt.

Zufälligkeit ist keine Zustandsadresse

Der anwendungsspezifische Mechanismus muss einen neu erzeugten Token mit mindestens 128 Bit Entropie liefern. Diese Forderung schützt gegen Erraten. Sie beantwortet nicht, zu welchem Dienst, Konto, Gerät oder Sitzungsobjekt der Token gehört.

Eine Wiederaufnahme benötigt mehr als ein Secret. Eine Nachrichtenanwendung braucht etwa Queue, Cursor, Abonnements und Bestätigungen. Eine Verwaltungsoberfläche braucht Lock, Entwurf, Policy-Version und offenen Vorgang. SASL-HT serialisiert diese Objekte nicht.

Wird beim Ausstellen nur das Secret gespeichert, kann ein Verifier später Besitz prüfen, aber keine Sitzungs-Linie. Ein gültiger Token kann dann die älteste noch auffindbare Sitzung, eine parallele Generation oder einen frischen Zustand öffnen. Kryptographisch ist das Ergebnis nicht widersprüchlich; betrieblich kann es falsch sein.

Der Ausstellungsbeleg sollte deshalb Vorgänger-Authentisierung, Subject, Service, beabsichtigten Mechanismus, Ausgabe-Epoche, Ablauf, Nutzungsgrenze, Session ID und Zielgeneration enthalten. Der Resume-Beleg nennt tatsächlich geladene Generation, Konfliktregel und Zustands-Hash.

Der Initiator beweist Besitz, der Responder eine zweite Richtung

Die Initiator-Nachricht enthält authcid, optionale Werte und einen HMAC über Initiator, Channel-Binding-Daten und diese Werte. Der Server berechnet ihn neu. Übereinstimmung authentisiert den Initiator; Abweichung muss scheitern.

Bei Erfolg sendet der Server eigene Werte und einen HMAC über Responder. Der Client muss ihn prüfen, damit gegenseitige Authentisierung entsteht. Ein Server-Log mit erfolgreichem ersten Vergleich beweist nicht, dass der Client die Antwort empfangen und den Peer authentisiert hat.

Bricht die Verbindung nach dem Senden ab, besitzt der Server einen Erfolg, der Client aber ein unbestimmtes Ergebnis. War der Token bereits reserviert oder verbraucht, kann der nächste Versuch korrekt abgelehnt werden. Ohne getrennte Zeitpunkte wirkt der Zustand wie ein Ausfall statt wie eine Folge der Sicherheitsregel.

Der Nachweis trennt Empfang, Vergleich, Reservierung, Antwortbildung, Versand, nachfolgende Client-Aktivität und Commit. Zwei Nachrichten reduzieren Round Trips; sie reduzieren nicht die Zahl der relevanten Zustandsübergänge.

Mechanism Pin und Channel Binding sind eigene Attribute

Die HT-Namen kombinieren Hash mit ENDP, UNIQ, EXPR oder NONE. Die ersten drei wählen verschiedene TLS-Bindungen. NONE setzt die Bindungsdaten leer. Ein gültiger HMAC unter NONE beweist keine Bindung, die nicht in seine Eingabe einging.

Monitoring muss den vollständigen Mechanismusnamen, TLS-Peer, Binding-Typ und einen sicheren Digest der Eingabe oder ihr ausdrückliches Fehlen behalten. Eine Policy, die EXPR fordert, darf NONE nicht nach erfolgreicher Mathematik als gleichwertig anzeigen.

Der Entwurf empfiehlt außerdem, den vorgesehenen SASL-Mechanismus bei Ausgabe zu signalisieren. Nutzung unter einem anderen Mechanismus muss scheitern. Diese Downgrade-Abwehr hängt an einem dauerhaft replizierten Pin im Token-Datensatz. Das Secret allein trägt ihn nicht.

Authentische Zusatzwerte sind noch keine Anweisung

Beide Nachrichten dürfen Key/Value-Paare tragen. Weil ihre Bytes in den HMAC eingehen, sind Integrität und Herkunft geschützt. Das ist nützlich für Downgrade-Hashes und anwendungsspezifischen Kontext.

Der HMAC definiert jedoch kein Schema. Er entscheidet nicht, ob ein Key bekannt, ein Wert typgerecht, eine Kombination zulässig oder der Absender für die behauptete Session-Generation autorisiert ist. Ein authentisches generation=4 kann veraltet oder fremd sein.

Die Anwendung braucht Allowlist, Version, Parser, Konfliktregel und Autorisierungsentscheidung. Der Beleg enthält Message-Digest, Schema-Version, Entscheidung und resultierenden Zustandswechsel. „Vom Token-Inhaber gesagt“ bleibt von „als Handlungsgrund zugelassen“ getrennt.

Kurzlebigkeit braucht Uhr, Zähler und Konvergenz

Der Entwurf empfiehlt begrenzte Lebensdauer nach Zeit oder Nutzung und einen Weg für Rotation oder Widerruf. Sein Beispiel widerruft den erfolgreich verwendeten Token. Das ist eine Ablaufidee, kein Beweis für einen replizierten Commit.

Zwei Knoten können denselben unbenutzten Datensatz lesen und gleichzeitig korrekte HMACs akzeptieren. Soll der Token einmalig sein, braucht die Plattform eine atomare Reservierungs- oder Verbrauchsgrenze über alle berechtigten Verifier — oder sie muss ehrlich eine begrenzte Mehrfachverwendung beschreiben.

Reservierung vor der Antwort kann bei Verlust einen Token verbrennen. Verbrauch danach öffnet ein Doppelannahmefenster. Die Wahl richtet sich nach dem möglichen Folgeschaden. Ein frischer Autorisierungscheck vor einer reversiblen neuen Sitzung ist anders als unmittelbare Wiederöffnung einer privilegierten Steuerfläche.

Die Empfehlung zu periodischer Vollauthentisierung begrenzt außerdem die Kette aus abgeleiteten Tokens. Ohne festgelegtes Intervall kann „periodisch“ im Betrieb verschwinden.

Early Data verschiebt die Reihenfolge, nicht die Zuständigkeit

Die Initiator-Nachricht darf in TLS-1.3-0-RTT-Daten stehen. Weitere Application Payload ist dort verboten; der Responder muss bei zusätzlicher Nutzlast abbrechen. Early Data kann wiederholt werden, daher muss der frühe Vorgang idempotent bleiben.

Ein wiederholbarer Authentisierungsbeweis macht eine Zahlung, Löschung oder Konfigurationsänderung nicht wiederholbar. Replay-Prüfung, Nutzungsreservierung und aktuelle Autorisierung müssen vor nicht idempotenter Arbeit abgeschlossen sein.

Auch eine schnelle Serverantwort bleibt nur ein Teil: Der Client prüft den Responder-HMAC, die Anwendung interpretiert Kontext und wählt Zustand. Weniger Netzwerkrunden bedeuten nicht weniger Autoritäten.

Authentisierung ist nicht authzid

Der Text sagt ausdrücklich, dass HT keine Authorization Identity übertragen und keine schützen kann. HT stellt Channel Binding bereit, keine SASL Security Layer. Der Erfolg identifiziert daher den Besitz bezogen auf authcid, nicht die heutige Befugnis für eine Operation.

Rollen können sich nach Ausgabe ändern. Ein gesperrtes Konto kann einen noch gültigen Token besitzen. Die Autorisierungsentscheidung muss gegen aktuellen Zustand laufen. Ebenso muss die Anwendung eine konkrete Session-Generation prüfen, statt Identitätserfolg mit Zustandskontinuität gleichzusetzen.

Ein vollständiger, aber geheimnisarmer Beleg verbindet Token-Record-ID, Aussteller, Vorgänger-Authentisierung, Subject, Service, Pin, Zeit und Nutzungslimit, TLS und Binding, beide Message-Digests, Zusatzschema, Replay-Reservierung, Widerruf, Policy-Version, geladene Generation, Operation und Beobachtung. Raw Token und wiederverwendbares Binding-Material bleiben geschützt.

Die Sprache folgt den Belegen: Besitz validiert; gegenseitige Prüfung abgeschlossen; Verbrauch in einem benannten Scope committed; aktuelle Policy genehmigte Transition; Anwendung beobachtete Resultat. Kein Satz ersetzt den nächsten.

Quellen