Zusammenfassung

  • Fällt die Prüfung des Response Authenticator einer Antwort fehl, muss ein RadSec-Client sie laut RADEXT-Entwurf 18 verwerfen und die (D)TLS-Verbindung dennoch offen halten. Dasselbe gilt für eine Antwort ohne noch ausstehende Anfrage. Das Dokument befindet sich in der IESG-Bewertung und ist kein verabschiedeter RFC.
  • Nach einem Timeout kann die ein Byte lange RADIUS-Kennung erneut vergeben werden. Die alte Antwort erreicht dann einen Client, der unter derselben Kennung bereits eine neue Anfrage verwaltet; die Prüfung scheitert im falschen Kontext. Die Ausnahme betrifft die Verbindung, nicht die Gültigkeit des Pakets und nicht echte Fehler beim Message-Authenticator.

Wer einen abgelehnten Response Authenticator sieht, sieht zunächst ein Urteil über ein Paket. Das ist noch kein Urteil über jede weitere Transaktion auf derselben TLS- oder DTLS-Verbindung. Ein Client wartet auf Anfrage A, gibt nach Ablauf der Frist ihre Kennung frei und sendet Anfrage B mit derselben Nummer. Antwort A kommt nachträglich. Die noch offene Anfrage B liefert den falschen Bezug für die Prüfung; Antwort A fällt durch. Das Paket gehört in den Papierkorb. Der bisherige Kurzschluss war, auch den geschützten Kanal abzubrechen.

Die am 30. September veröffentlichte Revision 18 von draft-ietf-radext-radiusdtls-bis löst diesen Kurzschluss an einer klar bezeichneten Stelle. Abschnitt 3.12 verpflichtet den Client, eine Antwort mit ungültigem Response Authenticator wegzuwerfen, die Verbindung aber aufrechtzuerhalten. Eine Antwort, zu der keine Anfrage mehr aussteht, wird ebenso behandelt. In Revision 17 stand die erste Störung noch bei den Gründen für einen Abbruch; bei der zweiten durfte die Implementierung wählen. Ein neuer Anhang A.1 erklärt den Wettlauf von Zeitüberschreitung, Kennungswiederverwendung und alter Serverantwort. Neu ist nicht die Erkenntnis, dass Sicherheit wichtig sei, sondern die engere Zuordnung einer Fehlermeldung zu ihrer Reichweite.

RFC 6613 macht den Bruch sichtbar. Für RADIUS/TCP musste eine Verbindung nach fehlerhaftem Response Authenticator geschlossen werden; bei einer Antwort ohne passende Anfrage war Schließen oder Offenlassen zulässig. Das Identifier-Feld umfasst ein Oktett, also 256 mögliche Werte pro Verbindung für gleichzeitig unterscheidbare Anfragen. Unter Last kann eine gerade frei gewordene Kennung rasch wieder verwendet werden. Der Server schickt womöglich die ältere Antwort ab, bevor er die neue Anfrage überhaupt erhalten hat. Unterschiedliche Zeitlimits in einem Proxy-Verbund liefern einen weiteren Weg zu verwaisten Antworten.

Die Quellen beschreiben ein mögliches Protokollverhalten, keinen nachgewiesenen Ausfall bei einem bestimmten Betreiber.

Die Gegenprobe ist unverzichtbar. Die beanstandete Antwort wird nicht akzeptiert. Ist ihr Response Authenticator bereits fehlgeschlagen, spielt eine zusätzliche Prüfung ihres Message-Authenticator für dieses verworfene Paket keine Rolle. Hat dagegen die Zuordnung zur Anfrage Bestand und scheitert der Message-Authenticator, bleibt der Verbindungsabbruch geboten. Auch einen nicht akzeptablen Client muss der Server sofort von (D)TLS trennen und bei RADIUS/TLS zusätzlich die TCP-Verbindung schließen. Ein pauschales Fehleretikett würde diese Unterschiede verdecken und entweder unnötige Unterbrechungen oder gefährliche Nachsicht begünstigen.

Für die Abnahme einer Implementierung ist deshalb eine Aufzeichnung mit Zustandsbezug nötig: Gab es noch eine passende Anfrage? Welche Prüfung schlug fehl? Wurde die Antwort tatsächlich verworfen? Konnte die Verbindung danach gültige Nachrichten verarbeiten? Der Entwurf empfiehlt Angaben zu Paketcode, Kennung und verletzter Regel im Log. Wenn die Verbindung bestehen bleibt, sollen Logs über ignorierte Pakete begrenzt werden, damit Diagnose nicht selbst zur Last wird. Eine solche abgestufte Testakte ist unsere redaktionelle Ableitung, kein neu festgelegtes IETF-Telemetrieschema.

Im Datatracker ist Revision 18 weiterhin ein aktiver RADEXT-Arbeitsgruppenentwurf in IESG Evaluation::AD Followup, eingereicht mit Zielstatus Proposed Standard. RFC 6614 und RFC 7360 würden erst bei Genehmigung ersetzt. Der konkrete Fortschritt liegt in einer engeren Regel: Eine Antwort kann ungültig sein, ohne dass aus diesem einen Befund die Vertrauenswürdigkeit des ganzen Kanals folgt.

Quellen