Annexe A. Analyse des exigences
[RFC5479] décrit les exigences de sécurité pour le matériel de clé média. Cette section évalue la présente proposition par rapport à chaque exigence.
A.1. Forking et retargeting (R-FORK-RETARGET, R-BEST-SECURE, R-DISTINCT)
Dans ce document, l'offre SDP (dans l'INVITE) est simplement une annonce de capacité de sécurité. Elle ne dépend pas de l'identité du pair; le forking et le retargeting fonctionnent lorsque toutes les extrémités font du SRTP. Avec un mélange d'extrémités SRTP et non-SRTP, on utilise le mécanisme de capacités SDP en cours de définition [MMUSIC-SDP] pour négocier la sécurité de façon transparente quand c'est possible. Comme DTLS établit une nouvelle clé par session, seule l'entité avec laquelle l'appel est finalement établie obtient les clés de chiffrement du média (R3).
A.2. Contextes cryptographiques distincts (R-DISTINCT)
DTLS effectue une nouvelle poignée de main avec chaque extrémité, établissant des clés et contextes cryptographiques distincts pour chaque extrémité.
A.3. Réutilisation d'un contexte de sécurité (R-REUSE)
DTLS permet de reprendre des sessions via la « reprise de session TLS ». Cela peut réduire le calcul cryptographique lorsque deux pairs rétablissent la communication. Voir [RFC5764] pour la reprise de session dans ce contexte.
A.4. Écrêtage (R-AVOID-CLIPPING)
Comme l'établissement des clés se fait dans le plan média, le média n'a pas besoin d'être écrêté avant réception de la réponse SDP. Seule la confidentialité est assurée jusqu'à ce que l'offreur reçoive la réponse: le répondant sait qu'il n'envoie pas à un attaquant, mais l'offreur ne peut pas savoir qu'il reçoit du répondant.
A.5. Attaques passives sur le chemin média (R-PASS-MEDIA)
Les algorithmes à clé publique des suites DTLS (RSA, Diffie-Hellman, ECDH) résistent aux attaques passives.
A.6. Attaques passives sur le chemin de signalisation (R-PASS-SIG)
DTLS protège contre les adversaires passifs sur le chemin de signalisation car seul un fingerprint est échangé via SIP.
A.7. (R-SIG-MEDIA, R-ACT-ACT)
Un attaquant contrôlant le canal média mais pas la signalisation peut mener un MITM sur la poignée de main DTLS, mais cela change les certificats et fait échouer la vérification d'empreinte. Toute attaque réussie exige donc de modifier la signalisation pour remplacer les empreintes.
Avec RFC 4474 Identity ou équivalent, un attaquant contrôlant la signalisation entre les proxys qui signent Identity ne peut modifier les empreintes sans invalider la signature. Même un attaquant maîtrisant signalisation et média ne peut pas réussir. Le canal entre l'UA et le service d'authentification MUST être sécurisé et le service MUST vérifier l'identité de l'UA.
Un attaquant contrôlant le service d'authentification peut usurper l'UA: c'est voulu avec SIP Identity — le service possède l'espace de noms.
A.8. Liaison aux identifiants (R-ID-BINDING)
Avec SIP Identity [RFC4474], SIP Connected Identity [RFC4916] ou S/MIME de bout en bout, les empreintes de certificat sont liées à l'adresse From de la signalisation; l'empreinte est couverte par la signature Identity. Avec d'autres mécanismes (p. ex. SIPS), la liaison est plus faible.
A.9. Secret parfait en avant (R-PFS)
DTLS prend en charge les suites DH et ECDH offrant le PFS.
A.10. Négociation d'algorithme (R-COMPUTE)
DTLS négocie les suites avant un calcul cryptographique important, permettant la négociation d'algorithmes et plusieurs suites sans surcoût notable.
A.11. Vérification de validité RTP (R-RTP-VALID)
Les paquets DTLS ne passent pas le test de validité RTP: le premier octet est le type de contenu et les types DTLS actuels ont les deux premiers bits à zéro, donnant une version zéro; ils échouent donc au premier test. Les paquets DTLS sont distinguables des paquets STUN. Voir [RFC5764] pour le démultiplexage.
A.12. Certificats tiers (R-CERTS, R-EXISTING)
Les certificats tiers ne sont pas requis: la signalisation (p. ex. [RFC4474]) authentifie les certificats DTLS. Si les parties partagent une infrastructure compatible TLS (certificats tiers ou clés partagées), elle peut être utilisée.
A.13. FIPS 140-2 (R-FIPS)
Les implémentations TLS peuvent déjà être approuvées FIPS 140-2; les algorithmes ici sont cohérents avec l'approbation de DTLS et DTLS-SRTP.
A.14. Lien entre échange de clés et signalisation SIP (R-ASSOC)
L'échange de signalisation est lié à la gestion de clés par les empreintes dans SIP et les certificats échangés dans DTLS.
A.15. Vulnérabilité par déni de service (R-DOS)
DTLS offre une certaine protection DoS intégrée (voir section 4.2.1 de [RFC4347]).
A.16. Agilité cryptographique (R-AGILITY)
DTLS permet de négocier les suites; de nouveaux algorithmes peuvent être déployés progressivement. Le remplacement de la PRF fixe MD5/SHA-1 est en cours.
A.17. Protection contre l'attaque par déclassement (R-DOWNGRADE)
DTLS protège contre le déclassement car le choix des suites offertes est confirmé plus tard dans la poignée de main. Efficace sauf si un adversaire casse une suite en temps réel. RFC 4474 peut empêcher un attaquant actif sur la signalisation de faire passer l'appel de SRTP à RTP.
A.18. Négociation de sécurité média (R-NEGOTIATE)
DTLS permet à un agent utilisateur de négocier les paramètres de sécurité média pour chaque session.
A.19. Indépendance du protocole de signalisation (R-OTHER-SIGNALING)
Le cadre DTLS-SRTP ne dépend pas de SIP; tout protocole capable d'échanger une empreinte et la description média peut être sécurisé.
A.20. Enregistrement média (R-RECORDING)
Une extension, voir [SIPPING-SRTP], prend en charge l'enregistrement sans exiger des intermédiaires en MITM.
Si l'enregistrement est fait par des intermédiaires, ils doivent agir en MITM.
A.21. Interfonctionnement avec intermédiaires (R-TRANSCODER)
Pour un intermédiaire qui transcode, le transcodeur doit accéder au matériel de clé et être traité comme un endpoint aux fins de ce document.
A.22. Terminaison sur passerelle PSTN (R-PSTN)
Le cadre DTLS-SRTP permet de terminer la sécurité média sur une passerelle PSTN. Ce n'est pas de bout en bout mais cohérent avec les objectifs: la passerelle est autorisée à parler pour l'espace de noms PSTN.
A.23. R-ALLOW-RTP
DTLS-SRTP permet à la partie appelante de recevoir du RTP jusqu'à négociation SRTP avec le répondant; ensuite le SRTP est préféré au RTP.
A.24. R-HERFP
Le problème de fork avec réponses d'erreur hétérogènes (HERFP) ne s'applique pas à DTLS-SRTP: l'échange de clés suit le chemin média, les erreurs y circulent et les proxys n'ont pas besoin de les faire progresser.