11.3. Re-keying and access control (Erneutes Schlüsseln und Zugriffskontrolle)
11.3. Re-keying and access control (Erneutes Schlüsseln und Zugriffskontrolle)
Das erneute Schlüsseln kann aufgrund von Zugriffskontrolle (z. B. wenn ein Mitglied während einer Multicast-RTP-Sitzung entfernt wird) oder aus rein kryptografischen Gründen (z. B. wenn der Schlüssel am Ende seiner Lebensdauer ist) auftreten. Bei Verwendung von SRTP-Standardtransformationen MUSS der Hauptschlüssel ersetzt werden, bevor einer der Indexräume für einen der Streams erschöpft ist, die von ein und demselben Hauptschlüssel geschützt werden.
Wie die Schlüsselverwaltung SRTP-Implementierungen neu verschlüsselt, liegt außerhalb des Umfangs, aber es ist klar, dass es unkomplizierte Möglichkeiten gibt, Schlüssel für eine Multicast-Gruppe zu verwalten. Beim Multicast mit einem Sender liegt es beispielsweise typischerweise in der Verantwortung des Senders, zu bestimmen, wann ein neuer Schlüssel benötigt wird. Der Sender ist die einzige Entität, die nachverfolgen kann, wann die maximale Anzahl von Paketen gesendet wurde, da Empfänger jederzeit der Sitzung beitreten und sie verlassen können, es kann Paketverlust und Verzögerung usw. geben. In anderen Szenarien als Multicast mit einem Sender können andere Methoden verwendet werden. Hier muss berücksichtigt werden, dass der Schlüsselaustausch eine kostspielige Operation sein kann, die für einen einzelnen Austausch mehrere Sekunden dauert. Daher wird einige Zeit bevor der Hauptschlüssel erschöpft ist/abläuft, eine Out-of-Band-Schlüsselverwaltung initiiert, die zu einem neuen Hauptschlüssel führt, der mit dem/den Empfänger(n) geteilt wird. In jedem Fall kann die Gruppenrichtlinie zur Aufrechterhaltung der Synchronisierung beim Wechsel zum neuen Schlüssel zwischen der Verwendung des MKI und des <From, To> wählen, wie in Abschnitt 8.1 beschrieben.
Für Zugriffskontrollzwecke werden die <From, To>-Perioden mit der gewünschten Granularität in Abhängigkeit von der Paketrate festgelegt. Das erneute Schlüsseln mit hoher Rate kann in einigen Szenarien mit großen Gruppen problematisch für SRTCP sein. Wie erwähnt, gibt es potenzielle Probleme bei der Verwendung des SRTP-Index anstelle des SRTCP-Index zur Bestimmung des Hauptschlüssels. Insbesondere kann es für kurze Zeiträume während des Wechsels von Hauptschlüsseln der Fall sein, dass SRTCP-Pakete nicht unter dem aktuellen Hauptschlüssel des entsprechenden SRTP stehen. Daher wird die Verwendung des MKI für das erneute Schlüsseln in solchen Szenarien bessere Ergebnisse erzielen.