Appendix A. Requirements Analysis (Analisi dei requisiti)
[RFC5479] descrive i requisiti di sicurezza per il materiale di chiave media. Questa sezione valuta questa proposta rispetto a ciascun requisito.
A.1. Forking e retargeting (R-FORK-RETARGET, R-BEST-SECURE, R-DISTINCT)
In questo documento l'offerta SDP (nell'INVITE) è solo un annuncio di capacità di sicurezza. Non dipende dall'identità del peer; forking e retargeting funzionano quando tutti gli endpoint supportano SRTP. Con endpoint misti SRTP/non-SRTP si usa il meccanismo di capacità SDP in definizione [MMUSIC-SDP] per negoziare la sicurezza in modo trasparente dove possibile. Poiché DTLS stabilisce una nuova chiave per sessione, solo l'entità con cui la chiamata viene stabilita ottiene le chiavi di cifratura media (R3).
A.2. Contesti crittografici distinti (R-DISTINCT)
DTLS esegue un nuovo handshake con ogni endpoint, stabilendo chiavi e contesti crittografici distinti.
A.3. Riutilizzo di un contesto di sicurezza (R-REUSE)
DTLS consente la ripresa di sessione con la funzionalità di ripresa sessione TLS, riducendo il carico crittografico quando due peer ristabiliscono la comunicazione. Vedi [RFC5764].
A.4. Clipping (R-AVOID-CLIPPING)
Poiché l'establishment delle chiavi avviene nel piano media, il media non deve essere tagliato prima della risposta SDP. Fino alla risposta all'offerente è garantita solo la riservatezza: il rispondente sa di non inviare a un attaccante; l'offerente non sa di ricevere dal rispondente.
A.5. Attacchi passivi sul percorso media (R-PASS-MEDIA)
Gli algoritmi a chiave pubblica delle suite DTLS (RSA, DH, ECDH) resistono agli attacchi passivi.
A.6. Attacchi passivi sul percorso di segnalazione (R-PASS-SIG)
DTLS protegge da avversari passivi sul segnale perché si scambia solo un fingerprint via SIP.
A.7. (R-SIG-MEDIA, R-ACT-ACT)
Un attaccante che controlla il canale media ma non la segnalazione può tentare MITM su DTLS, ma ciò cambia i certificati e fa fallire il controllo delle impronte. Un attacco riuscito richiede di alterare le impronte nella segnalazione.
Con RFC 4474 Identity o equivalente, un attaccante che controlla la segnalazione tra i proxy che firmano Identity non può alterare le impronte senza invalidare la firma; nemmeno controllando entrambi i percorsi. Il canale tra UA e authentication service MUST essere protetto e il servizio MUST verificare l'identità dell'UA.
Un attaccante che controlla l'authentication service può impersonare l'UA: è una caratteristica voluta di SIP Identity.
A.8. Legame agli identificatori (R-ID-BINDING)
Con meccanismi end-to-end come SIP Identity [RFC4474], SIP Connected Identity [RFC4916] o S/MIME, le impronte dei certificati sono legate al From nella segnalazione; l'impronta è coperta dalla firma Identity. Con altri meccanismi (es. SIPS) il legame è più debole.
A.9. Perfect Forward Secrecy (R-PFS)
DTLS supporta suite DH e ECDH che forniscono PFS.
A.10. Negoziazione degli algoritmi (R-COMPUTE)
DTLS negozia le suite prima di calcolo crittografico significativo, supportando negoziazione e più suite senza grande costo aggiuntivo.
A.11. Controllo di validità RTP (R-RTP-VALID)
I pacchetti DTLS non superano il controllo di validità RTP: il primo byte è il tipo di contenuto; i tipi DTLS attuali hanno i primi due bit a zero (versione zero), quindi falliscono al primo test. Distinzione da STUN in [RFC5764].
A.12. Certificati di terze parti (R-CERTS, R-EXISTING)
Non richiesti: la segnalazione (es. [RFC4474]) autentica i certificati DTLS. Infrastrutture condivise compatibili TLS (certificati terzi o chiavi condivise) possono essere usate.
A.13. FIPS 140-2 (R-FIPS)
Le implementazioni TLS possono essere approvate FIPS 140-2; gli algoritmi sono coerenti con l'approvazione di DTLS e DTLS-SRTP.
A.14. Collegamento tra scambio di chiavi e segnalazione SIP (R-ASSOC)
Lo scambio di segnalazione è collegato alla gestione delle chiavi tramite le impronte in SIP e i certificati in DTLS.
A.15. Vulnerabilità denial-of-service (R-DOS)
DTLS offre una certa protezione DoS integrata (sezione 4.2.1 di [RFC4347]).
A.16. Agilità crittografica (R-AGILITY)
Le suite sono negoziabili; nuovi algoritmi possono essere dispiegati incrementalmente. Sostituzione della PRF fissa MD5/SHA-1 in corso.
A.17. Protezione dal downgrade (R-DOWNGRADE)
DTLS protegge dal downgrade perché la scelta delle suite offerte è confermata in una fase successiva dell'handshake; efficace salvo un avversario che rompa una suite in tempo reale. RFC 4474 può impedire il downgrade attivo da SRTP a RTP sul segnale.
A.18. Negoziazione della sicurezza media (R-NEGOTIATE)
DTLS consente a un UA di negoziare parametri di sicurezza media per ogni sessione.
A.19. Indipendenza dal protocollo di segnalazione (R-OTHER-SIGNALING)
Il framework DTLS-SRTP non dipende da SIP; ogni protocollo capace di scambiare impronta e descrizione media può essere protetto.
A.20. Registrazione media (R-RECORDING)
Un'estensione, vedi [SIPPING-SRTP], supporta la registrazione senza richiedere intermedi in MITM.
Se la registrazione è fatta dagli intermedi, devono agire in MITM.
A.21. Interoperabilità con intermediari (R-TRANSCODER)
Per un intermediario che transcodifica, il transcoder deve accedere al materiale di chiave ed è trattato come endpoint ai fini di questo documento.
A.22. Terminazione su gateway PSTN (R-PSTN)
Il framework DTLS-SRTP consente di terminare la sicurezza media su un gateway PSTN. Non è end-to-end ma coerente con gli obiettivi: il gateway è autorizzato a parlare per lo spazio dei nomi PSTN.
A.23. R-ALLOW-RTP
DTLS-SRTP consente RTP alla parte chiamante fino alla negoziazione SRTP con il rispondente; poi si preferisce SRTP.
A.24. R-HERFP
HERFP non si applica a DTLS-SRTP: lo scambio di chiavi avviene sul percorso media; i messaggi di errore seguono quel percorso e i proxy non devono inoltrarli.