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/