12. Sicherheitsüberlegungen

RTP-Pakete mit dem in dieser Spezifikation definierten Nutzlastformat unterliegen den allgemeinen Sicherheitsüberlegungen in RTP [3], Abschnitt 9.

In typischen Streaming-Szenarien sind Nachrichtenauthentifizierung, Datenintegrität, Schutz vor Wiedergabe und Vertraulichkeit erwünscht.

Fehlende Authentifizierung kann Man-in-the-Middle- und Wiedergabeangriffe ermöglichen, die für RTP-Retransmission sehr schädlich sein können. Beispielsweise können manipulierte RTCP-Pakete unangemessene Retransmissionen auslösen, die den tatsächlich dem Originaldatenstrom zugewiesenen Bitrateanteil effektiv verringern; manipulierte RTP-Retransmission-Pakete könnten den Decoder des Clients zum Absturz bringen; manipulierte Retransmissionsanforderungen können den in Abschnitt 5 beschriebenen SSRC-Zuordnungsmechanismus ungültig machen. Wiedergegebene Pakete könnten zu falschen Umordnungs- und RTT-Messungen (nötig für die Retransmissionsanforderungsstrategie) führen und den Empfängerpuffer zum Überlauf bringen.

Um Vertraulichkeit der Daten zu gewährleisten, müssen die Originalnutzlastdaten verschlüsselt werden. Der 2-Oktett-Retransmission-Payload-Header muss tatsächlich nicht verschlüsselt werden, da er keine Hinweise auf den Dateninhalt liefert.

Es wird RECOMMENDED, dass die kryptografischen Mechanismen für dieses Nutzlastformat Schutz vor Known-Plaintext-Angriffen bieten. RTP empfiehlt, dass der anfängliche RTP-Zeitstempel zufällig sein SHOULD, um den Strom gegen Known-Plaintext-Angriffe zu schützen. Dieses Nutzlastformat folgt dieser Empfehlung nicht, da der anfängliche Zeitstempel der Medienzeitstempel des ersten retransmittierten Pakets ist. Da der anfängliche Zeitstempel des Originalstroms jedoch selbst zufällig ist, wäre bei Verschlüsselung des Originalstroms der Zeitstempel des ersten retransmittierten Pakets für einen Angreifer ebenfalls zufällig. Die Vertraulichkeit wäre daher nicht beeinträchtigt.

Wird Kryptografie genutzt, um Sicherheitsdienste für den Originalstrom zu liefern, MUST dieselben Dienste mit gleichwertiger kryptografischer Stärke für den Retransmission-Strom bereitgestellt werden. Die Verwendung desselben Schlüssels für retransmittierten und Originalstrom kann Sicherheitsprobleme verursachen, z. B. Two-Time-Pads. Siehe Abschnitt 9.1 des Secure Real-Time Transport Protocol (SRTP) [12] zur Diskussion von Two-Time-Pads und deren Vermeidung.

Zum Zeitpunkt der Abfassung dieses Dokuments bietet SRTP nicht alle genannten Sicherheitsdienste. Es gibt mindestens zwei Gründe: 1) das Auftreten von Two-Time-Pads und 2) die Tatsache, dass dieses Nutzlastformat typischerweise unter dem RTP/AVPF-Profil arbeitet, während SRTP nur RTP/AVP unterstützt. Eine angepasste SRTP-Variante soll diese Mängel künftig beheben.

Staukontrollüberlegungen bei Retransmission werden in Abschnitt 7 dieses Dokuments behandelt.