5. Considerazioni sulla sicurezza

Il profilo SAVPF eredita le sue proprietà di sicurezza dal profilo SAVP; pertanto, è soggetto alle considerazioni sulla sicurezza discusse nella RFC 3711 [4]. Rispetto al SAVP, il profilo SAVPF non aggiunge né toglie alcun servizio di sicurezza.

Vi è il desiderio di supportare la sicurezza per i flussi multimediali e, allo stesso tempo, la compatibilità all'indietro con i nodi non-SAVP(F).

I progettisti di applicazioni dovrebbero essere consapevoli che la sicurezza NON DOVREBBE essere scambiata con l'interoperabilità. Se le informazioni devono essere distribuite a gruppi chiusi (ovvero protette con riservatezza), si RACCOMANDA di non offrire alternative per una sessione multimediale diverse da SAVP e SAVPF come descritto nelle Sezioni 3.3 e 3.4, a meno che non vengano utilizzati altri meccanismi di sicurezza, ad esempio quelli descritti nella Sezione 9.1 della RFC 3550 [1]. Allo stesso modo, se la protezione dell'integrità è considerata importante, si RACCOMANDA di non offrire alternative diverse da SAVP e SAVPF, a meno che non si sappia che sono in atto altri meccanismi in grado di garantirla, ad esempio meccanismi di livello inferiore come descritto nella Sezione 9 della RFC 3550 [1].

Offrire contemporaneamente profili sicuri e non sicuri può aprire ad attacchi di bidding down (declassamento). Pertanto, tale combinazione di offerta di profili NON DOVREBBE essere effettuata.

Si noti che le regole per la condivisione delle chiavi master si applicano come descritto nella RFC 3711 [4] (ad esempio, Sezione 9.1). In particolare, si applicano le stesse regole per evitare il "two-time pad" (riutilizzo del keystream): una chiave master NON DEVE essere condivisa tra diverse sessioni RTP a meno che gli SSRC utilizzati non siano unici in tutti i flussi RTP delle sessioni RTP che condividono la stessa chiave master.

Quando sono stati messi in sicurezza 2^48 pacchetti SRTP o 2^31 pacchetti SRTCP con la stessa chiave (a seconda di quale evento si verifica per primo), deve essere chiamata la gestione delle chiavi per fornire una o più nuove chiavi master (le chiavi precedentemente memorizzate e utilizzate NON DEVONO essere riutilizzate), oppure la sessione DEVE essere interrotta.

Diverse sessioni multimediali possono utilizzare un mix di profili diversi, includendo in particolare un profilo sicuro e un profilo non sicuro. Tuttavia, mischiare sessioni multimediali sicure e non sicure può rivelare informazioni a terzi e quindi la decisione di farlo DEVE essere in linea con una politica di sicurezza locale. Ad esempio, la politica locale DEVE specificare se è accettabile avere, ad esempio, il flusso audio non protetto e il relativo video protetto.

Anche le considerazioni sulla sicurezza nella RFC 4585 [3] sono valide. Si noti in particolare che l'applicazione del profilo SAVPF implica la protezione obbligatoria dell'integrità su RTCP. Sebbene ciò risolva il problema dei pacchetti falsi provenienti da membri non appartenenti al gruppo, non risolve i problemi relativi a un membro malintenzionato che agisce in modo improprio.