F Session Initiation Protocol

Transkript

1 F Session Initiation Protocol F.1 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

2 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 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

3 1.1 IM-URIs URI-Schema für Zieladressen von Instant Messaging z.b. ähnlicher Aufbau wie -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:[email protected] ä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 SIP Instant Messaging SIP MESSAGE Transaktion definiert in RFC 3428 [email protected] [email protected] Body der Request-Nachricht enthält eigentliche Message für IM F.6

4 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 SIP Instant Messaging (3) Proxy als Zwischenspeicher einsetzbar 202 Accepted Proxy speichert Nachricht 202 Status Proxy liefert Nachricht aus, sobald Benutzer registriert ist F.8

5 1.2 SIP Instant Messaging (4) SIP Nachricht (Request) MESSAGE SIP/2.0 Via: SIP/2.0/TCP alice.a.com;branch=z9hg4bk776sgdkse Max-Forwards: 70 From: sip:;tag=49583 To: Call-ID: 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 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

6 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 PUBLISH NOTIFY SUBSCRIBE Fähigkeiten des Präsenzdienstes mit OPTIONS abfragbar ermittelt unterstützte Transaktionstypen ermittelt unterstützte Event-Packages (Header: Allow-events) F 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

7 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 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

8 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:"> <tuple id="sg89ae"> <status> <basic>open</basic> </status> <contact priority="1.0">mailto:</contact> </tuple> </presence> F 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

9 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 Bedrohungen Registration Hijacking User-Agent täuscht falsche Identität vor z.b. falsche Registrierung REGISTER Mögliche Verteidigung Authentisierung beim Registrieren im Registrar F.18

10 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 [email protected] [email protected] 301 Moved Permanently to [email protected] Mögliche Verteidigung Authentisierung des Servers bzw. Proxy F Bedrohungen (3) Spoofing Vortäuschen eines falschen Absenders z.b. Jack gibt vor Bob zu sein falscher From-Header [email protected] [email protected] MESSAGE from [email protected] MESSAGE Mögliche Verteidigung Authentisierung des Absenders F.20

11 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 Mögliche Verteidigung Sicherstellung der Integrität der Nachrichten Sicherstellung der Vertraulichkeit F 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

12 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 Authentisierung (2) HTTP-Digest-Authentifizierung (fortges.) Beispiel: Authentisierung eines User-Agent beim Registrar REGISTER Erzeuge Hash 401 Unauthorized (+Nonce) REGISTER (+MD5 Hash) Überprüfe Hash Nonce sorgt vor gegen Abhören der Verbindung dennoch: Verschlüsselung der Verbindung ist zu bevorzugen F.24