IP-Telefonie, Streaming (Peter Knapp)

IP - Telefonie / Streaming
Sicherheit in Applikationsprotokollen
Wintersemester 2011/12
Peter Knapp
MatrNr: 0615297
29. November 2011
Inhaltsverzeichnis
1 Session Initiation Protokoll
1.1 Einleitung . . . . . . . . . . . . . . . . . . . .
1.2 SIP Entities . . . . . . . . . . . . . . . . . . .
1.3 SIP Nachrichten . . . . . . . . . . . . . . . .
1.3.1 Requests . . . . . . . . . . . . . . . . .
1.3.2 Responses . . . . . . . . . . . . . . . .
1.3.3 Header / Body . . . . . . . . . . . . .
1.4 Kommunikationsbeispiele . . . . . . . . . . .
1.4.1 Registrierung . . . . . . . . . . . . . .
1.4.2 Sitzung aufbauen und beenden . . . .
1.4.3 Sitzung über einen Proxy . . . . . . .
1.5 Sicherheitsaspekte in SIP . . . . . . . . . . .
1.5.1 Gefahren und Risiken . . . . . . . . .
1.5.2 HTTP Authentifizierung . . . . . . . .
1.5.3 S/MIME . . . . . . . . . . . . . . . .
1.5.4 Sicherheit im Transport und Netzwerk
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
Layer
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
. 2
. 3
. 3
. 3
. 4
. 5
. 6
. 6
. 6
. 6
. 6
. 6
. 7
. 9
. 10
2 H.323
2.1 Information Streams . . . . . . .
2.2 Protokolle und Codecs . . . . . .
2.3 Netzwerk Komponenten . . . . .
2.3.1 Terminals . . . . . . . . .
2.3.2 Multipoint Control Units
2.3.3 Gateways . . . . . . . . .
2.3.4 Gatekeepers . . . . . . . .
2.3.5 Beispiel Kommunikation .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
11
11
11
12
12
12
13
3 Inter–Asterisk eXchange
3.1 Peer Verhalten und Nachrichten . . . .
3.1.1 Registration . . . . . . . . . . .
3.1.2 Call Link Managment . . . . .
3.1.3 Call Control . . . . . . . . . . .
3.1.4 Call Path Optimization . . . .
3.1.5 Mid–Call Behavior . . . . . . .
3.1.6 Call Tear Down . . . . . . . . .
3.1.7 Network Monitoring . . . . . .
3.1.8 Digit Dialing . . . . . . . . . .
3.1.9 Miscellaneous . . . . . . . . . .
3.1.10 Media Messages . . . . . . . .
3.2 Struktur der Frames . . . . . . . . . .
3.2.1 Full Frames . . . . . . . . . . .
3.2.2 Mini Frames . . . . . . . . . .
3.2.3 Meta Frames . . . . . . . . . .
3.3 Verschlüsselung und Authentifizierung
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
14
14
14
14
15
15
15
16
16
16
16
16
16
17
17
17
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
4 Real–Time Transport Protokoll & RTP Control
4.1 RTP . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 RTCP . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 RTCP Paket Format . . . . . . . . . . . .
4.3 Sicherheit . . . . . . . . . . . . . . . . . . . . . .
Protokoll
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
5 Secure Real–Time Transport Protokoll
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
19
19
20
20
21
Session Initiation Protokoll
1.1
Einleitung
Das Session Initiation Protokoll (SIP)[10] ist ein Applikationsprotokoll, welches dazu dient
Sitzungen (sessions) zwischen einen oder mehreren Teilnehmern aufzubauen. Weiters können diese verändert, sowie auch beendet werden. Mit Hilfe von SIP können sich die Teilnehmer auf Eigenschaften einer Sitzung einigen. Eine Sitzung ist in diesem Kontext der
Austausch von Daten zwischen einer Gruppe von Teilnehmern. Mögliche Szenarien sind
zum Beispiel Internet-Telefonanrufe, Multimedia Verbreitung und auch Multimedia Konferenzen.
Das Protokoll selbst wird dabei nicht zur Datenübertragung verwendet. Diese wird
von anderen Protokollen übernommen, welche Real–Time Multimedia-Daten übertragen
können. Das Session Initiation Protokoll bietet diesen Anwendungen die Endpunkte der
Verbindung (genannt user agents). Um diese und weitere Funktionen gewährleisten zu
können, wird eine Netzwerk Infrastruktur (proxy server) aufgebaut , welche dazu verwendet wird um user agents zu registrieren, Einladungen zu Sitzungen und andere Anfragen
zu bearbeiten.
SIP bietet dabei fünf Aspekte des Auf- und Abbaus von Multimedia-Sitzungen:
• User Location: Das Finden des Endpunktes der Kommunikation.
• User Availability: Bestimmung ob der Teilnehmer gewillt ist an der Sitzung teilzunehmen.
• User Capabilities: Einigung auf Medien und Multimediaparameter welche in der
Sitzung verwendet werden sollen.
• Session Setup: Benachrichtigung des angerufenen Teilnehmers über den Anruf, sowie
das Festlegen der Sitzungsparameter.
• Session Managment: Transfer und Beendigung von Sitzungen, die Veränderung der
Sitzungsparameter und der Aufruf von weiteren Services.
Zu beachten ist allerdings, dass SIP kein Kommunikationssystem ist, sondern ein Teil einer
Multimediakommunikation, welche auch andere Protokolle, wie zum Beispiel RTP, beinhaltet. Auch anzumerken ist, dass SIP selbst keine zusätzliche Services bietet, allerdings
werden Primitive angeboten, über die man einen Service implementieren kann. Als Beispiel kann man mit SIP ein Objekt übermitteln, welches dann verwendet werden kann um
einerseits Sitzungsparameter anderer Protokolle, oder auch Bilder beziehungsweise andere
Medien zu übertragen.
Ein weiterer wichtiger Punkt ist, dass das Session Initiation Protokoll eine Reihe an
Sicherheitsfunktionen bietet. Diese sind eine DoS–Prevention, Authentifizierung zwischen
den Teilnehmern und auch zwischen Teilnehmern und Proxy Servern, sowie der Schutz
von Integrität und Verschlüsselung.
2
1.2
SIP Entities
Im Session Initiation Protokoll gibt es 4 logische Entitäten, wobei eine physische Ressource
durchaus in mehreren Rollen tätig sein kann.
User Agent: Der User Agent ist ein Endpunkt der Verbindung. Diese starten und beenden die Sitzungen indem sie Requests (1.3.1) und Responses (1.3.2) austauschen.
Dabei enthält der User Agent zwei Teile. Einerseits den User Agent Client (UAC)
welcher SIP Requests startet und andererseits der User Agent Server welcher den
Nutzer über eintreffende Requests informiert und im Auftrag des Nutzers Responses
versendet.
Proxy Server: Ein Proxy Server ist eine Entität welche als Client, wie auch als Server
im Auftrag anderer Clients handelt um Requests zu versenden. Der Request kann
entweder intern bearbeitet werden oder dieser wird weitergegeben (auch an andere
Server).
Redirect Server: Dieser akzeptiert Requests und bildet die SIP Adresse des gerufenen
Teilnehmer auf null ab wenn es keine bekannte Adresse zu diesem gibt oder gibt die
neuen Adressen des Teilnehmers zurück. Der Redirect Server leitet allerdings keine
Requests an andere Server weiter.
Registrar: Dies ist ein Server, der REGISTER Requests akzeptiert um dessen Kontakt
Informationen zu speichern.
1.3
SIP Nachrichten
Es wird der UTF-8 Zeichensatz in SIP verwendet, da es ein textbasiertes Protokoll ist.
Es gibt zwei Arten von Nachrichten. Die erste ist der Request, welcher von einem Client
zum Server gesendet wird und die zweite Art der Response vom Server zum Client. Der
Aufbau beider Nachrichten ist an sich gleich und unterscheidet sich nur in der Statuszeile,
wie der folgende Auszug aus [10] zeigt:
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line
= Request-Line / Status-Line
1.3.1
Requests
Ein SIP–Request beginnt immer mit einer Request–Line, welche den Methoden Namen, die
Request–URI, sowie die Protokoll–Version beinhaltet und diese sind durch ein Leerzeichen
getrennt. Es gibt sechs verfügbare Methoden:
1. REGISTER: Registriert einen Teilnehmer am Proxy mit seinen Kontakt Informationen
2. INVITE: Baut eine Sitzung auf
3. ACK: Akzeptiert eine Sitzung
4. CANCEL: Bricht einen Sitzungsaufbau ab
3
5. BYE: Beendet eine Sitzung
6. OPTIONS: Erfragen der Funktionen des Servers
Die Request–URI ist eine SIP oder SIPS URI (Uniform Resource Indicator), welche den
Teilnehmer oder Service beschreibt, der von dem Request angefordert wird. In einer URI
sind ausreichend Informationen enthalten um eine Sitzung mit der Ressource aufbauen
und aufrechterhalten zu können. Beispiele für eine Ressource sind ein User eines Online
Services, eine Mailbox eines Nachrichtensystems, oder auch eine Abteilung einer Organisation.
Der Unterschied zwischen einer SIP und einer SIPS URI besteht darin, dass bei Angabe einer SIPS URI eine sichere Verbindung über TLS zwischen dem user agent client
(UAC) und der Domain der URI verwendet werden muss. Innerhalb der Domain bestimmt
die Sicherheitspolitik der Domain, welche Sicherheitsmaßnahmen verwendet werden. Außerdem kann jede Ressource, die mit einer SIP URI, beschrieben ist aufgewertet werden
zu einer SIPS URI, wenn sicher kommuniziert werden soll.
sip:user:password@host:port;uri-parameters?headers
Die obige Zeile ist der Aufbau einer SIP, bzw. SIPS URI, wobei bei der SIPS Version
das "sip:" durch "sips:" ersetzt wird. Die einzelnen Teile dieser URI sind einerseits die User
Information, welche "user" und "password" beinhaltet. Es ist allerdings aus sicherheitstechnischen Gründen nicht empfehlenswert "password" zu verwenden, da in diesem Fall das
Passwort im Klartext übertragen wird. Insofern das "@" Zeichen vorhanden ist, muss der
"user" angegeben werden, ansonsten kann auch ein Host alleine angegeben werden (wenn
dieser zB. keine User verwaltet oder selbst die Ressource ist). Der "host" enthält entweder
einen Fully Qualified Domain Name oder eine IPv4/IPv6-Adresse.
Die "uri–parameters" können beliebig viele sein, dürfen sich allerdings nicht wiederholen
und sind von der Form parameter–name = parameter–Wert. Hier kann man beispielsweise
das Transportprotokoll angeben (TCP/UDP/SCTP). Mit den "?headers" kann man noch
Header Felder in der URI angeben. Diese müssen von der Form hname = hvalue sein.
1.3.2
Responses
Im Fall einer Response beginnt die Nachricht mit einer Status-Line, welche wie folgt aufgebaut ist:
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
Es gibt die folgenden Status–Codes aus [10]:
1xx: Provisional -- request received, continuing to process the request;
2xx: Success -- the action was successfully received, understood,
and accepted;
3xx: Redirection -- further action needs to be taken in order
to complete the request;
4xx: Client Error -- the request contains bad syntax or cannot
be fulfilled at this server;
5xx: Server Error -- the server failed to fulfill an apparently
valid request;
6xx: Global Failure -- the request cannot be fulfilled at any server.
Beispiele für Status–Codes sind in Tabelle 1 gegeben.
4
Status–Code
100
180
181
182
183
200
300
301
302
305
380
400
401
402
403
404
405
406
407
408
410
413
414
415
416
Beschreibender Text
Trying
Ringing
Call Is Being Forwarded
Queued
Session Progress
OK
Multiple Choices
Moved Permanently
Moved Temporarily
Use Proxy
Alternative Service
Bad Request
Unauthorized
Payment Required
Forbidden
Not Found
Method not allowed
Not Acceptable
Proxy Authentication Required
Request Timeout
Gone
Request Entity Too Large
Request URI Too Long
Unsupported Media Type
Unsupported URI Scheme
Status–Code
420
421
423
480
481
482
483
484
485
486
487
488
491
493
500
501
502
503
504
505
513
600
603
604
606
Beschreibender Text
Bad Destination
Extension Required
Interval Too Brief
Temporarily Unavailable
Call/Transaction Does Not Exist
Loop Detected
Too Many Hops
Address Incomplete
Ambiguous
Busy Here
Request Terminated
Not Acceptable Here
Request Pending
Undecipherable
Server Internal Error
Not Implemented
Bad Gateway
Service Unavaillable
Server Time–Out
Version Not Supported
Message Too Large
Busy Everywhere
Decline
Does Not Exists Anywhere
Not Acceptable
Tabelle 1: Status–Codes in SIP
1.3.3
Header / Body
Jedes Header Feld besteht aus Paaren wie folgt: "field-name: field-value". Dabei ist es unerheblich wie viele Leerzeichen darin vorkommen und es werden auch field–value Werte
erlaubt, welche sich über mehrere Zeilen erstrecken, solange die darauffolgenden Zeilen
mit Tabs oder Leerzeichen beginnen. Die Reihenfolge der Headerfelder ist ebenfalls unerheblich, allerdings ist es empfohlen die Proxy-relevanten Felder zuerst anzuführen. Es
ist auch möglich gleiche Headerfelder mehrmals anzuführen. Dabei muss es möglich sein
diese Felder in ein einziges umzuschreiben in eine durch Beistriche getrennte Liste. Die
Reihenfolge der gleichen Felder ist auch entscheidend.
Requests, wie auch Responses können einen Body enthalten, wobei dieser abhängig von
der Request Methode ist. Im Fall einer Response wird der Inhalt des Body von der Methode
und dem Rückgabe–Code der Response bestimmt. Der Medientyp des Body muss von
einem Content–Type Header Feld bestimmt werden und insofern der Body in irgendeiner
Form codiert wurde (zB. komprimiert), ist dies auch im Header als Content–Encoding
anzugeben. Ebenfalls können binäre Teile im Body enthalten sein, sowie "multipart" MIME
Typen. Die Länge ist im Header per Content–Length anzugeben.
5
1.4
1.4.1
Kommunikationsbeispiele
Registrierung
Zu Beginn muss sich ein Teilnehmer, in diesem Fall Bob, bei einem Registrar anmelden,
sodass er auch von anderen Teilnehmern gefunden werden kann. Dies geschieht mit den
Nachrichten REGISTER und der Antwort 200 OK:
REGISTER sip:registrar.biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Bob <sip:[email protected]>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:[email protected]>
Expires: 7200
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
;received=192.0.2.4
To: Bob <sip:[email protected]>;tag=2493k59kd
From: Bob <sip:[email protected]>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:[email protected]>
Expires: 7200
Content-Length: 0
1.4.2
Sitzung aufbauen und beenden
Hier wird versucht eine Sitzung zwischen zwei Teilnehmern aufzubauen, wobei auch ein
Warten in einer Warteschlange angeführt ist. Die Vollständigen SIP Nachrichten werden
nicht mehr aufgeführt, allerdings sind in der Grafik 1 die Abläufe und Funktionen bzw.
Status–Codes ersichtlich. Zwischen "7: ACK" und "1 BYE" ist die Sitzung im Gange und
zB. ein IP-Telefongespräch läuft.
1.4.3
Sitzung über einen Proxy
In dem Beispiel in Grafik 2 sieht man den Sitzungsaufbau über einen Proxy Server, welcher
der Request weiterleitet. Weiters sieht man, dass nach dem OK beide Endpunkte ohne den
Server weiter kommunizieren.
1.5
1.5.1
Sicherheitsaspekte in SIP
Gefahren und Risiken
Eine Gefahr besteht darin, dass ein Angreifer die Registrationseinträge bei einem Registrar ändert. Da es für Berechtige Personen möglich ist diese Daten für andere zu ändern,
kann es einem Angreifer gelingen diese Rechte zu erhalten und somit alle Informationen
6
Abbildung 1: Aufbau einer SIP Sitzung und Beenden dieser, Quelle: [16]
so zu verändern, dass anstelle der eigentlichen Empfänger, seine selbst angegebenen Empfänger die Nachrichten erhalten. Daher ist es sehr wichtig die Urheber eines Requests
authentifizieren zu können.
Eine weitere Möglichkeit wäre, dass ein Angreifer sich für einen anderen Server ausgibt
und so kann er Nachrichten die über den eigentlichen Server gehen sollten abfangen und
falsch bzw. gar nicht weitergeben. Somit sollten auch UA’s die Möglichkeit haben Server
zu authentifizieren.
Proxy Server werden oft benötigt um Nachrichten weiterzuleiten. Diesen muss vertraut werden ob durch Authentifizierung oder durch guten Willen. Dennoch möchte man
oft nicht, dass diese den Nachrichten Body lesen können. Wenn zum Beispiel Verschlüsselungsinformationen im Body übertragen werden, sollten diese nicht mitgelesen werden.
Möglich wäre auch, dass ein solcher Server die nachfolgenden verschlüsselten Nachrichten
liest, oder gar die Schlüssel ändert und auch Sicherheitsanforderungen vermindert. Wenn
darin Informationen über RTP vorhanden sind, könnten auch diese so verändert werden,
dass folgende Medien Ströme auf andere Devices ebenfalls übertragen werden um dort
mitzuhören.
Insofern ein Angreifer Nachrichten mitgelesen hat und er die Parameter der Sitzung
kennt, könnte er zu einem späteren Zeitpunkt die Parameter ändern, indem er Nachrichten
an beide Parteien sendet. Er kann auch BYE an beide senden, womit die Sitzung sofort
beendet würde.
Denial of Service Attacken sind ebenso denkbar, wenn beispielsweise Nachrichten mit
falschem Absender an tausende Empfänger gesendet werden. Durch die Menge an Antworten könnte der vermeintliche Absender außer Gefecht gesetzt werden.
1.5.2
HTTP Authentifizierung
Das Session Initiation Protokoll bietet einen zustandlosen Mechanismus der mit Hilfe von
Aufgaben funktioniert. Dieser dient zur Authentifizierung und basiert auf dem Mechanismus in HTTP. Der grundlegende Nutzer davon ist, dass ein User Agent oder Proxy Server,
7
Abbildung 2: Aufbau einer SIP Sitzung über einen Proxy, Quelle: [16]
der einen Request erhält, feststellen kann ob der Teilnehmer autorisiert ist, den Request
zu stellen. Ein UAS sowie ein Registrar oder Redirect Server wird auf einen Request mit
einem 401 Unauthorized antworten und so diesen Authentifizierungsmechanismus anfordern. Ein Proxy Server hingegen wird mit 407 Proxy Authentication Required antworten.
In dem RFC 2617[9] ist der HTTP Authentifizierungsmechanismus beschrieben. Dieser
wird, wie bereits erwähnt auch für SIP verwendet. Die Header Felder Proxy–Authenticate,
Proxy–Authorization, WWW–Authenticate und Authorization werden genau gleich verwendet wie bei HTTP. Wichtig anzumerken ist allerdings, dass SIP den Gebrauch des
"Basic" Schemas nicht erlaubt. Es muss die "Digest Access Authentication" verwendet
werden. Der Digest Mechanismus verlangt ein Shared Secret, welches nicht im Klartext
übertragen wird. Standardmäßig wird für die Berechnung der Md5–Algorithmus verwendet, andere sind allerdings auch möglich. Wenn mit 401 geantwortet wird, so muss eine
Aufgabe per WWW–Authenticate übermittelt werden und im Fall einer 407 Antwort wird
die Aufgabe mit Proxy–Authenticate übertragen. Der Teilnehmer, der sich authentifizieren
will, wird als Antwort in seinen Request entweder das Authorization Header Feld oder das
Proxy–Authorisation Feld einbauen.
Im Gegensatz zu HTTP wird in SIP der "realm–string" nicht als canonical-root-URL
verwendet, da es diese in SIP nicht gibt. Wichtig ist aber, dass der "realm–string" global
eindeutig sein muss und es empfohlen ist einen Hostnamen, oder Domainnamen zu verwenden. Weiters ist es nicht möglich ein ACK oder CANCEL zu authorisieren. Da auf ein
ACK keine Antwort erwartet wird, kann man hier auch keine Challenge in der Antwort
senden. Somit muss ein Empfänger ein ACK akzeptieren, das die gleichen Zugangsdaten
wie vorangegangene Requests von dem Sender beinhaltet. Ein CANCEL wird akzeptiert,
wenn es von dem gleichen Hop kommt, der auch den zu terminierenden Request gesendet
8
hat. Dies kommt daher, dass ein CANCEL nicht mehrmals gesendet werden kann.
User zu User Authentifizierung
Insofern ein UAS einen Request erhält, kann er entscheiden diesen zuerst zu authentifizieren bevor er den Request bearbeitet. Wenn auch keine Nutzerdaten bereitstellt, können
diese gefordert werden mit dem 401 Status–Code in der Antwort. Wobei ein WWW–
Authenticate im Header vorhanden sein muss. Dieser hat beispielsweise diese Form:
WWW-Authenticate: Digest
realm="biloxi.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
Möchte sich der UAC nun authentifizieren kann er den Request erneut senden mit dem
folgenden Header Feld:
Authorization: Digest
username="bob",
realm="biloxi.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="sip:[email protected]",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
Proxy zu User Authentifizierung
In diesem Fall geschieht die Authentifizierung gleich wie oben, nur dass hier vom Proxy
mit 407 und dem Proxy–Authenticate geantwortet wird. Wenn mehrere Proxy Server am
Weg liegen müssen diese die 407 Antwort weiterleiten an den User und dürfen Proxy–
Authenticate nicht verändern. Der Teilnehmer muss wieder seine Nutzerinformationen
angeben für diese Proxy und den Request erneut senden.
1.5.3
S/MIME
Da SIP Nachrichten MIME Bodies haben können, ist es auch möglich S/MIME zu verwenden. Die S/MIME Zertifikate, welche für Endnutzer verwendet werden, unterscheiden sich
von Server Zertifikaten. Der Unterschied liegt darin, dass sichergestellt werden muss, dass
das Zertifikat einem Endnutzer gehört und daher wird eine Endnutzeradresse verwendet.
Dies ist von der Form "userinfo"@"domainname".
Die Zertifikate beinhalten auch die Schlüssel, welche zum signieren oder verschlüsseln
der Nachrichten Bodies verwendet werden. Ein Problem hier ist, dass es keine Stelle gibt
welche Zertifikate für Endnutzeranwendungen ausgibt, dennoch sollten Nutzer versuchen
Zertifikate von öffentlichen Stellen zu erhalten. Der Schlüsselaustausch kann auch mit SIP
vonstatten gehen. Wenn eine CMS SignedData Nachricht in S/MIME verwendet wird, so
muss das Zertifikat mit dem public Key, der nötig ist um die Signatur zu prüfen, enthalten
sein. Wichtig ist dass S/MIME Implementierungen zumindest SHA1 für die Signierung und
3DES als Verschlüsselungsalgorithmus unterstützen müssen.
9
SIP Header Geheimhaltung und Integrität mit S/MIME
Um eine gewisse End-to-End Authentifikation, Integrität oder Vertraulichkeit für SIP
Header sicherstellen zu können, kann man ganze SIP Nachrichten mit S/MIME als MIME Bodies mit den "message/sip"Typ einpacken. Somit kann man darauf die Sicherheitsmöglichkeiten von S/MIME anwenden. Allerdings sind diese eingepackten SIP Requests
Kopien des äußeren Header oder auch Erweiterungen dazu. Somit kann man überprüfen,
ob der äußere Header verändert wurde. Insofern nun ein UAS eine solche getunnelte SIP
Nachricht erhält, soll dieser auf gleiche Art und Weise antworten. Normale MIME Bodies
sollten allerdings in der inneren Nachricht angehängt werden, sodass diese auch von der
MIME Sicherheit profitieren.
1.5.4
Sicherheit im Transport und Netzwerk Layer
In diesem Fall gibt es zwei Möglichkeiten Geheimhaltung und Integrität zu gewährleisten.
Einerseits die Verwendung von IPsec, das vor allem verwendet werden kann wenn bereits
bekannte Stellen miteinander kommunizieren und es kann auch auf einer Hop to Hop Basis
verwendet werden.
Andererseits gibt es die Möglichkeit TLS über TCP zu verwenden, indem man eine
SIPS-URI verwendet. Dies ist am Besten zu verwenden, wenn sich die Parteien nicht von
vornherein vertrauen. Der Nachteil ist allerdings, dass vom einen Ende zum anderen die
Verbindung über Hops geht, weil auch bei den Hops (zB. Proxy Server) das Via-Feld gesetzt
wird. Daher kann man sich nicht sicher sein, dass die ganze Verbindung über TLS geht,
da ein Hop dazwischen kein TLS zum nächsten Hop verwendet könnte. Die minimal implementierte Verschlüsselungsumgebung muss TLS_RSA_WITH_AES_128_CBC_SHA
sein.
2
H.323
Die ITU-T Recommendation H.323[15, 5] deckt die Voraussetzungen ab, welche für Multimedia Kommunikation nötig sind. Die Komponenten sind Terminals, Gateways, Gatekeeper, Multipoint Controllers, Multipoint Processors und Multipoint Control Units. Nicht
alle dieser Komponente sind für eine Kommunikation von Nöten, aber zu mindestens zwei
Terminale müssen vorhanden sein. Mit Hilfe von Kontrollnachrichten wird zwischen diesen
Komponenten kommuniziert. Diese Kommunikation geschieht mit Information Streams.
2.1
Information Streams
Diese Streams werden benötigt, damit Telefonkomponenten kommunizieren können und
werden wie folgt unterteilt:
Audio Signals beinhalten digitalisierte codierte Sprache. Dieses Signal wird von einem
Audio Control Signal begleitet.
Video Signals beinhalten digitalisierte und codierte bewegte Bilder, also Videos und
wird von einem Video Control Signal begleitet.
Data Signals bestehen aus Bildern, Dokumenten, Dateien und anderen Datenströmen.
Communication Control Signals geben Kontrollinformationen zwischen den einzelnen funktionalen Elementen weiter und werden zB. für das Öffnen und Schließen
logischer Kanäle verwendet.
10
Call Control Signals werden zB. für das Aufbauen und Beenden von Anrufen verwendet.
Diese Information Streams sind nach der ITU-T Rec. H.225.0[14] formatiert und werden
auch wie dort beschrieben versendet.
2.2
Protokolle und Codecs
H.323 benötigt und definiert einige weitere Protokolle und Codecs. Die verwendeten Codecs
sind für die Audio Kommunikation G.711, G.729, G.723.1, G.726, G.722, G.728, Speex.
Für die Video Übertragung wird H.261, H.263, H.264 verwendet und für Texte T.140.
Zumindest G.711 und H.261 sind notwendig und müssen implementiert sein.
Für die Kommunikation zwischen den einzelnen Komponenten werden verschiedene
Protokolle verwendet. Darunter wird H.255.0 für die Registration, Administration und
den Status (RAS) zwischen Terminal und Gatekeeper verwendet, sowie für die Anruf
Kommunikation zwischen zwei beliebigen Komponenten.
H.245 ist ein Kontrollprotokoll, welches für die Multimediakommunikation verwendet
wird um die Fähigkeiten der Komponenten auszutauschen und um logische Kanäle zu
öffnen und zu schließen. Für das Senden von Multimedia Information wird in der Regel
RTP verwendet.
Es können auch noch weitere Protokolle verwendet werden. Von diesen ist zum Beispiel
H.235 zu erwähnen, welches Sicherheitsaspekte für Signalströme, wie Multimediaströme
für H.323 beschreibt. In dieser Recommendation werden die Sicherheitsvorkehrungen, wie
in Grafik 3 gezeigt, beschrieben.
Abbildung 3: Sicherheit für H.323 laut H.235, Quelle: [13]
2.3
2.3.1
Netzwerk Komponenten
Terminals
Dies sind die grundlegenden Komponenten, die auch bei jedem Nutzer vorhanden sind. Sie
sind beispielsweise in IP-Telefonen eingebaut. Ein Terminal verwaltet einen Protokollstack,
der zumindest die notwendigen oben beschriebenen Protokolle und Codecs unterstützt.
In Grafik 4 sieht man den Aufbau von H.323 und die Protokolle bzw. Codecs wie sie
zusammenarbeiten.
11
Abbildung 4: Überblick über H.323, Quelle: [6]
2.3.2
Multipoint Control Units
Diese besteht aus zwei Teilen, dem Multipoint Controller und dem Multipoint Processor.
Sie dienen dazu Konferenzen mit mehreren Teilnehmern zu verwalten und es ist zum
Beispiel möglich, dass nicht nur die Audio Daten aller Teilnehmer gemixt werden und
man so alle hört, sonder dass man auch die Video Daten aller Teilnehmer bekommt und
so alle seine Gesprächsteilnehmer nicht nur hört, sondern auch sieht.
2.3.3
Gateways
Diese ermöglichen die Kommunikation zwischen H.323 Netzwerken und anderen Netzwerken, wie dem Festnetz (PSTN) oder ISDN Netzwerken. Insofern ein Teilnehmer kein
H.323 Terminal verwendet, müssen die Daten über ein Gateway zu dem Teilnehmer gesendet werden. Das Gateway ermöglicht somit die Kommunikation zwischen dem Festnetz
und IP-Telefonen.
2.3.4
Gatekeepers
Gatekeepers sind optionale Komponenten, die allerdings verschiedene Funktionen für die
anderen Komponenten bereitstellen. Dazu gehört die Registrierung der Endpunkte, Auflösung von Adressen und auch Authentifizierung. Sehr wichtig ist dabei die Auflösung
von Adressen, da somit auch Teilnehmer kommunizieren können, die ihre gegenseitigen
IP-Adressen nicht kennen.
Ein Gatekeeper kann in zwei Modi arbeiten. Einerseits "direct routed", er löst also
nur die Adresse auf und die Teilnehmer kommunizieren dann direkt miteinander und
andererseits "gatekeeper routed". Dies heißt dass der ganze Datenverkehr weiterhin vom
einen Teilnehmer zum Anderen über den Gatekeeper läuft. Die Kommunikation zwischen
Terminal und Gatekeeper, sowie zwischen Gatekeeper läuft über RAS.
12
2.3.5
Beispiel Kommunikation
Eine mögliche Kommunikation mit H.323 zwischen zwei Terminals könnte wie in Grafik 5
aussehen.
Abbildung 5: Kommunikation über H.323, Quelle: [7]
3
Inter–Asterisk eXchange
Das Inter–Asterisk eXchange Protokoll (IAX)[12] ist ein Protokoll der Anwendungsschicht,
das zur Kontrolle und Übertragung von Multimediainhalten dient. Es wird hauptsächlich
im Bereich der Voice over IP Anruf Kontrolle verwendet, kann aber auch mit anderen
Multimediainhalten verwendet werden.
IAX ist ein offenes Protokoll, das ursprünglich von Asterisk, einer Software, die die
Funktionalität einer Telefonanlage abdeckt, verwendet wurde. Es ist weiters ein binäres
Protokoll, vor allem um Overhead in Hinblick auf VOIP Verbindungen zu reduzieren.
Es verwendet auch den Ansatz, dass UDP als Transportprotokoll verwendet wird und
Daten immer auch an einen einzelnen Port gesendet werden. Dies sollt helfen den Verkehr
leichter zu erkennen und durch Firewalls durchzulassen. Die Grundstruktur dabei ist, dass
13
IAX Signale und mehrere Medienströme über einen UDP Strom zwischen zwei Rechnern
bündelt. Es wird der UDP Port 4569 verwendet für jeden möglichen IAX Datenverkehr.
Weiters gibt es die Authentifikation über Md5 oder RSA.
3.1
Peer Verhalten und Nachrichten
Es gibt zwei Kategorien von Nachrichten. Einerseits verlässliche und andererseits nicht
garantierte Nachrichten. Zu den ersten gehören die "Full Frames", welche den kompletten
Anruf Identifier und alle Identifier der Peers beinhaltet, sowie mögliche "Information Elements"(IE). Der andere Typ sind "Mini–Frames" oder "Meta–Frames", die nur den Identifier des sendenden Peers beinhalten. Im Folgenden wird das Verhalten in einige funktionale
Teile unterteilt:
3.1.1
Registration
Um es möglich zu machen, dass ein Peer einen anderen findet, ist es nötig dessen Netzwerkadresse zu kennen. Dies ist entweder manuell anzugeben, oder es kann in einem geteilten
Verzeichnis zu finden sein. IAX bietet auch die Möglichkeit, dass sich ein Peer bei einem
anderen registriert, sodass er gefunden werden kann. Dafür gibt es nun unterschiedliche
Nachrichten und wird mit einem REGREQ begonnen. Insofern Authentifikation erwünscht
ist wird mit REGAUTH geantwortet. Darauf wird REGREQ wieder gesendet, wobei die
Authentifikationsinformationen enthalten sind. Durch ein REGACK wird die Registrierung bestätigt und es kann jederzeit mit einem REGREJ ein Fehler signalisiert werden.
Die Registrierung gilt nur für bestimmte Zeit und danach muss diese mit erneuter Registrierung verlängert werden. Sollte dies nicht gewünscht sein kann auch ein REGREL zum
Registrar gesendet werden, welches wieder authentifiziert werden kann, um die Registrierung zu beenden. Ein möglicher Datenfluss für eine Registrierung ist in Grafik 6 zu sehen.
3.1.2
Call Link Managment
Mit IAX kann man einen Link zwischen zwei Peers aufbauen. Dies geschieht über eine
NEW Nachricht, welche die Nummer des zu rufenden Teilnehmers beinhaltet. Darauf hin
kann der Remote–Peer mit einer Forderung nach Authentifizierung(AUTHREQ), mit REJECT oder ACCEPT antworten. Mit AUTHREP kann der Sender die Authentifizierung
vornehmen. Daraufhin ist der Link in einem verbundenen Zustand und er kann weiter
verwendet werden um Kontrollnachrichten zu senden bis der Anruf beendet wird. Das
Beenden wird über die HANGUP Nachricht vollzogen.
3.1.3
Call Control
Hier werden Nachrichten versendet, welche erst möglich sind nachdem ein Link mit ACCEPT zustandegekommen ist. Als erstes nach einer NEW Nachricht wird eine RINGING
sein. Allerdings ist es auch erlaubt, dass eine ANSWER zuerst kommt, ansonsten erst
danach. Weiters gibt es eine BUSY Nachricht und mit HANGUP kann der Anruf auch
sofort wieder beendet werden. Insofern mit DIAL begonnen wurde folgt darauf ein PROCEEDING und dann erst das RINGING.
14
Abbildung 6: Registration unter IAX, Quelle: [17]
3.1.4
Call Path Optimization
Wenn zwei Peers über einen dritten in der Mitte kommunizieren, kann sich dieser aus
der Kommunikation herausnehmen, sodass die beiden anderen direkt in Kontakt stehen.
Hier gibt es die Nachrichten TXREQ (beginne den Transfer Prozess für die Optimierung),
TXCNT und TXACC(Prüfe die Verbindung welche die Existierende ersetzen soll), TXREADY(beende Verbindung und arbeite mit der neuen weiter).
3.1.5
Mid–Call Behavior
Hier gibt es Nachrichten FLASH(bei analogen Anlagen wenn eine kurze Unterbrechung
festgestellt wird), HOLD(den Anruf anhalten), UNHOLD(den Anruf weiterführen), QUELCH(der
Remote–Peer unterbricht den Anruf), UNQUELCH(Remote–PEER setzt Anruf fort), und
TRANSFER(Der Anruf soll abgebrochen werden und von empfangenden Peer wieder neu
aufgenommen werden).
3.1.6
Call Tear Down
Dies wird mit den bereits erwähnten Nachrichten HANGUP, REJECT, TRANSFER und
auch mit TXREADY in ihrem jeweiligen Kontext vollzogen.
15
3.1.7
Network Monitoring
Mit der POKE und PING Nachrichten wird die Erreichbarkeit eines Peers überprüft und
dieser muss mit PONG antworten und mit LAGRQ die Qualität des momentanen Links.
Dabei wird ein Timestamp gesendet der mit LAGRP zurückgesendet wird.
3.1.8
Digit Dialing
Diese Funktionalität dient dazu, dass auch analoge Geräte mit IAX kommunizieren können. Dabei werden eine Menge von DPREQ Nachrichten gesendet welche von DPREP
beantwortet werden, indem sie anzeigen ob der Server eine Rufnummer eines Peers kennt
die gleich ist oder ob weitere Zahlen eingegeben werden müssen. Wenn DPREP anzeigt
dass es die Nummer gibt, kann diese mit DIAL "angerufen" werden
3.1.9
Miscellaneous
Erhaltene Nachrichten (Full Frames) werden mit ACK bestätigt, insofern sie keine andere
Antwort erwarten. Wenn eine nicht gültige Nachricht erhalten wird, sendet der Peer eine
INVAL Nachricht. Wenn Nachrichten nicht in der richtigen Reihenfolge eintreffen (ein
Mini–Frame mit Audio Inhalt bevor ein Full–Frame eingelangt ist der den Beginn des
Audiotransfers einleitet), so wird ein VNAK gesendet. MWI wird verwendet um einem
anderen Peer zu sagen, dass man noch Nachrichten hat die warten gesendet zu werden.
Wenn ein Peer eine Nachricht nicht unterstützt, wird dies mit UNSUPPORT angezeigt.
3.1.10
Media Messages
Audio und Video Nachrichten werden mit Mini–Frames übertragen. Sie sind einzigartig,
da sie eigene Codierungen verwenden. Allerdings muss immer wenn der Timestamp ein
Vielfaches von 0x8000 ist ein Full–Frame gesendet werden. Wenn Mediennachrichten erhalten werden, welche keine solchen Mini–Frames sind, muss darauf ein ACK gesendet
werden.
Mediennachrichten sind bei IAX: DTMF (Dual Tone Multi-Frequency), Voice Media,
Video Media, Text Media, Image Media, HTML Media Nachrichten und Comfort Noise
Nachrichten.
3.2
3.2.1
Struktur der Frames
Full Frames
Der Full Frame ist wie in Grafik 7 aufgebaut. Das F-bit zeigt an ob es sich um einen Full
Frame handelt. Die 15bit Source Call Number zeigt die Nummer an welche der Sender
benützt um den Anruf zu identifizieren. Das R-bit zeigt an ob der Frame noch einmal
übertragen wird oder das erste Mal. Die Destination Call Number wird vom Sender verwendet um den Anruf bei dem Remote–Peer zu identifizieren und stimmt mit der Source
Call Number des Remote–Peer überein. Der Time-Stamp ist ein 32bit Zahl welche in Millisekunden darstellt wie viel Zeit ab der ersten Nachricht des Anrufs vergangen ist. OSeqno
ist eine Stream Sequenz Nummer die mit jedem gesendeten Full Frame erhöht wird. ISqeno wird hingegen mit jedem empfangenen Full Frame erhöht. Der Frametype zeigt den
Typ der Nachricht an, die transportiert wird. Das C-bit deutet an wie die darauffolgenden 7 Subclass bits zu interpretieren sind. Wenn C=1, dann als Potenz von 2, sonst als
vorzeichenlose Ganzzahl.
16
Abbildung 7: Aufbau eines Full Frame, Quelle: [1]
3.2.2
Mini Frames
Diese werden so genannt, da ihre Header minimal sind und sie keine Kontrolldaten beinhalten. Sie dienen nur dazu Medien über einen bereits aufgebauten Link zu senden. Sie
haben das F-bit, welches 0 sein muss, eine Source Call Number, die wie beim Full Frame
den Anruf identifiziert und einen Time-Stamp welcher die unteren 16bit des Full Frame
Time-Stamp beinhaltet. In Grafik 8 ist ein solcher Frame dargestellt.
Abbildung 8: Aufbau eines Mini Frame, Quelle: [2]
3.2.3
Meta Frames
Hier gibt es zwei Sorten von Frames. Das eine sind Video Frames, welche es erlauben Video
Daten mit einem optimierten kürzeren Header zu übertragen und das andere sind Media
Trunk Frames, welche meherere IAX Medienströme zwischen zwei Peers zusammenfassen.
Die beiden Frames sind in Grafiken 9 und 10 abgebildet.
3.3
Verschlüsselung und Authentifizierung
IAX unterstützt die Verschlüsselung von Anrufen mit symmetrischen Schlüsseln per AES
128bit. Die NEW Nachricht wird im Klartext übertragen und zeigt die Verschlüsselung
an. Dabei gibt man das IE ENCRYPTION an. Alle nachfolgenden Nachrichten müssen
verschlüsselt sein, wobei nur die Datenteile der Nachrichten codiert werden. Die Header
17
Abbildung 9: Aufbau eines Meta Video Frame, Quelle: [12]
Abbildung 10: Aufbau eines Meta Trunk Frame, Quelle: [12]
Call Numbers werden im Klartext übertragen und der Rest des Frame wird mit 16 bis
32Byte zufälliger Daten aufgefüllt und anschließend verschlüsselt. Die zufälligen Daten
werden dabei aber vor den eigentlichen Daten eingefügt.
Authentifizierung erfolgt in IAX mittles Md5 oder RSA. Mit dem Information Element CHALLENGE wird die Aufgabe für Md5 oder RSA, welches zuerst vereinbart wird
(mit dem IE AUTHMETHODS), übertragen. Die beiden IE’s MD5 RESULT bzw. RSA
RESULT liefern dann die Antwort auf die Aufgabe.
4
Real–Time Transport Protokoll & RTP Control Protokoll
Das Real–Time Transport Protokoll[11] bietet die Möglichkeit Echtzeitdaten, wie interaktive Audio- und Videokonferenzen, von einem Ende zum Anderen zu übertragen. Normalerweise wird RTP mit UDP verwendet, es ist aber auch möglich andere Transportprotokolle
zu verwenden. Ebenso wird Multicast unterstützt.
Das RTP Control Protokoll[11] wird verwendet um die Qualität des Service festzustellen und um Informationen über die Teilnehmer weiterzuleiten.
18
4.1
RTP
Abbildung 11: RTP Header, Quelle: [3]
In der Grafik 11 sind die fixen Header Felder von RTP angeführt. Das V-bit steht für
die Version und das P-bit deutet an ob am Ende ein oder mehrere Padding Bytes folgen.
Wenn das X-bit gesetzt ist, muss nach dem Header eine Header Erweiterung folgen. CC
bestimmt die Anzahl an CSRC Identifier, die nach dem Header folgen. M steht für das
Markerbit, das zB das Ende eines Streams anzeigen kann. PT definiert den Datantyp des
Payload, wobei ein Empfänger Pakete ignorieren muss, wenn er den Payload Typ nicht
kennt. SSRC ist eine zufälliger Identifier der die syncronization source bezeichnet. Die
CSRC list beinhaltet 0 bis 15 Einträge, welche die contributing sources identifizieren. Dies
ist wichtig wenn der Datenstrom aus mehreren Quellen gemixt wird.
RTP sollte einen geraden Ziel Port wählen und RTCP den nächsten ungeraden Port.
Der Port darf nicht der gleiche sein, da die Ports verwendet werden um die Ströme wieder
zu trennen.
Da RTP für viele Anwendungen verwendet werden kann, kann man für gewisse Anwendungen Profile beschreiben. Hier wählt oder definiert man die benötigten Erweiterungen,
welche für die Anwendungen benötigt werden. Ein zweiter Teil ist die Spezifikation des
Formates der Payload. Hier wird angegeben, wie zB Videodaten codiert und in RTP transportiert werden sollen.
4.2
RTCP
RTCP basiert auf dem periodischen Senden von Paketen zu allen Teilnehmern einer Sitzung und es hat folgende vier Funktionen:
• Das Protokoll soll Informationen über die Qualität der Datenverteilung liefern. Somit
können auch Fehler in der Übertragung festgestellt werden und Netzwerk Probleme
diagnostiziert werden.
• RTCP hat einen persistenten Identifier für die RTP source, der auch canonical Name
genannt wird (CNAME). Da ein SSRC sich im Konfliktfall ändern kann, oder wenn
ein Programm neu gestartet wird, brauchen Teilnehmer den CNAME um alle Teilnehmer weiterhin finden zu können. Der CNAME ist auch wichtig um zB Audio und
Videostreams, die in zwei RTP Sitzungen übertragen werden, zu synchronisieren.
• Da alle Teilnehmer RTCP Pakete senden, wissen sie immer wie viele Teilnehmer
zugegen sind und können die Rate kontrollieren und anpassen, mit welcher die Pakete
gesendet werden.
19
• Optional ist es auch möglich einige Kontrollfunktionen weiterzuleiten, wie zB Teilnehmerinformationen, welche dann in einem User Interface dargestellt werden können.
4.2.1
RTCP Paket Format
Es gibt mehrere Formate, die unterschiedliche Kontrollinformationen beinhalten:
SR: Sender Report wird verwendet um Übertragungsstatistiken und Empfangsstatistiken
von aktiv sendenden Teilnehmern zu erhalten.
RR: Receiver Report teilt Empfangsstatistiken von nicht sendenden Teilnehmern mit.
SDES: Source Description Items sind beispielsweise der CNAME.
BYE: Zeigt das Ende der Teilnahme an einer Sitzung an.
APP: Übermittelt Applikationsspezifische Funktionen.
Jedes RTCP Paket beginnt mit einem fixen Teil, der dem von RTP gleicht, gefolgt von
einem variablen Teil, der abhängig ist von dem Typ des Paketes. Doch jedes Paket muss an
einer 32bit Grenze enden und somit können RTCP Pakete zusammengehängt werden und
als compound RTCP packet in einem (zB UDP) Paket übertragen werden. Ein Beispiel
für ein solches Paket ist in Grafik 12 gegeben.
Abbildung 12: compound RTCP Paket, Quelle: [11]
4.3
Sicherheit
RTP hat einen eigenen Verschlüsselungsmechanismus um die Geheimhaltung zu gewährleisten. Dennoch ist es auch zum Teil gewollt, dass die Transportschicht die Sicherheitsaspekte abdeckt.
Wenn nun Verschlüsselung verwendet wird, so werden alle RTP oder RTCP Pakete,
welche in der darunterliegenden Schicht gemeinsam in einem Paket gesendet werden auch
gemeinsam codiert. Bei RTCP muss man vor jede solche Einheit eine 32bit Zufallszahl
einfügen, bei RTP ist dies nicht nötig, aber die Sequenznummer und der Time-Stamp
werden mit zufälligen Offsets initialisiert. Danach werden die Pakete verschlüsselt. Verwendet wird DES mit dem cipher block chaining Modus. Empfohlen wird allerdings die
Verwendung besserer Algorithmen, wie Triple-DES. Alternativ ist es möglich Profile zu
definieren, die zusätzliche eigene Payload Typen definieren. In diesen ist es dann erlaubt
eigene Codierungen zu verwenden. Wenn es ausreichend ist die Payload zu verschlüsseln
ist dies ein guter Ansatz. Ansonsten sei auf SRTP verwiesen.
Authentifizierung und Integritätsgewährleistung ist in keiner Weise vorgesehen.
20
5
Secure Real–Time Transport Protokoll
SRTP[8] ist eigentlich ein Profil des RTP, welches Geheimhaltung und Authentifizierung
für RTP und RTCP bietet. Das SRTP Framework arbeitet indem es RTP Pakete beim
Senden in SRTP Pakete umschreibt und beim Empfangen diese wieder als normale RTP
Pakete weitergibt. Für RTCP wird SRTCP verwendet bei dem Authentifizierung verpflichtet ist.
Ein SRTP Paket hat das Format das in Grafik 13 dargestellt ist. Die verschlüsselten
Abbildung 13: SRTP Paket, Quelle: [4]
Daten sind der RTP Payload, welcher gleich groß oder größer (wegen dem Padding) als der
Klartext sein kann. Die einzigen von SRTP definierten Felder sind MKI (optional) und der
Authentication Tag. MKI ist der Master Key Identifier, der von dem Schlüssel Management
definiert wird. Dieser identifiziert den Master Key von welchem die Sitzungsschlüssel über
eine Funktion abgeleitet werden.
Der Authentication Tag überträgt die Authentifizierungsdaten. Die authentifizierten
Daten sind der RTP Header, sowie die verschlüsselten Daten. Daher soll auch immer die
Verschlüsselung vor der Authentifizierung geschehen. Der Tag liefert dabei Informationen
zur Authentifizierung der Payload und des Headers. Ebenfalls wird die Sequenznummer
authentifiziert, sodass die Nachrichten nicht von Angreifern verändert und erneut gesendet
werden können.
SRTCP hingegen definiert vier neue Felder. Diese sind das E-Flag, welches anzeigt
ob das momentane Paket verschlüsselt ist. Der SRTCP-Index ist ein 31bit Zähler der bei
jedem gesendeten SRTCP Paket um 1 erhöht wird. Der Authentication Tag ist wie bei
SRTP verwendet und der MKI ebenfalls.
Als Verschlüsselungsalgorithmus wird AES mit 128bit verwendet und zur Authentifizierung der Hash basierte Authentifizierungscode mittels SHA1 und einem 160bit Schlüssel,
wobei ein 80bit Tag entstehen soll. Dadurch dass Funktionen verwendet werden um aus
einem Master Key alle benötigten Schlüssel für SRTP und SRTCP abzuleiten, ist es nur
nötig den Master Key sicher auszutauschen und wenn nötig noch ein Master Salt.
21
Literatur
[1] http://www.en.voipforo.com/images/IAX-Full-F-Frame.gif.
[2] http://www.en.voipforo.com/images/IAX-Mini-M-Frame.gif.
[3] https://prof.hti.bfh.ch/myf1/www/projects/polyphem/www/documents/images
/rtp_header.jpg.
[4] http://www.cisco.com/en/US/i/200001-300000/220001-230000/227001228000/227279.jpg.
[5] H.323. http://en.wikipedia.org/wiki/H.323.
[6] CISCO. http://www.cisco.com/image/gif/paws/5244/h323-scope.gif.
[7] CISCO. http://www.en.voipforo.com/images/H323-communication.gif.
[8] Baugher et. al. The secure real-time transport protocol (srtp), rfc3711, 3 2004.
http://tools.ietf.org/pdf/rfc3711.pdf.
[9] Franks et. al. Http authentication: Basic and digest access authentication, rfc2617, 6
1999. http://tools.ietf.org/pdf/rfc2617.pdf.
[10] Rosenberg et. al.
Sip: Session
http://tools.ietf.org/pdf/rfc3261.pdf.
initiation
protokoll,
rfc3261,
2002.
[11] Schulzrinne et. al. Rtp: A transport protocol for real-time applications, rfc3550, 7
2003. http://tools.ietf.org/pdf/rfc3550.pdf.
[12] Spencer et. al.
Iax: Inter-asterisk exchange version 2, rfc5456, 2 2010.
http://tools.ietf.org/pdf/rfc5456.pdf.
[13] ITU-T. H.323 security: Baseline security profile, 9 2005. http://www.itu.int/rec/TREC-H.235.1-200509-I/en.
[14] ITU-T. H.225.0 call signaling protocols and media stream packetization for packetbased multimedia communication systems, 12 2009. http://www.itu.int/rec/T-RECH.225.0/en.
[15] ITU-T.
H.323 packet-based multimedia communications systems, 12 2009.
http://www.itu.int/rec/T-REC-H.323-200912-I/en.
[16] Radvision. Sip: Protocol overview. http://www.radvision.com/NR/rdonlyres/51855E82BD7C-4D9D-AA8A-E822E3F4A81F/0/RADVISIONSIPProtocolOverview.pdf.
[17] Holder Schildt. Voip mit iax. http://www.qucosa.de/fileadmin/data/qucosa/ documents/4811/data/iax.pdf.
22