Passa al contenuto principale

6. Considerazioni sulla Sicurezza

Le considerazioni sulla sicurezza della [RFC3550] si applicano a questo promemoria.

6.1. Considerazioni sull'Univocità dei CNAME RTCP​

Le considerazioni in questa sezione si applicano ai CNAME RTCP casuali.

Le raccomandazioni fornite in questo documento per la generazione del CNAME RTCP assicurano che un insieme di partecipanti cooperanti in una sessione RTP avrà, con probabilità molto alta, CNAME RTCP univoci. Tuttavia, né la [RFC3550] né questo documento forniscono alcun modo per garantire che i partecipanti scelgano i CNAME RTCP in modo appropriato; pertanto, le implementazioni NON DEVONO fare affidamento sull'univocità dei CNAME RTCP per alcun servizio di sicurezza essenziale. Ciò è coerente con la [RFC3550], che non richiede che i CNAME RTCP siano univoci all'interno di una sessione, ma afferma invece che tale condizione DOVREBBE sussistere. Come descritto nella sezione sulle Considerazioni sulla Sicurezza della [RFC3550], poiché ogni partecipante in una sessione è libero di scegliere il proprio CNAME RTCP, può farlo in modo da impersonare un altro partecipante. In altre parole, si confida che i partecipanti non si impersonino a vicenda. Nessuna raccomandazione per la generazione dei CNAME RTCP può impedire questa impersonificazione, poiché un utente malintenzionato può ignorare la disposizione. Il protocollo Secure RTP (SRTP) [RFC3711] tiene le entità non autorizzate fuori da una sessione RTP, ma non mira a prevenire attacchi di impersonificazione da parte di entità autorizzate.

A causa delle proprietà del PRNG, non vi è alcuna differenza significativa in termini di privacy/collegabilità tra CNAME RTCP lunghi e brevi. Tuttavia, il requisito di generare CNAME RTCP univoci implica una certa lunghezza minima. Una lunghezza di 96 bit consente nell'ordine di 2^{40} CNAME RTCP a livello globale prima che vi sia una grande probabilità di collisione (c'è circa il 50% di probabilità di una collisione dopo 2^{48} CNAME RTCP).

6.2. Correlazione delle Sessioni basata sui CNAME RTCP​

Le raccomandazioni precedenti per la generazione del CNAME RTCP consentivano un valore fisso del CNAME RTCP, il che permetteva a un utente malintenzionato di collegare facilmente sessioni RTP separate, eliminando l'offuscamento fornito dagli indirizzi di privacy IPv6 [RFC4941] o dalla traduzione degli indirizzi e delle porte di rete (NAPT) IPv4 [RFC3022].

Questa specifica non descrive più una procedura per generare valori fissi di CNAME RTCP, quindi i valori CNAME RTCP non forniscono più tale collegamento tra le sessioni RTP. Ciò è stato necessario per eliminare tale collegamento da parte di un utente malintenzionato, ma ovviamente complica il collegamento da parte di dispositivi di analisi del traffico (ad esempio, dispositivi che cercano pacchetti persi o ritardati).

7. Ringraziamenti

Grazie a Marc Petit-Huguenin, che ha suggerito di utilizzare gli UUID nella generazione dei CNAME RTCP. Inoltre, grazie a David McGrew per aver fornito il testo per la sezione sulle Considerazioni sulla Sicurezza nella RFC 6222.

8. Riferimenti

8.1. Riferimenti Normativi​

  • [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., e V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, Luglio 2003.

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, Marzo 1997.

  • [RFC4122] Leach, P., Mealling, M., e R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, Luglio 2005.

  • [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, Ottobre 2006.

  • [RFC4086] Eastlake, D., Schiller, J., e S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, Giugno 2005.

8.2. Riferimenti Informativi​

  • [RFC6222] Begen, A., Perkins, C., e D. Wing, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 6222, Aprile 2011.

  • [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., e E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, Febbraio 1996.

  • [RFC3022] Srisuresh, P. e K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, Gennaio 2001.

  • [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., e K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, Marzo 2004.

  • [RFC4941] Narten, T., Draves, R., e S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, Settembre 2007.

  • [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, Aprile 2010.

  • [RFC5764] McGrew, D. e E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, Maggio 2010.

  • [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., e E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, Giugno 2002.

  • [ARCH] Rescorla, E., "WebRTC Security Architecture", Work in Progress, Luglio 2013.

  • [RESCORLA] Rescorla, E., "Random algorithm for RTP CNAME generation", Work in Progress, Luglio 2012.

Ultimo aggiornamento il