Zum Hauptinhalt springen

9. Security (Sicherheit)

Untere Protokollebenen können möglicherweise alle Sicherheitsdienste bereitstellen, die für RTP-Anwendungen gewünscht werden könnten, einschließlich Authentifizierung, Integrität und Vertraulichkeit. Diese Dienste wurden für IP in [27] spezifiziert. Da die ersten RTP nutzenden Audio- und Videoanwendungen einen Vertraulichkeitsdienst benötigten, bevor solche Dienste für die IP-Ebene verfügbar waren, wurde der im nächsten Abschnitt beschriebene Vertraulichkeitsdienst für die Verwendung mit RTP und RTCP definiert. Diese Beschreibung ist hier enthalten, um bestehende Praxis zu kodifizieren. Neue RTP-Anwendungen KÖNNEN diesen RTP-spezifischen Vertraulichkeitsdienst für Abwärtskompatibilität implementieren und/oder alternative Sicherheitsdienste implementieren. Der Overhead des RTP-Protokolls für diesen Vertraulichkeitsdienst ist gering, sodass die Strafe minimal sein wird, falls dieser Dienst in Zukunft von anderen Diensten obsolet gemacht wird.

Alternativ können andere Dienste, andere Implementierungen von Diensten und andere Algorithmen für RTP in der Zukunft definiert werden. Insbesondere wird ein RTP-Profil namens Secure Real-time Transport Protocol (SRTP) [28] entwickelt, um die Vertraulichkeit der RTP-Nutzlast zu bieten, während der RTP-Header im Klartext bleibt, sodass Link-Ebene-Header-Kompressionalgorithmen weiterhin operieren können. Es wird erwartet, dass SRTP für viele Anwendungen die richtige Wahl sein wird. SRTP basiert auf dem Advanced Encryption Standard (AES) und bietet stärkere Sicherheit als der hier beschriebene Dienst. Es wird keine Behauptung aufgestellt, dass die hier vorgestellten Methoden für einen bestimmten Sicherheitsbedarf geeignet sind. Ein Profil kann angeben, welche Dienste und Algorithmen von Anwendungen angeboten werden sollten, und kann Hinweise zu deren angemessener Verwendung geben.

Schlüsselverteilung und Zertifikate liegen außerhalb des Rahmens dieses Dokuments.

9.1 Confidentiality (Vertraulichkeit)​

Vertraulichkeit bedeutet, dass nur die vorgesehenen Empfänger die empfangenen Pakete decodieren können; für andere enthält das Paket keine nützlichen Informationen. Die Vertraulichkeit des Inhalts wird durch Verschlüsselung erreicht.

Wenn RTP oder RTCP gemäß der in diesem Abschnitt spezifizierten Methode verschlüsselt werden soll, werden alle Oktette, die für die Übertragung in einem einzigen Paket der unteren Ebene gekapselt werden, als Einheit verschlüsselt. Für RTCP MUSS eine für jede Einheit neu gezogene 32-Bit-Zufallszahl dem Paket vor der Verschlüsselung vorangestellt werden. Für RTP wird kein Präfix vorangestellt; stattdessen werden die Felder Sequenznummer und Zeitstempel mit zufälligen Versätzen initialisiert. Dies wird aufgrund schlechter Zufälligkeitseigenschaften als schwacher Initialisierungsvektor (IV) betrachtet. Zusätzlich, falls das nachfolgende Feld, der SSRC, von einem Gegner manipuliert werden kann, gibt es eine weitere Schwäche der Verschlüsselungsmethode.

Für RTCP KANN eine Implementierung die einzelnen RTCP-Pakete in einem zusammengesetzten RTCP-Paket in zwei separate zusammengesetzte RTCP-Pakete trennen, eines zu verschlüsseln und eines im Klartext zu senden. Beispielsweise könnten SDES-Informationen verschlüsselt werden, während Empfangsberichte im Klartext gesendet werden, um Drittanbieter-Überwacher zu unterstützen, die den Verschlüsselungsschlüssel nicht kennen. In diesem in Abb. 4 dargestellten Beispiel MUSS die SDES-Information an ein RR-Paket ohne Berichte (und die Zufallszahl) angehängt werden, um die Anforderung zu erfüllen, dass alle zusammengesetzten RTCP-Pakete mit einem SR- oder RR-Paket beginnen. Das SDES-CNAME-Element ist entweder im verschlüsselten oder im unverschlüsselten Paket erforderlich, aber nicht in beiden. Dieselbe SDES-Information SOLLTE nicht in beiden Paketen transportiert werden, da dies die Verschlüsselung kompromittieren kann.

            UDP-Paket                     UDP-Paket
  -----------------------------  ------------------------------
  [random][RR][SDES #CNAME ...]  [SR #senderinfo #site1 #site2]
  -----------------------------  ------------------------------
             verschlüsselt                     unverschlüsselt

  #: SSRC-Identifikator

      Abbildung 4: Verschlüsselte und unverschlüsselte RTCP-Pakete

Das Vorhandensein von Verschlüsselung und die Verwendung des korrekten Schlüssels werden vom Empfänger durch Header- oder Nutzlastgültigkeitsprüfungen bestätigt. Beispiele für solche Gültigkeitsprüfungen für RTP- und RTCP-Header sind in den Anhängen A.1 und A.2 gegeben.

Zur Konsistenz mit den bestehenden Implementierungen der ursprünglichen RTP-Spezifikation in RFC 1889 ist der Standardverschlüsselungsalgorithmus der Data Encryption Standard (DES)-Algorithmus im Cipher Block Chaining (CBC)-Modus, wie in Abschnitt 1.1 von RFC 1423 [29] beschrieben, außer dass die Auffüllung auf ein Vielfaches von 8 Oktetten wie für das P-Bit in Abschnitt 5.1 beschrieben angezeigt wird. Der Initialisierungsvektor ist Null, da Zufallswerte im RTP-Header oder durch das Zufallspräfix für zusammengesetzte RTCP-Pakete geliefert werden. Einzelheiten zur Verwendung von CBC-Initialisierungsvektoren finden sich in [30].

Implementierungen, die die hier spezifizierte Verschlüsselungsmethode unterstützen, SOLLTEN stets den DES-Algorithmus im CBC-Modus als Standardchiffre für diese Methode unterstützen, um die Interoperabilität zu maximieren. Diese Methode wurde gewählt, weil sich gezeigt hat, dass sie in experimentellen Audio- und Videowerkzeugen im Internet leicht und praktisch zu verwenden ist. DES wurde jedoch seitdem als zu leicht brechbar befunden.

Es wird EMPFOHLEN, stärkere Verschlüsselungsalgorithmen wie Triple-DES anstelle des Standardalgorithmus zu verwenden. Ferner erfordert sicherer CBC-Modus, dass der erste Block jedes Pakets mit einem zufälligen, unabhängigen IV derselben Größe wie die Blockgröße der Chiffre XOR-verknüpft wird. Für RTCP wird dies (teilweise) durch Voranstellen einer für jedes Paket unabhängig gewählten 32-Bit-Zufallszahl erreicht. Für RTP beginnen Zeitstempel und Sequenznummer mit Zufallswerten, aber aufeinanderfolgende Pakete werden nicht unabhängig randomisiert. Es sollte beachtet werden, dass die Zufälligkeit in beiden Fällen (RTP und RTCP) begrenzt ist. Anwendungen mit hohem Sicherheitsbedarf SOLLTEN andere, konventionellere Schutzmittel in Betracht ziehen. Andere Verschlüsselungsalgorithmen KÖNNEN für eine Sitzung durch Nicht-RTP-Mittel dynamisch spezifiziert werden. Insbesondere wird das auf AES basierende SRTP-Profil [28] entwickelt, um Known-Plaintext- und CBC-Plaintext-Manipulationsbedenken zu berücksichtigen, und wird in der Zukunft die richtige Wahl sein.

Als Alternative zur Verschlüsselung auf IP-Ebene oder auf RTP-Ebene wie oben beschrieben KÖNNEN Profile zusätzliche Nutzlasttypen für verschlüsselte Kodierungen definieren. Diese Kodierungen MÜSSEN angeben, wie Auffüllung und andere Aspekte der Verschlüsselung gehandhabt werden sollen. Diese Methode erlaubt es, nur die Daten zu verschlüsseln, während die Header für Anwendungen, die dies wünschen, im Klartext bleiben. Sie kann besonders nützlich für Hardwaregeräte sein, die sowohl Entschlüsselung als auch Decodierung handhaben. Sie ist auch wertvoll für Anwendungen, wo eine Link-Ebene-Kompression von RTP- und Header der unteren Ebenen gewünscht ist und die Vertraulichkeit der Nutzlast (aber nicht der Adressen) ausreicht, da die Verschlüsselung der Header die Kompression ausschließt.

9.2 Authentication and Message Integrity (Authentifizierung und Nachrichtenintegrität)​

Authentifizierungs- und Nachrichtenintegritätsdienste sind auf RTP-Ebene nicht definiert, da diese Dienste ohne eine Schlüsselverwaltungsinfrastruktur nicht direkt machbar wären. Es wird erwartet, dass Authentifizierungs- und Integritätsdienste von den unteren Protokollebenen bereitgestellt werden.