Einleitung. IP Security Policy Oliver Spata

Transkript

1 Einleitung In Zeiten ständig wachsender und komplexer werdender Computer-Vernetzung stellt sich auch die Frage nach einer entsprechenden Netzwerk-Sicherheit. Die Frage nach der Wahl der Sicherheitsmittel geht einher mit der Frage, wann diese Mittel worauf angewendet werden sollen. Es sind also entsprechende Regelungen zur Festlegung der Netzwerksicherheit notwendig. Dabei gibt es verschiedenste Anwendungsbeispiele: Für Firmen, die über das Internet e- commerce betreiben ist Sicherheit ebenso wichtig wie für solche Firmen, die sensible austauschen wollen, ob über eigene interne Netze oder im Austausch mit Geschäftspartnern über öffentliche (und damit prinzipiell unsichere) Netze. Ein weiteres Beispiel ist ein Mitarbeiter, der sich von seinem Notebook über remote login auf ein Firmennetz einwählen möchte. Ein klassisches Mittel zur Sicherung von Netzen ist eine Firewall, allerdings zeigen Statistiken, dass heutzutage mehr Sicherheitsverstöße von innerhalb eines lokalen Netzwerkes begangen werden als von außerhalb. Daher kann es notwendig werden, möglichst direkt am Ursprung, also beim Versender zu sichern, was entsprechende Protokolle notwendig macht. In heutigen Netzwerken ist TCP/IP vorherrschend, und diese Protokolle besitzen von sich aus keine besonderen Schutzmechanismen. Die Angriffsmöglichkeiten sind vielfältig: - einfaches Abhören, gerne auch von Passwörtern (Sniffing bzw. Password- Snooping) - unerlaubt Zugang zu geschützten Netzen verschaffen mit Hilfe von gefälschten Identitäten (IP-Maskierung bzw. IP-Spoofing) - Einfügen eigener Pakete in eine bestehende Verbindung (Hijacking) - Missbräuchliche ICMP-Kommandos: Destination Unreachable (bewirkt Abbruch der Verbindung), Fragmentation Needed (Erhöhung der Netzlast), Source Quench (starke Verbindungs-Verzögerung), Redirect (Umleiten von Verbindungen) - Erzwingung eines gewissen Kommunikationsweges, z.b. über den Angreifer selbst (Source Routing) - Überlasten eines Rechners durch übermäßig viele Anfragen (Denial of Service, Flooding) Für Sicherheitslösungen gibt es drei Hauptziele, die es zu erreichen gilt: - Vertraulichkeit der, damit Dritte nicht mitlesen können. Dies wird durch Verschlüsselung erreicht. - integrität, also die Sicherheit vor Veränderung der übertragenen auf dem Übertragungsweg. Hierfür kann man z.b. Checksummen oder Hash- Verfahren einsetzen. - Authentifizierung des Kommunikationspartners mit Hilfe von Signaturen Zur Erhöhung der Sicherheit gibt es verschiedene Lösungen, die auf unterschiedlichen Ebenen des Netzwerk-Schichtenmodells arbeiten: - Es gibt verschiedene Ansätze, die auf der Anwendungsebene und damit oberhalb von TCP agieren: Zur sicheren Mailübertragung in Form von Pretty Good Privacy (PGP), Privacy Enhanced Mail (PEM) oder S/MIME als Erweiterung von Multipurpose Internet Mail Extensions (MIME), als HTTP-kompatibler Standard mit zusätzlichen Sicherheitsfunktionen SHTTP, oder als telnet-ersatz Secure Shell 1

2 (SSH). Diese Verfahren sind nur nutzbar, wenn sie von der gebrauchten Anwendung auch unterstützt werden. - Ebenfalls oberhalb der Transport-, aber gleichzeitig unterhalb der Anwendungsebene arbeitet SSL (Secure Sockets Layer), welches damit einen anderen Ansatz verfolgt als die vorherigen Methoden. SSL wurde ursprünglich von Netscape entwickelt und später als TLS (Transport Layer Security) standardisiert. TLS arbeitet in beide Richtungen transparent, d.h. für Anwendungen wirkt es wie das Transportprotokoll und für das Protokoll wie eine Anwendung. - Auch auf der IP-Ebene und damit unterhalb von TCP gibt es Sicherheitsansätze: Hier sei zunächst das Simple Key Management for Internet Protocols (SKIP) genannt, welches ein von Sun entwickeltes einfaches Verfahren zur Verschlüsselung von IP-Paketen darstellt. Im folgenden soll aber vor allem auf das IP Security Protocol (IPSec) eingegangen werden. Anwendungsebene PGP, SHTTP, SSH, HTTP, FTP,... SSL/TLS HTTP, FTP, SMTP,... Transportebene TCP TCP TCP IP-Ebene IP IP SKIP, IPSec Innerhalb der Anwendungsebene Oberhalb der Transportebene Innerhalb der IP-Ebene Abb. 1: Vergleich der unterschiedlichen Sicherheitsansätze IPSec Im November 1998 wurde von der IETF durch den RFC 2401 IPSec als Standard festgelegt. Dass es auf der IP-Ebene arbeitet ist insofern von Vorteil, weil es dadurch ohne Umstellung der eingesetzten Anwendungen eingesetzt werden kann. Das bedeutet, bestehende Software kann weiterhin genutzt werden, Personal muss nicht umgeschult werden usw., was auch ein wichtiger wirtschaftlicher Grund ist. IPSec ist z.b. die Grundlage für den Aufbau von virtuellen privaten Netzen (VPN). Ursprünglich wurde IPSec für IPv6 entwickelt, dann aber wegen der Verzögerungen bei dessen Einführung auch für IPv4 umgesetzt. IPSec wird von Hosts an den Endpunkten einer Verbindung ebenso eingesetzt wie von Security-Gateways an Teilstrecken entlang einer Verbindung und schützt den IP-Verkehr von und zu diesen Knoten. Hierfür gibt es zwei Arbeitsweisen von IPSec, den Transport- und den Tunnelmodus. Der Transportmodus wird zwischen zwei Hosts eingesetzt, während man den Tunnelmodus zwischen Host und Gateway oder aber zwischen zwei Gateways verwendet. 2

3 Der Unterschied besteht darin, dass im Transportmodus das vorhandene IP-Paket gesichert wird, während im Tunnelmodus ein neues, gesichertes IP-Paket erzeugt wird, welches das alte Paket als Nutzdaten enthält (das alte Paket wird somit in ein neues eingepackt). Dieses neue Paket bekommt neue Absender- und Zieladressen, nämlich die Adressen von Start- und Zielpunkt des neu eingerichteten Tunnels. Am Ende des Sicherheitstunnels wird das ursprüngliche Paket wieder entpackt und an den anfänglichen Empfänger weiterversendet. Wer also eine Leitung abhört, über die getunnelte IPSec-Pakete laufen, kann keine Rückschlüsse mehr über die ursprüngliche Kommunikation ziehen. IPSec bietet zwei Sicherungsarten an, den Authentication Header (AH) und die Encapsulated Security Payload (ESP). Durch AH wird die Unversehrtheit der per Hashing und die Echtheit des Absenders sichergestellt, jedoch keine verschlüsselung benutzt. Will man auch diese, so verwendet man ESP. Im Transportmodus wird bei beiden Verfahren hinter dem ursprünglichen IP-Header und vor den Nutzdaten des Paketes ein zusätzlicher Sicherungsheader eingefügt. Im Falle von ESP folgt nach den Nutzdaten noch ein ESP-trailer (daher die Bezeichnung encapsulated). Im Tunnelmodus werden die Sicherungsheader hinter den neuen IP-Header und vor das alte, verpackte Paket eingefügt. Der Tunnelmodus kann auch mehrfach in Folge genutzt werden (vernestete Tunnel), dementsprechend wird das bestehende Paket einfach immer wieder neu verpackt. AH sichert das komplette Paket inklusive des vorangehenden IP-Headers (mit Ausnahme der sich während der Übertragung verändernden Headereinträge) und seines eigenen Headers. ESP hingegen verschlüsselt nur die Nutzdaten, also damit ausschließlich das Paket des eingesetzten Transportprotokolls (meist TCP). Es ist auch möglich beide Sicherungsarten zugleich einzusetzen, dann wird der AH-Header zuletzt ermittelt und vor den ESP-Header gesetzt, da er auch diesen mitsichern muss. IP-Header IP-Header AH Header authentifiziert AH im Transportmodus IP-Header IP-Header ESP Header ESP Trailer verschlüsselt ESP im Transportmodus Abb.2: IPSec im Transportmodus 3

4 IP-Header Neuer Header AH Header Alter Header authentifiziert AH im Tunnelmodus IP-Header Neuer Header ESP Header Alter Header ESP Trailer verschlüsselt ESP im Tunnelmodus Abb.3: IPSec im Tunnelmodus Bevor IPSec genutzt werden kann, muss erst zwischen den Verbindungspartnern eine Einigung über die Einzelheiten der sicheren Verbindung erzielt werden. Hierfür wird das Internet Key Exchange (IKE) Protokoll verwendet. Es setzt sich zusammen aus dem Internet Security Association and Key Management Protocol (ISAKMP), welches den Rahmen für Authentifizierung und Schlüsselaustausch setzt ohne sie wirklich festzulegen, und Oakley, welches die Verfahren genauer beschreibt. IKE ist dafür zuständig, dass auf einem IPSec verwendenden Rechner die benötigten Security Associations (SA) eingerichtet werden. Eine SA ist eine Sammlung von Schlüsseln und Regeln und definiert für einen Rechner, wie mit ankommenden und ausgehenden IPSec- Paketen umgegangen werden soll. Für jede neue Verbindung mit einem anderen Kommunikationspartner müssen neue, passende SA eingerichtet werden. Der Verbindungsaufbau mittels IKE verläuft in zwei Phasen: In Phase 1 wird zunächst ein SA für IKE selber angelegt. Die IKE-SA ist bidirektional, das heißt werden in beide Richtungen verschickt. Die Phase 1 wird entweder im Main oder im Agressive Mode ausgeführt, wobei der Unterschied darin liegt, dass im Agressive Mode schneller eine Einigung erzielt wird, weil mehr Parameter gleichzeitig ausgetauscht werden. IKE handelt folgende Parameter aus: - Art der Verschlüsselung, z.b. Data Encryption Standard (DES) - Wahl des Hash-Verfahrens, normalerweise entweder Message Digest 5 (MD5) oder SHA (Secure Hash Algorithm) - Wahl der Authentifizierungsmethode entweder über pre-shared keys (Schlüssel, die vorher abseits des Internets verteilt wurden), Digital Signature Standard (DSS) 4

5 oder public keys mit RSA (benannt nach den Entwicklern Rivest, Shamir, Adleman) Nachdem ein IKE-SA eingerichtet wurde, erstellt IKE die SAs für IPSec selber. Diese sind unidirektional, es müssen also für eingehende und herausgehende eigene SAs eingerichtet werden, außerdem jeweils eigene für AH und ESP. Für eine bidirektionale Verbindung zwischen zwei Knoten, die sowohl AH als auch ESP benutzt, müssen damit auf beiden Seiten vier IPSec-SA eingerichtet werden. In einer IPSec-SA sind alle für IPSec relevanten Parameter enthalten, also die Parameter für die AH- bzw. ESP-Sicherung (Verschlüsselungsart, Hash-Methode etc. ähnlich zu IKE), aber auch Adressierung oder die Lebensdauer der Verbindung (in Übertragungszeit oder Menge der übertragenen ) und die Zeitintervalle, in denen Keepalive durchgeführt werden muss. Sämtliche SAs eines Systems werden in der Security Association Database (SADB) abgespeichert. Dabei wird ein SA-Eintrag eindeutig durch den Security Parameter Index (SPI) festgelegt, der in jedem IPSec-Header (ob AH oder ESP) eingetragen ist, sowie durch die IP-Zieladresse sowie die eingesetzte Sicherungsart (AH oder ESP). Wenn also beispielsweise ein Host ein IPSec-Paket empfängt, sucht er anhand des SPI und der Zieladresse des Pakets die passende SA aus der SADB und verarbeitet das Paket so, wie es die Parameter dort vorschreiben. Bevor die Gültigkeit einer SA abgelaufen ist, sollte sie natürlich rechtzeitig erneuert werden. Die SA legen somit die Art und Weise fest, wie mit einem Paket umgegangen wird, auf das IPSec angewendet werden soll. Doch was passiert, falls ein ungesichertes IP-Paket eintrifft oder es für ein abzuschickendes Paket gar keine entsprechende SA gibt? Hierfür muss es auf jedem System noch eine allgemeinere Sammlung von Regeln geben, und dazu gibt es die Security Policy Database (SPD). In ihr werden policies, also Bedingungen und dazugehörige Aktionen zum Umgang mit ankommenden oder herausgehenden Paketen festgelegt. Auf diese Weise lassen sich Regelungen festlegen, die spezielle Quell- oder Zieladressen betreffen, spezielle Transportprotokolle oder auch gewisse Ports. In einer SPD lassen sich drei grundlegende Aktionen festlegen, die bei Erfüllung einer Bedingung ausgeführt werden sollen: - Discard: Das fragliche IP-Paket wird verworfen. - Bypass: Das Paket wird ohne Anwendung von IPSec weitergeleitet. - Apply: Das Paket soll mittels IPSec behandelt werden und wird an die entsprechende Security Association verwiesen, in der die genauere Vorgehensweise spezifiziert ist. Auf diese Weise kann man z.b. erreichen, dass in ein gewisses Subnetz nur IPSec-geschützte für genau festgelegte Ports zugelassen werden, und alle sonstigen Pakete werden vor dem Versenden in dieses Subnetz verworfen. Sobald ein System IPSec einsetzt, muss also jedes dort ankommende oder abgehende Paket anhand der SPD überprüft werden. Mittels Policy Management fügt man neue policies hinzu oder ändert bzw. löscht bereits bestehende. 5

6 IP Security Policy Mit Hilfe von IKE lassen sich die benötigten Informationen zur Erstellung einer Verbindung zwischen zwei Endpunkten einer Security Association austauschen. Entlang des Kommunikationsweges kann es aber Knotenpunkte wie Security-Gateways oder Router mit Filtern geben, die gewisse einschränkende Policies durchsetzen. Es wäre also für die Endpunkte einer Verbindung nötig, Informationen über diese Policy Enforcement Points (PEP) zu gewinnen und mit ihnen über Zugangsmöglichkeiten zu verhandeln. Allgemein bedeutet dies den Bedarf an Mitteln zur Darstellung von geltenden Policies auf einem Knoten, zur Feststellung derselben auf einem entfernten Knoten, zum Policy-Austausch zwischen solchen Knoten und zu deren Verwaltung, soweit es sich um Policies handelt, die den Zugang zu Netzwerkressourcen kontrollieren. Daher hat sich die IP security policy working group (ipsp WG) der Internet Engineering Task Force (IETF) gebildet, um entsprechende Lösungen auszuarbeiten. Zielsetzungen der Working Group sind: - Spezifizierung eines plattform-unabhängigen Informationsmodells zur Darstellung von IP Security Policies, nach Möglichkeit soll das Modell sich von dem existierenden Modell der Policy Framework Working Group ableiten. - Entwicklung oder Anpassung einer erweiterbaren Sprache zur Policy- Spezifizierung. Die Sprache muss vor allem die benötigten Mechanismen von IPSec unterstützen, soll aber auch auf Policies anderer Protokolle anwendbar sein. - Richtlinien zur Unterstützung von IPSec Policies mit existierenden Policy Distribution-Protokollen wie Lightweight Directory Access Protocol (LDAP), Common Object Policy Service (COPS) und Simple Network Management Protocol (SNMP) - Anpassung oder Entwicklung eines Protokolls für den Austausch und die Verhandlung von Policies. Das Protokoll muss in der Lage sein, Policy Server festzustellen, Security Policies zu verteilen und auszuhandeln und Policy- Konflikte innerhalb oder zwischen Domänen zu lösen. Das Protokoll muss unabhängig vom eingesetzten Sicherheitsprotokoll und der Schlüsselverwaltung sein. - Vereinbarung einer festen Terminologie für Dokumente im Bereich des Policybasierten Netzwerkmanagements Das erste Internet-Draft veröffentlichte die ipsp-wg im Januar 2000, seitdem folgten verschiedene weitere. Request For Comments (RFC) gibt es bislang noch keine, die Standardisierungen sind also noch in Arbeit. Im folgenden sollen auf das geplante Informationsmodell und das Policy-Protokoll näher eingegangen werden. 6

7 IPSec Configuration Policy Model Es existiert ein Internet-Draft mit obigem Titel (mittlerweile in der Version 04 vom November 2001), welches ein objekt-orientiertes Modell zur Repräsentation von IPSec Policy beschreibt. Es basiert auf dem Policy Core Information Model (PCIM), welches im RFC 3060 von der Policy Framework WG standardisiert wurde, und den dazugehörenden Extensions (PCIMe), welche bislang nur als Internet-Draft existieren. In dem Modell werden die Objekte ebenso wie die meisten Verbindungen zwischen ihnen durch Klassen dargestellt. Nähere Informationen über die einzelnen Objekte (z.b. Angaben über Adressen, Lebensdauer etc.) lassen sich über die Properties dieser Klassen angeben. Pfeile symbolisieren Vererbung, wobei der Pfeil zur Ursprungsklasse zeigt. IPsecPolicyGroup RuleForIKENegotiation RuleForIPsecNegotiation PolicyTimePeriodCondition PolicyRuleValidityPeriod SAConditionInRule PolicyActionInSARule SACondition SARule PolicyAction IKERule IPsecRule Abb.4: Grundsätzlicher Aufbau: Die IPSec Policy-Klassen In dem Modell repräsentiert IPSecPolicyGroup die Menge von Policies, die auf einem Interface verwendet werden. Zentraler Punkt ist hierbei die SARule-Klasse, welche lediglich eine Basisklasse für IKERule und IPSecRule ist (sie darf nicht instanziert werden). Durch sie wird ein einheitlicher Verbindungspunkt für die Bedingungen und die Aktionen definiert, die zur Regel gehören. IKERule und IPSecRule leiten sich davon ab und stellen die Verbindung zwischen den Condition- und den Action-Klassen her. Hierbei steht IKERule für Phase 1 der IKE- Verhandlungen und IPSecRule respektive für Phase 2. Die beiden Regeln werden durch die Verbindungen RuleForIKENegotiation bzw. RuleForIPsecNegotiation in die IPSecPolicyGroup hinzugefügt. PolicyTimePeriodCondition entstammt dem PCIM und repräsentiert die Zeiten, zu denen eine Regel gültig ist. Befindet sich das System momentan außerhalb einer Gültigkeitsphase, gilt die Regel nicht. Verbunden wird eine Regel über SAConditionInRule mit einer Bedingung, repräsentiert durch SACondition (Einzelheiten weiter unten), und über PolicyActionInSARule mit PolicyAction, die ebenfalls aus dem PCIM entstammt. Im Grunde ist PolicyAction lediglich ein Platzhalter für die SAAction-Klasse (die weiter unten folgt). Sie wird an dieser Stelle 7

8 verwendet, weil sie auch durch einen Verbund von mehreren Aktionen ersetzt werden kann (welches sich dann CompoundPolicyAction nennt), somit können also auch mehrere Aktionen hintereinander ausgeführt werden. Diese Verbundklasse stammt wiederum aus der PCIM. Bedingungen und Filter SACondition FilterOfSACondition FilterList EntriesInFilterList FilterEntryBase IPHeaderFilter CredentialFilterEntry IPSOFilterEntry PeerIDPayloadFilterEntry Abb.5: Bedingungen- und Filterklassen Eine SACondition erhält über die FilterOfSACondition-Verbindung eine Liste von Filtern, die wiederum aus einzelnen Filter-Einträgen besteht. Diese Filter-Einträge definieren genau den Bedingungsteil einer Regel. Die FilterEntryBase-Klasse entstammt dem Network Model der Distributed Management Task Force (DMTF), von ihr leiten sich vier Filterarten ab: - Der IPHeaderFilter hat ebenfalls seinen Ursprung in dem DMTF Network Model und definiert einen klassischen IP-Paketfilter, der auf Informationen wie Quellund Zieladresse oder Ports arbeitet. Diese Informationen werden in den Properties der Klasse abgelegt. - IPSOFilterEntry wird für Übertragungen benutzt, die die IP Security Options Header verwenden (ClassificationLevel und ProtectionAuthority). Diese Art von Filter wird verwendet, um unterschiedliche IPSec-Sicherheitslevel entsprechend der IPSO-Klassifikation der Übertragung auszuwählen. - CredentialFilterEntry wird genutzt, um Vergleiche basierend auf Credentials wie X.509 Zertifikate oder Kerberos-Tickets (unter Windows 2000) durchzuführen - PeerIDPayloadFilterEntry definiert Filter, um für IKERules gewisse ID payload Werte wie z.b. in der Form *@company.com mit der ID payload von IKE- vergleichen zu können. 8

9 Aktionen SAAction SAStaticAction SANegotiationAction IPsecBypassAction IPsecAction IKEAction IPsecDiscardAction IPsecTransportAction IKERejectAction IPsecTunnelAction PeerGateway PeerGatewayForTunnel Abb.6: Aktionsklassen SAAction (abgeleitet von der PCIM-Klasse Policy Action) steht ganz allgemein für eine Aktion, die infolge einer erfüllten Bedingung ausgeführt werden soll und ist die Oberklasse, von der sich zwei grundlegende Aktionsarten ableiten, SAStaticAction und SANegotiationAction. Diese zwei Arten teilen die Aktionen in solche auf, die sofort ausgeführt werden können, und solche, für die noch Verhandlungen notwendig sind. Für beide Arten kann man durch eine Klassen-Property festlegen, ob bei ausgeführten Aktionen Log-Nachrichten erstellt werden sollen. Von SAStaticAction leiten sich die IPsecBypassAction (erlaubt Weiterleitung eines Paketes ohne Sicherung), IPsecDiscardAction (Paket wird verworfen) und IKERejectAction (verhindert eine IKE-Verhandlung mit einem Knoten, wird zur Abwehr gewisser Denial of Service-Attacken verwendet). SANegotiationAction ist die Basisklasse für Aktionen, die in einer IKE-Verhandlung resultieren. IKEAction leitet sich von ihr ab und beinhaltet die nötigen Parameter für eine IKE Phase 1-Verhandlung, z.b. wann der Refresh für eine SA stattfindet oder welcher Modus (Main/Aggressive) verwendet wird. Von IPsecAction wiederum leiten sich IPsecTransportund IPsecTunnelAction ab, sie enthalten die Parameter für eine IKE Phase 2-Verhandlung. Die für die Einrichtung eines Tunnels benötigten Informationen über das Security Gateway (Adresse oder String für den Namen) werden in der PeerGateway-Klasse gespeichert, welche mit IPsecTunnelAction verbunden ist. 9

10 Dies stellt lediglich einen Teil des Policy Models dar. Es gibt z.b. noch eine Reihe von Proposal-Klassen, welche genauer die Verhandlungen bei Verbindungsaufnahme beschreiben. Aber an dieser Stelle soll nur ein Überblick über dieses Modell gewährt werden. Das IPsec Policy Protokoll Ein Vorteil von IPSec sind die verschiedenen Sicherungsmechanismen, die angeboten werden und entsprechend den Sicherheitsanforderungen ausgewählt werden können, außerdem kann IPSec sowohl an den Endpunkten wie auch an Gateways entlang einer Verbindung eingesetzt werden. Durch das Wachstum des Internet werden separate Netze miteinander verbunden, die eine eigene Verwaltung besitzen und Security Policies für gewünschten oder nicht gewünschten Netzwerkverkehr definieren. An Firewalls und Gateways werden diese Policies dann durchgesetzt. Wenn zwei Hosts über die Grenzen von Netzwerken mit unterschiedlichsten Policies hinweg kommunizieren wollen, dann muss eine Verbindung eingerichtet werden, die nicht nur die Policies der beiden Endpunkte berücksichtigt, sondern die von allen Beteiligten. Aufgabe des IPSec Policy Protokolls ist die Feststellung und Verwaltung von Policies auf einem Knoten sowie die Aushandlung und Verteilung zwischen mehreren Knoten. Bei heterogenen Netzen stellen sich hier verschiedene Probleme: Bei den Knoten kann es sich um Einzelrechner, Gateways, Firewalls oder Server handeln. Auch wenn für zwei Hosts unterschiedliche Security Policies gelten und zunächst nichts über die des jeweils anderen bekannt ist, sollte nach Möglichkeit eine Verbindung zustande kommen. Falls auf einem Rechner Policies nicht über die IPSP-Sprache spezifiziert werden, sondern z.b. auf eine spezielle vom Hersteller definierte Weise, dann müssen die geltenden Policies, soweit sie die Kommunikation betreffen, IPSP-konform übersetzt werden. Bei Netzwerken ab einer bestimmten Größe ist es üblich, dass die Administration von verschiedenen Stellen aus geleistet wird. IPSP muss zur Vermeidung von Konflikten Mechanismen haben, um ausgewählte Stellen mit bestimmten Arten von Autorität auszustatten. Die IETF hat eine Reihe von Anforderungen aufgestellt, die das IPsec Policy Protokoll erfüllen muss: - Keine Änderungen an bestehenden Standards wie AH, ESP und IKE erforderlich. - Ein wohldefiniertes Policy Model zur eindeutigen Darstellung von Policies. - Ein Gateway Discovery-Mechanismus, der von jedem Host oder Gateway ausgeführt werden kann, um Informationen über IPSec-Gateways zu gewinnen, die zwischen Start- und Zielknoten einer gewünschten Verbindung liegen. - Eine einheitliche Sprache zur Beschreibung von IPSP, die von Hosts benötigt wird, um ihre geltenden Policies ausdrücken zu können. Die Sprache ist die Grundlage für die Feststellung von Policies auf anderen Systemen und deren Prüfung auf Verträglichkeit mit den eigenen Policies. - Remote Management von Policies auf entfernten Systemen, möglicherweise auch von mehr als einer administrativen Stelle aus. - Ein Mechanismus zur Policy Discovery, mit dem zwei Hosts feststellen können, welche möglichen Security Associations zwischen ihnen möglich sind. Dies ist vor allem wichtig für Hosts, die unterschiedlichen Domänen angehören und daher 10

11 unter Umständen keinerlei Informationen über einander haben. Daran anschließend soll eine entsprechende SA auf den Hosts eingerichtet werden. - Eine Prüfung auf Verträglichkeit der ermittelten SA mit den lokalen Policies, damit ein Fehler während der Ermittlung nicht die lokale Sicherheit verletzt. Eine Veröffentlichung mit genaueren Angaben das IPSP Protokoll betreffend bleibt noch abzuwarten. Es gibt allerdings schon einen Ansatz, der über den Umgang mit IPsec Policy hinausgeht, welcher im folgenden erläutert wird. Multidimensional Security Management and Enforcement Seit kurzer Zeit ist ein Internet Draft über die Anforderungen und den Aufbau des Multidimensional Security Management and Enforcement (MSME) Systems veröffentlicht. Im Zusammenhang mit MSME versteht man unter einer Koalition eine Gruppierung von Partnern (z.b. Firmen) mit eigener Administration, die sich aufgrund einer bestimmten Aufgabe zusammengeschlossen haben. Der Zweck des Systems ist es, einer Koalition zu ermöglichen, sich auf für alle Seiten akzeptable Policies zu einigen, damit Kommunikation zwischen den Partnern ermöglicht wird. Ziel ist es also, durch Austausch und Verhandlungen der Partner eine Lösung zu ermitteln, aber gleichzeitig soll jedes Mitglied der Koalition seine eigenen Policies aufrecht erhalten können. Policy Management in einer Koalition ist eine deutlich komplexere Aufgabe als für zwei Hosts an den Endpunkten einer Verbindung. In einer dynamischen Koalition können neue Mitglieder hinzukommen oder bestehende ausscheiden, und zwischen den Partnern muss nicht unbedingt ein gewisses Maß an Vertrauen bestehen. Außerdem benutzen die verschiedenen Mitglieder vermutlich sehr unterschiedliche Mittel wie z.b. Sicherheitsprotokolle, um ihre Regelungen durchzusetzen. Trotz dieser Schwierigkeiten ist es notwendig zu bestimmen, ob die Koalition ihre Aufgabe erfüllen kann. Dafür ist es erforderlich, dass Policies zwischen den Teilnehmern ausgetauscht werden können, damit danach eine annehmbare Lösung für alle ermittelt wird. Können auf einer Seite die Bedingungen für eine Lösung nicht erfüllt werden, so muss dies der entsprechenden Administration gemeldet werden. Darüber hinaus muss es auch eine Möglichkeit der Kontrolle darüber geben, ob alle Beteiligten auch tatsächlich die ausgehandelten Policies bei sich durchsetzen. Allerdings wird die Möglichkeit der Überwachung durch die Bereitschaft der Partner, diese auch zuzulassen, und darüber hinaus durch den Gebrauch von verschlüsselung eingeschränkt. Die Architektur von MSME besteht aus einer Sprache zur Beschreibung von Policies, Protokollen zum Austausch derselben, und den nötigen Verfahren zur Ermittlung von Policies, die für alle annehmbar sind. Falls sich eine Koalition neu bildet, sich deren Mitgliedschaft verändert oder die Policies von beteiligten Partner wechseln, dann erstellt jeder Teilnehmer ein Policy Level Agreement (PLA), welche die Anforderungen des Partners an eine gemeinsame Policy beschreibt. Dann werden die PLA entweder untereinander oder mit einem zentralen Punkt ausgetauscht. Danach beginnt der sogenannte Resolution-Prozess, bei dem eine für alle akzeptable Lösung ermittelt wird, die Resolved Policy Level Agreement (RPLA). Diese muss danach auf alle Teilnehmer verteilt werden, damit diese die RPLA mit ihren eigenen Anforderungen vergleichen können. Falls sie feststellen, dass die erarbeitete Lösung keine Verletzung ihrer 11

12 Policies darstellt, wird die einheitliche Policy bei den Partnern angewendet und kontrolliert, ob alle Beteiligten auch die richtige Policy verwenden und diese auch tatsächlich durchsetzen. Es gelten daher folgende Anforderungen an ein MSME-System: - Es muss den einzelnen Partnern erlaubt sein, intern eine eigene Policy-Sprache und eigene Methoden für den Umgang mit Policies zu verwenden, allerdings stellt MSME an diese eventuell gewisse Anforderungen. - Es muss ein einheitlicher Mechanismus zur Übertragung von Policies geben, und diese Übertragungen müssen gesichert erfolgen, was also Authentifizierung oder Integrität der nötig macht. - Es soll auch möglich sein, Teilkoalitionen zu bilden, um unter ihnen Policy- Informationen auszutauschen. - MSME muss vor einer Verbindungsaufnahme feststellen können, ob die gewünschte Verbindung vom aktuellen Policy Agreement zugelassen wird. - Zu jeder Zeit muss es möglich sein, die Menge von autorisierten Koalitionspartnern festzustellen. - Es muss ein Überwachungsmechanismus vorhanden sein, um sicherzustellen dass auch die richtigen Policies an den Enforcement Points gelten, und dass diese auch richtig durchgesetzt werden. - Allgemein soll MSME unterschiedliche Sicherheitsstandards unterstützen, es gibt also keine Einschränkung auf IPSec. Partner-abhängig MSME Intra-Partner PMT/ Administrator Policy Compilation Resolution Policy Language Policy Level Agreement Exchange Protocol Local Policy Repositories Reconciliation PEPs Monitoring Abb.7: Die MSME Architektur 12

13 Abb.7 illustriert den Aufbau von MSME. Die Partner-abhängigen Komponenten werden nicht als ein Teil von MSME definiert, aber MSME muss mit ihnen interagieren und stellt daher gewisse Anforderungen an sie. Die Intra-Partner Komponenten sind vollständig in einem Partner enthalten. Das System besteht aus folgenden Komponenten: - PLA sind die Mittel zur Formulierung und zum Austausch der Policy eines Partners. Eine PLA enthält verschiedene Informationen, z.b. über die Teilnehmer einer Koalition, das Mitglied welches die PLA versendet hat oder eine Versionsnummer - Policy Compilation ist der Vorgang, in dem jeder Partner sein PLA anhand der für ihn geltenden Regelungen erzeugt. - Resolution bezeichnet die Ermittlung einer RPLA, welche die Bedingungen sämtlicher PLAs erfüllt. Es wird angezeigt falls dies nicht möglich ist, damit die Administratoren (wo es nötig ist) ihre lokale Policy entsprechend ändern. Die Resolution wird entweder von einem zentralen Punkt aus oder auf dezentrale Weise ausgeführt. - Das Exchange Protocol ist das Transportmittel für die PLAs und RPLAs. Darüber hinaus ist es für die Synchronisation des Resolution-Prozesses zwischen den einzelnen Partnern zuständig. Dabei ist für den austausch Authentifizierung und optional Sicherung der integrität erforderlich. - Reconciliation wird nach dem Erzeugen einer RPLA von jedem Partner ausgeführt, um sicherzustellen, dass die eigenen Regeln in der RPLA auch entsprechend berücksichtigt bzw. nicht von ihr verletzt werden. - Monitoring ist die Überwachung darüber, dass die RPLAs von den Partnern richtig eingesetzt werden, dies schließt z.b. auch die Versionsüberprüfung von RPLAs mit ein. - Das Policy Management Tool (PMT) repräsentiert ein Hilfsmittel zur Darstellung und Verwaltung der lokalen Sicherheitsregeln, es ist das erste der Partnerabhängigen Komponenten - Die Policy Sprache ist die Sprache, welche der Partner in seiner Domäne einsetzt. Sie kann vom Partner gewählt werden, allerdings muss es Mittel zur Übersetzung in die PLA-Darstellung geben. - Auch die Local Policy Repositories sind sehr partnerspezifisch, sie repräsentieren die Mittel, mit denen die Informationen über die lokalen Sicherheitsregeln gespeichert werden. - Die Policy Enforcement Points schließlich sind die Stellen, an denen ein Koalitionsmitglied eine neue erhaltene RPLA durchsetzen muss, dort müssen also eventuell Änderungen der lokalen Policies vorgenommen werden. Die folgende Abbildung stellt noch einmal den Ablauf der einzelnen Schritte dar, ausgehend von der Erzeugung einer PLA anhand der geltenden lokalen Policy über die Ermittlung einer RPLA anhand aller eingegangenen PLAs bis zur Umsetzung der neuen lokalen Policy: 13

14 Lokale Policies Policy Compilation PLA PLA PLA Policy Resolution RPLA Reconciliation Anwendung Abb.8: Die Schritte bei der Erzeugung einer neuen RPLA Die Aufgabenstellungen von MSME unterscheidet sich zwar von IPSP, allerdings überschneiden sie sich auch. Eine Idee von MSME ist es, das Regelwerk von IPSP zu verallgemeinern, um es auch unter anderen Protokollen einsetzen zu können. Die Idee hierzu ist die Nutzung von Bezeichnern, die entsprechend dem Kontext der eingesetzten Sicherung unterschiedlich aufgelöst werden, anstatt in einer Regel explizite Angaben zu machen. Fazit Wie man anhand der fehlenden RFCs sehen kann, gibt es bislang noch keine fertigen Standards und erst recht keine tatsächlich anwendbaren Lösungen. Über nähere Einzelheiten oder den praktischen Gebrauch lässt sich daher momentan kaum etwas sagen. Da IPSec aber als kommender Sicherheitsstandard von einschlägigen Unternehmen der Computer- und Netzwerkbranche gefördert wird, kann man wohl davon ausgehen, dass auch die Fragestellung nach der Behandlung von IPSec Policies in Zukunft eher bedeutender wird. Da im Dezember 2001 diverse Internet Drafts der ipsp Arbeitsgruppe auslaufen, darf man also gespannt sein. 14

15 Quellen IPSP Requirements (Internet Draft), IPsec Configuration Policy Model (Internet Draft), Mutlidimensional Security Policy Management and Enhancements for IP Security Policy (Internet Draft), IPSec Policy Model (DMTF White Paper), Internet Protocol Security Revealed, An Introduction to IP Security (IPSec) Encryption, IP Security: Building Block of the Trusted Virtual Network, Firewall-Systeme, Norbert Pohlmann, MITP-Verlag 15