Zusammenfassung

  • RFC 3329 ließ SIP-Teilnehmer Mechanismen aushandeln, den bevorzugten gemeinsamen Mechanismus aktivieren und danach die vollständige statische Serverliste unter diesem Schutz als Security-Verify zurücksenden.
  • Der Abgleich machte Kürzungen, Umstellungen oder Parameteränderungen erkennbar. Er schützte das erste Angebot nicht nachträglich; die Sicherheitsgrenze blieb die schwächste zugelassene Option mit Integritäts- und Replay-Schutz.

Der erste Filter durfte die spätere Wahl verändern

Bei einer Kompatibilitätsverhandlung sieht eine gekürzte Liste zunächst nach einem gewöhnlichen Unterschied aus. Ein SIP-Server kann TLS und Digest anbieten, während ein Client beide kennt. Entfernt ein Zwischenknoten TLS aus der noch ungeschützten Antwort, bleibt Digest als gemeinsame Option. Beide Enden können weitermachen, ohne zu erfahren, dass ihre gemeinsame Grundlage unterwegs verändert wurde.

Genau darin unterschied sich der Angriff von einem offensichtlichen Verbindungsabbruch. Der Dienst konnte scheinbar funktionieren, nur unter einer schwächeren Vereinbarung als beabsichtigt. Und die naheliegende Forderung, schon die erste Liste zu schützen, lief ins Leere: Der Schutz sollte erst aus einer Liste ausgewählt und eingerichtet werden. Er konnte die Auswahl, die ihn erst möglich machte, nicht bereits voraussetzen.

RFC 3329 legte deshalb eine spätere Kontrollstelle fest. Der User Agent schickte Security-Client an seine nächste SIP-Station. Der Server antwortete mit Security-Server: einer statischen Liste seiner Mechanismen und dem Material für deren Einrichtung. Der Client nahm den ihm bekannten gemeinsamen Mechanismus mit der höchsten Serverpräferenz, aktivierte ihn und sandte eine weitere Anfrage. Darin spiegelte Security-Verify die zuvor empfangene Serverliste.

Der Server verglich die zurückgekehrte Fassung mit seiner eigenen Referenz. Gleiche Namen allein genügten nicht; Reihenfolge und Parameter gehörten dazu. Hatte der Server vier Einträge gesendet und der Client wegen einer entfernten Option nur drei zurückgegeben, war der Befund eindeutig: Die Liste, auf die sich die Auswahl stützte, entsprach nicht mehr dem statischen Angebot. Der Server setzte diesen Versuch nicht einfach fort.

Das ist kein nachträgliches Siegel auf der ersten Antwort. Die Manipulation konnte weiterhin vor dem Aufbau der Schutzbeziehung stattfinden. Der Unterschied lag im nächsten Schritt: Sollte auch der Server die verkürzte Liste akzeptieren, musste der Angreifer nun zusätzlich die Rückgabe in einer aktiven Schutzbeziehung fälschen. Aus dem billigen Entfernen einer Zeile wurde ein Angriff auf Integrität und Replay-Schutz des gewählten Mechanismus.

Ohne unabhängige Serverliste wäre der Abgleich zirkulär

Eine Prüfung hätte wenig Wert, wenn der Server seine Liste passend zur Clientliste zusammenstellte. Ein Angreifer könnte erst Security-Client verkürzen; der Server gäbe nur die verbleibenden Optionen zurück; der Client wiederholte genau diese Antwort. Der spätere Vergleich wäre stimmig und würde doch lediglich eine bereits beeinflusste Ausgangslage bestätigen.

Darum durfte die Serverliste nicht vom Inhalt des Clientangebots abhängen. Sie musste für den jeweiligen Geltungsbereich statisch sein. Ein Server konnte verschiedene Listen für verschiedene Netzschnittstellen führen. „Statisch“ hieß also nicht, dass ein Betreiber überall dieselbe Policy verwenden musste. Es hieß, dass die für diesen Zugriff geltende Referenz schon feststand, bevor die konkrete Clientliste eintraf.

Die Prioritäten selbst waren Teil der Daten. Unterschiedliche q-Werte bestimmten die Reihenfolge; der Client wählte den ihm bekannten gemeinsamen Mechanismus mit dem höchsten Serverwert. Die Liste des Clients blieb dennoch dessen eigene Aussage über seine Fähigkeiten. Wird sie verändert, kann notwendiges Einleitungsmaterial fehlen oder jede Seite auf eine andere Wahl kommen. Ein solcher Abbruch ist mit einem Angriff vereinbar, beweist ihn aber nicht. Veraltete Konfiguration oder fehlende Interoperabilität können genauso aussehen.

Das Verfahren hielt die SIP-Serverseite bei der Listenprüfung zustandsarm. Beim geschützten Folgeaufruf konnte sie den Rücklauf unmittelbar gegen die statische Liste halten, statt pro Client einen besonderen Challenge-Zustand zu speichern. Die zugrunde liegende Verbindung war damit nicht zustandslos: TLS kann beendet werden, IKE-SA haben eine Laufzeit, und Digest kann eine neue Challenge benötigen. Eingespart wurde der Zusatzspeicher für den Listenabgleich, nicht die Verwaltung der Sicherheit selbst.

421 und 494 waren Wegweiser, keine Urteile

Im clientinitiierten Ablauf trug die ungeschützte erste Anfrage Security-Client sowie Require und Proxy-Require mit sec-agree. Der Server antwortete mit 494 Security Agreement Required und seiner Liste, selbst wenn beide Seiten keinen Mechanismus gemeinsam hatten. So blieben Serverpolitik und Verhandlungsergebnis unterscheidbar.

Auch ein Server konnte die Erweiterung aufgrund lokaler Policy verlangen. Hatte der Client keine Unterstützung angekündigt, war 421 Extension Required vorgesehen. Hatte er sec-agree bereits angekündigt, aber den Schutz noch nicht ausgehandelt, kam 494 zum Einsatz. Die Codes erklärten den Protokollzustand. Sie belegten weder einen Angriff noch dessen Urheber. Ein alter Client, ein verlorenes Option-Tag, eine abgelaufene Konfiguration, eine fehlende Startinformation oder ein Eingriff konnten zur gleichen Stelle führen.

Der Geltungsbereich blieb auf User Agent und nächsten SIP-Knoten begrenzt, meist den ersten beziehungsweise ausgehenden Proxy. Bei serverinitiierter Aushandlung musste die Anfrage genau einen Via-Eintrag haben; mehrere bedeuteten, dass der Server nicht der erste Hop war und die Prozedur dort nicht anwenden durfte. Das war keine durchgehende Sicherung des Gesprächs, der vollständigen Proxy-Kette oder des Nachrichtenkörpers.

Auch der Start hing vom Mechanismus ab: TLS verwendete die SIP-Regeln zur Serverermittlung; Digest bezog die Serverliste in seine Verifikation ein; ipsec-ike versuchte eine IKE-Verbindung; manuell konfiguriertes IPsec setzte Schlüssel und Regeln außerhalb des SIP-Austauschs voraus. RFC 3310 ergänzte Digest um AKA, ersetzte aber nicht das Zurücksenden und Vergleichen der Serverliste.

Der Kompatibilitätsrest bestimmte das Sicherheitsminimum

Die Sicherheitsbedingung der RFC ließ wenig Spielraum: Selbst der schwächste noch angebotene Mechanismus musste Integrität und Replay-Schutz für Security-Verify bieten. War er durch einen Angreifer zu brechen, durfte er nicht weiter angeboten werden. Die Aushandlung konnte einen simplen Downgrade erschweren; sie konnte eine ungeeignete Option nicht dadurch stärken, dass beide Enden ihr zustimmten.

Ein erfolgreicher Abgleich war zudem kein Nachweis für Vertraulichkeit. Digest verschlüsselte den SIP-Inhalt nicht. TLS schützte eine Hop-Verbindung, nicht automatisch jede folgende Station. Bei IPsec entschieden die tatsächlich eingerichtete Assoziation und ihre Regeln. Ein übereinstimmender Rücklauf bewies die Entsprechung zur Serverliste an genau diesem Vergleichspunkt. Er bewies weder, dass alle angebotenen Verfahren gestartet wurden, noch dass jedes davon heutigen Anforderungen genügt.

Der historische Stand musste mitwandern. RFC 3329 erschien im Januar 2003. RFC 8996 aktualisierte es später und untersagte TLS 1.0 sowie 1.1; RFC 8446 beschreibt TLS 1.3 und RFC 7616 die überarbeitete HTTP-Digest-Authentifizierung. Ein Mechanismenname im IANA-Register ist dabei nur ein verwalteter Name, kein Nachweis für tatsächlichen Einsatz oder Sicherheit.

Auch die Errata markieren eine Grenze zwischen Beispiel und Regel. Zwei Beispiele setzen Security-Verify in eine ACK-Anfrage, obwohl die Tabelle zur Headerverwendung ACK als nicht anwendbar führt; die redaktionelle Korrektur steht noch aus. Ein bestätigtes Erratum änderte die SPI-Länge für ipsec-3gpp von genau zehn auf eine bis zehn Ziffern. Für die normative Verwendung zählt nicht die unbereinigte Beispielzeile.

RFC 3329 machte den ersten, ungeschützten Austausch nicht vertrauenswürdig. Es verlangte, die damalige Serverofferte nach Aktivierung einer Schutzbeziehung zurückzutragen und exakt gegen eine unabhängige Referenz zu prüfen. Das ist ein wirksames Muster gegen stilles Streichen — aber weder ein Gütesiegel für die gewählte Option noch ein Ersatz für die Entscheidung, welche schwache Kompatibilität man weiterhin zulässt.

Quellen