F.1-F.24 - Institut für Verteilte Systeme

Transcription

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
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
1.1 IM-URIs
■ URI-Schema für Zieladressen von Instant Messaging
◆ z.B. im:[email protected]
◆ ä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:[email protected]
◆ ähnlicher Aufbau wie IM-URIs
■ 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
1.2 SIP Instant Messaging
■ SIP MESSAGE Transaktion
◆ definiert in RFC 3428
[email protected]
[email protected]
MESSAGE [email protected]
200 OK
[email protected]
200 OK
◆ Body der Request-Nachricht enthält eigentliche Message für IM
F.6
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
F.7
■ Proxy als Zwischenspeicher einsetzbar
[email protected]
[email protected]
[email protected]
202 Accepted
200 OK
◆ Proxy speichert Nachricht
• 202 Status
◆ Proxy liefert Nachricht aus, sobald Benutzer registriert ist
F.8
■ SIP Nachricht (Request)
MESSAGE sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP alice.a.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:[email protected];tag=49583
To: sip:[email protected]
Call-ID: [email protected]
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
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
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
[email protected]
[email protected]
◆ Fähigkeiten des Präsenzdienstes mit OPTIONS abfragbar
• ermittelt unterstützte Transaktionstypen
• ermittelt unterstützte Event-Packages (Header: Allow-events)
F.11
■ 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
■ 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
■ 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
■ 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:[email protected]">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">mailto:[email protected]</contact>
</tuple>
</presence>
F.15
■ 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
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
2.1 Bedrohungen
■ Registration Hijacking
◆ User-Agent täuscht falsche Identität vor
◆ z.B. falsche Registrierung
[email protected]
[email protected]
[email protected]
REGISTER [email protected]
200 OK
200 OK
■ Mögliche Verteidigung
◆ Authentisierung beim Registrieren im Registrar
F.18
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]
[email protected]
301 Moved Permanently
to [email protected]
◆ Authentisierung des Servers bzw. Proxy
F.19
2.1 Bedrohungen (3)
■ Spoofing
◆ Vortäuschen eines falschen Absenders
◆ z.B. Jack gibt vor Bob zu sein
• falscher From-Header
[email protected]
[email protected]
[email protected]
from [email protected]
200 OK
200 OK
◆ Authentisierung des Absenders
F.20
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
[email protected]
[email protected]
[email protected]
200 OK
200 OK
◆ Sicherstellung der Integrität der Nachrichten
◆ Sicherstellung der Vertraulichkeit
F.21
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
◆ Authentisierung der Sender
◆ Provider kann evtl. Quelladressen sperren
F.22
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
2.3 Authentisierung (2)
■ HTTP-Digest-Authentifizierung (fortges.)
◆ Beispiel: Authentisierung eines User-Agent beim Registrar
[email protected]
[email protected]
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

F.1-F.24 - Institut für Verteilte Systeme

Transcription

Similar documents

13 Signaling Protocols for Multimedia Communication

CISCO SMART UC IM ÜBERBLICK dAs koMMUnikATionssYsTeM

Slides

13 Signaling Protocols for Multimedia Communication

SIP - VDE

Effiziente und sichere Behördenkommunikation

Chef/Sek und Team-Dashboard für Microsoft® Skype for Business

Calisto 620-M

Chef/Sek-Dashboard für Microsoft® Lync™ Quicklink 2.3

Einzelraum-Management mit LON-Technologie in der ABN AMRO

Sondermann S und S Strategy 16.06.09

Kapitel 5.7

kunde. Wehrwissenschaftliche Rundschau. Offizielle

F.102a F.102b - Institut für Verteilte Systeme