Sichere Netzdienste. Georg Mayer Hauptseminar: Sicherheit in Kommunikationsnetzen Technische Universität München

Transkript

1 Sichere Netzdienste Georg Mayer Hauptseminar: Sicherheit in Kommunikationsnetzen Technische Universität München WS 2002 (Version 6. März 2003) Zusammenfassung Dieses Papier behandelt die Anwendung von Quality of Service mit Hilfe von IntServ (Integrated Services) und RSVP (Resource ReserVation Protocol) mit den dazugehörigen Sicherheitsaspekten. 1 Einleitung Quality of Service wird auf Grund des immer stärkeren Bedarfs von Multimedia, sowohl von Internet als auch Intranet, immer wichtiger. Dieses Paper befasst sich deshalb mit einer Realisierungsmöglichkeit von Quality of Service mit Hilfe von Integrated Services und den Sicherheitsaspekten. Dazu wird zuerst Quality of Service mit Hilfe von Integrated Service betrachtet. Im zweiten Teil werden die Sicherheitsaspekte dazu betrachtet. 2 Quality of Service und IntServ/RSVP In den letzten Jahren wurden im Bereich Multimedia starke Umsatzsteigerungen erreicht. Die Grundlage dieses enormen Wachstums ist in den technischen Fortschritten bei der Entwicklung adäquater Hardware- und Software-Komponenten zu suchen. Deshalb war es nur eine Frage der Zeit, bis die Industrie und private Haushalte Multimedia für ihre Zwecke entdeckt haben. In der Industrie wird es z.b. zum multimedialen Lernen und für Videokonferenzen benützt. Im Heimbereich dagegen steht der Spaß im Vordergrund, der durch die bunten und tönenden Spiele und durch die Sound- und Bildwiedergabefähigkeiten aufkommt. Momentan werden, vor allem im Heimbereich, noch größtenteils lokale Multimedia- Daten benutzt. Wobei allerdings immer mehr Bedarf für verteilt ablaufenden Multimedia- Applikationen, wie Bildschirmkonferenzsysteme, Video-on-Demand, Netzwerkspiele und auf Multimedia gestützte, virtuelle Welten besteht. Wird die Dienstgüte (Quality of Service) der Multimedia-Ströme bei lokal arbeitenden Anwendungen maßgeblich durch die Hardware-Komponenten CPU und Hauptspeicherausbau eines Rechners, sowie deren Verwaltung bestimmt, kommt im verteilten Fall eine weitere Komponente hinzu: das Transportsystem zwischen den Rechnern. An das Transportsystem wird gerade von den kontinuierlichen Medien, wie Audio und Video sehr hohe Ansprüche gestellt. Deshalb ist das zur Zeit weit verbreitete Netzwerkprotokoll IP (Internet Protokoll), das nur ein sehr einfaches Dienstmodell anbietet und die Daten nach dem Best Effort-Prinzip liefert schlecht geeignet. Nachteile davon sind keine Garantie für das Ankommen oder die richtige Reihenfolge der 1

2 2 Überblick über Sicherheitsprobleme Pakete, i.a. keine Zulassungbeschränkung für neue Clients und auch keine Erfüllung von Echtzeitanforderungen. Dieses einfache Modell ist für die neu entwickelten, verteilt ablaufenden Multimedia- Applikationen ungeeignet. Vielmehr werden Dienste benötigt, die Quality of Service (QoS) ermöglichen. Die wichtigsten Paramenter für QoS sind Garantie für hohen Durchsatz, geringen Jitter und geringen Delay. Ein Ansatz um dies zu ermöglichen sind die Integrated Services (IntServ). Hierbei werden Netzwerkressourcen mit Hilfe von RSVP reserviert. 2.1 Basis Konzept von RSVP RSVP wird in der Protokollhierarchie auf Ebene der Transportschicht eingeordnet. Protokolle dieser Schicht bieten Dienste an, die eine verbindungsorientierte und zuverlässige Ende-zu- Ende-Verbindung bereitstellen, um Daten zwischen einem Sender und Empfänger übertragen zu können. RSVP transportiert jedoch keine Nutzdaten einer Applikation. Vielmehr kümmert es sich darum, dass Reservierungen von Netzwerk-Ressourcen korrekt ablaufen und die dafür notwendigen Verwaltungsnachrichten gesendet werden. Deshalb wird in den Schichten durch die Integration von RSVP kein Protokoll ersetzt, vielmehr wird die Transportschicht um das RSVP-Protokoll ergänzt. Somit können zur Übertragung von Daten weiterhin das TCP oder UDP-Protokoll verwendet werden. So greift RSVP gegebenenfalls kontrollierend auf diese Transportprotokolle zu. RSVP kooperiert mit den bereits vorhandenen Protokollen, wie dem Internet Protokoll Version 4 und Version Prinzipieller Ablauf einer Reservierung Wird nun von einem oder mehreren Empfängern eine Anforderung an einen Sender gegeben, so überträgt dieser zunächst Path-Nachrichten an den oder die Empfänger, die den kommenden Datenstrom beschreiben. Diese Nachrichten sind genauso adressiert wie die Datenpakete (als Absender- und Empfängeradresse sind die Endpunkte der Übertragung gesetzt) und werden daher genauso geroutet. In jedem Knoten, den sie passieren, wird ein Pfadzustand gesetzt, der unter anderem die IP-Adresse des vorhergehenden Knotens enthält. Erreicht die Path-Nachricht einen Empfänger, so sendet dieser eine Resv-Nachricht zurück, in der die gewünschte Ressourcen-Reservierung definiert ist. Um sicherzustellen, dass Resv- Nachrichten auf dem gleichen Weg zurücklaufen, den später die Datenpakete nehmen, werden Resv-Nachrichten Knoten für Knoten auf dem Weg versandt, den auch die Path-Nachrichten genommen haben (mit Hilfe der im Pfadzustand gespeicherten Adresse des jeweils vorhergehenden Knotens). In jedem Knoten, den die Resv-Nachricht passiert, wird ein Reservierungszustand gesetzt, der die für diesen Datenstrom reservierten Ressourcen beschreibt. Nach Empfang der Resv-Nachricht beginnt der Sender schließlich, seine Daten an den oder die Empfänger zu übertragen. Siehe Abbildung Detaillierte Betrachtung einer Resv-Nachricht Betrachten wir eine Resv-Nachricht genauer: Kern jeder Reservierungsanforderung ist der sog. Flow Descriptor. Er besteht aus einer Flow Spec, die eine bestimmte Dienstqualität (QoS) definiert, und einer Filter Spec, die die Datenpakete definiert, denen diese QoS zugute kommen soll. Flow Spec Hier werden die geforderte QoS Dienstklasse, die entweder Controlled-Load oder Guaranteed Service sein können, und der kommende Datenstrom beschrieben. [RFC 2210]. Der Controlled-Load Service verhilft dem Datenstrom mit Hilfe von Zugangskontrollmechanismen [RFC 2211] auch in Überlastungssituationen annähernd zu der QoS, die er auch von einem unbelasteten Netzknoten erhalten würde.

3 2 QUALITY OF SERVICE UND INTSERV/RSVP 3 Abbildung 1: Schematischer Ablauf einer Reservierung mit RSVP

4 4 Überblick über Sicherheitsprobleme Guaranteed Service stellt sicher, dass die Ende-zu-Ende-Verzögerung sich innerhalb definierter Grenzen bewegt und garantiert so ein festes Maß an Verzögerung und Bandbreite [RFC 2212]. In der Reservation Spec (RSpec) wird die gewünschte QoS spezifiziert, die von RSVP jedoch nur blind übertragen wird. Für die Auswertung der RSpec-Parameter wie Rate (zu übertragende Bytes/Sekunde) und Slack Term (Differenz zwischen gewünschter und angebotener Verzögerung) ist der Netzknoten verantwortlich. Gleiches gilt für die Traffic Spec (TSpec), die den Datenstrom mit Hilfe von Parametern wie Peak Data Rate und Maximum Packet Size beschreibt. Filter Spec In diesem Teil der Reservierungsanforderung wird definiert, welchen Datenpaketen die gewünschte QoS zugute kommen soll. Datenpakete werden über die IP-Adresse und (optional) den Quellport ihres Senders gefiltert. Anstatt der IP- Adresse und Quellports kann bei IPv6 auch der Flow Label verwendet werden, der in jedem Paketheader enthalten ist und einen bestimmten Datenstrom vom Sender zum Empfänger eindeutig identifiziert. Auch wenn in der aktuellen RSVP-Spezifikation nur diese Parameter als Filter vorgesehen werden, können prinzipiell beliebige Parameter des Übertragungs- bzw. übertragenen Protokolls verwendet werden. Path Message Path-Nachrichten enthalten ähnliche Informationen zur Beschreibung des zu erwartenden Datenstroms: Auch sie verwenden eine Filter Spec, um die Pakete des Datenstroms zu identifizieren, sowie eine TSpec, um die Charakteristika des Datenstroms anzugeben. Reservierungsmechanismus Bei Eingang eine Reservierungsanforderung, übergibt der dort laufende RSVP-Prozess die Nachricht zunächst an die Admission Control, die überprüft, ob der Knoten über genügend Ressourcen verfügt, um die gewünschte QoS bereitzustellen, und an die Policy Control, die überprüft, ob der Benutzer das Recht hat, diese Reservierung durchzuführen. Wie schon die QoS-Parameter werden auch die Policy-Parameter von RSVP nur blind übertragen, jedoch nicht interpretiert [RFC 2750]. Verlaufen beide Checks positiv, so werden Packet Classifier und Packet Scheduler so eingestellt, dass sie die in der Flow Spec definierte QoS liefern: Der Packet Classifier bestimmt die Route des Paketes. Er wird entsprechend der Filter Spec eingestellt. Der Packet Scheduler hingegen bestimmt die Reihenfolge, in der die Datenpakete weitergeleitet werden und somit sind beide für die Realisierung der QoS verantwortlich. Siehe dazu Abbildung 2. Anschließend wird eine neue Resv-Nachricht an den nächsten Upstream-Knoten auf dem Pfad zum Sender weitergeleitet. Diese Reservierungsanforderung kann sich von der empfangenen unterscheiden, da in einem Knoten die Anforderungen mehrerer Empfänger zusammenlaufen können. In diesem Fall wird nur eine Anforderung weitergeleitet, die eine Kombination der Einzelanforderungen darstellt. Siehe dazu Abbildung 3.

5 2 QUALITY OF SERVICE UND INTSERV/RSVP 5 Abbildung 2: Komponenten eines RSVP-fähigen Hosts Abbildung 3: Multicast entlang der Pfade

6 6 Überblick über Sicherheitsprobleme 3 Security bei QoS und RSVP Definition 1 (Begriff-Definition) EH = End Host ist ein Endgerät, mittels dessen der Benutzer auf Netzdienste zugreift. In diesem Fall ist es z.b. ein Computer, an den für die Videokommunikation eine Videokamera angeschlossen ist. Definition 2 (Begriff-Definition) PDP = Policy Decision Point ist eine logische Einheit, welche für die Autorisierung bzw. Zulassung oder Ablehnung von Services bzw. Ressourcen zuständig ist. Der PDP befindet sich in einem PS = Policy Server, von dem es durchaus mehrere in einem Netzwerk geben kann (z.b. einen für die Ressourcenzuteilung und einen für die Session-Autorisierung). Definition 3 (Begriff-Definition) SIP = session initiation protocol ist ein session control protocol zum Aufbau und zur Pflege von Kommunikationssitzungen. Definition 4 (Begriff-Definition) SMS = Session Management Server ist eine logische Gruppierung von Elementen, welche dem Benutzer Session Management Services (z.b. für IP-Telefongespräche, Videokonferenzen oder Videoübertragungen) anbietet. 3.1 Motivation Angriffe auf QoS können einerseits auf den Kontrollpfad, also die Signalisierungsbotschaften, und andererseits auf den Datenpfad geschehen. Die hier beschriebenen Mechanismen der Autorisierung, Identifizierung und Authentifizierung wirken sich nur auf die Sicherheit des Signalisierungspfades aus. Dabei geht es um eine hohe und wirtschaftliche Verfügbarkeit für genau die rechtmäßigen Benutzer. Die ist von den Angriffen auf die Daten selbst zu unterscheiden (Manipulierung, Abhören, Fälschen). 3.2 Autorisierung, kryptographische Authentifizierung, Identifizierung Wenn für Anwendungen die Dienstgüte wichtig ist, dann muss die Bereitstellung dieses Dienstes auch berechnet und unberechtigte Benutzer von der Benutzung ausgeschlossen werden können. Andernfalls würde jeder Benutzer versuchen, soviel Bandbreite wie möglich für sich zu reservieren. Zunächst geht es um die Autorisierung der Sitzung für die Reservierung einer bestimmten Bandbreite. Ein Sender (enthält unter anderem einen RSVP client und einen SIP user agent), welcher Informationen an einen Empfänger senden will, muss sich zuerst mit einem SMS (session management server) über SIP (session initiation protocol) in Verbindung setzen und von diesem durch ein SIP INVITE ein session authorization policy element anfordern, das sogenannte AUTH SESSION-Objekt. Dabei authentifiziert sich der Sender beim SMS. Der SMS greift auf den SIP-PDP zu, der die Anforderung mit einer Datenbank (Policy-DB), in der alle Benutzer registriert sind, abgleicht und mittels der darin abgespeicherten Policies eine Entscheidung über die Autorisierung des Datenstromes durchführt. Als Rückgabe wird eine Nachricht an den SMS gesendet, die ein das zu benutzende Medium autorisierendes Token, das AUTH SESSION-Objekt, enthält. Darin enthalten sind die das Medium beschreibenden Charakteristiken wie z.b. maximale Bandbreite. Der SMS schickt dieses Token zusammen mit der Beschreibung des autorisierten Mediums mittels SIP an den EH zurück. Dieser fügt das erhaltene AUTH SESSION-Objekt innerhalb des POLICY DATA-Objekts in seine RSVP-PATH-message ein und schickt es auf den Weg zum Empfänger. Am Router, wird die admission control policybasiert durchgeführt. Dazu wird AUTH SESSION (enthält das autorisierende Token) überprüft und eine Entscheidung darüber gefällt, ob mit fortgefahren werden soll oder nicht. Mittels des AUTH SESSION-Objektes wird überprüft, ob der Anfordernde wirklich den zuvor

7 3 SECURITY BEI QOS UND RSVP 7 autorisierten Service angefordert hat, ob also die Anforderung gültig ist. Der PDP greift dazu auf eine Policy-Datenbank zu und richtet daraufhin gemäß der Policy einen state für den betreffenden Datenstrom ein. Wie bei RSVP üblich, wird die RSVP-PATH-message dann so von RSVP-Router zu RSVP-Router weiter zum Empfänger geschickt, der dann an den Sender auf dem gleichen Weg eine Reservierungsnachricht zurückschickt. Nach erfolgter Reservierung an jedem Knoten (wiederum Policybasiert) wird der Aufbau der Verbindung bestätigt und die eigentliche Datenübertragung kann beginnen. Um die Authentizität des authorisierden Tokens zu gewährleisten, sollte eine digitale Signatur im AUTH SESSION Objekt eingeschlossen werden. Es ist hier noch einmal herauszustellen, dass die einzigen Komponenten, die das AUTH SESSION-Objekt wirklich inhaltlich interpretieren können müssen, die beiden PDPs sind. Um die Integrität eines Paketes zu gewährleisten wird die INTEGRITY-Option eines jeden POLICY DATA-Objektes wird mit einer einmalig verwendbaren Sequenznummer versehen, die Wiederbenutzung erkennen und verhindern lässt. Daraus wird dann mittels eines geheimen Authentifizierungsschlüssels und eines keyed-hash Algorithmus eine Art Prüfsumme berechnet, die ebenfalls in INTEGRITY-Option eingetragen und darin übermittelt wird. Vertraulichkeit wird dadurch allerdings nicht erreicht, da keine Verschlüsselung geschieht, die Botschaften also nach wie vor im Klartext transportiert werden. Um die Identität des Absenders sicherzustellen (sichere Identifizierung des Senders), kann man innerhalb des POLICY DATA-Objektes ein authentication policy element (AUTH DATA) übermitteln, in dem entweder die User login ID im Klartext/Unicode, ein Kerberos Session Ticket oder ein digitales Zertifikat in Verbindung mit einer digitalen Signatur (digitales Zertifikat), als Benutzer-credential angegeben ist. Ein Kerberos Session Ticket ist ein von einer dritten Instanz vergebene eindeutige Indentifizierung einer Sitzung. Ein digitales Zertifikat, vergleichbar mit einer Unterschrift, wird von einer unabhängigen Instanz ausgestellt und identifiziert eine Person/Gesellschaft. 3.3 Datensicherheit Ein Ansatz um bei RSVP die Daten sicher zu übertragen ist IPSec. IPSec ist eine Sammlung von Sicherheitsmechanismen, welche kryptographie-basierte Sicherheit für Ipv4 und Ipv6 verfügbar machen. IPSec kann benutzt werden, um einen oder mehrere sichere Pfade zwischen zwei Hosts herzustellen. In Zusammenhang mit IPSec und RSVP kommt es darauf an, das die in der Security Policy Database gespeicherten lokalen Policies die lokalen Sicherheitsanforderungen korrekt widerspiegeln und dass diese Policies keine Konflikte mit lokalen Policies an einem anderen Netzwerkknoten ergeben. Hierzu gibt es zwei Ansätze: den Celestial-System-Ansatz, bei dem versucht wird aus den einzelnen lokalen Policies eine konfliktfreie end-to-end-anwendung abzuleiten, und den Ansatz eines zentralen Policy Management Systems. Im weiteren wird das Celestial System näher betrachtet. 3.4 Celestial System Bei diesem Ansatz geht es darum, aus den lokalen Policies einen einheitlichen Sicherheitsanwendungsplan für die end-to-end-sicherheit zu erstellen. Will man diese anwenden, so benötigt man Informationen über Anforderungs- und Implementierungspolicies sowie den Pfad für den Datenstrom.

8 8 Überblick über Sicherheitsprobleme Für ein intra-domain-management könnte man diese von einem zentralen Policy Server der Domäne erhalten. Für eine inter-domain- Kommunikation ist dies aber nicht möglich. Um auch hier die benötigten Informationen zu erlangen, benötigt man ein inter-domain-securitymanagement-system wie das Celestial System. Dieses System ermöglicht einen skalierbaren und verlässlichen end-zu-end-sicherheits-dienst, welcher auf verschiedenen im Netzwerk verteilten Sicherheitsmechanismen aufbaut. Dazu ist in den Netzwerkkomponenten ein Security Management Agent (SMA) installiert, der weitreichende Managementkompetenzen hat, die die Konfiguration und Rekonfiguration von Sicherheitsmechansismen auf allen Layern betreffen. Mittels des Inter-Domain-SMA Coordination Protocols (ISCP) wird der Transport der Informationen zu Sicherheitsverhandlungen und anschließend zum Sicherheitsmanagement/Reservierung zwischen allen SMA-fähigen Komponenten durchgeführt. Dies funktioniert wie folgt in 2 Phasen: In der discovery phase werden vom Sender (dessen SMA) ausgehend zum Empfänger hin der Pfad markiert, die Sicherheitsanforderungen der Applikation mitgeteilt und die Sicherheitsfähigkeiten bzw. Policies der einzelnen Netzknoten gesammelt, sofern sie die Anforderung mit ihren Fähigkeiten/Policies unterstützen, und an den Empfänger übertragen. Danach ermittelt der SMA, welcher sich im Empfänger befindet, aus den gesammelten Policies mit Hilfe von verschiedenen Algorithmen einen optimalen Sicherheitskonfigurationsplan für alle Knoten. In der zweiten Phase, der Reservierungsphase (Reservierungsbotschaft zurück zum Sender), verteilt der SMA die für die Umsetzung des Planes notwendigen Informationen an die SMAs in den an der Umsetzung beteiligten Netzwerkkomponenten. Diese SMAs setzen die ihnen vorgegebenen Einstellungen um. Das bedeutet, sie stoßen den Einrichtungsprozess für die Security Associations (SA Verwendung von Sicherheitsalgorithmen, Schlüsselsätze zur Ver /Entschlüsselung und zur Unterschrift/Verifizierung,...) an. Diese sind ja die Basis für die Bereitstellung eines sicheren Dienstes zwischen zwei Parteien. Gleichzeitig senden die Knoten eine Bestätigungsmeldung zum Sender, dass ihre Sicherheitsbeziehungen nun funktionsfähig sind. Wenn nun sowohl die RESV-Nachricht als auch die Bestätigungsmeldungen beim Sender angekommen sind, schickt dieser wiederum eine Bestätigungsmeldung an den Empfänger, dass die end-to-end-sicherheitskette steht. Der Empfänger bestätigt diese Nachricht noch einmal und gibt damit sein OK für das Versenden des eigentlichen Datenstromes. Diesem Datenstrom wird dann die angeforderte Sicherheit zuteil. Von Zeit zu Zeit werden weiterhin Discovery-messages vom Sender zum Empfänger gesendet, die upgedatete Pfad- und Policy- Informationen sowie Informationen über ein mögliches Eindringen ins Netz enthalten. Wird eine Änderung des Verhaltens der SMAs oder ein neuer Pfad nötig, so werden neue Reservierungsnachrichten versendet. Der Verbindungsabbau geschieht durch den Sender, der entlang des bisherigen Übertragungspfades eine Verbindungsabbau-Nachricht an den Empfänger sendet. Dadurch werden alle states und alle anderen mit dieser Verbindung in Zusammenhang stehende Informationen in den SMAs gelöscht. Wie bereits beschrieben, verwendet dieses System ISCP als Transportprotokoll. Das Policy Modul im SMA überprüft mittels seiner Policies, ob der angeforderte Service vom Knoten überhaupt erlaubt ist. Die Security Mapping- und Configuration Module bestimmen den optimalen Sicherheitskonfigurationsplan und übergeben diese Informationen an ISCP zur Kommunikation. Schon durch die Art des Aufbaus des sicheren Kommunikationspfades wird deutlich, dass ISCP gewisse Ähnlichkeiten mit RSVP aufweist. Es ist nicht notwendig, dass alle Router auf dem Weg SMA-fähig sind, es reicht, wenn die Netzrandkomponenten der Netze, die unterschiedliche Sicherheitsmechanismen unterstützen, wie ER, Security Gateways oder Firewalls diese Funktion beinhalten. Die nichtunterstützenden normalen Router können außer acht gelassen werden, da sie von den ISCP-Nachrichten ganz normal wie von den IP-paketen passiert werden. Natürlich müssen auch die ISCP-messages gesichert werden. Das wird bei der discovery message mittels des public key-verfahrens gemacht, um einen Schutz auch gegen insider attacks herzustellen.

9 4 ZUSAMMENFASSUNG 9 4 Zusammenfassung RSVP weist einige grundlegende Schwächen auf: Vorallem ist zu bemerken, dass es ein kompliziertes Modell ist. Desweiteren ist es nur in geringem Maße skalierbar und erfordert eine Reservierung von Ressourcen für jeden einzelnen Datenfluss. Dazu kommt noch ein verstärktes auftreten von Kontrollnachrichten, die einen großen overhead darstellen und eine Strapazierung der Router und Bandbreite bedeuten.

10 10 Überblick über Sicherheitsprobleme Abbildungsverzeichnis 1 Schematischer Ablauf einer Reservierung mit RSVP Komponenten eines RSVP-fähigen Hosts Multicast entlang der Pfade

11 LITERATUR 11 Literatur [RFC 2205] Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification ftp://ftp.isi.edu/in-notes/rfc2205.txt [RFC 2210] The Use of RSVP with IETF Integrated Services ftp://ftp.isi.edu/innotes/rfc2210.txt [RFC 2211] Specification of the Controlled-Load Network Element Service ftp://ftp.isi.edu/in-notes/rfc2211.txt [RFC 2212] Specification of Guaranteed Quality of Service ftp://ftp.isi.edu/innotes/rfc2212.txt [RFC 2215] General Characterization Parameters for Integrated Service Network Elements ftp://ftp.isi.edu/in-notes/rfc2215.txt [HAMER] Session setup with media authorization