3. Motivation

Bien qu'il existe déjà des travaux antérieurs dans ce domaine (p. ex. Security Descriptions for SDP [RFC4568], Key Management Extensions [RFC4567] combiné avec MIKEY [RFC3830] pour l'authentification et l'échange de clés), cette spécification est motivée comme suit:

o TLS sera utilisé pour offrir la sécurité aux médias orientés connexion. La conception de TLS est bien connue et des implémentations sont largement disponibles.

o Cette approche gère le forking et l'early media sans exiger la prise en charge de Provisional Response ACKnowledgement (PRACK) [RFC3262], tout en préservant la propriété de sécurité importante permettant à l'offreur de choisir le matériel de clé pour chiffrer le média.

o L'établissement de la protection de sécurité pour le chemin média est également assuré le long du chemin média et non sur le chemin de signalisation. Dans de nombreux scénarios de déploiement, la signalisation et le trafic média empruntent des chemins différents dans le réseau.

o Lorsque la RFC 4474 est utilisée, cette solution fonctionne même lorsque les proxys SIP en aval du service d'authentification ne sont pas de confiance. Il n'est pas nécessaire de révéler les clés dans la signalisation SIP ou dans l'échange de messages SDP, comme dans SDESCRIPTIONS [RFC4568]. Lors du retargeting d'une requête formant un dialogue (changement de la valeur du Request-URI), l'agent utilisateur (UA) qui la reçoit (le serveur d'agent utilisateur, UAS) peut avoir une identité différente de celle du champ d'en-tête To. Lorsque la RFC 4916 est utilisée, il est alors possible de fournir son identité à l'UA pair au moyen d'une requête dans le sens inverse, et pour que cette identité soit signée par un service d'authentification.

o Dans cette méthode, les collisions de source de synchronisation (SSRC) n'entraînent aucune signalisation SIP supplémentaire.

o De nombreux extrémités SIP implémentent déjà TLS. Les changements d'usage existant de SIP et RTP sont minimes même lorsque DTLS-SRTP [RFC5764] est utilisé.