Zusammenfassung

  • RFC 5124 kombiniert das Feedback-Profil AVPF mit dem sicheren Profil SAVP zu SAVPF.
  • AVPF plant RTCP-Feedback; die SAVP-Schicht wendet danach SRTCP-Felder und kryptographische Verarbeitung an.
  • SRTCP-Integrität ist vorgeschrieben, doch Verschlüsselung ist ein eigener Dienst und kann als NULL konfiguriert sein.
  • In Gruppen kann ein gültiges Tag die Zugehörigkeit zum Schlüsselkreis belegen, ohne einen einzelnen Absender zu identifizieren.
  • Der Profilname beweist weder einen aktiven Schlüsselkontext noch die Annahme eines konkreten Pakets.
  • SRTCP vergrößert RTCP im beschriebenen Kontext ungefähr um 10 bis 20 Byte; das genannte Standardbeispiel beträgt 14 Byte.
  • avg_rtcp_size muss die geschützte Größe enthalten, weil sie die mögliche Feedback-Frequenz verändert.
  • In N <= B*T/R senkt ein größeres R die Zahl der innerhalb derselben Frist meldbaren Ereignisse.
  • Ein authentifiziertes Paket kann nach T_max_fb_delay eintreffen und für die Reparatur wertlos sein.
  • Sichere und unsichere Profilalternativen eröffnen Downgrade-Risiken; die Aushandlung selbst braucht Schutz.
  • Die Auswahl gilt je Medienbeschreibung, nicht pauschal für einen Anruf oder ein Produkt.
  • Führung braucht benannte Sicherheitsdienste und getrennte Belege für Wahl, Schlüssel, Paket, Zeit, Reaktion und Ergebnis.

Ein korrektes Tag mit zu großer Aussage

Der Empfänger prüft ein SRTCP-Paket. Das Authentifizierungs-Tag stimmt, der Index liegt im Replay-Fenster, und das Paket wird angenommen. Der Betrieb meldet daraufhin: „Feedback sicher und vom Sender bestätigt.“ Der erste Teil kann, je nach Konfiguration, zu breit sein; der zweite kann sachlich falsch sein.

RFC 3711 macht SRTCP-Integrität verpflichtend, weil manipulierte Kontrollinformationen den RTP-Strom stören könnten. Vertraulichkeit ist davon getrennt. Das Profil kennt NULL-Verschlüsselung. Ein gültiges Tag kann also Integrität und Replay-Bezug tragen, während der Kontrollinhalt offen bleibt.

Auch „Absender authentifiziert“ verlangt Kontext. Teilen mehrere Gruppenmitglieder Schlüsselmaterial, kann das Tag zeigen, dass ein Inhaber des Gruppengeheimnisses das Paket erzeugte. Es muss nicht zeigen, welcher. RFC 3711 weist darauf hin, dass die übliche Bezeichnung message authentication in manchen Gruppensituationen tatsächlich nur Integrität liefert.

Die ehrliche Anzeige nennt deshalb den Dienst: Integrität bestanden, Replay-Prüfung bestanden, Verschlüsselung AES oder NULL, Schlüsselmodell paarweise oder Gruppe, identifizierbarer Ursprung ja oder nein. Das Wort „sicher“ darf diese Felder zusammenfassen, aber nicht ersetzen.

Zwei Schichten, zwei Verantwortungen

AVPF aus RFC 4585 erweitert RTCP um Feedback-Formate und verändert die Senderegeln. SAVP aus RFC 3711 schützt RTP und RTCP. RFC 5124 kombiniert beide, ohne die obere Funktion umzuschreiben. AVPF entscheidet, wann ein Paket gesendet werden darf; SAVP verarbeitet es anschließend als SRTCP.

Alle RTCP-Pakete unter SAVPF müssen die SRTCP-Kapselung verwenden. Hinzu kommen Index, Authentifizierungs-Tag und gegebenenfalls MKI oder transformabhängige Felder. RFC 5124 nennt im damaligen Kontext wahrscheinlich 10 bis 20 Byte Zusatzlast und 14 Byte als Standardfall. Das ist keine ewige Konstante, sondern eine Warnung vor unsichtbarer Größe.

Die Variable avg_rtcp_size muss auf den geschützten Paketen beruhen. Sonst plant AVPF mit einer kleineren fiktiven Einheit und überschätzt, wie häufig ein Empfänger innerhalb des RTCP-Bandbreitenanteils berichten darf.

RFC 4585 fasst den Immediate-Bereich näherungsweise als N <= B*T/R zusammen. N steht für zu meldende Ereignisse, B für verfügbare RTCP-Bandbreite, T für das Intervall und R für die mittlere Paketgröße. Steigt R, passen bei unverändertem Budget weniger Ereignisse in die Zeit.

Schutz verbraucht dieselbe Reparaturfrist

Immediate Feedback bedeutet, dass praktisch jedes relevante Ereignis rechtzeitig gemeldet werden kann. Early RTCP erlaubt nur eine Auswahl, die dem Sender noch bei Anpassung oder Reparatur helfen kann. Im Regular-Modus ist ereignisbezogenes Feedback wegen Gruppengröße oder Zeitmaßstab nicht mehr sinnvoll.

Die Übergänge hängen nicht allein von Teilnehmerzahlen ab. Feedback-Typ, Paketfrequenz, Verlustverteilung, Codec, Ereignisrate, Bandbreite und geschützte Größe wirken zusammen. Ein längeres Authentifizierungs-Tag kann die Sitzung näher an eine Grenze bringen, ohne irgendeine kryptographische Prüfung scheitern zu lassen.

T_max_fb_delay bezeichnet die anwendungsspezifische Grenze, nach der Feedback keinen Nutzen mehr hat. RFC 5124 garantiert keine universelle Frist. Ein angenommenes SRTCP-NACK kann den Sender nach Ablauf des Wiedergabefensters erreichen. Dann ist der Sicherheitsnachweis positiv und der Zeitnachweis negativ.

Selbst rechtzeitige Annahme beweist keine Reparatur. Der Sender kann nicht retransmittieren, eine andere Anpassung wählen oder eine Wiederholung verlieren. Der Decoder kann den Referenzzustand nicht zurückgewinnen. Ereignis, Planung, Versand, Annahme, Senderaktion, Medienankunft, Decodierung und Darstellung gehören in getrennte Zeilen.

Der Schlüsselkontext ist nicht im SDP-Token enthalten

Der Betrieb eines SRTCP-Pakets setzt Algorithmen, Master- und Sitzungsschlüssel, Paketindex, Replay-Fenster, Gültigkeitszeit und gegebenenfalls MKI voraus. RTP/SAVPF in SDP benennt die beabsichtigte Profilfamilie. Es beweist nicht, dass diese Laufzeitwerte existieren oder übereinstimmen.

Ein Paket aus einer alten Schlüsselepoche kann nach einem Wechsel eintreffen und korrekt verworfen werden. Ein fehlender Kontext kann dieselbe sichtbare Folge erzeugen. Ohne Epochenkennung und Prüfergebnis bleibt nur die unbrauchbare Meldung „sicheres Feedback verloren“.

RFC 5124 fügt SAVP keine Sicherheitsleistung hinzu und nimmt keine weg. Es definiert weder einen neuen Cipher noch ein Schlüsselmanagement- oder Identitätssystem. MIKEY, SDP-Schlüsselverwaltung, Security Descriptions und das später standardisierte DTLS-SRTP behalten ihre eigenen Beweisgrenzen.

Vor dem Paket steht eine angreifbare Wahl

Ein Angebot kann sichere und unsichere Alternativen enthalten. RFC 5124 warnt vor bidding down und ähnlichen Angriffen. Werden beide Familien angeboten, muss die Aushandlungssignalisierung angemessen geschützt sein. Eine lokale Präferenz für SAVPF reicht nicht, wenn ein Angreifer den bevorzugten Eintrag löschen kann.

SRTCP beginnt erst nach Profilwahl und Schlüsselaufbau. Es kann ein vorher manipuliertes Angebot nicht rückwirkend beglaubigen. Deshalb braucht der Betrieb den geschützten Wortlaut des Angebots, die Reihenfolge, die Feedback-Attribute und die Antwort.

Für eine Medienbeschreibung sind AVP, AVPF, SAVP und SAVPF gegenseitig ausschließliche Wahlen. Unterstützt der Antworter ein angebotenes SAVPF nicht, muss er dieses Medium ablehnen. Will er SAVPF, obwohl es nicht angeboten wurde, muss er ebenfalls ablehnen und kann später ein Gegenangebot senden. Eine stillschweigende Umdeutung wäre kein gemeinsamer Beschluss.

Die Aushandlung erfolgt je Medium. Audio kann funktionieren, während Video abgelehnt wird. Verschiedene RTP-Sitzungen dürfen verschiedene Profile verwenden. Ein anrufweites Symbol verwischt diese zulässige Teilung.

Kompatibilität mit genauer Naht

SAVP- und SAVPF-Teilnehmer dürfen in derselben sicheren RTP-Sitzung zusammenarbeiten; AVP und AVPF dürfen es in einer unsicheren Sitzung. Sichere und unsichere Familien dürfen nicht in derselben Sitzung vermischt werden, weil RTP und SRTP dort keine kompatiblen Drahtformate sind.

Im von RFC 5124 beschriebenen RTSP-Ablauf wählt der Client in SETUP genau ein Profil je gewünschtem Strom, und der Server bestätigt oder verweigert. Ein Profilwechsel erfordert in diesem historischen Ablauf TEARDOWN und erneutes SETUP. Damit endet ein alter Transport- und Schlüsselzustand, bevor ein neuer bewiesen werden kann.

Bei nicht-interaktiven Ankündigungen per SAP, Web oder Mail fehlt die Antwort. Der Initiator trägt die Verantwortung für brauchbare Alternativen und sicheren Zugriff. Inline-Schlüssel nach RFC 4568 brauchen einen vertraulichen Verteilkanal. Ein anschließend korrektes SRTCP-Paket heilt keine zuvor offengelegte Schlüsselverteilung.

RFC 8866 löste später die alte SDP-Spezifikation ab, RFC 7826 die alte RTSP-Fassung; RFC 5763 und RFC 5764 lieferten späteren DTLS-SRTP-Kontext. Das sind Dokumentlebenszyklen, keine automatische Aktualisierung von RFC 5124 und kein Nutzungsnachweis.

Der RFC Editor führt RFC 5124 als Proposed Standard vom Februar 2008 ohne ausgewiesene Update- oder Obsolet-Beziehung. IANA kann Parameterzuweisung belegen. Die eingefrorenen Quellen nennen keine aktuelle Installation, keinen Herstellerfall, keine Verbreitungsquote und keine gemessene Medienverbesserung.

Quellen