DTLS -Datagram Transport Layer Security

D ► DTLS DTLS Autor: Prof. Dr.-Ing. Datagram Transport Layer Security Anatol Badach Das Sicherheitsprotokoll DTLS wurde entwickelt, um die Sicherheit der Kommunikation im Internet und in anderen privaten IP1-Netzen beim Einsatz eines unzuverlässigen Transportprotokolls wie dem User Datagram Protocol (UDP) gewährleisten zu können. DTLS stellt eine modifizierte Version des wichtigen Sicherheitsprotokolls Transport Layer Security (TLS) dar und wird daher auch als Da- tagram TLS bezeichnet. Im Gegensatz zu TLS, mit dem der Trans- port von Daten mithilfe eines verbindungsorientierten (Connection- oriented Transport Service, COTS) – und demzufolge eines zuver- lässigen – Transportprotokolls wie dem Transmission Control Pro- tocol (TCP) gegen bösartige Angriffe abgesichert werden kann, Auszug aus dem ermöglicht DTLS den Transport von Daten beim Einsatz eines ver- Werk: bindungslosen (Connectionless Transport Service, CLTS) – und somit eines unzuverlässigen – Transportprotokolls abzusichern. Die erste Version von DTLS – kurz als DTLS 1.0 bezeichnet – wur- de im Dokument RFC 4347 (2006) der Internet Engineering Task Force (IETF) veröffentlicht und basiert auf der im RFC 4346 spezi- fizierten Version 1.1 des Protokolls TLS. Inzwischen wurde DTLS 1.0 von der Working Group TLS bei der IETF weiterentwickelt und um neue Sicherheitsverfahren so erweitert, dass eine neue und auf Herausgeber: dem Protokoll TLS 1.2 basierende Version von DTLS als RFC Heinz Schulte 4347bis veröffentlicht werden soll. Mit der Bezeichnung dieser WEKA-Verlag neuen Version als DTLS 1.22 soll auf das Basisprotokoll – und zwar auf TLS 1.2 – direkt verwiesen werden. ISBN 978- 3824540662 Bedeutung von DTLS http://www.weka.at/bestellen/ protokolle-und-dienste-der- Ebenso wie TLS wird DTLS im Schichtenmodell – wie Bild 004172 informationstechnologie dies illustriert – in der Anwendungsschicht quasi als eine DTLS- Teilschicht zwischen Anwendungsprotokollen und einem verbin- 1 Internet Protocol 2 http://tools.ietf.org/id/draft-ietf-tls-rfc4347-bis-03.txt 1 D ► DTLS dungslosen Transportprotokoll wie UDP, Datagram Congestion Control Protocol (DCCP)3 oder Stream Control Transmission Proto- col (SCTP)4 im unzuverlässigen Modus angesiedelt. Zu den Anwen- dungsprotokollen, die ein verbindungsloses Transportprotokoll nutzen, gehören vor allem Protokolle für die Realisierung der Diens- te zur Übermittlung von Echtzeitmedien – wie Sprache, Audio und Video – über IP-Netze. Derartige Dienste gewinnen immer mehr an Bedeutung. Ein Beispiel dafür ist Voice over IP (VoIP) und auf das fernsehorientierte TV over IP (TVoIP) werden wir mit Sicherheit nicht lange warten müssen. Bild 004172: DTLS im Schichtenmodell und seine Bedeutung WKP: Well Known Port ???: WKP ist noch nicht festgelegt Nutzt ein Anwendungsprotokoll DTLS, so wird der Name des An- wendungsprotokolls – ebenso wie bei TLS – mit dem Buchstaben „S“ beendet. SIP (s.u.) wird beispielsweise zu SIPS umbenannt. Damit wird zum Ausdruck gebracht, dass es sich um die gesicherte Version eines Anwendungsprotokolls handelt. Wie in Bild 004172 dargestellt, können mithilfe von DTLS folgende Anwendungsprotokolle vor bösartigen Angriffen geschützt werden: 3 RFC 4340 4 RFC 4960 2 D ► DTLS • SIP over DTLS – Secure SIP (SIPS) Das Session Initiation Protocol (SIP)5 wird vor allem bei VoIP als Signalisierungsprotokoll verwendet. Normalerweise nutzt SIP innerhalb einer Domain im Sinne des Verzeichnisdienstes Domain Name System (DNS) das verbindungslose Transportpro- tokoll UDP. Zur Übermittlung von SIP-Nachrichten zwischen sog. SIP-Proxies aus verschiedenen Domains kommt aber immer häufiger SIPS zum Einsatz, um die Übermittlung von SIP- Nachrichten vor böswilligen Angreifern zu sichern. Das Konzept von SIP over DTLS beschreibt der Internet-Draft draft- jennings-sip-dtls-05. • SNMP over DTLS – Secure SNMP (SNMPS) Das Simple Network Management Protocol (SNMP)6 ist ein Pro- tokoll für den Transport von Nachrichten beim Netzwerkmana- gement. SNMPS ermöglicht eine gegenseitige Authentifizierung der Kommunikationspartner und garantiert sowohl die Integrität als auch die Vertraulichkeit von Managementnachrichten. • RADIUS over DTLS – oft Secure RADIUS genannt und als RADSec, RadSec bzw. als RADSEC bezeichnet Der Remote Authentication Dial-in User Service (RADIUS)7 wird als Zugriffsprotokoll auf einen AAA-Server (Authenticati- on, Authorization and Accounting Server) eingesetzt, der dem- zufolge meist als RADIUS-Server bezeichnet wird. Es beschreibt die Kommunikation zwischen einem RADIUS-Client und einem RADIUS-Server. Zur Absicherung dieser Kommunikation wird RADSec eingesetzt. Dieses Konzept beschreibt der Internet- Draft draft-dekok-radext-dtls-01. • Syslog over DTLS – genannt Secure Syslog Als Syslog (System-Login) wird ein Protokoll – siehe RFC 5424 – zur Übermittlung von sog. Log-Meldungen in Form von kurzen Textnachrichten (mit weniger als 1024 Bytes) in einem IP-Netz bezeichnet. Um diese Übermittlung gegen böswillige Angriffe – 5 RFC 3261 6 RFC 1157 7 RFC 2865 3 D ► DTLS z.B. gegen das Abhören – abzusichern, kann Secure Syslog ver- wendet werden. • IPFIX over DTLS – Secure IPFIX (IPFIXS) Das Protokoll Internet Protocol Flow Information Export (IPFIX)8 wird zur Überwachung der IP-Netze verwendet. Als Flow werden dabei zusammengehörende Pakete eines Daten- stroms bezeichnet, wie z.B. aus der gleichen Datenquelle, zum gleichen Ziel oder des gleichen Anwendungsprotokolls. Mit IPFIXS können sich die beiden kommunizierenden Netzeinrich- tungen – wie z.B. ein Netzmonitor und eine von ihm überwachte Netzkomponente – gegenseitig authentifizieren und untereinan- der verschlüsselte Nachrichten übermitteln. • RTP over DTLS Das Realtime Transport Protocol (RTP)9 gehört zu den wichtigs- ten Protokollen und wird zum Transport von Echtzeitmedien – z.B. von Sprache, Audio und Video – verwendet. RTP nutzt das verbindungslose Transportprotokoll UDP. Mit dem Einsatz von RTP over DTLS besteht daher die Möglichkeit, die Echtzeit- kommunikation in IP-Netzen gegen bösartige Angriffe abzusi- chern. Hervorzuheben ist aber, dass es bereits vor der TLS-Ära (seit März 2004) das Protokoll Secure RTP (SRTP)10 gab. Es verwendet ein zusätzliches Protokoll – das sog. Multimedia In- ternet Keying (MIKEY)11 – zur Erzeugung eines geheimen Schlüssels. Es werden auch einige Konzepte entwickelt, welche RTP over DTLS mit dem Protokoll SRTP so integrieren, dass MIKEY nicht mehr gebraucht wird. In diesem Zusammenhang spricht man bereits von SRTP over DTLS oder von DTLS-SRTP – für Näheres siehe z.B. den Internet-Draft draft-ietf- avt-dtls-srtp-07.txt. 8 RFC 5101 9 RFC 3550 10 RFC 3711 11 RFC 3830 4 D ► DTLS TLS over Datagram – Wo sind die Probleme? Das grundlegende Konzept von DTLS ist es zu ermöglichen, dass TLS den verbindungslosen und unzuverlässigen Transportdienst – d.h. den sog. Datagrammdienst (Datagram Service), insbesondere mithilfe des UDP – nutzen kann. Ein solches Konzept verlangt aber eine Anpassung von TLS an die Besonderheiten des Datagramm- dienstes. Dafür gibt es mehrere Ursachen, die infolge der Datenver- luste beim Datagrammdienst entstehen. Die Anpassungen von TLS lassen sich zu den folgenden zwei Punkten zusammenfassen: 1. Der Ablauf von TLS, der zum Aufbau einer sog. TLC- Verbindung12 führt, setzt aber voraus, dass alle TLS- Nachrichten das Ziel erreichen, also unterwegs nicht verloren gehen. Bei DTLS ist dies aber nicht der Fall, sodass mit Verlus- ten von transportierten TLS-Nachrichten gerechnet werden muss. 1-te TLS-Anpassung: Bei DTLS müssen somit bestimmte Me- chanismen – u.a. die Nummerierung von Nachrichten und zu- sätzlich ein Timeout-basierter Mechanismus – eingeführt wer- den, damit man zuerst feststellen kann, ob eine Nachricht ver- mutlich unterwegs verloren gegangen ist und wann diese erneut gesendet werden soll (Bild 004175). 2.