Zusammenfassung

  • Ein individueller IETF-Entwurf sieht einen DNS-Eintrag mit Aussteller, OAuth-Client und eigens reservierter Token-Zielgruppe vor. Ein gültiger Eintrag macht den berechtigungsfreien Nachweis zur Pflicht.
  • Das Löschen des Eintrags widerruft den Agenten nicht. Neue Empfänger können ihn als unverknüpft behandeln; erst die Deaktivierung des Clients unterbindet neue Token, während alte noch gelten können.

Das Türschild wird abmontiert, und der neue Wachmann fragt womöglich nicht mehr nach dem Ausweis. Diesen unbequemen Effekt zeigt der Entwurf Agent DNS-OAuth Link vom 20. Oktober. Unter dem Agentennamen steht ein TXT-Eintrag _agent-oauth mit Kennung des Ausstellers, OAuth-Client und einer ausschließlich für den Nachweis bestimmten Zielgruppe. Der Eintrag ist ein Wegweiser, kein Abschaltknopf.

Der Agent holt sich ein JWT-Zugriffstoken bei seinem eigenen Autorisierungsserver und legt es dem Empfänger vor. Dieser liest DNS-Eintrag und öffentliche Schlüssel des Ausstellers und prüft Signatur, Client, Zielgruppe und Alter. Ein gültiger Eintrag verlangt das Token; ein ungültiger führt zur Ablehnung. Ohne Eintrag gilt die normale Politik für unverknüpfte Absender.

Das Token soll ausdrücklich nichts erlauben. Seine Zielgruppe darf kein Ressourcenserver als Zugangsrecht anerkennen. Der Name des Absenders muss über einen geschützten Kanal oder ein an seinen Schlüssel gebundenes Token, etwa nach DPoP, feststehen. Erst danach trifft der Empfänger seine eigene Zugangsentscheidung. Die Organisation am anderen Ende kann mit einem DNS-Eintrag nicht deren Berechtigungen festlegen.

Nun verschwindet der Eintrag. Ein neuer Empfänger sieht keine Verknüpfung und kehrt zu seiner gewöhnlichen Regel zurück. Ein Empfänger, der schon einmal eine gültige Verknüpfung sah, soll bei einer fehlgeschlagenen DNS-Abfrage weiter ein Token verlangen, bis eine erfolgreiche Abfrage das Entfernen bestätigt. Ein DNS-Ausfall darf die Prüfung nicht stillschweigend aushebeln. Im Abschnitt über Widerruf sagt der Entwurf selbst: Das Entfernen des Eintrags widerruft den Agenten nicht, sondern stoppt die Tokenpflicht bei neuen Empfängern.

Neue Token werden beim Aussteller gestoppt: Der Betreiber deaktiviert den OAuth-Client. Bereits ausgegebene Token bleiben bis zu ihrem Ablauf oder bis zur Altersgrenze des Empfängers nutzbar; DNS- und Schlüssel-Caches zählen für die wirksame Verzögerung mit. Allgemein empfiehlt der Entwurf höchstens 120 Minuten. Für Zahlungen, Handel oder schnelle Änderungen an Produktionssystemen nennt er kürzere 5 bis 15 Minuten als Beispiel. Einen gemessenen Einsatz meldet er nicht.

Auch die DNS-Antwort selbst kann angegriffen werden. Eine Fälschung könnte auf einen fremden Client zeigen, eine Unterdrückung die Verknüpfung verbergen. Der Entwurf empfiehlt Zonensignaturen und Validierung mit DNSSEC. Der IETF-Eintrag steht auf I-D Exists: ein individueller Vorschlag. Für eine Abschaltprobe müssen DNS-Löschung, Client-Deaktivierung und Ablauf des letzten alten Tokens getrennt ausgeführt werden.