F.1-F.24 - Institut für Verteilte Systeme
Transcription
F.1-F.24 - Institut für Verteilte Systeme
F Session Initiation Protocol F.1 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 1 Instant Messaging ■ Definition ◆ Instant Message: Textmitteilung ◆ Instant Messaging: Dienst zur sofortigen Übermittlung von Instant Messages • Chat ◆ Instant Messenger: Software zum Instant Messaging ■ Diverse proprietäre Protokolle, u.a. ◆ IRC – Internet Relay Chat ◆ XMPP – Extensible Messaging and Presence Protocol (Jabber) ◆ SILC – Secure Internet Live Conferencing ◆ OSCAR – Open System for Communication in Realtime (AOL IM, ICQ) ◆ SIMPLE – SIP for Instant Messaging and Presence Leveraging Extensions F.2 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 1 Instant Messaging (2) ■ Warum Instant Messaging mit SIP? ◆ Konvergenz der Kommunikationsmöglichkeiten • SIP als generisches Kontrollprotokoll ◆ Zusatz in vorhandenen SIP-fähigen Geräten • z.B. VoIP-Telefon • Vereinfachung der Protokollimplementierungen ◆ “The IETF Way of Instant Messaging” F.3 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 1 Instant Messaging (3) ■ SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) ◆ Working Group der IETF • Arbeiten basieren auf CPIM und CPP • CPIM = Common Profile for Instant Messaging (RFC 3860) • CPP = Common Profile for Presence (RFC 3859) ◆ RFC 3428 definiert SIP MESSAGE-Transaktion • Versenden von Nachrichten über SIP ◆ RFC 3265 und RFC 3856 definieren Ereignisse und Präsenzfunktionen über SIP • Präsenzfunktion benachrichtigt Benutzer über deren Verfügbarkeit • weitere RFCs zu Presence-Formaten, Presence-Filtering u.a. • weitere IETF-Drafts, z.B. zu Advanced IM — Benachrichtigung für serverseitig gespeicherte Nachrichten — Is-Composing („Benutzer X schreibt gerade an mich“) F.4 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 1.1 IM-URIs ■ URI-Schema für Zieladressen von Instant Messaging ◆ z.B. im:bob@b.com ◆ ähnlicher Aufbau wie E-mail-Adressen bzw. SIP-URIs • definiert in RFC 3860 ■ URI-Schema für Presentities ◆ Presentity = Instanz, über die Präsenzinformation gewonnen werden kann ◆ z.B. pres:bob@b.com ◆ ähnlicher Aufbau wie IM-URIs • definiert in RFC 3859 ■ Umsetzung der IM-URIs ◆ DNS basierte Suche nach Kontaktpunkt für Tupel (IM-Uri, IM-Protokoll) ◆ im Fall von SIP: • Ermittlung eines Proxy • Umwandlung in eine SIP-URI F.5 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 1.2 SIP Instant Messaging ■ SIP MESSAGE Transaktion ◆ definiert in RFC 3428 alice@a.com proxy@b.com MESSAGE bob@b.com 200 OK bob@b.com MESSAGE bob@b.com 200 OK ◆ Body der Request-Nachricht enthält eigentliche Message für IM F.6 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 1.2 SIP Instant Messaging (2) ■ Einbindung in eine SIP Sitzung (Dialog) ◆ Transaktion gehört zu einem Dialog • im Rahmen einer INVITE/BYE-Klammer • momentan nicht definiert ◆ Transaktion ist eigenständig • eigener Dialog mit eigener Call-ID • definiert in RFC 3428 F.7 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 1.2 SIP Instant Messaging (3) ■ Proxy als Zwischenspeicher einsetzbar alice@a.com proxy@b.com bob@b.com MESSAGE bob@b.com 202 Accepted MESSAGE bob@b.com 200 OK ◆ Proxy speichert Nachricht • 202 Status ◆ Proxy liefert Nachricht aus, sobald Benutzer registriert ist F.8 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 1.2 SIP Instant Messaging (4) ■ SIP Nachricht (Request) MESSAGE sip:bob@b.com SIP/2.0 Via: SIP/2.0/TCP alice.a.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: sip:alice@a.com;tag=49583 To: sip:bob@b.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 18 Watson, come here. ■ Kopfzeilen ◆ Content-Type: Format der angehängten Nachricht (beliebiger MIME-Type) ◆ Content-Length: Länge der Nachricht ■ Body ◆ Nachricht F.9 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 1.3 SIP-Präsenzfunktion ■ SIP Präsenzfunktion definiert in RFC 3856 ◆ Anzeige des Präsenzstatus anderer Teilnehmer ◆ Verbreitete Verwendung in heutigen IM-Clients • z.B. ICQ, AIM, ... ■ Gebräuchliche Beispiele ◆ “free for chat”, “busy”, “away”, “do not disturb” ■ Andere Standards für Presence ◆ Open Mobile Alliance (OMA): Instant Message and Presence Service (IMPS) ◆ Jabber: Extensible Messaging and Presence Protocol (XMPP) F.10 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 1.3 SIP-Präsenzfunktion (2) ■ Basis: SIP-Erweiterung für Ereignisse (Events) ◆ definiert in RFC 3265 und 3903 ◆ SIP Nachrichten: PUBLISH, SUBSCRIBE, NOTIFY Presence-Server SUBSCRIBE PUBLISH NOTIFY alice@a.com bob@b.com ◆ Fähigkeiten des Präsenzdienstes mit OPTIONS abfragbar • ermittelt unterstützte Transaktionstypen • ermittelt unterstützte Event-Packages (Header: Allow-events) F.11 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 1.3 SIP-Präsenzfunktion (3) ■ Nachrichtenaufbau ◆ Event-Header: identifiziert ein Event-Package • z.B. Event: presence ◆ Event-Package definiert Ereignisse und deren Behandlung ◆ PUBLISH-Transaktion • veröffentlicht ein Ereignis • Ereignisdaten im Body • z.B. aktueller Status bzw. Statusänderung einer Presentity F.12 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 1.3 SIP-Präsenzfunktion (4) ■ Nachrichtenaufbau (fortges.) ◆ SUBSCRIBE-Transaktion • abonniert Ereignisse bestimmten Typs — identifiziert durch URI, Eventtyp und evtl. Body — z.B. bei Präsenz: URI der Presentity oder SIP-URI, Eventtyp presence • Abonnement ist zeitbeschränkt — Laufzeit ist Minimum von Sender- und Empfängervorschlägen — Expire-Header mit Laufzeit in Sekunden , z.B. Expire: 3600 • erzeugt einen SIP-Dialog, d.h. alle NOTIFY-Transaktionen und Abonnementverlängerungen durch weitere SUBSCRIBE-Transaktionen tragen gleiche Call-ID • z.B. Abonnement von Präsenzinformationen über eine Presentity ◆ Aufheben des Dialogs und des Abonnements durch SUBSCRIBE mit Laufzeit 0s F.13 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 1.3 SIP-Präsenzfunktion (5) ■ Nachrichtenaufbau (fortges.) ◆ NOTIFY-Transaktion • informiert Abonnenten über abonnierte Ereignisse — Daten evtl. im Body • z.B. Präsenzstatus einer Presentity • eine NOTIFY-Transaktion wird unmittelbar nach Empfang von SUBSCRIBE gesendet — unterstützt Polling-Betrieb (z.B. mit Laufzeit von 0s bei SUBSCRIBE) F.14 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 1.3 SIP-Präsenzfunktion (6) ■ Format der Präsenzinformation ◆ mindestens Unterstützung des PIDF-Formats application/pidf+xml ◆ zusätzlich beliebige andere Formate unterstützbar ■ Presence Information Data Format (PIDF) ◆ definiert in RFC 3863 ◆ spezifiziert Datenformat und Medientyp application/pidf+xml ◆ Beispiel <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" entity="pres:alice@a.com"> <tuple id="sg89ae"> <status> <basic>open</basic> </status> <contact priority="1.0">mailto:alice@a.com</contact> </tuple> </presence> F.15 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 1.3 SIP-Präsenzfunktion (7) ■ Aufbau des PIDF-Formats ◆ presence-Tag: Wurzelelement eines PIDF-Dokuments • entity-Attribut: benennt Presentity ◆ tuple-Tag: enthält eine Statusinformation für eine Presentity • mehrere tuple-Tags möglich • eindeutige Zuordnung über die Zeit hinweig über eindeutige ID ◆ status-Tag: enthält eigentlichen Präsenzstatus • zur Zeit definiert: basic-Tag • eigene Erweiterungen möglich in anderen Namensräumen ◆ contact-Tag: enthält eine Kontaktadresse (optional) ◆ note-Tag: enthält Hinweise (optional) ◆ weitere Angaben über Erweiterungen möglich • typisch über andere XML-Namensräume F.16 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 2 SIP-Sicherheit ■ Allgemeine Anforderungen ◆ Authentizität: Überprüfbarkeit der Echtheit einer Person oder eines Dienstes ◆ Integrität: Unveränderlichkeit der Daten ◆ Vertraulichkeit: Zugriff auf Daten nur durch autorisierte Personen ◆ Privatsphäre: Gewährleistung von Anonymität ■ Weitere hier nicht betrachtete Anforderungen ◆ Einhaltung von Datenschutz ◆ Verbindlichkeit: Änderungen müssen erkennbar und nicht abstreitbar sein ◆ Verfügbarkeit F.17 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 2.1 Bedrohungen ■ Registration Hijacking ◆ User-Agent täuscht falsche Identität vor ◆ z.B. falsche Registrierung alice@a.com proxy@b.com jack@b.com REGISTER bob@b.com MESSAGE bob@b.com MESSAGE bob@b.com 200 OK 200 OK ■ Mögliche Verteidigung ◆ Authentisierung beim Registrieren im Registrar F.18 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 2.1 Bedrohungen (2) ■ Impersonating a Server ◆ Server täuscht falsche Identität vor • führt zu falscher bzw. keiner Weiterleitung bzw. Behandlung ◆ z.B. falscher Redirect alice@a.com proxy@b.com bob@b.com MESSAGE bob@b.com 301 Moved Permanently to jack@b.com ■ Mögliche Verteidigung ◆ Authentisierung des Servers bzw. Proxy F.19 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 2.1 Bedrohungen (3) ■ Spoofing ◆ Vortäuschen eines falschen Absenders ◆ z.B. Jack gibt vor Bob zu sein • falscher From-Header jack@b.com proxy@a.com MESSAGE alice@a.com alice@a.com MESSAGE alice@a.com from bob@b.com 200 OK 200 OK ■ Mögliche Verteidigung ◆ Authentisierung des Absenders F.20 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 2.1 Bedrohungen (4) ■ Abhörbarkeit, Veränderbarkeit der Nachrichten ◆ Man-in-the-Middle (Proxy) kann Nachrichten lesen und verändern ◆ z.B. Proxy von b.com verändert Nachrichten alice@a.com proxy@b.com MESSAGE bob@b.com bob@b.com MESSAGE bob@b.com 200 OK 200 OK ■ Mögliche Verteidigung ◆ Sicherstellung der Integrität der Nachrichten ◆ Sicherstellung der Vertraulichkeit F.21 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 2.1 Bedrohungen (5) ■ (Distributed) Denial of Service ◆ Bombardieren eines User Agents, Proxies etc. mit Nachrichten • durch Überlastung keine zeitnahe Reaktion auf Requests mehr möglich ■ Mögliche Verteidigung ◆ Authentisierung der Sender ◆ Provider kann evtl. Quelladressen sperren F.22 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 2.2 Authentisierung ■ Überprüfbarkeit der Echtheit einer Person oder eines Dienstes ◆ User Agent, Registrar, Proxy, ... ■ Authentisierungsmechanismen ◆ HTTP-Digest-Authentisierung ◆ S/MIME-Signatur ■ HTTP-Digest-Authentisierung ◆ einfaches Challenge-Response-Verfahren • Einsatz einer sicheren Hashfunktion, per Default MD5 ◆ Server schickt Client einen zufälligen Wert (Nonce, fungiert als Challenge) ◆ Client schickt Hash (fungiert als Response) aus dem Tupel (Benutzername, Passwort, Nonce) • kann auf Serverseite verifiziert werden F.23 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/ 2.3 Authentisierung (2) ■ HTTP-Digest-Authentifizierung (fortges.) ◆ Beispiel: Authentisierung eines User-Agent beim Registrar alice@a.com reg@a.com REGISTER 401 Unauthorized (+Nonce) Erzeuge Hash REGISTER (+MD5 Hash) 200 OK Überprüfe Hash • Nonce sorgt vor gegen Abhören der Verbindung • dennoch: Verschlüsselung der Verbindung ist zu bevorzugen F.24 © 2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-F-SIP.fm, 2007-01-10 08.50] http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk/