11.1. Unicast

11.1. Unicast

Un exemple typique serait une application d'appel vocal ou de vidéo à la demande.

Considérons un flux RTP bidirectionnel comme une session RTP. Il est possible pour les deux parties de partager la même clé maîtresse dans les deux directions selon les principes de la section 9.1. Le premier tour de la dérivation de clé divise la clé maîtresse en l'une ou toutes les clés de session suivantes (selon les fonctions de sécurité fournies):

SRTP_encr_key, SRTP_auth_key, SRTCP_encr_key, et SRTCP_auth key.

(Par souci de simplicité, nous omettons la discussion des sels, qui sont également dérivés.) Dans ce scénario, il suffira dans la plupart des cas d'avoir une seule clé maîtresse avec la durée de vie par défaut. Cela garantit une durée de vie suffisamment longue des clés et un ensemble minimal de clés en place pour la plupart des besoins pratiques. De plus, dans ce cas, la protection RTCP peut être appliquée en douceur. Sous ces hypothèses, l'utilisation du MKI peut être omise. Comme la dérivation de clé en combinaison avec une grande différence dans le débit de paquets dans les directions respectives peut nécessiter le stockage simultané de plusieurs clés de session, si le stockage est un problème, nous recommandons d'utiliser une dérivation de clé à faible débit.

Les mêmes considérations peuvent être étendues au scénario unicast avec plusieurs sessions RTP, où chaque session aurait une clé maîtresse distincte.