8. Security Considerations (Considerazioni di sicurezza)
Il media DTLS o TLS segnalato con SIP richiede un modo per assicurare che i certificati dei peer siano corretti.
La strategia TLS/DTLS standard autentica le parti assegnando al server (e opzionalmente al client) un certificato PKIX [RFC5280]. Il client verifica il certificato e che il nome corrisponda al dominio del server. Funziona perché i server sono pochi e ben nominati; in VoIP di solito no.
Questo progetto sfrutta l'autenticità del canale di segnalazione (senza richiedere riservatezza). Finché ciascun lato può verificare l'integrità dell'SDP ricevuto dall'altro, l'handshake DTLS non può essere dirottato con MITM. L'integrità dal chiamante al chiamato (Alice a Bob, sezione 7) è fornita facilmente con SIP Identity [RFC4474]. Altri meccanismi, come S/MIME in RFC 3261 o futuri, potrebbero servire.
Senza tali meccanismi la sicurezza è limitata alla difesa da attacchi passivi degli intermediari. Attacco attivo alla segnalazione più attacco attivo al piano media può compromettere la connessione (R-SIG-MEDIA in [RFC5479]).
8.1. Identità del rispondente
SIP Identity non supporta firme nelle risposte. Idealmente Alice vorrebbe sapere che l'SDP di Bob non è stato manomesso e da chi proviene, per mostrare una chiamata sicura verso Bob. [RFC4916] definisce come un UA fornisca la propria identità al peer, firmata dall'Authentication Service. Esempio: Bob risponde poi invia subito UPDATE con fingerprint e SIP Identity come [email protected]. Svantaggio: round trip in più dell'UPDATE. È semplice e sicuro anche se non tutti i proxy sono fidati; Bob deve fidarsi solo del suo proxy. Gli offerenti SHOULD supportare questo meccanismo e i rispondenti SHOULD usarlo.
Spesso i rispondenti non mandano UPDATE e del media parte prima dell'UPDATE. Allora manca integrità per il fingerprint da Bob ad Alice. Un attaccante sul percorso di segnalazione potrebbe alterare il fingerprint e inserirsi in MITM sul media. Alice saprebbe di avere una chiamata sicura con qualcuno, non se è Bob o un MITM. Bob saprebbe dell'attacco. Il fatto che un lato lo rilevi fa sì che, se entrambi vogliono la cifratura, spesso non ci sia problema. Bob potrebbe sempre rivelare il media ricevuto; si assume che voglia anche comunicazioni sicure. Senza azioni, Bob sa che il media non è stato alterato o intercettato da terzi ed è da [email protected]. Alice sa di parlare con qualcuno che probabilmente ha verificato assenza di intercettazione o alterazione. Meno che ideale ma usabile in molti casi.
8.2. SIPS
Senza SIP Identity ma con segnalazione protetta da SIPS, le garanzie sono più deboli. Resta qualche sicurezza se tutti i proxy sono fidati (integrità del fingerprint in modello a catena di fiducia). Se i proxy non sono fidati, il livello è limitato.
8.3. S/MIME
RFC 3261 [RFC3261] definisce S/MIME per SIP, utilizzabile per firmare che il fingerprint proviene da Bob. Sarebbe sicuro.
8.4. Continuità dell'autenticazione
Proprietà desiderata: garantire crittograficamente di parlare alla stessa persona di prima. Con DTLS si ottiene riusando la stessa chiave pubblica/certificato autofirmato per ogni connessione (almeno con un dato peer). Si può memorizzare nella cache la credenziale (o l'hash) e verificare che non cambi. Dopo una prima connessione sicura si può stabilire un canale futuro anche con segnalazione insicura.
Per la continuità le implementazioni SHOULD mirare a una chiave a lungo termine stabile. Le implementazioni che verificano SHOULD mantenere una cache della chiave per identità di peer e avvisare l'utente se cambia.
8.5. Short Authentication String
Alternativa: Alice e Bob usano la voce per verificare l'identità e confrontano a voce le impronte. Se imitare la voce e modificare l'audio è difficile, l'approccio è relativamente sicuro. Meno efficace per video o IM. DTLS supporta questa modalità. Lunghezza minima sicura dell'impronta circa 64 bit.
ZRTP [AVT-ZRTP] include la modalità SAS con bitstring per connessione dall'handshake; il SAS può essere di 25 bit ed è più facile da leggere. DTLS non lo supporta nativamente. In base all'interesse di dispiegamento, un'estensione TLS [RFC5246] potrebbe aggiungerlo. Gli schemi SAS funzionano bene quando i peer si riconoscono a voce, non sempre (es. call center).
8.6. Limiti delle asserzioni di identità
Con RFC 4474 per legare il materiale di chiave media alla segnalazione SIP, le garanzie su provenienza e sicurezza del media sono solo buone quanto la segnalazione. Due casi importanti:
o RFC 4474 assume che il proxy con certificato « example.com » controlli lo spazio dei nomi « example.com ». Il servizio di autenticazione autoritativo per uno spazio nomi può decidere quale utente ha quale nome; può trasferire un indirizzo da Alice a Bob: è una caratteristica intenzionale di RFC 4474 e conseguenza dell'architettura degli spazi nomi SIP.
o Con URI di numero di telefono (es. « sip:[email protected] ») non c'è ragione strutturale di fidarsi che il dominio sia autoritativo per il numero, se non per accordi privati. È strutturale: elementi PSTN sono fidati per assertire i numeri senza concetto chiaro di entità autoritativa su uno spazio numerico.
In entrambi i casi le assicurazioni DTLS-SRTP su integrità d'origine e riservatezza non possono superare quelle di SIP per l'integrità di segnalazione con RFC 4474. Gli implementatori non devono mostrare identità di peer fuorvianti nell'UI. Se l'identità è sip:[email protected], non basta mostrare +17005551008 senza policy che « chicago.example.com » sia fidato per gli E.164 che assertisce. Se l'UA determina chiaramente E.164, può essere meno confuso indicare chiamata cifrata verso peer sconosciuto.
Inoltre alcune middleboxes (B2BUA, SBC) modificano parti del messaggio SIP incluse nel calcolo della firma RFC 4474, rompendo la firma: proprio ciò che RFC 4474 deve rilevare. Se la middlebox può generare firme RFC 4474 valide (stesso dominio amministrativo del servizio di autenticazione), può firmare il messaggio modificato o un'altra identità che può assertire. Altrimenti il destinatario non può fare affidamento sull'assertion Identity e l'UA MUST NOT indicare all'utente una chiamata sicura verso l'identità dichiarata. Implementazioni configurate solo per chiamate sicure SHOULD terminare la chiamata in questo caso.
Senza SIP Identity o equivalente si ha solo protezione contro attaccanti che non possono modificare attivamente la segnalazione. Meglio dei meccanismi precedenti, ma inferiore all'integrità di segnalazione.
8.7. Certificati di terze parti
Questa specifica non richiede certificati degli endpoint verificabili indipendentemente (es. da terza parte fidata); non vieta certificati terzi. Oltre alla difficoltà di ottenerli, le identità nei certificati non sono chiare (convenzione S/MIME RFC 3261 poco dispiegata). In contesti chiusi o semi-chiusi con convenzione stabilita, i certificati terzi possono ridurre la dipendenza dal fidarsi dei proxy del dominio dell'endpoint.
8.8. Perfect Forward Secrecy
Il compromesso di una chiave a lungo termine potrebbe esporre comunicazioni passate. Per prevenirlo DTLS supporta modalità PFS con suite Diffie-Hellman e ECDH. Con queste modalità il sistema è protetto. Il compromesso può comunque consentire attacchi attivi futuri. Se è una preoccupazione, usare un canale di autenticazione di riserva (fingerprint manuale o stringa di autenticazione breve).