3. Motivation (Motivazione)

Sebbene in questo ambito esistano già lavori precedenti (ad es. Security Descriptions for SDP [RFC4568], Key Management Extensions [RFC4567] combinato con MIKEY [RFC3830] per autenticazione e scambio di chiavi), questa specifica è motivata come segue:

o TLS sarà usato per offrire sicurezza ai media orientati alla connessione. La progettazione di TLS è ben nota e le implementazioni sono ampiamente disponibili.

o Questo approccio gestisce il forking e l'early media senza richiedere il supporto di Provisional Response ACKnowledgement (PRACK) [RFC3262], preservando la importante proprietà di sicurezza che consente all'offerente di scegliere il materiale di chiave per cifrare il media.

o L'istituzione della protezione di sicurezza per il percorso media è fornita lungo il percorso media e non sul percorso di segnalazione. In molti scenari di dispiegamento, la segnalazione e il traffico media seguono percorsi diversi nella rete.

o Quando si usa la RFC 4474, questa soluzione funziona anche quando i proxy SIP a valle del servizio di autenticazione non sono fidati. Non è necessario rivelare le chiavi nella segnalazione SIP o nello scambio di messaggi SDP, come avviene in SDESCRIPTIONS [RFC4568]. In caso di retargeting di una richiesta che forma un dialogo (modifica del valore del Request-URI), l'agente utente (UA) che la riceve (lo User Agent Server, UAS) può avere un'identità diversa da quella nel campo intestazione To. Quando si usa la RFC 4916, è possibile fornire la propria identità all'UA peer tramite una richiesta nella direzione inversa, e tale identità può essere firmata da un Authentication Service.

o In questo metodo, le collisioni della synchronization source (SSRC) non comportano segnalazione SIP aggiuntiva.

o Molti endpoint SIP implementano già TLS. Le modifiche all'uso esistente di SIP e RTP sono minime anche quando si usa DTLS-SRTP [RFC5764].