Zusammenfassung

  • nc zählt die Anfragen, die der Client nach eigener Aussage mit der in der Anfrage enthaltenen Server-Nonce gesendet hat. Erst der passende Zustand auf dem Server macht einen doppelten Wert zum Replay-Indiz.
  • Die Digest-Berechnung bindet den Zähler an abgeleitetes Credential-Material, Nonces und ausgewählte HTTP-Elemente. Sie macht daraus weder eine globale Kennung noch eine Autorisierung oder einen Ausführungsbeleg.
  • Folgenschwere Vorgänge brauchen zusätzlich eine dauerhafte Operations-ID und eine abrufbare Postcondition. Eine gültige erneute Authentifizierung beweist nicht, dass der frühere Versuch wirkungslos blieb.

Eine saubere Folge mit zu kleiner Zuständigkeit

Die erste Anfrage für eine Nonce trägt nc=00000001. Danach erhöht der Client den achtstelligen Hexadezimalwert. Verwahrt der Server eine eigene Zählung und sieht denselben Wert im verfolgten Kontext erneut, kann er ein Replay feststellen. Gerade diese geordnete Gestalt lädt dazu ein, den Wert mit einer Transaktionsfolge zu verwechseln.

Die Norm zählt jedoch nur, wie viele Anfragen der Client mit dieser Nonce gesendet haben will, einschließlich der aktuellen. Sie bestätigt weder die Annahme früherer Anfragen noch deren Verarbeitung durch dieselbe Instanz. Sie sagt nichts darüber, ob Anwendungszustand in derselben Reihenfolge geändert wurde. Außerhalb der Nonce ist der Wert nicht eindeutig.

Eine neue Server-Nonce eröffnet eine neue Folge. Andere Clients, Realms und Schutzräume besitzen eigene Folgen. Der Neustart bei eins ist deshalb kein Neustart der Geschäftshistorie. Er markiert einen anderen Authentisierungskontext. nc ordnet eine Anfrage innerhalb dieses Kontexts ein, nicht innerhalb aller Vorgänge eines Dienstes.

Auch als Replay-Beleg braucht der Wert Begleitdaten. Acht Stellen ohne Nonce, Client-Nonce, Identität, Realm und Serverentscheidung sind kaum auswertbar. Mit vollständigem Kontext belegen sie eine Authentisierungsentscheidung. Ob die Anwendung einen Commit vollzog, bleibt eine andere Frage.

Der Zähler ist nur so belastbar wie sein Zustand

RFC 7616 beschreibt Replay-Erkennung ausdrücklich als Vergleich mit einer serverseitig gehaltenen Kopie. Der Clientwert bezeugt sich nicht selbst. Seine Bedeutung hängt davon ab, wie der Server die Nonce erzeugt, begrenzt und wiedererkennt.

Die Nonce ist für den Client undurchsichtig und implementationsabhängig. Sie kann an Zeit, Ressource, Client oder Nutzungszahl gebunden sein. Eine Einmal-Nonce mit gespeichertem Verbrauch schützt auch gegen sofortiges Replay, verlangt aber mehr Zustand und stört pipelined requests. Eine länger gültige Nonce zusammen mit nc lässt mehrere Anfragen dasselbe Challenge-Material nutzen und behält einen großen Teil der Replay-Abwehr.

Deshalb existiert der Zähler nie ohne Betriebsarchitektur. Ein Cluster muss entscheiden, ob Replay-Zustand geteilt, repliziert oder aufgeteilt wird. Ein Failover oder Verlust dieses Zustands verändert, welche Wiederholung die Authentisierungsschicht erkennt. Bereits bestätigte Datenbankänderungen, Queue-Nachrichten oder externe Aufrufe werden dadurch weder zurückgenommen noch nachgewiesen.

Was die Digest-Formel tatsächlich umfasst

Bei aktivem qop fließen vom Passwort abgeleitetes Material, Server-Nonce, nc, Client-Nonce, qop und der Hash von A2 in den response-Wert ein. Unter qop=auth enthält A2 HTTP-Methode und Request-URI. Unter qop=auth-int kommt der Hash des entity body hinzu. Der Server kann damit die Kenntnis des Geheimnisses prüfen und bestimmte Wiederholungen oder Veränderungen erkennen.

Der Schutzbereich bleibt begrenzt. Selbst auth-int deckt die meisten HTTP-Header nicht ab; RFC 7616 warnt, dass ein Angreifer in der Mitte sie ändern kann. Digest verschlüsselt den übrigen Austausch nicht und sollte über HTTPS eingesetzt werden.

Zudem ist Authentisierung keine fachliche Autorisierung. Ein gültiger Digest stützt die Aussage, dass der Antragsteller das konfigurierte Geheimnis kennt. Ob diese Identität zahlen, löschen, signieren oder deployen darf, entscheidet die Anwendung anhand ihrer Rollen und ihres aktuellen Zustands.

Auch die Zuschreibung muss präzise bleiben. Rifaat Shekh-Yusef ist benannter Herausgeber und Mitautor des IETF-Konsensdokuments, nicht Erfinder jedes Bestandteils. Der Nonce-Zähler stand bereits in RFC 2617. RFC 7616 behielt ihn bei und ergänzte SHA-256, SHA-512/256, Algorithmusverhandlung, aktualisierte qop-Regeln, Userhash und deutlichere Sicherheitshinweise. Der Text betont zugleich, dass Algorithmusagilität Wörterbuchangriffe auf merkbare Passwörter nicht löst.

Gegenseitige Authentisierung ist noch keine Quittung

Eine Antwort kann Authentication-Info mit rspauth sowie cnonce und nc der zugehörigen Anfrage enthalten. So kann der Server Kenntnis des Benutzergeheimnisses zeigen; auth-int bringt begrenzte Integrität der Antwort. Das ist eine wertvolle Zuordnung im Authentisierungsprotokoll.

Sie benennt aber keine Zahlung, keinen Auftrag, keinen Commit und keine Kompensation. Der Server kann Digest prüfen, die Arbeit an einen Worker übergeben und die HTTP-Antwort verlieren, nachdem der Worker die Änderung festgeschrieben hat. Der Client erhält eine neue Nonce und authentisiert einen Retry korrekt. Zwei fehlerfreie Digest-Abläufe schließen eine doppelte fachliche Wirkung nicht aus.

Die fehlende Kontrolle gehört in die Anwendung. Ein Idempotenzschlüssel verbindet mehrere Versuche mit derselben beabsichtigten Operation, bevor die Wirkung entsteht. Eine Ergebnisabfrage unter dieser Kennung löst Ungewissheit nach einem Timeout. RFC 7616 definiert beides nicht; nc darf nicht nachträglich dazu umgedeutet werden.

Fünf Nachweise statt eines Erfolgsereignisses

Ein belastbarer Dienst hält Authentisierungserfolg, Replay-Entscheidung, fachliche Autorisierung, dauerhafte Operationsidentität und bestätigte Postcondition auseinander. Gegebenenfalls kommt der Nachweis hinzu, dass die Antwort den Client erreichte. Jeder Zustand kann unabhängig vom anderen scheitern.

Die disziplinierte Nutzung würdigt den Nonce-Zähler: Der Server schützt den Zustand, der den Vergleich ermöglicht, wählt bei hohem Risiko beschränkte Nonces, entscheidet qop nach dem nötigen Integritätsumfang und nutzt HTTPS. Danach endet die Aussagekraft. Ein Authentisierungszähler beobachtet das Geschäftsbuch nicht und kann es nicht ersetzen.

Quellen