Mögliche Vorgehensweise bei S/MIME-Signatur

Transkript

1 2.2 Authentisierung (3) S/MIME-Signatur SIP verwendet MIME für Attachments für die Codierung des Body definiert in RFC S/MIME bietet Möglichkeit für Signaturen definiert in RFC 2633 Integration eines verschlüsselten Hashwertes Verschlüsselung mit privatem Schlüssel erfordert Schlüsselverwaltung für öffentliche Schlüssel Mögliche Vorgehensweise bei S/MIME-Signatur Signatur über Bodyinhalte Signatur über gesamte SIP-Nachricht Authenticated Identity Body (AIB) F Authentisierung (4) S/MIME-Signatur über Bodyinhalte Standardvorgehen wie bei signierter Aufteilung in MIME-Type multipart/signed 1. Teil: Originalinhalt 2. Teil: Signatur dazu Body Body Teil 1 Signatur Teil 2 erlaubt Authentisierung des Body nicht jedoch der kompletten SIP-Nachricht F.26

2 2.2 Authentisierung (5) S/MIME-Signatur über gesamte SIP-Nachricht ähnlich wie bei Signatur über Bodyinhalt Auteilung in MIME-Type multipart/signed 1. Teil: komplette (ursprüngliche SIP-Nachricht) mit MIME-Type: message/sip 2. Teil: Signatur dazu Body Body Teil 1 Signatur Teil 2 erlaubt Authentisierung der kompletten Nachricht F Authentisierung (6) S/MIME-Signatur über gesamte SIP-Nachricht (fortges.) erfordert Vergleich der signierten mit den äußeren SIP-n Nachricht könnte mit Signatur kopiert sein Probleme Verdoppelung der SIP- schwieriger Abgleich zwischen verschiedenen -Gruppen Proxies ändern teilweise F.28

3 2.2 Authentisierung (7) S/MIME-Signatur über Authenticated-Identity-Body (AIB) definiert in RFC 3893 Integration eines signierten Fragments der ursprünglichen SIP-Nachricht (den AIB) in den Body z.b. mit MIME-Type multipart/mixed zusammen mit anderen Bodyinhalten MIME-Type des AIB ist message/sipfrag definiert in RFC 3420 wird eingebettet in multipart/signed Inhalt des AIB wichtige der SIP Nachricht: From, Date, Call-ID, Contact, To, CSeq F Authentisierung (8) S/MIME-Signatur über Authenticated-Identity-Body (fortges.) Aufbau der Nachricht Body Body Teil 1 AIB Signatur Teil 2 Teil 2.1 Teil 2.2 F.30

4 2.2 Authentisierung (9) Authentication Service definiert in RFC 4474 Authentisierung gegenüber Proxy mit integriertem Authentication-Service Proxy authentisiert UA mit Hilfe von HTTP-Digest oder S/MIME Proxy bildet Hash über signifikante Contact, Date, Call-ID, CSeq, To, From mit From- auch über Absender-URI Proxy verschlüsselt Hash mit privatem Domänenschlüssel öffentlicher Schlüssel kann über Identity-Info- ermittelt werden Identitätsnachweis (verschlüsselter Hash) wird in Identity- abgelegt und mit der Nachricht weitergeleitet Empfänger können Identität nachprüfen erfordert Vertrauen zur Domäne (typischerweise Provider) F Authentisierung (10) Authentisierung gegenüber Registrar HTTP-Digest-Authentisierung S/MIME-Signatur Authentisierung gegenüber anderem User-Agent HTTP-Digest-Authentisierung S/MIME-Signatur Authentification-Service Authentisierung gegenüber dem Proxy oder Authentication-Service HTTP-Digest-Authentifizierung Status der Antwort vom Proxy: 407 Proxy Authentication Required statt 401 Unauthorized Nutzung anderer um Authentisierung gegenüber anderem User- Agent nicht zu stören S/MIME-Signatur F.32

5 2.2 Authentisierung (11) Authentisierung gegenüber einem anderen User-Agent Problem: Sender kann nicht sicherstellen, dass sich Proxies auf dem Pfad zum Empfänger korrekt verhalten Lösung: zusätzliche Authentisierung der Antwort durch S/MIME-Signatur INVITE INVITE 200 OK (signed) 200 OK (signed) F Integrität Unveränderbarkeit der Daten Veränderungen müssen erkennbar sein Integritätsicherung Hop-by-Hop TLS Realisierung in Transportschicht ersetzt und nutzt TCP verschiedene Varianten von Verschlüsselung und Authentisierung möglich bei SIPS-URI (z.b. automatische TLS-Nutzung IPSec Realisierung in Vermittlungsschicht zwischen Netzwerkknoten in der Regel nicht ausreichend für Ende-zu-Ende Absicherung F.34

6 2.3 Integrität (2) Integrität von Ende zu Ende Realisierung auf Anwendungsschicht Integration einer Signatur z.b. S/MIME-Signatur über komplette Nachricht z.b. S/MIME-Signatur über Body und Verwendung des AIB F Vertraulichkeit Lesen von Daten nur durch autorisierte Entitäten Hop-by-Hop TLS (Transportschicht, TCP, SIPS-URI) IPSec (Netzwerkebene) nicht ausreichend für Ende-zu-Ende Absicherung Ende-zu-Ende Problem: Komplette Nachricht darf nicht verschlüsselt werden Proxies müssen Nachricht korrekt weiterleiten können S/MIME Verschlüsselung der Anhänge bzw. des Body Nur benötigte im Klartext schicken To, From, Call-ID, CSeq, Contact,... AIB: Verschlüsselung der relevanten (anstelle kompletter Nachricht) F.36

7 2.5 Privatsphäre Gewährleistung der Anonymität eines Nutzers definiert in RFC 3323 enthalten Angaben zur Benutzeridentität From-, Contact- Verbergen der Identität gegenüber Angerufenem Zwischenknoten wie z.b. Proxies Unterscheidung der Maßnahmen Maßnahmen beim Benutzer (user-provided) im User-Agent Maßnahmen im Netz (network-provided) Einsatz von Privayc-Services in Form von speziellen Proxies F Privatsphäre (2) Anforderung durch den User-Agent Privacy- mit verschiedenen Werten header: Schutz für Informationen im session: Schutz für die Sitzung user: Schutz für die Identität durch Privacy-Service statt durch lokalen UA none: keine Maßnahmen erforderlich Schutz der Identität im UA oder in einem Privacy-Service (user) Privacy-Service, falls UA des Anrufers nicht dazu in der Lage Anonymisieren des From-s kann für Angerufenen in Form einer verschlüsselten SIPFRAG-Nachricht angehängt werden Entfernen aller möglichen unnötiger Server, Organization, User-Agent, Call-Info etc. F.38

8 2.5 Privatsphäre (3) Schutz für den in einem Privacy-Service (header) keine neuen unnötigen durch Zwischenknoten Entfernung bisheriger Via- bei Anfragen Hinzufügen bei Antworten Umsetzen des Contact-s z.b. Contact: Schutz der Sitzung durch einen Privacy-Service (session) Umsetzen der Zieladressen z.b. in SDP-Payload erfordert unverschlüsselten Body verschlüsselte Sitzung wird dringend empfohlen F Spam over Internet Telephony (Spit) Problemstellung Bekannt: Spam und Spim (Spam over instant messaging) Internet-Telephonie bisher kostenlos unerwünschte, automatisierte Werbeanrufe per IP-Telefonie Mögliche Lösungen Whitelisting nur ausgewählte Anrufer kommen durch Integration mit Authentisierung (Digest bzw. S/MIME) erweitertes Whitelisting über Vertrauensnetzwerk d.h. Anrufer auf Whitelisten von gelisteten Teilnehmern kommen durch (bis zu einer gewissen Indirektionsstufe) Blacklisting Ausschluss bestimmter Anrufer F.40

9 2.6 Spam over Internet Telephony (2) Mögliche Lösungen (fortges.) Graylisting erstmaliges Abweisen, erneuter Anruf führt zum Ziel Voice-Menü Anrufer wird gebeten Informationen zu übermitteln Bitte drücken Sie #563 um verbunden zu werden zur Zeit nicht von Automaten nachvollziehbar SPIT-Filter (statistische Blacklists) ähnlich wie SPAM-Filter SIP Erweiterungen Feedback-Mechanismus für intelligente Proxies zur Anpassung von Strategien ( War SPIT! ) F Spam over Internet Telephony (3) Mögliche Lösungen (fortges.) Kosten für IP-Telefonie einführen zum Vergleich: SMS-Spam vergleichsweise gering erstmalige Weiterleitung auf klassisches Telefonnetz Aufgabe lösen lassen SPIT wird kurz- bis mittelfristig wahrscheinlich zu einem Problem Aktuell werden die Sicherheitskonzepte zur Absicherung von SIP kaum bis gar nicht praktisch eingesetzt! F.42

10 3 Verhandlung Wieso Verhandlung? Vielzahl von Endgeräten mit unterschiedlichen Fähigkeiten: Codecs, Präsentationsmedien, Bandbreiten, Rechenleistungen etc. Ziel komplette konsistente Sicht aller Teilnehmer auf eine Sitzung alle können die gesendete Informationen darstellen im Idealfall optimale Qualität unter den gegebenen Umständen F Offer-Answer-Modell Einfaches Verhandlungsmodell definiert in RFC 3264 bezieht sich auf SDP und auf beliebiges Kontrollprotokoll Offerer: sendet Answerer seine gewünschte Sicht auf die Sitzung Answerer: antwortet mit seiner gewünschten Sicht auf die Sitzung Sicht des Answerer bereits angepasst an Einschränkungen des Offerer Alice OFFER ANSWER Bob Unterstützung von Aktualisierungen während der Sitzung F.44

11 3.2 Offer-Answer-Modell bei SIP SIP als Kontrollprotokoll für den Sitzungsaufbau Offer wird in INVITE-Nachricht mitgeschickt Answer in 200 OK Nachricht INVITE (+Offer) 180 Ringing 200 OK (+Answer) ACK RTP-Session F Offer-Answer-Modell bei SIP (2) Besonderheiten der SDP-Beschreibung INVITE v=0 o=alice IN IP4 client.atlanta.example.com s=- // Kein/Dummy-Session-Name c=in IP t=0 0 // VoIP Sitzungen können nicht zeitversetzt stattfinden m=audio RTP/AVP 0 8 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/ OK v=0 o=bob IN IP4 client.biloxi.example.com s=c=in IP t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F.46

12 3.2 Offer-Answer-Modell bei SIP (3) UPDATE-Transaktion nochmaliges Verhandeln mit Offer/Answer z.b. Einbeziehung eines Gateways nach erfolgloser erster Verhandlung INVITE (+Offer1) 180 Ringing 200 OK (+Answer1) UPDATE (+Offer2) 200 OK (+Answer2) ACK RTP-Session F Offer-Answer-Modell bei SIP (4) Änderungen der Anforderungen und Gegebenheiten Wiederverhandlung (Re-Negotiation) bzw. Rekonfiguration zur Laufzeit Änderung des Codecs Änderung der IP bzw. des Ports Re-Invite in SIP neue INVITE-Nachricht gehört zum INVITE-Dialog kein Klingeln F.48