Appendix A. Requirements Analysis (Anforderungsanalyse)
[RFC5479] beschreibt Sicherheitsanforderungen für Medienschlüsselung. Dieser Abschnitt bewertet den Vorschlag je Anforderung.
A.1. Forking und Retargeting (R-FORK-RETARGET, R-BEST-SECURE, R-DISTINCT)
Das SDP-Angebot (in INVITE) ist hier nur eine Fähigkeitsankündigung für Sicherheit. Es hängt nicht von der Peer-Identität ab; Forking und Retargeting funktionieren, wenn alle Endpunkte SRTP können. Bei gemischten SRTP-/Nicht-SRTP-Endpunkten nutzt man den in [MMUSIC-SDP] definierten SDP-Fähigkeitsmechanismus für transparente Sicherheitsaushandlung wo möglich. Da DTLS pro Sitzung neue Schlüssel etabliert, erhält nur die endgültig verbundene Entität die Medienverschlüsselungsschlüssel (R3).
A.2. Getrennte kryptografische Kontexte (R-DISTINCT)
DTLS führt mit jedem Endpunkt einen neuen Handshake aus und etabliert getrennte Schlüssel und kryptografische Kontexte.
A.3. Wiederverwendung eines Sicherheitskontexts (R-REUSE)
DTLS erlaubt Sitzungswiederaufnahme über TLS Session Resumption und kann kryptografische Last bei erneuter Kommunikation senken. Siehe [RFC5764].
A.4. Clipping (R-AVOID-CLIPPING)
Schlüsselsetup im Medienpfad vermeidet Clipping vor SDP-Antwort. Bis zur Antwort an den Offerer gilt nur Vertraulichkeit: der Answerer weiß, nicht an einen Angreifer zu senden; der Offerer weiß nicht, vom Answerer zu empfangen.
A.5. Passive Angriffe auf den Medienpfad (R-PASS-MEDIA)
Öffentliche Schlüsselverfahren in DTLS-Suites (RSA, DH, ECDH) sind gegen passive Angriffe sicher.
A.6. Passive Angriffe auf den Signalisierungspfad (R-PASS-SIG)
DTLS schützt vor passiven Gegnern auf dem Signalweg, da nur ein Fingerprint per SIP ausgetauscht wird.
A.7. (R-SIG-MEDIA, R-ACT-ACT)
Ein Angreifer mit Medienkanal ohne Signalisierung kann MITM auf DTLS versuchen; geänderte Zertifikate scheitern am Fingerprint-Vergleich. Erfolg erfordert Manipulation der Fingerprints in der Signalisierung.
Mit RFC-4474-Identity oder Äquivalent kann ein Angreifer zwischen den Identity-signierenden Proxys Fingerprints nicht ändern, ohne die Signatur zu brechen; selbst Kontrolle über beide Pfade reicht nicht. Kanal UA–Authentication Service MUST gesichert sein; der Dienst MUST die UA-Identität prüfen.
Kontrolliert der Angreifer den Authentication Service, kann er den UA impersonieren – beabsichtigt bei SIP Identity (Namensraumbesitz).
A.8. Bindung an Identifikatoren (R-ID-BINDING)
Ende-zu-ende mit SIP Identity [RFC4474], SIP Connected Identity [RFC4916] oder S/MIME binden Zertifikats-Fingerprints an From; der Fingerprint liegt unter der Identity-Signatur. Schwächere Bindung bei z. B. SIPS.
A.9. Perfect Forward Secrecy (R-PFS)
DTLS unterstützt DH- und ECDH-Suites mit PFS.
A.10. Algorithmusverhandlung (R-COMPUTE)
DTLS verhandelt Cipher-Suites vor größerem kryptografischen Aufwand und erlaubt Algorithmuswahl ohne großen Mehraufwand.
A.11. RTP-Gültigkeitsprüfung (R-RTP-VALID)
DTLS-Pakete bestehen die RTP-Gültigkeitsprüfung nicht: erstes Byte ist Content-Type; aktuelle DTLS-Typen haben die ersten Bits null (Version 0), erster Check fällt durch. Unterscheidung von STUN siehe [RFC5764].
A.12. Drittzertifikate (R-CERTS, R-EXISTING)
Nicht erforderlich: Signalisierung (z. B. [RFC4474]) authentifiziert DTLS-Zertifikate. Geteilte TLS-kompatible Infrastruktur (Drittzertifikate oder Shared Keys) kann genutzt werden.
A.13. FIPS 140-2 (R-FIPS)
TLS-Implementierungen können FIPS 140-2 genehmigt sein; Algorithmen passen zu DTLS/DTLS-SRTP-Genehmigung.
A.14. Verknüpfung Schlüsselaustausch und SIP-Signalisierung (R-ASSOC)
Signalisierung ist über Fingerprints in SIP mit Schlüsselverwaltung verknüpft; Zertifikate laufen über DTLS.
A.15. Denial-of-Service (R-DOS)
DTLS bietet eingebauten gewissen DoS-Schutz (Abschnitt 4.2.1 von [RFC4347]).
A.16. Krypto-Agilität (R-AGILITY)
Cipher-Suites sind verhandelbar; neue Algorithmen inkrementell deploybar. Ersatz der festen MD5/SHA-1-PRF läuft.
A.17. Downgrade-Schutz (R-DOWNGRADE)
DTLS schützt vor Downgrade, da Suite-Auswahl später im Handshake bestätigt wird – wirksam, außer ein Gegner bricht eine Suite in Echtzeit. RFC 4474 kann aktives Downgraden von SRTP zu RTP auf dem Signalweg verhindern.
A.18. Medien-Sicherheitsaushandlung (R-NEGOTIATE)
Ein UA kann pro Sitzung Medien-Sicherheitsparameter aushandeln.
A.19. Unabhängigkeit vom Signalisierungsprotokoll (R-OTHER-SIGNALING)
DTLS-SRTP hängt nicht von SIP ab; jedes Protokoll mit Fingerprint- und Medienbeschreibungsaustausch kann gesichert werden.
A.20. Medienaufzeichnung (R-RECORDING)
Erweiterung [SIPPING-SRTP] für Aufzeichnung ohne MITM-Pflicht für Vermittler.
Aufzeichnung durch Vermittler erfordert MITM.
A.21. Zusammenspiel mit Vermittlern (R-TRANSCODER)
Für transcodierende Vermittler braucht der Transcoder Schlüsselzugang und gilt als Endpunkt nach diesem Dokument.
A.22. PSTN-Gateway-Terminierung (R-PSTN)
Mediensicherheit kann am PSTN-Gateway enden; nicht Ende-zu-Ende, aber im Rahmen der Ziele, da das Gateway für den PSTN-Namensraum sprechen darf.
A.23. R-ALLOW-RTP
DTLS-SRTP erlaubt RTP beim Anrufer bis zur SRTP-Aushandlung mit dem Angerufenen; danach bevorzugtes SRTP.
A.24. R-HERFP
HERFP trifft auf DTLS-SRTP nicht zu: Schlüsselaustausch läuft über den Medienpfad; Fehler gehen dort entlang, Proxys müssen sie nicht vorwärts leiten.