Sicherheit in SIP-basierten VoIP-Netzen

Inhaltsverzeichnis

1. Einleitung

2. Der VoIP-Protokollstack
2.1. Das ISO/OSI-Referenzmodell
2.1.1. Einordnung der VoIP-Protokolle im ISO/OSI-Referenzmodell
2.2. Protokolle für die Mediadatenübertragung
2.2.1. Das Real-time Transport Protocol
2.2.2. Das Real-time Transport Control Protocol
2.3. Signalisierungsprotokolle
2.3.1. Das Session Initiation Protocol
2.3.2. Das Inter-Asterisk eXchange Protocol
2.4. Weitere VoIP-Protokolle

3. Sicherheitsbezogene Protokolle und Mechanismen
3.1. Internet Protocol Security Protocol (IPsec)
3.1.1. Implementierung der Sicherheitsdienste und Betriebsarten von IPsec
3.1.2. Umsetzung einer Sicherheitsstrategie bei IPsec
3.1.3. Kritikpunkte
3.2. Transport Layer Security (TLS)
3.2.1. TLS Handshake Protocol
3.2.2. TLS Record Protocol
3.2.3. Kritikpunkte
3.3. SIP Digest Authentication
3.4. Session Initiation Protocol Secure (SIPS)
3.5. Secure Real-time Transport Protocol (SRTP)
3.5.1. Multimedia Internet KEYing (MIKEY)
3.5.2. Ablauf der gesicherten Kommunikation bei SRTP
3.5.3. Zfone Real-Time Transport Protocol (ZRTP)

4. VoIP und NAT
4.1. Network Address Translation
4.2. Die NAT-Problematik bei SIP
4.3. Lösungsmöglichkeiten im Bezug zur NAT-Problematik
4.3.1. Symmetric Response Routing
4.3.2. Symmetric RTP/RTCP
4.3.3. Weitere Lösungsmöglichkeiten

5. Die ungeschützte Testumgebung
5.1. Verwendete Hardund Software
5.1.1. Die Linux-Firewall Netfilter/iptables
5.1.2. Der VoIP-Server Asterisk
5.1.3. Der VoIP-Client Blink
5.2. Überblick auf die ungesicherte VoIP-Infrastruktur
5.3. Konfiguration der Komponenten
5.3.1. Konfiguration der NAT-Gateways
5.3.2. Konfiguration des DNS-Servers
5.3.3. Konfiguration der Asterisk-Server
5.3.4. Konfiguration der VoIP-Clients
5.4. Testen der ungesicherten VoIP-Infrastruktur

6. Feststellen der Bedrohungen
6.1. Klassifikation von Angriffen
6.2. Netzwerkspezifische Bedrohungen
6.2.1. Bedrohungen auf der Sicherungsschicht
6.2.2. Bedrohungen auf der Vermittlungsschicht
6.2.3. Bedrohungen auf der Transportschicht
6.2.4. Bedrohungen auf der Anwendungsebene
6.3. Strukturanalyse der VoIP-Testumgebung
6.4. Angriffe auf die primären Schutzziele
6.4.1. Angriffe auf das Schutzziel der Verfügbarkeit
6.4.2. Angriff auf das Schutzziel der Vertraulichkeit
6.4.3. Angriff auf das Schutzziel der Integrität und Authentizität

7. Schutzbedarfsfeststellung
7.1. Schutzbedarfsfeststellung für die VoIP-Testumgebung
7.1.1. Schutzbedarfsfeststellung für Anwendungen
7.1.2. Schutzbedarfsfeststellung für IT-Systeme
7.1.3. Schutzbedarfsfeststellung für Räume
7.1.4. Schutzbedarfsfeststellung für Kommunikationsverbindungen

8. Auswahl und Umsetzung geeigneter Sicherheitsmaßnahmen
8.1. Schutz der Signalisierungsdaten mittels TLS
8.1.1. Zertifikate
8.1.2. Konfiguration der Asterisk-Server
8.1.3. Konfiguration der VoIP-Clients
8.1.4. Konfiguration des DNS-Servers
8.2. Schutz der Mediadaten mittels SRTP
8.2.1. Konfiguration der Asterisk-Server
8.2.2. Konfiguration der VoIP-Clients
8.3. Die Konfiguration der Firewall
8.4. Testen der geschützten Umgebung
8.5. Wiederholung der Angriffe auf die primären Schutzziele
8.5.1. Angriff auf das Schutzziel der Verfügbarkeit
8.5.2. Angriff auf das Schutzziel der Vertraulichkeit
8.5.3. Angriff auf das Schutzziel der Integrität und Authentizität

9. Fazit
9.1. Erkannte Schwachstellen
9.1.1. Schwachstellen in Bezug auf die Vertraulichkeit
9.1.2. Schwachstellen in Bezug auf die Authentizität und Integrität
9.1.3. Schwachstellen in Bezug die Verfügbarkeit
9.2. Vergleich mit IPsec
9.3. Schlusswort

Literaturverzeichnis

Abbildungsverzeichnis

Listings

Tabellenverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

Der heutzutage anzutreffende Trend, Telefonate statt über das klassische leitungsgebundene Telefonnetz über das Internet zu führen, bietet neben den monetären noch weitere Vorteile. Ein Aspekt betrifft beispielsweise die Ortsungebundenheit. Einem Teilnehmer wird eine Adresse, ähnlich einer E-Mail-Adresse, zugewiesen. Das Telefon des Teilnehmers, dem die Adresse durch entsprechende Konfiguration bekannt gegeben wird, kann an jedem Ort der Welt mit dem Internet verbunden werden und garantiert somit die Erreichbarkeit des Teilnehmers.

Doch wie steht es um die Sicherheit? Können Gespräche über das Internet genauso „sicher“ wie über das klassische Telefonnetz oder das GSM-Netz abgewickelt werden? Um diese Frage zu klären, soll an dieser Stelle darauf hingewiesen werden, dass auch jene Netze, die an einen Telefonprovider gebunden sind, nicht hundertprozentige Sicherheit bieten. Zum einen lässt das heute allgegenwärtige Thema „Vorratsdatenspeicherung“ erkennen, dass zumindest die Verkehrsdaten aufgezeichnet werden, unabhängig davon, ob es sich um Festnetzoder GSM-Telefonie handelt. Auf der anderen Seite ist es auch versierten Privatpersonen möglich, dank der Open Source-Software OpenBTS und relativ kostengünstiger Hardware einen IMSI-Catcher (International Mobile Subscriber Identity) zu bauen und damit illegalerweise Telefongespräche abzuhören.

Nichtsdestotrotz soll diese Diplomarbeit lediglich klären, ob ein sicheres Telefonieren über das Medium Internet möglich ist. Dazu wird nachfolgend aufgeführte Gliederung verwendet.

Dass der Einleitung folgende Kapitel 2 beleuchtet im ersten Schritt die wichtigsten Protokolle im Bezug auf die Telefonie über das Internet. Neben den „klassischen“ Protokollen wie beispielsweise das Internet Protocol auf der Vermittlungsschicht und dem Transmission Control Protocol und dem User Datagram Protocol auf der Transportebene liegt der Fokus dieses Kapitels auf jenen Protokollen, welche für die Durchführung eines Telefonats über ein Netzwerk von Relevanz sind. Hier handelt es sich auf der einen Seite um das Session Initiation Protocol, das für die Signalisierung und somit in weiterer Folge für die Etablierung eines Mediakanals, in dem die Sprachdaten ausgetauscht werden, zuständig ist. Auf der anderen Seite wird auf das Real-time Transport Protocol eingegangen, dass dermaßen konzipiert ist, dass es auch echtzeitkritische Daten, wie den Mediaverkehr in Form von Sprachdatenpaketen, über ein Netzwerk transportieren kann.

Besteht der Bedarf, die Signalisierungsund Mediadaten bezüglich der Vertraulichkeit, Authentizität und Integrität zu schützen, so bedarf es gesonderter Protokolle, die solche Schutzziele erfüllen. Einen Teil solcher Protokolle behandelt Kapitel 3. Neben dem auf der Netzwerkschicht arbeitenden Internet Protocol Security Protocol, kurz IPsec, liegt das Hauptaugenmerk in diesem Kapitel auf dem Transport Layer Security (TLS)-Protokoll. Während das erstgenannte Protokoll in der Lage ist, sowohl die Signalisierungsals auch die Sprachdaten zu schützen, wird TLS nur herangezogen, um die Signalisierungsdaten abzusichern. Um dennoch den Schutz der Mediadaten zu gewährleisten, kann auf das ebenfalls beschriebene Secure Real-time Transport Protocol (SRTP) zurückgegriffen werden.

In Kapitel 4 wird darauf folgend erkannt, dass bei der Signalisierung und dem Transport der Mediadaten Probleme auftreten können, wenn sich zwischen den beteiligten Komponenten ein Network Address Translation (NAT)-Gateway befindet. Beleuchtet werden in diesem Kapitel nicht

KAPITEL 1. EINLEITUNG

Abbildung in dieser Leseprobe nicht enthalten die möglicherweise auftretenden Probleme, sondern auch unterschiedliche Lösungsansätze.

Im nächsten Schritt, beschrieben in Kapitel 5, erfolgt der Aufbau einer Testumgebung zum Zwecke der Internet-Telefonie. Beim Herzstück dieser Umgebung handelt es sich um zwei Asterisk- Server in unterschiedlichen Domänen. Daneben finden sich noch fünf VoIP-Clients in Form der Software Blink sowie ein Domain Name System (DNS)-Server. Nach der Konfiguration sämtlicher genannter Komponenten wird in diesem Kapitel abschließend noch ein Funktionstest hinsichtlich einer ungeschützten Kommunikation durchgeführt.

Diese Testumgebung dient in weiterer Folge als Grundlage für das Kapitel 6, in dem jene Bedrohungen festgestellt werden, denen die ungeschützte Testumgebung ausgeliefert ist. Um sämtliche Bedrohungen erkennen zu können, bedarf es einer systematischen Vorgehensweise. In dieser Arbeit wurde der IT-Grundschutz, ein vom Bundesamt für Sicherheit in der Informationstechnik (BSI) veröffentlichter Standard, als Vorgehensweise herangezogen. Abgeschlossen wird dieses Kapitel mit einer Auswahl von Angriffen auf die Testumgebung, um die Existenz der erkannten Bedrohungen offensichtlich zu machen.

Der nächste logische Schritt nach der Bedrohungsfeststellung ist zu erkennen, welcher Schutzbedarf notwendig ist, um den Bedrohungen entgegenwirken zu können. Kapitel 7 befasst sich mit dieser Thematik. Auch hier wird wieder nach dem IT-Grundschutz des BSI vorgegangen.

Nachdem die Bedrohungen und der benötigte Schutz festgestellt wurden, gilt es nun, geeignete Sicherheitsmaßnahmen auszuwählen und umzusetzen, damit der Schutzbedarf auch tatsächlich befriedigt wird. Kapitel 8 stellt sich im ersten Teil dieser Problematik, anschließend wird die zu betrachtende Umgebung wieder auf deren Funktion im Hinblick auf die implementierten Sicherheitsmaßnahmen getestet. Abschließend werden nochmals jene Angriffe durchgeführt, die schon zuvor in der ungesicherten Testumgebung zum Erfolg führten.

Am Ende der vorliegenden Arbeit in Kapitel 9 soll letztendlich Resümee gezogen werden. Es soll die Frage geklärt werden, ob dank der umgesetzten Sicherheitsmaßnahmen eine sichere Telefonie über ein unsicheres Netzwerk – und beim Internet handelt es sich um ein solches – möglich ist.

2. Der VoIP-Protokollstack

Die Kommunikation in einem Netzwerk verläuft nach bestimmten Protokollen. Dies gilt auch für Voice over IP (VoIP), einer in IP-Netzen durchgeführten Sprachkommunikation. Die von einer Applikation auf Senderseite erzeugten Daten durchlaufen mehrere Protokollschichten, bevor sie anschließend über ein physikalisches Medium zum Rechner des Empfängers übertragen werden. Dort werden die selben Schichten nochmals, diesmal aber in inverser Reihenfolge, passiert. Die Aufgaben jeder einzelnen Schicht sind dabei unterschiedliche. Grundsätzlich gibt es zwei Modelle, mit denen eine Kommunikation beschrieben werden kann. Zum einen handelt es sich um das ISO/OSI-Referenzmodell, welches eher einen theoretischen Ansatz verfolgt, und zum anderen um das in der Praxis tatsächlich verwendete TCP/IP-Referenzmodell. Details zum erstgenannten Modell finden sich im anschließenden Kapitel 2.1 wieder.

Bei einer VoIP-Kommunikation muss eine Unterscheidung zwischen der Signalisierung und der eigentlichen Übermittlung der Sprachdaten getroffen werden. Die Signalisierung ist für die Herstellung und den Abbau einer Verbindung zwischen den Kommunikationspartnern zuständig. Eine Beschreibung der bekanntesten Signalisierungsprotokolle erfolgt in Kapitel 2.3, wobei hier das Hauptaugenmerk auf das Session Initiation Protocol SIP gelegt wird. Nach einem erfolgreichen Verbindungsaufbau kann die Übertragung der Sprachdaten erfolgen. Ein dafür zuständiges Protokoll ist das in Kapitel 2.2 beleuchtete Real-time Transport Protocol RTP sowie dessen zugehöriges Kontrollprotokoll RTCP (Real-time T ransp o r t Control Protocol).

2.1. Das ISO/OSI-Referenzmodell

Das ISO/OSI-Referenzmodell wurde seit den späten 70er Jahren mit dem Ziel entwickelt, ein offenes System für Kommunikationsverbindungen (OSI - Open Systems Interconnection) zu schaffen. Standardisiert wurde dieses Modell im Jahr 1983 von der International Organization for Standardization (ISO). Das aus sieben Schichten bestehende ISO/OSI-Referenzmodell (kurz: OSI-Modell) stellt selbst keine Netzwerkarchitektur dar, sondern beschreibt lediglich die Aufgaben der einzelnen Schichten. Die Wahl auf ein siebenschichtiges Modell fiel dabei u. a. auf Grund folgender Überlegungen [1]:

- ein neuer Abstraktionsgrad soll die Erstellung einer neuen Schicht bedingen
- jede Schicht hat eine definierte Funktion zu erfüllen
- die Abgrenzung der Schichten sollte so erfolgen, dass der Informationsfluss zwischen benachbarten Schichten so gering wie möglich ist
- die Anzahl der Schichten soll einen Kompromiss zwischen der Überschaubarkeit der Architektur und einer klaren Funktionstrennung darstellen

Betrachtet man das OSI-Modell in Abbildung 2.1, so lässt sich erkennen, dass der Kommunikationsfluss hier auf zwei Ebenen erfolgt. Auf der einen Seite erfolgt die Kommunikation auf vertikale Weise, das bedeutet, dass jede Schicht ein Interface zu den angrenzenden Schichten besitzt (Interlayer-Kommunikation). Ein wesentliches Merkmal dieser Kommunikationsart ist, dass eine Schicht die Dienste der darunterliegenden Ebene nutzt und im Gegenzug seine Dienste der überliegenden Schicht anbietet. Auf der anderen Seite erfolgt die Kommunikation horizontal, man spricht hier auch von einer Peer-to-Peer-Kommunikation. Hier kommuniziert jede Schicht des OSI-Modells auf dem System des Absenders mit der gleichrangigen Schicht auf dem Zielsystem.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.: Das ISO/OSI-Referenzmodell [1]

2.1.1. Einordnung der VoIP-Protokolle im ISO/OSI-Referenzmodell

Jene Protokolle, die für eine erfolgreiche VoIP-Kommunikation erforderlich sind, befinden sich in unterschiedlichen Schichten des OSI-Modells. Ein gemeinsames Merkmal sämtlicher für den Verbindungsaufbau zuständigen Signalisierungsprotokolle ist deren Zuordnung zur Anwendungsschicht. Unterschiede ergeben sich aber bei der Wahl des Transportprotokolls. So verwendet das Signalisierungs-Framework H.323-SIG hauptsächlich TCP, während das in Kapitel 2.3.1 beschriebene Session Initiation Protocol Mechanismen zur Fehlerbehebung selbst mitbringt und somit auf das verbindungslose UDP aufsetzen kann. Auch das Inter-Asterisk eXchange Protocol sowie diverse Protokolle zur Steuerung von VoIP-Gateways wie MGCP oder Megaco nutzen das verbindungslose Transportprotokoll.

Schwieriger gestaltet sich die Zuordnung des Real-time Transport Protocols (RTP), das für die Übertragung der Mediadaten zuständig ist (siehe Kapitel 2.2.1). So deklariert der für dieses Protokoll zuständige RFC 3550 [2], dass es sich bei RTP um ein Transportprotokoll, also einem Protokoll der Transportschicht, handelt. Andererseits nutzt es aber UDP und dessen Multiplexingfähigkeiten. Ebenso ist RTP sehr eng mit der Applikation verknüpft und würde somit einer Zuordnung zu Schicht 7 entsprechen. Eine Möglichkeit der Einordnung wäre, UDP als Protokoll Schicht 4a zu betrachten und darauf aufsetzend RTP dem Layer 4b zuzuordnen [3].

2.2. Protokolle für die Mediadatenübertragung

Protokolle zum Zwecke der Übertragung von Mediadaten müssen vor allem einen Aspekt berücksichtigen: Die Übermittlung der Audiound Videodaten soll in Echtzeit erfolgen. Ein Protokoll, dass diesen Aspekt zu erfüllen versucht, ist das in Kapitel 2.2.1 betrachtete Real-time Transport Protocol (RTP) sowie das zugehörige Real-time Transport Control Protocol (RTCP), welches eine Überwachung der RTP-Echtzeitkommunikation vornimmt und dadurch eine Sicherstellung der Übertragungsqualität gewährleisten soll. RTCP wird in Kapitel 2.2.2 behandelt. Sowohl RTP als auch RTCP sind im RFC 3550 [2] spezifiziert.

2.2.1. Das Real-time Transport Protocol

Bei RTP handelt es sich um ein verbindungsloses und ungesichertes Transportprotokoll, das in der Regel auf UDP aufsetzt. RTP teilt den von der Anwendungsschicht einlangenden Mediastrom in Pakete auf, die den Payload eines RTP-Pakets darstellen. Diesem Payload wird noch ein Header (siehe Kapitel 2.2.1.2) vorangestellt, bevor das RTP-Paket an das darunterliegende Transportprotokoll weitergereicht wird. Auf dem Weg vom Sender zum Empfänger kann dieses Paket mehrere RTP-spezifische Komponenten durchlaufen, wie im anschließenden Kapitel 2.2.1.1 beschrieben wird.

2.2.1.1. Komponenten eines RTP-Systems

In diesem Abschnitt wird auf die grundlegendsten Elemente eines RTP-Systems eingegangen. Im Konkreten handelt es sich dabei um folgende Komponenten, wobei die drei letztgenannten Punkte optionale Bestandteile sind:

- Sender
- Empfänger
- Session
- Translator
- Mixer
- Monitor

Der RTP-Sender erfasst (im Kontext von VoIP) die Sprache und digitalisiert diese. Anschließend werden die so gewonnenen Daten entweder Abtastwertoder Segment-orientiert codiert und als Payload eines oder mehrerer RTP-Pakete verwendet. Nach der Erzeugung eines RTP-Headers wird diesen Paketen noch ein UDP- und IP-Header vorangestellt und schlussendlich versandt [4]. Eine weitere Aufgabe des RTP-Senders ist die Generierung von Sender Reports sowie der Empfang und die Auswertung von Receiver Reports, um im Bedarfsfall eine Übertragungsanpassung vornehmen zu können (siehe auch Kapitel 2.2.2).

Der RTP-Empfänger durchläuft diese Prozedur in umgekehrter Reihenfolge. Er empfängt die Pakete, führt eventuelle Fehlerkorrekturen durch, dekodiert die Sprachdaten und transformiert sie mittels eines D/A-Wandlers in ein analoges Signal. Damit der RTP-Sender die zuvor erwähnte Anpassung durchführen kann, muss der Empfänger diesem auch in periodischen Abständen Receiver Reports zukommen lassen.

Unter einer RTP-Session versteht man eine Menge an Teilnehmern, die mittels RTP miteinander kommunizieren, wobei jeder Teilnehmer durch eine Netzwerkadresse und einem Port-Paar identifi- ziert werden kann. Der erste dieser beiden Ports muss eine geradzahlige Portnummer besitzen und wird für die RTP-Kommunikation verwendet. Der darauffolgende Port (mit ungerader Portnummer) dient der Übermittlung von RTCP-Paketen. Sessions können in zwei Gruppen kategorisiert werden: Zum einen in Unicast-Sessions, bei denen die Kommunikation Punkt-zu-Punkt erfolgt, oder in Multicast-Sessions, in denen mehr als zwei Teilnehmer involviert sind.

Die Verwendung eines Translators zwischen Sender und Empfänger ist dann notwendig, wenn eine Konvertierung der Mediadaten vorzunehmen ist. Ein Translator kann aber auch andere Aufgaben durchführen, wie etwa eine Verund Entschlüsselung oder eine Filterung des Mediastreams. Das SSRC-Feld im RTP-Header (siehe Kapitel 2.2.1.2) bleibt bei der Weiterleitung des Pakets durch die Bearbeitung dieser Komponente unberührt.

Ein Mixer empfängt RTP-Datenpakete von einer oder mehreren Quellen und führt diese zusammen, um sie anschließend als eine Abfolge von Paketen weiterzuleiten, die nur aus einer einzigen Quelle, dem Mixer, stammen. Diese Quelle wird auch bei den neu geformten Paketen im SSRC-Feld des RTP-Headers eingetragen.

Als letzte Komponente sei noch der Monitor zu erwähnen, dessen Einsatz dann Sinn macht, wenn statistische Auswertungen oder Fehlerdiagnosen einer Sprachverbindung durchzuführen sind. Ein Monitor empfängt die RTCP-Pakete und kann aus den dort enthaltenen Informationen Rückschlüsse über den aktuellen Dienstgüte-Status der Verbindung ziehen.

2.2.1.2. Der RTP-Header

Ein RTP-Paket besteht aus einem Header sowie einem Nutzdatenanteil, welcher das eigentliche Medium (z. B. Sprache) in codierter Form enthält.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.: RTP-Header

Die Bedeutung der einzelnen Felder im RTP-Header (Abbildung 2.2) ist im RFC 3550 [2] folgendermaßen definiert:

- V (Version): Dieses Feld kennzeichnet die RTP-Version, welche laut RFC 3550 mit dem Wert 2 definiert ist.
- (Padding): Bei gesetztem Padding-Flag enthält dieses Paket eine Menge von Füllbytes am Paketende, die nicht Teil des Payloads sind.
- X (Extension): Ist dieses Flag gesetzt, muss am Ende des Headers genau eine Header Extension in einem vorgegebenen Format angefügt werden.
- CC (CSRC Count): Der hier eingetragene Wert kennzeichnet die Anzahl der in diesem Header befindlichen CSRC Identifier.
- M (Marker): Die Interpretation dieses Felds ist durch ein Profil definiert.
- PT (Payload Type): Die Angabe in diesem Feld beschreibt das Verfahren, mit dem die Mediadaten im Payload-Abschnitt codiert wurden. Einen Aufschluss über das Mapping zwischen dem Payload Type und dem verwendeten Audiooder Videocodec gibt der RFC 3551 [5].
- Sequence Number: Der Wert dieses Feldes wird bei jedem zu sendenden RTP-Paket um den Wert 1 inkrementiert. Der Empfänger hat dadurch einerseits die Möglichkeit, fehlende Pakete zu erkennen und andererseits die Reihenfolge der einlangenden Pakete wieder herzustellen. Es wird empfohlen, für das erste Paket eine zufällige, nicht vorausbestimmbare Zahl zu verwenden, um Known-Plaintext-Angriffe zu erschweren.
- Timestamp: Dieser Wert spiegelt jenen Zeitpunkt wieder, zu dem das erste Nutzdaten-Byte erzeugt wurde. Wie schon bei der Sequence Number sollte auch hier der Anfangswert ein zufälliger sein. Der Zeitstempel ist vor allem notwendig, um auftretende Zeitschwankungen einlangender Pakete (Jitter) erkennen und entsprechende Maßnahmen einleiten zu können.
- SSRC (Synchronization Source Identifier): Damit ein Empfänger Pakete unterschiedlichen Quellen zuordnen kann, wählt ein Sender eine für die Dauer der Session gültige Zufallszahl, die in dieses Feld eingetragen wird. Durch die Breite von 32 Bit ist zwar die Möglichkeit gering, dass zwei Quellen denselben SSRC besitzen, dennoch ist sie gegeben. Aus diesem Grund müssen RTP-Implementierungen derartige Kollisionen erkennen und bewältigen können.
- CSRC (Contributing Source Identifiers): Bei Verwendung eines Mixers werden mehrere Medienströme gebündelt und an den Empfänger weitergeleitet. Als SSRC ist in solchen Paketen jene vom Mixer angegeben. Damit der Empfänger dennoch die Ursprungsquellen feststellen kann, fügt der Mixer die SSRCs von maximal fünfzehn Quellen in diesen jeweils 32 Bit breiten (optionalen) Feldern ein.
- Extension Header: Dieses optionale Feld ermöglicht es, RTP zu erweitern und dadurch an neue Anwendungen anzupassen.

2.2.2. Das Real-time Transport Control Protocol

Als Schwesternprotokoll von RTP kann das Real-time Transport Control Protocol (RTCP) betrachtet werden, welches ebenso im RFC 3550 [2] spezifiziert ist. Die Grundlage von RTCP ist der periodische Versand von Kontrollpaketen an alle Teilnehmer innerhalb einer Session. Mit Hilfe dieser RTCP-Pakete können vier Aufgaben erfüllt werden. Die in den meisten Fällen wichtigste Funktion ist, dass anhand von Reports Abschätzungen über die Netzqualität getroffen werden und im Bedarfsfall gegenlenkende Maßnahmen, wie etwa eine Drosselung der Sendedatenrate, herbeigeführt werden können. Die nächste Aufgabe besteht darin, jedem Teilnehmer einen eindeutigen, kanonischen Namen (CNAME) zu geben, anhand dessen er identifiziert werden kann. Ein Empfänger kann so mehrere Mediaströme eines bestimmten Teilnehmers unterschiedlicher Sessions wieder bündeln. Grundsätzlich ist dies auch mit dem SSRC-Feld des RTP-Headers möglich, aber bei Verwendung eines Mixers entfällt diese Option. Die Berechnung des Intervalls, in dem RTCP-Pakete versendet werden, ist die dritte Aufgabe dieses Protokolls. Bei vielen Teilnehmern kann ein zu häufiger Versand von RTCP-Paketen die zur Verfügung stehende Bandbreite für die eigentlichen Nutzdaten negativ beeinträchtigen. Da jeder Teilnehmer die Gesamtzahl der Sessionteilnehmer anhand der erhaltenen RTCP-Pakete kennt, kann er so einen optimalen Zeitintervall berechnen, in dem die Kontrollpakete gesendet werden. Als letzte (optionale) Funktionalität sei noch die Möglichkeit erwähnt, dass ein Teilnehmer ihn betreffende Informationen übermitteln kann, welche dann beispielsweise auf der Benutzeroberfläche der anderen Teilnehmer erscheint.

Insgesamt unterscheidet der RFC 3550 [2] zwischen fünf unterschiedlichen RTCP-Paketen:

- Sender Report (SR)
- Receiver Report (RR)
- Source Description (SDES)
- Beendigung der Teilnahme (BYE)
- Applikationsspezifische Pakete (APP)

Im Hinblick auf die Überwachung der Kommunikationsqualität sind hier die beiden erstgenannten Paketarten von besonderer Relevanz [4], die deshalb nun näher betrachtet werden.

Ein Sender Report (Abbildung 2.3) besteht, wenn man von optionalen profilspezifischen Erweiterungen absieht, aus drei Abschnitten:

- Header
- Sender Info
- keinen, einen oder mehrere Report-Blöcke

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3.: Sender Report

Manche der Header-Felder im Sender Report existieren auch schon im Header eines RTP-Pakets und haben auch hier die selbe Bedeutung (Version, Padding und SSRC). Das Packet Type-Feld (PT) gibt Aufschluss darüber, um welches RTCP-Paket es sich handelt. Im Falle eines Sender Reports ist hier der dezimale Wert 200 eingetragen. Wie soeben festgestellt wurde, kann ein Sender Report eine unterschiedliche Anzahl von Report-Blöcken enthalten. Der Reception Report Count (RC) informiert über diese Anzahl. Der Eintrag im Length-Feld gibt schlussendlich Auskunft über die Größe des RTCP-Pakets, angegeben in 32-Bit-Blöcken. Miteingeschlossen ist hier auch der Header.

Der zweite Abschnitt, die Sender Info, fasst die Informationen der Datenübertragung des Senders zusammen. Die ersten beiden Bestandteile dieses Abschnitts sind zwei unterschiedliche Zeitstempel. Zum einen handelt es sich um einen 64 Bit breiten Network Time Protocol (NTP)-Zeitstempel und zum anderen um einen 32-Bit-RTP-Zeitstempel. Der Letztgenannte ist vom Format her betrachtet ident mit jenem Zeitstempel im RTP-Header, jedoch sind hier unterschiedliche Werte . Der Grund hierfür liegt darin, dass das RTP- und das RTCP-Paket zu unterschiedlichen Zeitpunkten versendet werden. Mit Hilfe der Zeitstempel ist es möglich, die Round Trip Delay der übertragenen Pakete zu ermitteln. Der im Sender’s Packet Count-Feld eingetragene Wert informiert über die Anzahl der gesendeten RTP-Datenpakete seit Session-Beginn. Eine ähnliche Bedeutung hat das Sender’s Octet Count-Feld, dessen Wert die Menge versendeter Bytes seit Beginn der Session angibt. Hier werden jedoch nur die Nutzdaten betrachtet, der Header und eventuell vorhandene Padding-Bytes werden hier nicht berücksichtigt.

Der letzte Abschnitt umfasst die Report-Blöcke. Die Anzahl dieser Blöcke richtet sich danach, von wie vielen Quellen – auf Grund des nur fünf Bit breiten RC-Feldes jedoch höchstens 31 – seit dem letzten Versand eines Sender Reports RTP-Pakete empfangen wurden. Das bedeutet unter anderem auch, dass ein nur als Sender agierendes Element keinen Report-Block in seinem Sender Report enthält. Folgende Felder sind in einem Report-Block enthalten:

- SSRC: jene Quelle, der dieser Report-Block zugeordnet ist
- Fraction Lost: gibt das Verhältnis zwischen verlorenen und erwarteten Paketen seit dem letzten Report-Versand wieder
- Cumulative Number of Packets Lost: die Gesamtzahl der verlorenen Pakete seit Session- Beginn
- Extended Highest Sequence Number Received: Dieses 32-Bit-Feld enthält zwei Informationen: Die niederwertigen 16 Bits enthalten die höchste Sequenznummer aller empfangenen RTP-Pakete dieser Quelle, während die höherwertigen 16 Bits die Anzahl der Zyklen beschreibt.

- Interarrival Jitter: gibt eine Abschätzung des Jitter-Wertes wieder
- Last Sender Report Timestamp (LSR): enthält die mittleren 32 Bit des 64 Bit breiten NTP-Zeitstempels. Wurde noch kein Sender Report empfangen, ist der Wert dieses Felds Null.

- Delay Since Last SR (DLSR): enthält die Zeitspanne zwischen dem zuletzt empfangenen Sender Report und dem Versand dieses Report-Blocks, wobei hier eine Zeiteinheit 2 − 16 Sekunden bedeuten. Auch hier gilt, dass der Wert dieses Felds Null ist, solange kein Sender Report eingegangen ist.

Der Receiver Report weist gegenüber einem Sender Report nur zwei Unterschiede auf. Zum einen ist hier im Payload Type-Feld der Dezimalwert 201 eingetragen und zum anderen enthält ein Receiver Report keinen Sender Info-Abschnitt.

2.3. Signalisierungsprotokolle

Vor der Übertragung der Mediadaten ist es notwendig, eine Verbindung zwischen den beteiligten Kommunikationspartnern herzustellen. Die in diesem Kapitel vorgestellten Signalisierungsprotokolle dienen genau diesem Zweck. Die ausführlichste Beschreibung verdient hier das Session Initiation Protocol in Kapitel 2.3.1, da dieses Protokoll in Bezug auf die Signalisierung im Mittelpunkt dieser Diplomarbeit steht. Im darauffolgenden Kapitel 2.3.2 erfolgt eine kurze Betrachtung des InterAsterisk eXchange Protocols, welches aber eine Sonderstellung einnimmt: Es ist kein „reines“ Signalisierungsprotokoll, vielmehr zeichnet es sich auch für den Transport der Mediadaten verantwortlich.

2.3.1. Das Session Initiation Protocol

Beim Session Initiation Protocol (SIP) handelt es sich um ein textbasiertes Signalisierungsprotokoll auf der Anwendungsschicht. Es ist sowohl für den Aufund Abbau als auch für die Steuerung von Sessions zwischen zwei oder mehreren Teilnehmern verantwortlich. Bei den Sessions muss es sich nicht zwingenderweise um Sprachtelefonate handeln. Ebenso lassen sich auch Videotelefonie, Instant Messaging Services oder ähnliche Dienste mit diesem Protokoll realisieren.

2.3.1.1. SIP-Funktionalitäten

Der RFC 3261 [6] erkennt folgende fünf Aspekte bezüglich der Errichtung und der Terminierung einer Kommunikation, welche durch SIP abgedeckt werden:

User Location: Dieser Aspekt beschreibt die Möglichkeit, ein für die Kommunikation erforderliches Endsystem zu lokalisieren. Ein potenzieller Gesprächsteilnehmer ist somit nicht an eine fixe IP-Adresse gebunden, unter der er erreichbar ist. Vielmehr meldet sich dieser Teilnehmer von einer beliebigen IP-Adresse bei einem Registrar Server (siehe Kapitel 2.3.1.2) an, wobei die aktuelle IP-Adresse in einer Location Database gespeichert wird. Ein Anrufer erhält dann durch eine Anfrage an diese Datenbank die Adresse des gewünschten Gesprächspartner und kann im weiteren Verlauf einen Anruf initiieren.

User Availability: Dieser Punkt gibt dem Teilnehmer die Möglichkeit, den Status seiner Verfügbarkeit – schon vor dem Eintritt in eine Session – zu definieren. Vergleichbar ist dies mit Instant Messaging Diensten wie etwa Skype. Auch hier kann der Benutzer festlegen, ob er für andere erreichbar sein soll.

User Capabilities: Vor dem Aufbau einer Verbindung muss festgestellt werden, welche Medientypen bzw. welche Parameter von sämtlichen an der Kommunikation Beteiligten unterstützt werden.

Session Setup: Hier ist die Aufgabe gemeint, den kompletten Aufbau einer Session durchzuführen, sodass am Ende eine Verbindung zwischen zwei oder mehreren Teilnehmern hergestellt ist. Erst im Anschluss an eine erfolgreiche Etablierung können die eigentlichen Gesprächsdaten in Form eines Mediastreams zwischen den Beteiligten übertragen werden.

Session Management: Das Session Management ist unter anderem für das Beenden von Sessions, der Modifikation von Session-Parameter sowie das Aufrufen bestimmter Dienste verantwortlich.

2.3.1.2. Netzelemente in einer SIP-Infrastruktur

Eine SIP-Infrastruktur besteht aus unterschiedlichen Netzelementen, um die im vorigen Kapitel 2.3.1.1 beschriebenen Anforderungen erfüllen zu können. Zu den wichtigsten Netzelementen gehören:

- User Agent (UA)
–User Agent Client (UAC)
–User Agent Server (UAS)
- Proxy Server
–Stateless Proxy Server
–Stateful Proxy Server
- Registrar Server
- Redirect Server

User Agent

User Agents stellen die eigentlichen Kommunikationsendpunkte in einer SIP-Infrastruktur dar. Dabei unterscheidet man zwischen zwei Ausprägungsformen: entweder in Form eines sogenannten Hardphones oder als Softphone. Bei der erstgenannten Variante handelt es sich um eine eigens für den Zweck der Telefonie geschaffene Hardware. Die Konfiguration von Hardphones erfolgt entweder direkt am Gerät oder mittels einer Weboberfläche. Bei einem Softphone handelt es sich um eine Software-Applikation, die auf einer bestimmten Plattform läuft. Ein bekannter Vertreter hierfür ist das Programm Blink, das sowohl für das Windows-, MacOSX- als auch für das Linux-Betriebssystem existiert. Ebenso findet man derartige Anwendungen auch für PDAs und Smartphones.

Ein User Agent kann die Rolle eines Clients oder eines Servers übernehmen, dementsprechend wird hier eine Unterscheidung zwischen einem User Agent Client (UAC) und einem User Agent Server (UAS) getroffen. Welche Rolle ein User Agent dabei annimmt, ist von der jeweiligen Transaktion abhängig. Wie schon beim auf dem Request/Response-Verfahren basierenden Hypertext Transfer Protocol (HTTP) stellt auch hier der Anfragende (der Anrufer) den Client und der Beantworter (der Angerufene) den Server dar. Beendet der Angerufene das Gespräch, so wechseln die Rollen: Der Angerufene – in diesem Fall nun der Client – sendet einen Request für die Terminierung, welchen der als Server agierende Anrufer mit einem entsprechenden Response beantwortet.

Die nachfolgende Tabelle 2.1 listet die möglichen Requests auf, die ein UAC versenden kann. Hierbei ist zu beachten, dass es sich nur um die grundlegenden Requests handelt. Bei der Verwendung von SIP-Erweiterungen (siehe Kapitel 2.3.1.5) sind zusätzliche Requests möglich.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1.: SIP-Requests

Die Tabelle 2.2 auf der nächsten Seite gibt einen Überblick über die Response-Klassen, die sich stark an HTTP orientieren. Weiters sind in dieser Tabelle die wichtigsten Responses eingetragen. Eine vollständige Liste aller Responses ist dem RFC 3261 [6] zu entnehmen.

Proxy Server

Die Hauptaufgabe eines SIP Proxy Servers besteht darin, die einlangenden Requests sowie die zugehörigen Responses nach entsprechender Bearbeitung weiterzuleiten. Ein Request kann dabei mehrere Proxy Server durchlaufen, bis er den UAS erreicht hat. Die Antwort des UAS an den UAC passiert die selben Proxy Server in umgekehrter Reihenfolge. Der Proxy Server prüft jedoch den Request vor der Weiterleitung und beantwortet in Ausnahmefällen (z. B. wenn vom Client für den weiteren Verlauf Credentials benötigt werden) diese Anfrage selbst, anstatt sie an den UAS zu delegieren.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2.: SIP-Response-Klassen

Man unterscheidet zwischen zustandslosen und zustandsbehafteten Proxy Server. Im ersten Fall wird jeder Request bzw. Response unabhängig von den zuvor bearbeiteten behandelt, d. h. es werden keine Sitzungszustände gespeichert. Ein Stateless Proxy verwirft sämtliche Informationen, nachdem er die Nachricht weitergeleitet oder beantwortet hat. Im Gegensatz dazu speichert ein Stateful Proxy sämtliche Informationen aller getätigten Transaktionen. Dadurch können zukünftige Nachrichten unter Berücksichtigung der bereits getätigten Transaktionen bearbeitet werden. Solch ein zustandsbehafteter Proxy ist unter anderem vonnöten, wenn ein Request an mehrere Endpunkte gesendet werden soll (Forking). Bestätigt ein Endpunkt den Erhalt des Requests mit einem Response 200 (OK), so wird dieser Zustand gespeichert. Die anderen Endsysteme können nun von weiteren Anfragen ausgeschlossen werden.

Registrar Server

Beim Registrar Server handelt es sich um eine spezielle Form eines User Agents, der nur REGISTER-Requests empfängt. Die Aufgabe des Registrars ist es, die Ortsunabhängigkeit zu unterstützen, indem eine gültige Bindung zwischen einem Address-of-Record (AoR) in Form einer SIP URI eines Benutzers und seinem momentanen physikalischen Standort als IP-Adresse erzeugt und gespeichert wird.

Eng verbunden mit dem Registrar ist ein Location Server. Bei diesem handelt es sich um eine Datenbank, in der sämtliche Bindungen gespeichert sind. Nach jeder erfolgreichen Registrierung wird ein Update dieser Datenbank durchgeführt. Danach kann ein Benutzer von einem Anrufer durch eine Abfrage des Location Service lokalisiert werden. Der Ablauf der Registrierung und einer Lokalisierung ist in Abbildung 2.4 ersichtlich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4.: Registrierung und Lokalisierung in einer SIP-Infrastruktur

Im ersten Schritt registriert Bob sein Softphone auf der Domain biloxi.com. Der REGISTER- Request beinhaltet neben der physikalischen Adresse auch den AoR von Bob. Nach erfolgreicher Registrierung wird das Binding im Location Server gespeichert (Schritt 2). Versucht Alice im dritten Schritt, eine Session mit Bob herzustellen, so sendet sie einen INVITE-Request an den Inbound Proxy der Domain biloxi.com. Dieser Request beinhaltet auch den AoR von Bob. Der Inbound Proxy sendet eine Anfrage an den Location Server, ob der Benutzer Bob existiert und angemeldet ist (Schritt 4). Eine erfolgreiche Rückmeldung an den Inbound Proxy enthält unter anderem auch die aktuelle Kontaktadresse von Bob. Im letzten Schritt ersetzt der Inbound Proxy den AoR der Request URI durch die Kontaktadresse und leitet diesen INVITE-Request an das Softphone von Bob weiter.

Redirect Server

Anstelle eines Proxy Servers kann auch ein Redirect Server eingesetzt werden, um den Initiator der Kommunikaton über die IP-Adresse des Anzurufenden zu informieren. Nach einer Anfrage des UAC an den Redirect ermittelt dieser die IP-Adresse mit Hilfe eines Location Service. Das Ergebnis wird anschließend dem UAC mittels eines Response 302 (Moved Temporarily) mitgeteilt. Die weitere Kommunikation erfolgt dann – anders als beim Einsatz eines Proxy Servers – direkt zwischen den beiden Endsystemen.

Weitere Netzelemente

Zusätzlich zu den bisher aufgeführten Netzelementen finden in manchen Umgebungen noch weitere Elemente Verwendung. So kann etwa ein Back-to-Back User Agent (B2BUA) eingesetzt werden, um eine Anonymisierung oder ein Prepaid-Service zu realisieren. Des Weiteren wird ein B2BUA auch für ein eventuell erforderliches Audiooder Videotranscoding verwendet.

Ein weiteres wichtiges Netzelement, das SIP-Gateway, muss in die Infrastruktur integriert werden, wenn Netzwerke mit unterschiedlichen Topologien miteinander verbunden werden sollen. Ein Beispiel für den Einsatz dieses Netzelements ist ein Gateway zwischen einem IP-Netz und einem Public Switched Telephone Network (PSTN). Aus der Sicht von SIP agiert dieses Gateway als User Agent, welcher Sessions erzeugt und terminiert. Intern ist das Gateway aber für die Umsetzung der Signalisierungsund Mediadaten der beiden unterschiedlichen Netze verantwortlich.

2.3.1.3. Das SIP-Trapezoid

Das SIP-Trapezoid in Abbildung 2.5 beschreibt den Ablauf eines Verbindungsaufbaus in einer Infrastruktur, in der sich die beiden Teilnehmer in unterschiedlichen Domänen befinden. Die Bestandteile dieser Infrastruktur sind neben den beiden User Agents ein Inbound und ein Outbound Proxy Server sowie ein Domain Name Server (DNS) und ein Location Server.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5.: SIP-Trapezoid

Der Outbound Proxy Server im Domänenbereich des Anrufers hat die Aufgabe, eine SIP- Verbindung nach dem Erhalt eines INVITE-Requests vom UAC herzustellen. Zu diesem Zweck kontaktiert er einen DNS-Server, um eine Lokalisierung des Inbound Proxy Servers im fremden Domänenbereich vorzunehmen. Nach einem erfolgreichen Lokalisierungsvorgang leitet er den Request an den Inbound Proxy Server weiter.

Der für den Empfänger zuständige Inbound Proxy Server befindet sich auch in dessen Domänenbereich. Er empfängt den INVITE-Request und lokalisiert daraufhin den passiven Teilnehmer mit Hilfe des Location Service. Als abschließenden Schritt wird der Request an den UAS übermittelt. Der genaue Ablauf des SIP-Trapezoids wird nun anhand der Abbildung 2.5 erläutert, in der Alice versucht, eine Verbindung zu Bob’s Softphone herzustellen. Zur Verdeutlichung wird der Nachrichtenfluss auch in einem Sequenzdiagramm (Abbildung 2.6) dargestellt. Sämtliche Interaktionen mit den für die Lokalisierung erforderlichen DNS- und Location Server bleiben dort aber aus Übersichtsgründen unberücksichtigt. Neben dem Verbindungsaufbau ist in diesem Sequenzdiagramm die eigentliche VoIP-Kommunikation sowie der Verbindungsabbau eingetragen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6.: SIP Session Setup

Der UAC, in diesem Fall das Softphone von Alice, hat am Beginn keine Informationen bezüglich des Aufenthaltsortes vom UAS bzw. dem Inbound Proxy Server. Daher sendet der UAC einen INVITE-Request zum in der eigenen Domäne befindlichen Outbound Proxy Server mit folgendem Inhalt:

INVITE sip:bob@biloxi.com SIP/2.0 Contact: sip:alice@uac.atlanta.com

Die Adresse dieses Proxys ist Alice im Vorfeld bekannt und wird bei der Konfiguration des UAC dort eingetragen. Da sich die Zieladresse in einer anderen Domäne befindet, kontaktiert der Outbound Proxy Server einen DNS-Server, um den erforderlichen Inbound Proxy Server zu lokalisieren. Gleichzeitig sendet er einen First-Response (100 - Trying) an Alice, um sie über die Weiterleitung zu informieren. Der INVITE-Request wird nach der Namensauflösung um einen Record-Route-Eintrag mit folgendem Aussehen erweitert:

Record-Route: sip:outboundproxy.atlanta.com;lr> an den Inbound Proxy Server weitergereicht. Dieser überprüft, ob er für diese Domäne verantwortlich ist. Im Erfolgsfall sendet er eine Anfrage an das Location Service bezüglich der aktuellen IP-Adresse von Bob’s Softphone. Die ursprünglich im INVITE-Request enthaltene URI wird daraufhin durch eine SIP-URI mit Bob’s aktueller Adresse ersetzt. Ebenso wird ein weiterer Record-Route vor dem bereits bestehenden im INVITE-Request eingefügt:

Record-Route: sip:inboundproxy.biloxy.com;lr>

Der so modifizierte INVITE-Request wird abschließend an den UAS weitergeleitet. Ebenso erfolgt wieder eine Benachrichtigung in Bezug auf den momentanen Bearbeitungsstatus an das vorliegende Netzelement, dem Outbound Proxy Server, wieder in Form eines Response 100 (Trying).

Das Softphone von Bob antwortet nach dem Erhalt des INVITE-Requests mit einem Response 180 (Ringing). Dieser Response durchläuft alle Netzelemente bin hin zu Alice’ UAC. Die Lokalisierung des Clients stellt hier kein Problem dar, da sämtliche Netzelemente, die den Request weitergeleitet haben, ihre IP-Adresse in das VIA-Feld des SIP-Headers eingetragen haben. Wenn Bob die eingehende Verbindung annimmt, so sendet der UAS einen Response 200 (OK) an den UAC. Wie schon zuvor passiert auch dieser Response sämtliche Netzelemente. Der Body des Response 200 enthält auch eine SDP Media Description (siehe Kapitel 2.3.1.4), welche den Session-Typ enthält, den Bob mit Alice herstellen will.

Der Verbindungsaufbau endet mit einem von Alice initiierten ACK-Request an Bob, der den Erhalt des Response 200 bestätigt. Dieser Request erfolgt nun auf direktem Weg, da beide Parteien die IP-Adressen des jeweiligen Kommunikationspartners wissen.

Nach Beendigung des Gesprächs, das im Sequenzdiagramm in Abbildung 2.6 als Media Stream dargestellt ist, erfolgt der Verbindungsabbau, hier vom Teilnehmer Bob eingeleitet. Dieser besteht lediglich aus einem BYE-Request, der wieder direkt, ohne Umweg über die Proxy Server, an Alice gesendet wird, die diesen Request ihrerseits mit einem Response 200 bestätigt.

2.3.1.4. Das Session Description Protocol

Bevor Gesprächsdaten zwischen den Teilnehmern ausgetauscht werden können, ist es notwendig, dass zuvor die den Mediastream betreffenden Parameter ausverhandelt werden. Das textbasierte Session Description Protocol (SDP) [7] beschreibt, wie die Medienaushandlung zwischen den beteiligten Gesprächsteilnehmern zu erfolgen hat, um eine Kompatibilität der Endgeräte zu gewährleisten. Anzumerken ist, dass das SDP nicht explizit für den Einsatz mit SIP geschaffen wurde. Ebenso profitieren Streaming Videooder Multimedia-Konferenz-Protokolle von der Verwendung dieses Protokolls.

Die benötigten Parameter werden im Falle von SIP im Message Body eingetragen und nach der Übertragung entsprechend ausgewertet. Der Parameteraustausch findet hier im Sinne eines Offer/Answer-Modells statt: UA1 sendet jene Parameter, die er unterstützt, in einem INVITE- Request oder einem Response 200 an UA2. Dieser verifiziert die erhaltenen Parameter mit jenen, die ihm zur Verfügung stehen. Findet sich ein gemeinsamer Nenner, so werden vom UA2 die geeignetsten Parameter ausgewählt und als Antwort in Form eines Response 200 oder eines ACK- Requests an UA1 übermittelt. Erhält UA2 jedoch eine inkompatible Medienliste, die keine von ihm unterstützten Parameter enthält, so wird die Session mittels eines BYE-Requests abgebrochen.

Der RFC 4566 unterscheidet zwischen unbedingt erforderlichen sowie optionalen Parametern.

Unbedingt einzutragen sind folgende fünf Parameter:

Der Parameter v= dient lediglich zur Kennzeichnung der SDP-Version und wird im RFC 4566 mit dem Wert 0 definiert. Der Parameter o= enthält den Namen des Session-Erzeugers samt dessen IP-Adresse. Weitere Bestandteile sind der Netztyp (die Angabe „IN“ kennzeichnet hier das

Internet) sowie ein Adresstyp, z. B. IP4 oder IP6, eine Session-ID und eine Session-Version. Bei der Session-ID handelt es sich um einen global eindeutigen Bezeichner für diese Session. Mit dem Parameter s= wird der Session ein Name gegeben. Der gültige Zeitraum der Session wird mit dem Parameter t= festgelegt. Dieser enthält zwei Werte, die Startsowie die Stoppzeit. Will man den für VoIP-Zwecke sinnvoll erscheinenden Zeitraum auf unendlich setzen, so sind beide Zeitpunkte mit dem Wert 0 zu belegen. Auch der Parameter m= enthält mehrere Angaben. Zum einen wird hier der Mediatyp festgelegt, über den der Mediastream empfangen wird, sowie eine Angabe über das Nutzdatenprotokoll (z. B. RTP/AVP). Als letzter Bestandteil dieses Parameters wird noch eine Liste der verfügbaren Codecs angegeben.

2.3.1.5. SIP-Erweiterungen

Der RFC 3261 [6] beschreibt die Basisfunktionalitäten des SIP-Protokolls. Bei SIP handelt es sich aber um ein erweiterbares Protokoll, d. h. es können neue Funktionalitäten entwickelt und in SIP integriert werden. Mehrere RFCs befassen sich mit diesem Aspekt, vier davon werden im Folgenden kurz beschrieben.

RFC 3262 - Reliability of Provisional Responses in SIP

Im RFC 3261 ist kein Mechanismus vorgesehen, um den Erhalt von Response-Nachrichten der Klasse 1xx (Provisional) zu bestätigen. Das bedeutet, dass ein UAS keine Bestätigung darüber erhält, ob ein derartiger Response beim Kommunikationspartner angekommen ist. Obwohl dies in einer reinen Internet-Umgebung unproblematisch ist, kann dies aber bei Miteinbeziehung anderer Netze wie etwa PSTN ein Nachteil sein. Unter der Annahme, dass ein Anruf aus dem Internet einen Gesprächsteilnehmer in einem fremden Netz erreichen soll, der einen Mehrwertdienst anbietet, so muss hier der Anrufer über die Kosten des bevorstehenden Gesprächs informiert werden (in der Regel mittels eines Response 183 (Session Progress)). Eine Bestätigung über den Erhalt dieses Responses bietet dem Mehrwertdienstbetreiber einen Beweis darüber, dass diese Informationen dem Anrufer zugänglich gemacht wurden. Der RFC 3262 [8] behandelt diese Problematik durch die Zurverfügungstellung eines neuen Requests, dem Provisional Response Acknowledgement (PRACK).

RFC 3428 - Instant Messaging

Mittels SIP können auch Kurzmitteilungen versendet werden. Anstatt hierfür einen Session-Aufbau durchzuführen, sieht der RFC 3428 [9] vor, diese Kurzmitteilungen in den Body eines Message Requests einzufügen, der anschließend an den Empfänger übermittelt wird. Eine ähnliche Vorgehensweise ist auch in der GSM-Technologie anzutreffen. Dort erfolgt der Versand von Kurznachrichten (SMS) auch nicht über den Daten-, sondern über den Signalisierungskanal.

RFC 3265 - Event Notification

Mit der im RFC 3265 [10] beschriebenen Spezifikation wird ein Presence Service ermöglicht, der über den Online-Status anderer Teilnehmer informiert. Notwendig dafür sind zwei neue Requests, SUBSCRIBE und NOTIFY. Mittels SUBSCRIBE beantragt UA1 eine Berechtigung zum Bezug des aktuellen Status beim UA2. Ist dieser damit einverstanden, so sendet er bei jeder Änderung seines Online-Status einen entsprechenden NOTIFY-Request.

RFC 3903 - Event State Publication

Auf ähnliche Weise funktioniert auch das im RFC 3903 [11] erläuterte Event Publishing. Die dafür notwendige Architektur besteht aus einem oder mehreren Presence User Agents (PUA), welche einen Presence Server mittels PUBLISH-Requests mit neuen Informationen versorgen. Ein Teilnehmer kann durch eine Registrierung mit Hilfe eines SUBSCRIBE-Requests sein Interesse an diesem Service kundtun. Beim Einlangen neuer Nachrichten sendet der Presence Server diese mittels NOTIFY an die Abonnenten dieses Service.

2.3.2. Das Inter-Asterisk eXchange Protocol

Das Inter-Asterisk eXchange Protocol, von der Asterisk Open Source Community entwickelt und im RFC 5456 [12] beschrieben, liegt aktuell in der zweiten Version vor (IAX2). Der Fokus bei der Entwicklung dieses Protokolls lag bei VoIP, dennoch kann IAX2 auch zur Übertragung anderer Medien, z. B. Streaming Video, benutzt werden.

Der RFC 5456 betrachtet IAX2 als sogenanntes „All-in-One“-Protokoll, da es sowohl für die Signalisierung als auch für die Medienübertragung zuständig ist. Gegenüber SIP bietet dieses Protokoll einige Vorteile [13]:

Geringerer Overhead: IAX2 als Anwendungsprotokoll setzt bei der Mediadatenübertragung direkt auf UDP auf, anstatt den „Umweg“ über RTP zu gehen. Infolgedessen reduziert sich auch der Overhead.

NAT/Firewall-Tauglichkeit: IAX2 benötigt einen einzigen UDP-Port, der sowohl für die Signalisierung als auch für die Mediadaten verwendet wird. Der RFC 5456 sieht dabei für beide Seiten der Verbindung den Port 4569 vor.

Einfacheres Protokoll: Aufgrund der Tatsache, dass IAX2-Protokolle nicht in textueller, sondern in binärer Form vorliegen, entfällt ein entsprechendes Parsing. Die Anfälligkeit für Buffer Overflows wird so reduziert.

Gesprächstransfers: Gespräche können wahlweise direkt oder über einen Server geführt werden.

Trunking: Mittels Multiplexing können mehrere Gespräche über eine Verbindung übertragen werden, indem für alle Gespräche ein gemeinsamer Header verwendet wird.

Trotz dieser vielen Vorteile existieren auch bei diesem Protokoll Nachteile. So macht die Verwendung eines einzigen UDP-Ports IAX2 anfälliger für Denial of Service-Attacken (DoS). Ein weiterer Nachteil betrifft die geringere Auswahl der Endgeräte, unabhängig davon, ob es sich um Hardoder Softphones handelt.

2.4. Weitere VoIP-Protokolle

Neben den bisher behandelten Protokollen existieren noch eine Vielzahl weiterer Protokolle im Bereich der Sprachdatenkommunikation, die aber hier nicht weiter behandelt werden. Als Beispiel seien hier die zur Steuerung von VoIP-Gateways zuständigen Protokolle MGCP und Megaco oder proprietäre Protokolle wie das Skinny Client Control Protocol (SCCP) und Unistim von Nortel erwähnt.

3. Sicherheitsbezogene Protokolle und Mechanismen

Die aus technischer Perspektive betrachtete Umsetzung des geforderten Schutzbedarfs für eine VoIP-Infrastruktur kann durch die Verwendung unterschiedlicher Sicherheitsprotokolle bzw.

-mechanismen realisiert werden. Das charakteristische Merkmal einer VoIP-Kommunikation, die Verwendung unterschiedlicher Kommunikationspfade sowohl für die Signalisierung als auch für den Mediatransport, darf dabei bei der Auswahl der Protokolle nicht unberücksichtigt bleiben. Ebenso unterscheiden sich die Anforderungen in Bezug auf das Echtzeitverhalten zwischen einem Signalisierungsund einem Mediakanal. Sicherheitsmechanismen, die einen deutlich höheren Paket-Overhead, eine Vielzahl zusätzlich auszutauschender Nachrichten oder die Berechnung „teurer“ komplexer Operationen verlangen, stellen einen zusätzlichen Zeitaufwand dar, der im Zuge der Signalisierung i. d. R. vernachlässigbar ist, aber bei der Übertragung von Sprachdaten durch den dabei entstehenden Delay und Jitter für den Benutzer untragbar ist.

Bei der ersten Protokollarchitektur, die in diesem Abschnitt in Kapitel 3.1 vorgestellt wird, handelt es sich um das Internet Protocol Security Protocol (IPsec), welches die Sicherheitsdienste auf der Netzwerkschicht anbietet. Mittels IPsec kann sowohl der Signalisierungsals auch der Mediapfad abgesichert werden. Dies ist beim Transport Layer Security Protocol (TLS) (Kapitel 3.2) nicht der Fall, da TLS auf einem verbindungsorientierten Protokoll wie TCP oder SCTP aufsetzt. Eine Sprachdatenübertragung verlangt jedoch nach einem verbindungslosen Protokoll, d. h. TLS kann lediglich zur Absicherung der Signalisierung verwendet werden.

Einen Mechanismus zur Authentifikation eines SIP-Teilnehmers stellt das in Kapitel 3.3 beschriebene SIP Digest Authentication Verfahren dar, welches an HTTP Digest angelehnt ist.

Das darauffolgende Kapitel 3.4 beschäftigt sich mit dem SIPS URI Schema, bei dessen Anwendung sichergestellt wird, dass eine Übermittlung der SIP-Nachricht vom Absender bis hin zum letzten Netzelement vor dem Empfänger mittels TLS erfolgt.

Kapitel 3.5 befasst sich schlussendlich mit der Thematik zur Absicherung des Mediatransports mit Hilfe des Secure Real-time Transport Protocols (SRTP). Grundvoraussetzung für die Absicherung der Mediadaten durch SRTP ist jedoch, dass die beteiligten Kommunikationspartner im Besitz eines gemeinsamen Geheimnisses sind. Damit beide Seiten an dieses gelangen, ohne dieses Geheimnis über einen unsicheren Kanal transportieren zu müssen, bedarf es eines Schlüsselausverhandlungsprotokolls. Zwei hierfür geschaffene, jedoch unterschiedliche Ansätze sind ebenfalls Teil dieses Kapitels.

3.1. Internet Protocol Security Protocol (IPsec)

Bei IPsec handelt es sich um einen IETF Sicherheitsstandard, der eine Architektur für die beiden Internetprotokolle IPv4 und IPv6 beschreibt. Diese Architektur besteht aus mehreren Protokollen, die zusammen eine sichere Kommunikation auf der Netzwerkschicht ermöglichen. Bei IPsec handelt es sich um eine flexible Architektur, bei der es dem Anwender überlassen bleibt, welche Sicherheitsdienste und welche Authentifizierungsbzw. Verschlüsselungsmechanismen er in Anspruch will. Nichtsdestotrotz sind einige Algorithmen in einem IPsec-System vorgeschrieben, um die Interoperabilität unterschiedlicher Protokollimplementierungen aufrechtzuerhalten. Die Implementierung von IPsec kann sowohl in einem Endsystem als auch in einem Gateway erfolgen, konsequenterweise lässt sich also mit IPsec auch ein Virtual Private Network (VPN) errichten, bei dem die zu verbindenden Netzwerke durch ein unsicheres Netzwerk wie dem Internet voneinander getrennt sind.

3.1.1. Implementierung der Sicherheitsdienste und Betriebsarten von IPsec

IPsec verwendet zur Sicherstellung der erforderlichen Schutzziele zwei Protokolle. Zum einen handelt es sich um das im RFC 4302 [14] beschriebene Authentication Header Protocol (AH), welches eine Realisierung der Sicherheitsdienste „Authentifikation des Datenursprungs“ und „Datenintegrität verbindungsloser Kommunikation“ ermöglicht. Optional kann auch ein Schutz gegen Wiedereinspielungen von Paketen gewährleistet werden. Zum anderen handelt es sich um das Encapsulating Security Payload Protocol (ESP), spezifiziert im RFC 4303 [15]. Es bietet neben jenen vom AH-Protokoll bereitgestellten Sicherheitsdiensten auch die Möglichkeit einer vertraulichen verbindungslosen Kommunikation.

Die Übertragung der mittels IPsec geschützten Pakete kann auf zwei unterschiedliche Arten erfolgen, dem Transportund dem Tunnelmodus. In beiden Betriebsarten können sowohl das AH- Protokoll, das ESP-Protokoll oder gar beide zum Einsatz kommen.

Im T ransp ortmo dus werden die Sicherheitsdienste lediglich auf die Nutzdaten angewandt. Diese heutzutage eher bedeutungslose Betriebsart kann für eine direkte Peer-zu-Peer-Kommunikation gewählt werden [16]. Von Bedeutung hingegen ist der T unnelmodus , bei dem neben den Nutzdaten auch die Verkehrsdaten geschützt werden. Unter Verwendung des ESP-Protokolls ist in diesem Modus auch die Errichtung eines auf dem OSI-Layer 3 agierenden VPNs möglich. Abbildung 3.1 verdeutlicht abschließend den Unterschied zwischen den beiden Betriebsarten bei der Verwendung des ESP-Protokolls.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1.: ESP im Transportund Tunnelmodus

3.1.2. Umsetzung einer Sicherheitsstrategie bei IPsec

Eine Sicherheitsstrategie bzw. Securit y P olicy (SP) definiert, welche Sicherheitsdienste in welcher Art auf eine konkrete Verbindung angewendet werden sollen und kann somit als Grundlage eines IPsec-Systems betrachtet werden. Sämtliche Strategiespezifikationen werden, getrennt nach einund ausgehenden Verbindungen, in der Strategiedatenbank (Security P olicy Database , SPD) verwaltet. Die dort enthaltenen Einträge legen für jedes einlangende und ausgehende IP-Paket fest, ob es verworfen, unbearbeitet weitergeleitet oder einer IPsec-Behandlung unterzogen wird. Im letztgenannten Fall definiert die SPD das Protokoll und den Modus.

Eine Sicherheitsassoziation bzw. Securit y Association (SA) dient der Realisierung einer Sicherheitsstrategie im konkreten Anlassfall und enthält u. a. folgende Informationen:

- IP-Adresse bzw. -Adressbereich des Empfänger(kreises), auf den sich die SA-Vereinbarungen beziehen
- Lebensdauer der SA (Zeitund/oder Byte-basiert)
- Algorithmen, Schlüssel, Modi für AH oder ESP
- bei ESP mit Verschlüsselung und entsprechendem Blockchiffren-Betriebsmodus (z. B. CBC): Initialisierungsvektor

Zu beachten ist, dass eine SA nur für eine Übertragungsrichtung gültig ist. Soll eine bidirektionale Verbindung abgesichert werden, so sind entsprechende Ableitungen aus der SDP für beide Richtungen explizit vorzunehmen. Ebenso muss – bei gleichzeitiger Verwendung des AH- und ESP- Protokolls – für jedes Protokoll eine eigene SA abgeleitet werden. Die einzelnen SAs werden in einer Datenbank, der Securit y Association Database (SAD) gespeichert, wobei hier eine Trennung zwischen einund ausgehenden Verbindungen vorgenommen wird. Der Securit y Parameter Index (SPI), der Teil des AH- bzw. ESP-Headers ist, kommt nun zum Tragen, wenn der Empfänger ein solches Paket erhält. Der SPI wird aus diesem Paket extrahiert, anschließend wird in der SAD anhand dieses Zeigers nach der für diese Verbindung gültigen SA gesucht. Existiert dieser Eintrag, so kann er mit den dort gespeicherten Informationen bezüglich der Verfahren und aktuellen Schlüssel das Paket entschlüsseln und/oder authentifizieren. Wird jedoch kein Eintrag in der SAD gefunden, so muss aus der SDP eine SA abgeleitet werden. Dies kann auf manuelle Weise oder mittels Delegation an ein Schlüsselaustauschprotokoll, z. B. das Internet Key Exchange Protocol (IKE), erfolgen.

3.1.3. Kritikpunkte

Trotz der vielen Vorteile, die IPsec mit sich bringt, erkennen Bruce Schneier und Niels Ferguson im Zuge einer Evaluierung dieser Architektur auch einige Missstände [17]. Im Mittelpunkt der Kritik steht dabei die Komplexität des Systems, dessen Design viele unterschiedliche Kommunikationssituationen anhand einer Vielzahl von Optionen zu befriedigen versucht. Ein solches hochkomplexes System kann mit vorhandenen Methoden nur schwer analysiert und korrekt implementiert werden. Das Paper stellt weiters die Existenzberechtigung des AH-Protokolls und des Transportmodus in Frage. Der Transportmodus, der gegenüber dem Tunnelmodus keine funktionalen Vorteile mit sich bringt, hat zwar einen geringeren Paket-Overhead, dieser Nachteil kann jedoch durch die Anwendung eines Kompressionsalgorithmus beim Tunnelmodus wieder wettgemacht werden. Beim Einsatz des Tunnelmodus bietet das ESP-Protokoll keine schwächere Authentifizierung als das AH-Protokoll, da auch hier der ursprüngliche IP-Header sowie die Nutzdaten authentifiziert werden. Beim Wegfall des AH-Protokolls müsste jedoch auch eine Anpassung des ESP-Protokolls erfolgen, bei dem die Verschlüsselung und Authentifikation optionale Bestandteile sind. Da eine

Verschlüsselung ohne zusätzliche Authentifikationsmechanismen sicherheitskritisch ist, wird hier empfohlen, die Authentifikation in das ESP-Protokoll zu integrieren und nur die Verschlüsselung optional verfügbar zu machen. Werden beide Dienste in Anspruch genommen, so erfolgt beim ESP- Protokoll die Authentifizierung nach der Verschlüsselung. Dies widerspricht dem Horton-Prinzip – authenticate what was meant, not what was said – bei dem die Authentifikation für den Klartext erfolgen sollte [18]. Als letzter Kritikpunkt aus dieser Evaluierung sei noch die Konfiguration der SAs aufgeführt, die auf unidirektionale Weise erfolgt. Einerseits erfolgt in den meisten Fällen eine bidirektionale Kommunikation zwischen den beteiligten Rechnern, andererseits ist auch eine asymmetrische Konfiguration mit unterschiedlichen Algorithmen nicht sicherheitsfördernd, sodass durch eine Bündelung der beiden unidirektionalen zu einer einzigen bidirektionalen SA die Konfiguration einfacher realisierbar wäre.

3.2. Transport Layer Security (TLS)

Das Transport Layer Security Protokoll (TLS), dessen aktuelle Version 1.2 im RFC 5246 [19] beschrieben ist, ist eine Weiterentwicklung der Secure Socket Layer-Spezifikation (SSL). Die grundlegende Funktionsweise ist bei beiden Protokollen zwar gleich, dennoch sind die Unterschiede signifi- kant genug, um eine Interoperabilität zwischen diesen Protokollen zu verhindern. Aus diesem Grund beinhaltet jede TLS-Version einen Mechanismus, um im Bedarfsfall auf eine SSL-Implementierung ausweichen zu können.

Das TLS-Protokoll hat zum vorrangigen Ziel, eine vertrauliche, verbindungsorientierte Endezu-Ende-Kommunikation mit gleichzeitiger Gewährleistung der Nachrichtenintegrität herzustellen, ebenso ist eine Authentifikation beider Kommunikationspartner möglich. Realisiert wird dieses Vorhaben mittels kryptografischer Maßnahmen wie der Verwendung asymmetrischer Verschlüsselungsverfahren und X.509-Zertifikaten, symmetrischer Sitzungsschlüssel sowie der Anwendung des HMAC-Verfahrens. Weitere Ziele von TLS betreffen die Interoperabilität der Applikationen, welche diesen Standard benutzen, eine Erweiterbarkeit in Bezug auf den Austausch bzw. die Integration neuer kryptografischer Verfahren dank eines modularen Designs sowie eine effziente Vorgehensweise bezüglich eines Verbindungsaufbaus. Der letztgenannte Punkt wird bei TLS durch ein Sitzungsund Verbindungskonzept gelöst, bei dem zwar eine Sitzung mittels teurer, asymmetrischer Operationen etabliert werden muss, eine oder mehrere konkrete Verbindungen einer bestehenden Sitzung können jedoch mit relativ wenig Aufwand instanziiert werden.

Das TLS-Protokoll ist zwischen einem verbindungsorientierten Transportprotokoll (z. B. TCP) und einem Protokoll der Anwendungsschicht angesiedelt. TLS ist somit ein anwendungsorientiertes Protokoll, welches als Grundlage für die Implementierung vonseiten eines Anwendungsprotokolls verwendet werden muss. Eine Anwendung, wie etwa SIP, greift dabei auf die von TLS zur Verfügung gestellten Dienste über reservierte Portadressen zu.

Das TLS-Protokoll besteht aus zwei Schichten, deren Einordnung in Abbildung 3.2 ersichtlich ist. Zum einen handelt es sich um den an der Anwendungsschicht angrenzenden TLS Handshake Layer (Kapitel 3.2.1), der aus mehreren Subprotokollen besteht und für die Etablierung einer Sitzung verantwortlich ist. Darunter befindet sich der Reco rd La y e r (Kapitel 3.2.2), der für die Kapselung der Protokolle einer höheren Ebene zuständig ist.

3.2.1. TLS Handshake Protocol

Mit Hilfe des zustandsbehafteten TLS-Protokolls werden Sitzungen zwischen den Kommunikationspartnern etabliert, wobei auch mehrere Sitzungen zwischen einem Client zu einem oder meh-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2.: Einordnung des TLS-Protokolls [16] Servern erlaubt sind. Die wesentliche Aufgabe des TLS Handshake Layers besteht darin, die notwendigen Informationen zur Berechnung des Sitzungsund MAC-Schlüssels auf Clientund Serverseite zwischen den Kommunikationspartnern auszutauschen und konsistent zu halten. Der Austausch der Sitzungsinformationen mittels des TLS Handshake Protokolls erfolgt auf solche Weise, dass die Sicherheitsdienste Authentizität des Servers (optional auch die des Clients), Vertraulichkeit und Nachrichtenintegrität gewährleistet werden. Weitere Subprotokolle des TLS Handshake Layers sind – neben dem für den Sitzungsaufbau dienlichen TLS Handshake Protokoll – folgende drei Protokolle:

- Change Cipher Spec Protocol : Dieses Protokoll umfasst lediglich eine Nachricht in der Länge von einem Byte mit dem Wert 1. Ab dem Zeitpunkt, an dem eine solche Nachricht gesendet wird, erfolgt die weitere Kommunikation mit den soeben ausgehandelten Parametern.

- Alert Protocol : Dieses Protokoll ist zuständig für den Versand von Warnungen an den Kommunikationspartner. Neben der Beschreibung des Alarms (z. B. ein abgelaufenes Zertifikat oder ein inkorrekt empfangener MAC-Wert) wird in einer Alert-Nachricht auch mit angegeben, wie schwer der entsprechende Alarm wiegt. Möglich sind hierbei die beiden Werte 1 (w a rning) oder 2 (fatal). Beim Eintritt des zweiten Falls wird ein sofortiger Abbruch der Verbindung erzwungen, ebenso werden keine neuen Verbindungen für diese Sitzung eröffnet.

- Application Data Protocol : Zweck dieses Protokolls ist die transparente Weiterleitung der Anwendungsdaten an den darunterliegenden Record Layer.

Das TLS Handshake Protokoll ist verantwortlich für die Authentifizierung der Kommunikationspartner und für die Etablierung eines gleichlautenden Master Secrets auf beiden Seiten. Das Master Secret, aus dem im späteren Verlauf die Sitzungsund MAC-Schlüssel an den Kommunikationsendpunkten abgeleitet werden, wird dabei nicht direkt über das Netzwerk übertragen. Stattdessen wird es an den Endpunkten durch die Anwendung eines Hashverfahrens auf Clientund Server- Zufallszahlen sowie dem im Zuge des TLS Handshake Protokollablaufs ausverhandelten Pre-Master Secret gebildet.

Nach erfolgreichem Ablauf des Protokolls ist schlussendlich eine Sitzung etabliert, aus der konkrete Verbindungen instanziiert werden können.

3.2.2. TLS Record Protocol

Aufgabe des TLS Record Protokolls ist die Übernahme der Datenpakete eines höher angesiedelten Protokolls (entweder das TLS Handshake Protokoll bzw. eines seiner Subprotokolle oder von einem beliebigen Anwendungsprotokoll, welches vom Application Data Protokoll durchgereicht wird), diese in Fragmente mit einer Maximalgröße von 214 Bytes zu zerlegen, eine optionale Kompression dieser Fragmente durchzuführen sowie eine als Integritätsmaßnahme erforderliche Berechnung des MAC-Werts dieses Fragments zu veranlassen, der diesem hintangefügt wird. Im abschließenden Schritt erfolgt eine Verschlüsselung des gesamten Fragments inklusive dem MAC-Wert und ein Hinzufügen eines TLS Record Headers am Beginn des chiffrierten Fragments. Das auf diese Weise generierte Paket wird dann der darunterliegenden Transportschicht zur sicheren Übermittlung weitergereicht.

Der MAC-Schlüssel für den Client bzw. den Server sowie die beiden symmetrischen Schlüssel werden für jede konkrete Verbindung aus dem zuvor vereinbarten Master Secret abgeleitet. Sowohl für die symmetrische Verschlüsselung als auch für die Berechnung des Hashwertes sind unterschiedliche Verfahren zulässig, jedoch sind hier versionsbedingte Unterschiede feststellbar. So sind bei TLS v1.0 die Blockchiffren DES (40 und 56 Bit), 3DES (168 Bit), IDEA (128 Bit) und RC2 (40 Bit), die Stromchiffre RC4 (40 oder 128 Bit) sowie die beiden Hashverfahren MD5 und SHA-1 erlaubt. In der Version 1.2 kommt hingegen nur die Stromchiffre RC4 mit 128 Bit und die Blockchiffren 3DES (168 Bit) und AES (128 und 256 Bit) zum Zuge. Sämtliche in der Ursprungsversion erlaubten Hashverfahren sind auch in der aktuellen Version zulässig, zusätzlich kann hier auch auch das Verfahren SHA-256 angewendet werden.

3.2.3. Kritikpunkte

Obwohl das TLS-Protokoll sehr ausgereift zu sein scheint, haben sich im Laufe der Zeit dennoch einige wenige Kritikpunkte herauskristallisiert. Auf der einen Seite soll hier aufgezeigt werden, dass anhand einer Schwäche im Design des TLS-Protokolls Angriffe möglich werden. Konkret handelt es sich um die erst im Jahr 2009 entdeckte TLS Renegotiation Vulnerability [20]. Diese Schwachstelle tritt dann in Erscheinung, wenn eine Neuausverhandlung, d. h. ein nochmaliges Durchlaufen des TLS Handshake-Protokolls, der Sicherheitsparameter zwischen dem Client und dem Server erfolgt. Da es einerseits zwischen diesem und dem ursprünglichen TLS-Handshake keinen kryptografischen Bezug gibt und andererseits der Server keine Unterscheidung zwischen dem ursprünglichen und dem erneuten Connection-Request treffen kann, wird es einem Man-in-the-Middle (MitM) ermöglicht, seine Daten in eine bestehende Sitzung zwischen dem Server und dem Client einzuschleusen.

Ein anderer Kritikpunkt betrifft die Ermöglichung der Verwendung unsicherer Cipher-Suiten bzw. zu geringer Schlüssellänge. Hervorzuheben sind hier u. a. die Anonymous Diffe-Hellmanund die NULL-Cipher-Suiten, welche keine Authentisierung bzw. keine Verschlüsselung vornehmen. Aber auch schwache kryptografische Algorithmen (DES) oder MAC-Verfahren (MD5) sind zwischenzeitlich in relativ kurzer Zeit zu brechen. Dieser Missstand ist zwar in der aktuellen Version 1.2 großteils behoben, dennoch existieren noch genügend Anwendungen, die TLS mit einer niedrigeren Protokollversion verwenden.

3.3. SIP Digest Authentication

SIP unterstützt einen zustandslosen, auf dem Challenge/Response-Prinzip basierenden Mechanismus, um einen SIP-Teilnehmer die Authentifizierung bei einem SIP-Netzelement zu ermöglichen

[6]. Neben der zusätzlichen Möglichkeit, dass auch ein UA eine Authentifizierung vonseiten eines mit ihm kommunizierenden Netzelements anfordern kann, bietet dieser Mechanismus auch einen Schutz gegen Wiedereinspielungsangriffe. Die Funktionsweise von SIP Digest ist dabei nahezu ident mit der im RFC 2617 [21] beschriebenen HTTP Digest Authentication. Eine Authentifizierung mittels SIP Digest ist nur zwischen zwei UAs bzw. zwischen einem UA und einem SIP Proxy, Redirect oder Registrar Server erlaubt. Eine Authentifikation zwischen zwei Proxy Servern darf nicht mit Hilfe dieses Mechanismus stattfinden, sodass für diesen Fall andere Maßnahmen (z. B. IPsec oder TLS) ergriffen werden müssen.

Die Funktionsweise von SIP Digest, welche sich auf ein gemeinsames Geheimnis beider Parteien stützt und somit eine Vertrauensbeziehung voraussetzt, wird im Nachfolgenden anhand eines vom UA initiierten Registrierungsvorgangs beschrieben (siehe auch Abbildung 3.3).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3.: Registrierung mit SIP Digest

Im ersten Schritt sendet Bob’s UA einen REGISTER-Request an den für ihn zuständigen Registrar Server in der Domäne biloxi.com. Ein Auszug des SIP-Headers hat dabei etwa folgendes Aussehen:

REGISTER sip:registrar.biloxi.com SIP/2.0

Via: SIP/2.0/UDP bob@biloxi.com:5060;branch=k8UcP94m3SEb0W From: Bob sip:bob@biloxi.com>;tag=b83ifklep

To: Bob sip:bob@biloxi.com> Contact: sip:bob@biloxi.com>

Der Registrar Server erhält diese Anfrage, lehnt diese jedoch mit einem Response 401 (Unauthorized) ab1. In diesem Response befindet sich auch das Header-Feld WWW-Authenticate, u. a. mit folgenden Informationen:

- realm: der Gültigkeitsbereich dieser Authentifizierung
- nonce: eine einmalig gültige Zufallszahl
- algorithm: der verwendete Hashalgorithmus

Abbildung in dieser Leseprobe nicht enthalten

1Ein unautorisierter Request vonseiten des UAC wird laut RFC 3261 [6] von einem UAS, einem Registrar und einem Redirect Server mit einem Response 401 (Unauthorized) beantwortet, ein Proxy Server darf jedoch eine Authentifizierung nur mit einem Response 407 (Proxy Authentication Required) anfordern.

- qop: beschreibt die „Quality of Protection“ des Servers, auth kennzeichnet dabei eine einfache Authentifizierung.

Die wesentlichsten Header-Felder des Response haben folgenden Inhalt:

SIP/2.0 401 Unauthorized

Via: SIP/2.0/UDP bob@biloxi.com:5060;branch=k8UcP94m3SEb0W;received=192.0.2.9 From: Bob sip:bob@biloxi.com>;tag=b83ifklep

To: Bob sip:bob@biloxi.com>;tag=1843794607

WWW-Authenticate: Digest realm="biloxi.com", qop="auth", nonce="6e3c2873436b353958572f5e7766673d", opaque="", stale=FALSE, algorithm=MD5

Bob’s UA, der diesen als Challenge dienenden Response erhält, berechnet den Hashwert im vorgegebenen Algorithmus (hier MD5) über unterschiedliche Komponenten, darunter seinem Benutzernamen, sein Passwort und dem vom Registrar Server übergebenen Nonce-Wert. Anschließend setzt der UA seinen Register-Request nochmals ab, dessen SIP-Header um den Eintrag Authorization erweitert wurde. Dieser neu hinzugekommene Eintrag enthält u. a. folgende Felder:

[...]