Aller au contenu principal

6. Considérations relatives à la sécurité

Les considérations relatives à la sécurité de la [RFC3550] s'appliquent à ce mémo.

6.1. Considérations sur l'unicité des CNAME RTCP​

Les considérations de cette section s'appliquent aux CNAME RTCP aléatoires.

Les recommandations données dans ce document pour la génération des CNAME RTCP garantissent qu'un ensemble de participants coopérants à une session RTP aura, avec une très grande probabilité, des CNAME RTCP uniques. Cependant, ni la [RFC3550] ni ce document ne fournissent de moyen d'assurer que les participants choisiront les CNAME RTCP de manière appropriée ; ainsi, les mises en œuvre NE DOIVENT PAS compter sur l'unicité des CNAME RTCP pour tout service de sécurité essentiel. Ceci est cohérent avec la [RFC3550], qui n'exige pas que les CNAME RTCP soient uniques au sein d'une session mais dit plutôt que cette condition DEVRAIT être respectée. Comme décrit dans la section Considérations relatives à la sécurité de la [RFC3550], parce que chaque participant à une session est libre de choisir son propre CNAME RTCP, il peut le faire de manière à usurper l'identité d'un autre participant. Autrement dit, on fait confiance aux participants pour ne pas usurper l'identité les uns des autres. Aucune recommandation pour la génération de CNAME RTCP ne peut empêcher cette usurpation d'identité, car un attaquant peut négliger la stipulation. Le protocole Secure RTP (SRTP) [RFC3711] maintient les entités non autorisées hors d'une session RTP, mais il ne vise pas à prévenir les attaques d'usurpation d'identité de la part d'entités autorisées.

En raison des propriétés du PRNG, il n'y a pas de différence significative en termes de confidentialité/liabilité entre les CNAME RTCP longs et courts. Cependant, l'exigence de générer des CNAME RTCP uniques implique une certaine longueur minimale. Une longueur de 96 bits permet d'avoir de l'ordre de 2^{40} CNAME RTCP globalement avant qu'il n'y ait une grande chance de collision (il y a environ 50 % de chances d'avoir une collision après 2^{48} CNAME RTCP).

6.2. Corrélation de sessions basée sur les CNAME RTCP​

Les recommandations précédentes pour la génération de CNAME RTCP permettaient une valeur de CNAME RTCP fixe, ce qui permet à un attaquant de lier facilement des sessions RTP séparées, éliminant l'obfuscation fournie par les adresses de confidentialité IPv6 [RFC4941] ou la traduction d'adresse et de port réseau (NAPT) IPv4 [RFC3022].

Cette spécification ne décrit plus de procédure pour générer des valeurs de CNAME RTCP fixes, de sorte que les valeurs de CNAME RTCP ne fournissent plus un tel lien entre les sessions RTP. Cela était nécessaire pour éliminer un tel lien par un attaquant, mais complique bien sûr le lien par des dispositifs d'analyse de trafic (par exemple, des dispositifs qui recherchent des paquets perdus ou retardés).

7. Remerciements

Merci à Marc Petit-Huguenin, qui a suggéré d'utiliser des UUID pour générer les CNAME RTCP. Merci également à David McGrew pour avoir fourni le texte de la section Considérations relatives à la sécurité de la RFC 6222.

8. Références

8.1. Références normatives​

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

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

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

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

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

8.2. Références informatives​

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

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

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

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

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

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

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

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

  • [ARCH] Rescorla, E., "WebRTC Security Architecture", travail en cours, juillet 2013.

  • [RESCORLA] Rescorla, E., "Random algorithm for RTP CNAME generation", travail en cours, juillet 2012.

Dernière mise à jour le