5. Considérations relatives à la sécurité

Le profil SAVPF hérite de ses propriétés de sécurité du profil SAVP ; par conséquent, il est soumis aux considérations de sécurité discutées dans la RFC 3711 [4]. Par rapport au SAVP, le profil SAVPF n'ajoute ni ne supprime aucun service de sécurité.

Il existe un désir de supporter la sécurité pour les flux médiatiques et, en même temps, pour la compatibilité descendante avec les nœuds non-SAVP(F).

Les concepteurs d'applications doivent être conscients que la sécurité NE DEVRAIT PAS être échangée contre l'interopérabilité. Si des informations doivent être distribuées à des groupes fermés (c'est-à-dire protégées confidentiellement), il est RECOMMANDÉ de ne pas proposer d'alternatives pour une session médiatique autres que le SAVP et le SAVPF comme décrit dans les sections 3.3 et 3.4, à moins que d'autres mécanismes de sécurité ne soient utilisés, par exemple ceux décrits dans la section 9.1 de la RFC 3550 [1]. De même, si la protection de l'intégrité est considérée come importante, il est RECOMMANDÉ de ne pas proposer d'alternatives autres que le SAVP et le SAVPF, à moins que d'autres mécanismes ne soient connus pour être en place pour la garantir, par exemple des mécanismes de couche inférieure comme décrit dans la section 9 de la RFC 3550 [1].

Proposer simultanément des profils sécurisés et non sécurisés peut ouvrir la voie à des attaques de repli (bidding down). Par conséquent, un tel mélange d'offres de profils NE DEVRAIT PAS être fait.

Notez que les règles pour le partage des clés maîtresses s'appliquent comme décrit dans la RFC 3711 [4] (par exemple, section 9.1). En particulier, les mêmes règles pour éviter le "two-time pad" (réutilisation du flux de clés) s'appliquent : une clé maîtresse NE DOIT PAS être partagée entre différentes sessions RTP à moins que les SSRC utilisés ne soient uniques à travers tous les flux RTP des sessions RTP qui partagent la même clé maîtresse.

Lorsque 2^48 paquets SRTP ou 2^31 paquets SRTCP ont été sécurisés avec la même clé (selon l'événement qui se produit en premier), la gestion des clés DOIT être appelée pour fournir une ou plusieurs nouvelles clés maîtresses (les clés précédemment stockées et utilisées NE DOIVENT PAS essere riutilizzate), ou la session DOIT être interrompue.

Différentes sessions médiatiques peuvent utiliser un mélange de profils différents, incluant notamment un profil sécurisé et un profil non sécurisé. Cependant, mélanger des sessions médiatiques sécurisées et non sécurisées peut révéler des informations à des tiers et donc la décision de le faire DOIT être conforme à une politique de sécurité locale. Per esempio, la politica locale DEVE specificare se è accettabile avere, ad esempio, il flusso audio non protetto e il relativo video protetto.

Les considérations de sécurité de la RFC 4585 [3] sont également valables. Notez en particulier que l'application du profil SAVPF implique une protection obligatoire de l'intégrité sur le RTCP. Bien que cela résolve le problème des faux paquets provenant de membres n'appartenant pas au groupe, cela ne résout pas les problèmes liés à un membre malveillant agissant de manière inappropriée.