8. Security Considerations (Sicherheitsaspekte)
Über SIP signalisierter DTLS- oder TLS-Medienverkehr braucht ein Verfahren, um die Richtigkeit der Peer-Zertifikate sicherzustellen.
Die übliche TLS/DTLS-Strategie ist, dem Server (optional dem Client) ein PKIX-Zertifikat [RFC5280] zu geben. Der Client prüft das Zertifikat und den Namen gegen den Domainnamen des Servers. Das funktioniert wegen weniger, klar benannter Server; in VoIP trifft das selten zu.
Das hier beschriebene Design nutzt die Authentizität des Signalisierungskanals (ohne Vertraulichkeit zu verlangen). Solange jede Seite die Integrität des empfangenen SDP prüfen kann, kann der DTLS-Handshake nicht per MITM gekapert werden. Integrität vom Anrufer zum Angerufenen (Alice zu Bob, Abschnitt 7) liefert leicht SIP Identity [RFC4474]. Andere Mechanismen wie S/MIME in RFC 3261 oder künftige könnten dasselbe leisten.
Ohne solche Integritätsmechanismen bleibt nur Schutz vor passiven Zwischenangriffen. Aktiver Angriff auf Signalisierung plus aktiver Angriff auf die Medienebene kann die Verbindung angreifen (R-SIG-MEDIA in [RFC5479]).
8.1. Identität des Antwortenden
SIP Identity unterstützt keine Signaturen in Antworten. Ideal wüsste Alice, dass Bobs SDP unverändert ist und von wem, damit die UA-Oberfläche einen sicheren Anruf zu Bob zeigt. [RFC4916] erlaubt es einem UA, seine Identität dem Peer-UA mitzuteilen, signiert vom Authentication Service. Beispiel: Bob sendet Antwort, dann sofort UPDATE mit Fingerprint und SIP Identity als [email protected]. Nachteil: zusätzlicher UPDATE-Roundtrip. Einfach und sicher auch ohne vollständig vertrauenswürdige Proxys; Bob muss nur seinem Proxy vertrauen. Offerer SHOULD diesen Mechanismus unterstützen, Answerer SHOULD ihn nutzen.
Oft senden Answerer kein UPDATE, und Media geht vor UPDATE los. Dann fehlt Integrität für Bobs Fingerprint zu Alice. Ein Angreifer auf dem Signalweg könnte den Fingerprint ändern und MITM auf dem Medium sein. Alice weiß, dass sie mit jemandem sicher spricht, nicht ob es Bob oder MITM ist. Bob erkennt den Angriff. Da eine Seite ihn oft merkt, ist das in vielen Fällen unkritisch, wenn beide Verschlüsselung wollen. Bob könnte empfangenes Media immer preisgeben; wir nehmen an, Bob will auch Sicherheit. Ohne Gegenmaßnahme weiß Bob, dass das Medium nicht manipuliert/abgefangen wurde und von [email protected] stammt. Alice weiß, mit jemandem zu sprechen, der vermutlich Abfangen/Manipulation geprüft hat. Weniger ideal, aber oft brauchbar.
8.2. SIPS
Ohne SIP Identity, aber mit SIPS-geschützter Signalisierung, sind die Garantien schwächer. Etwas Sicherheit bleibt, wenn alle Proxys vertrauenswürdig sind (Kettenmodell für Fingerprint-Integrität). Ohne vertrauenswürdige Proxys bleibt das Schutzniveau begrenzt.
8.3. S/MIME
RFC 3261 [RFC3261] definiert S/MIME für SIP und könnte signieren, dass der Fingerprint von Bob stammt. Das wäre sicher.
8.4. Authentifizierungskontinuität
Gewünscht ist kryptographisch sicherzustellen, weiter mit derselben Person zu sprechen. Mit DTLS erreicht man das, indem beide Seiten denselben öffentlichen Schlüssel/selbstsigniertes Zertifikat pro Verbindung (mindestens pro Peer) nutzen. Credential oder Hash können gecacht und auf Unverändertheit geprüft werden. Nach einer ersten sicheren Verbindung kann ein späterer Kanal auch bei unsicherer Signalisierung aufgebaut werden.
Implementierungen SHOULD eine stabile Langzeitschlüssel anstreben. Prüfende Implementierungen SHOULD pro Peer-Identität einen Schlüssel-Cache pflegen und bei Änderung warnen.
8.5. Short Authentication String
Alternative: Alice und Bob prüfen per Sprache die Identität und vergleichen Fingerprints mündlich. Wenn Stimmimitation und nahtlose Audio-Manipulation schwer sind, ist das relativ sicher. Für Video oder IM weniger geeignet. DTLS erlaubt den Modus. Mindestlänge sicherer Fingerprint etwa 64 Bit.
ZRTP [AVT-ZRTP] hat SAS-Modus mit pro Verbindung erzeugter Bitkette aus dem Handshake; SAS kann 25 Bit lang sein und leichter lesbar. DTLS unterstützt das nicht nativ. Bei Bedarf könnte eine TLS-Erweiterung [RFC5246] helfen. SAS setzt oft Stimmerkennung voraus, nicht überall gegeben (Callcenter).
8.6. Grenzen von Identitätsassertionen
Mit RFC 4474, um Medienschlüssel an SIP zu binden, sind Media-Zusicherungen nur so gut wie die Signalisierung. Zwei Fälle:
o RFC 4474 nimmt an, der Proxy mit Zertifikat „example.com“ kontrolliert den Namensraum „example.com“. Der Authentication Service für einen Namensraum kann zuweisen, welcher Nutzer welchen Namen hat; er kann eine Adresse von Alice auf Bob übertragen – beabsichtigt und Folge der SIP-Namensraumarchitektur.
o Bei Telefonnummer-URIs (z. B. „sip:[email protected]“) gibt es keinen strukturellen Grund, der Domain Autorität über die Nummer zu geben, auch wenn private Vereinbarungen existieren. Strukturell vertraut man PSTN-Elementen bei Nummernassertion ohne klare Autorität über Nummernräume.
In beiden Fällen sind DTLS-SRTP-Zusicherungen zu Herkunftsintegrität und Vertraulichkeit nicht besser als SIP-Signalisierungsintegrität unter RFC 4474. Implementierungen dürfen die UI nicht irreführend füllen. Bei sip:[email protected] reicht Anzeige von +17005551008 nicht ohne Policy, dass die Domain diese E.164 assertieren darf. Erkennt die UA klar E.164, kann „verschlüsselt, unbekannter Peer“ weniger verwirrend sein.
Manche Middleboxes (B2BUA, SBC) ändern SIP-Teile, die in die RFC-4474-Signatur eingehen, und brechen die Signatur – genau das soll RFC 4474 erkennen. Darf die Box gültige RFC-4474-Signaturen (gleiche Verwaltungsdomäne), kann sie neu signieren oder eine andere assertierbare Identität nutzen. Sonst ist die Identity-Assertion unzuverlässig und die UA MUST NOT einem Nutzer einen sicheren Anruf zur behaupteten Identität anzeigen. Nur-sichere-Anrufe-Konfigurationen SHOULD in dem Fall auflegen.
Ohne SIP Identity oder Äquivalent bleibt nur Schutz gegen Angreifer ohne aktive Signalisierungsänderung. Besser als früher, aber schwächer als mit Integrität.
8.7. Drittzertifikate
Die Spezifikation verlangt keine unabhängig verifizierbaren Endpunktzertifikate; nichts verbietet sie. Außer Beschaffungsschwierigkeit sind Identitäten unklar (RFC-3261-S/MIME-Konvention kaum verbreitet). In geschlossenen Kontexten mit Konvention können Drittzertifikate Proxy-Vertrauen reduzieren.
8.8. Perfect Forward Secrecy
Kompromittierung eines Langzeitschlüssels könnte alte Gespräche gefährden. DTLS bietet PFS-Modi mit Diffie-Hellman und ECDH. Damit ist das System dagegen geschützt. Langzeitschlüssel-Kompromittierung kann weiterhin zukünftige aktive Angriffe ermöglichen. Dann Backup-Kanal (manueller Fingerprint oder SAS) nutzen.