Zusammenfassung

  • RFC 5159 erschien im März 2008 als Informational RFC und registrierte vier SDP-Attribute aus OMA BCAST.
  • Die IETF koordinierte den SDP-Namensraum, während die OMA die Änderungshoheit über die technische Bedeutung behielt.
  • Registrierung verhinderte Namenskollisionen, zertifizierte aber keine Implementierung und keinen Einsatz.
  • bcastversion bezeichnete eine Version; ohne Integritätsschutz konnte das Feld einen Downgrade auslösen.
  • stkmstream verwies geschützte Medien auf zu verarbeitende Short Term Key Message Streams.
  • Eine korrekte Referenz lieferte keinen Schlüssel und belegte weder Berechtigung noch Entschlüsselung oder Wiedergabe.
  • Ein medienbezogener Wert ersetzte die Sitzungsliste, sodass der Geltungsbereich zum wirksamen Zustand gehörte.
  • Streamnummern waren nur innerhalb einer SDP-Sitzung eindeutig und keine dauerhaften Identitäten.
  • SRTPAuthentication wählte RCCm1, RCCm2 oder RCCm3, authentifizierte aber selbst kein Paket.
  • SRTPROCTxRate erklärte den ROC-Senderhythmus mit dem Standardwert eins, nicht den Empfangszustand.
  • Spätere Multiplexing-Einstufungen beschrieben Kopierverhalten und waren weder Sicherheitsnote noch Einsatznachweis.
  • Belastbare Prüfung trennt Register, semantische Fassung, Signalisierung, empfangenen Zustand und Medienergebnis.

Ein Register koordiniert Namen innerhalb einer Grenze

Protokollregister lösen ein konkretes gemeinsames Problem. Wenn verschiedene Organisationen Erweiterungen für SDP entwickeln, brauchen ihre Attribute eindeutige Namen und eine auffindbare Zuordnung. Sonst können zwei Implementierungen denselben Token für verschiedene Dinge verwenden oder denselben Mechanismus unter nicht kompatiblen Namen anbieten.

RFC 5159 registrierte bcastversion, stkmstream, SRTPAuthentication und SRTPROCTxRate. Damit wurden die Bezeichner im IANA-Raum stabil. Die technische Arbeit stammte jedoch aus OMA BCAST. Der RFC erläuterte deshalb, dass die OMA die Kontrolle über Änderungen an der Interpretation behielt.

Diese institutionelle Teilung ist kein Mangel. Sie ist ein bewusst begrenztes Zuständigkeitsmodell. Die IETF konnte einen Anschluss an SDP dokumentieren, ohne vorzugeben, die externe Spezifikation zu besitzen. Umgekehrt konnte die OMA die BCAST-Semantik entwickeln, ohne einen privaten SDP-Namensraum zu schaffen.

Problematisch wird es erst, wenn ein Registerbeleg mehr aussagen soll als diese Koordination. Eine aktuelle IANA-Zeile kann nicht allein bestimmen, welche OMA-Fassung ein historisches Gerät umgesetzt hat. Sie bestätigt auch nicht, dass das Gerät richtig arbeitete. Dafür braucht es die damalige Spezifikation, das Implementierungsprofil, die empfangene Sitzungsbeschreibung und Laufzeitbelege.

Ein Informational RFC war kein Einsatzstempel

Der Status Informational machte RFC 5159 nicht bedeutungslos. Er beschrieb eine konkrete Zuordnung und ermöglichte Interoperabilität. Er machte die Attribute aber auch nicht zu einem IETF-Standards-Track-Protokoll, dessen gesamte Semantik unter derselben Änderungskontrolle lag.

Der Text erwartete den Einsatz in Verbindung mit 3GPP MBMS, 3GPP2 BCMCS und DVB-H. Das war ein Entwurfskontext des Jahres 2008. Daraus folgt nicht, dass ein bestimmter Netzbetreiber die Attribute ausrollte, dass ein bestimmtes Endgerät sie verstand oder dass geschützte Inhalte erfolgreich wiedergegeben wurden.

Für einen Einsatznachweis wären erfasste SDP-Dokumente, Paketspuren, Geräteprotokolle, Herstellerangaben oder Betreiberbelege nötig. Für einen Wiedergabenachweis müsste die Kette bis zu Berechtigung, Schlüssel, installiertem Kryptokontext und Medienausgabe reichen. Eine erwartete Zielumgebung ersetzt keinen dieser Belege.

Die Streamkarte war nicht die Schlüssellieferung

stkmstream sollte Endgeräten Arbeit ersparen. In einem Multiplex mussten sie nicht jeden Kontrollstrom verarbeiten, sondern konnten den Short Term Key Message Streams folgen, die den ausgewählten geschützten Medien zugeordnet waren.

Mehrere Attribute konnten Alternativen oder mehrere benötigte Streams ausdrücken. Auf Sitzungsebene galt eine gemeinsame Liste; ein Wert in einem Medienabschnitt ersetzte sie für diesen Abschnitt. Die wirksame Zuordnung entstand somit erst nach der Auflösung von Wiederholung und Geltungsbereich.

Selbst eine fehlerfreie Zuordnung sagte nur, wo das Gerät suchen sollte. Nachrichten konnten fehlen, zu spät kommen oder die Integritätsprüfung nicht bestehen. Das Gerät konnte keine Berechtigung zum Entpacken besitzen. Ein gewonnener Schlüssel konnte in den falschen Kontext gelangen. Authentifizierung, Entschlüsselung oder Wiedergabe konnten später scheitern.

Wer stkmstream als Lieferbeleg behandelt, überspringt diese Grenzen. Richtig wäre je ein Beleg für Auswahl, Empfang, Prüfung, Berechtigungsentscheidung, Schlüsselentpackung, Zustandsinstallation und Medienergebnis.

Sitzungsnummern waren keine globalen Registerwerte

Der Streambezeichner war eine von null verschiedene Ganzzahl und musste innerhalb der SDP-Sitzung eindeutig sein. Diese lokale Eindeutigkeit genügte dem Empfänger der Beschreibung. Außerhalb der Sitzung durfte dieselbe Nummer eine völlig andere Bedeutung haben.

Wird stkmstream=5 ohne Sitzungsidentität in eine Datenplattform exportiert, verwandelt sich eine lokale Koordinate in einen scheinbaren Hauptschlüssel. Berichte können voneinander unabhängige Sitzungen verbinden. Außerdem kann ein abgeflachter Datensatz nicht mehr zeigen, ob der Sitzungswert durch einen Medienwert ersetzt wurde.

Ein belastbarer Export umfasst daher Beschreibungshash oder Version, Origin, Zeitpunkt, Medienabschnitt, wirksamen Geltungsbereich, Streamnummer und Endgeräteentscheidung. Erst dieses Bündel trägt die Bedeutung.

Eine angekündigte Sicherheitsregel war noch kein Ergebnis

SRTPAuthentication ordnete Zahlen den Verfahren RCCm1, RCCm2 und RCCm3 zu. Das Attribut teilte den Endpunkten mit, welche Regel vorgesehen war. Ob ein bestimmtes Paket authentisch war, konnte jedoch nur dessen Verarbeitung mit Schlüssel und passendem Zustand entscheiden.

SRTPROCTxRate erklärte, wie häufig der Sender den rollover counter übermittelte. Der zulässige Bereich lag zwischen 1 und 65535; bei fehlendem Attribut galt eins. Der ROC ergänzt den Sequenznummernraum. Verpassen oder verwerfen Empfänger die entscheidende Übermittlung, können die Endpunkte trotz identischer Konfiguration verschiedene Live-Zustände besitzen.

Prüfung muss den angekündigten Wert, tatsächlich beobachtete Kontrollpakete, deren authentifizierte Annahme, den installierten Zähler und die nachfolgenden SRTP-Ergebnisse verbinden. Ein gültig formulierter Parameter ist ein Syntaxbeleg, kein Zustandsbeleg.

Auch Metadaten brauchten Integrität

bcastversion wirkte wie ein harmloses Versionsschild. RFC 5159 warnte jedoch, dass eine ungeschützte Änderung einen Rückfall auf eine ältere Fassung bewirken konnte. Das Feld enthielt kein Geheimnis, steuerte aber die Auswahl sicherheitsrelevanter Regeln.

Ein manipuliertes stkmstream konnte das Gerät von benötigten Schlüsselnachrichten weglenken oder zu unnötiger Verarbeitung zwingen. Das Ergebnis wäre Dienstverweigerung. Damit gehörten die Wegbeschreibung und das Versionsschild zum Schutzbereich, nicht nur die Schlüssel.

Spätere Multiplexing-Regeln stuften bcastversion und stkmstream als NORMAL ein; die Kategorie der beiden SRTP-Attribute blieb unbestimmt. Diese Tabelle beantwortet eine Frage zum Verhalten beim Bündeln von Medien. Sie ist kein Gütesiegel für Kryptografie, Reife oder Verbreitung. Auch hier bleibt die Aussage des Registers begrenzt.

Quellen

  1. RFC 5159, HTML
  2. RFC 5159, Text
  3. RFC-Editor-Eintrag
  4. IETF-Datatracker-Eintrag
  5. Geschichte von RFC 5159
  6. Referenzen von RFC 5159
  7. Errata zu RFC 5159
  8. RFC 4566
  9. RFC 8866
  10. RFC 4771
  11. RFC 3711
  12. RFC 8859
  13. RFC 5761
  14. RFC 7201
  15. RFC 5764
  16. RFC 8126
  17. IANA-SDP-Parameter
  18. IPR-Offenlegung 2092
  19. RFC 2119
  20. RFC 8174
  21. RFC 3264
  22. Minimale Anfangsspezifikation
  23. Über Realitätsebenen
  24. Vorrang von laufendem Code