Authentisierung mit X.509-Zertifikaten in einem Virtual Private Network

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Hintergrund und Ausgangssituation
1.1 Virtual Private Networks
1.2 IPsec-Protokoll-Suite
1.2.1 Authentication-Header-Verfahren
1.2.2 Encapsulating-Security-Payload-Verfahren
1.2.3 Security Associations
1.2.4 Internet Key Exchange
1.3 Ausgangssituation: VPN der Universitat Regensburg
1.3.1 Technische Daten und Leistungsmerkmale der Cisco VPN Hard- und Software
1.3.2 VPN-Topologie an der Universitat Regensburg
1.3.3 Nutzung des VPN aus Benutzersicht
1.3.4 Nutzung des VPN aus technischer Sicht
1.4 VPN an der Fachhochschule Regensburg

2 Authentisierung mit X.509-Zertifikaten
2.1 Motivation und Hintergrund
2.2 Public-Key-Kryptographie
2.2.1 RSA
2.2.2 Public-Key-Infrastruktur
2.2.3 X.509-Zertifikate
2.2.4 Erzeugen und Signieren von X.509-Zertifikaten mit OpenSSL ...
2.3 Symmetrische Authentisierung mit X.509-Zertifikaten im VPN
2.3.1 Konfiguration
2.3.2 Funktionsweise
2.3.3 CGI-Skript fur die Ausstellung von X.509-Zertifikaten
2.4 Hybrid Authentication mit X.509-Zertifikaten im VPN
2.4.1 Konfiguration
2.4.2 Funktionsweise

3 Schlussfolgerung

Anhang

A Netzwerkanalyse-Listing IPsec mit XAUTH

B Netzwerkanalyse-Listing IPsec mit symmetrischer Authentisierung

C Netzwerkanalyse-Listing IPsec mit Hybrid Authentication

D Perl-Skript cert.pl

E Perl-Skript gencrl.pl

Literaturverzeichnis

Abkurzungsverzeichnis

Abbildungsverzeichnis

1.1 Main-Mode-Austausch

1.2 Aggressive-Mode-Austausch

1.3 Cisco VPN 3015 Concentrator

1.4 Cisco VPN 3015 Concentrator - Bestuckungsmoglichkeiten

1.5 VPN-Topologie an der Universitat Regensburg

1.6 Cisco VPN Client - Auswahl der Verbindungsprofile

1.7 Cisco VPN Client - Abfrage nach Benutzername und Passwort

1.8 Cisco VPN Client - Banner-Meldung

1.9 Traceroute uber VPN-Verbindung zur Universitat Regensburg

1.10 Cisco VPN Client - VPN-Verbindung aufgebaut

1.11 Cisco VPN Client - Statistik

2.1 Diffie-Hellman-Schlusselaustausch

2.2 RSA-Public-Key-Verschlusselung

2.3 RSA-Signaturverfahren

2.4 Struktur eines X.509v3-Zertifikates

2.5 cert.pl -Benutzerauthentisierung

2.6 cert.pl -Zertifikatsausgabe

2.1 Verzeichnisstruktur der integrierten CA-Applikation von openssl

2.2 Konfigurationsvariablen des Skriptes cert.pl

1 Hintergrund und Ausgangssituation

1.1 Virtual Private Networks

Ein Virtual Private Network (VPN) dient der Ubertragung privater Daten zwischen Endpunkten, auch VPN-Peers genannt, in einem offentlichen Netzwerk wie dem Kunden- netzwerk eines Telekommunikationsanbieters oder dem Internet. Die Ubertragung der Nutzdaten zwischen den Endpunkten findet dabei uber einen so genannten VPN-Tunnel statt. Dadurch entsteht ein virtuelles Netzwerk, in dem die Endpunkte wie in einem lokalen Netzwerk miteinander kommunizieren konnen. Im einfachsten Fall ist daher ein mit dem Generic Routing Encapsulation (GRE)-Protokoll realisierter und uber ein offentliches Netzwerk verlaufender Tunnel ein VPN. Damit lassen sich beispielsweise nicht-routbare Transportprotokolle wie das Local Area Transport (LAT)- Protokoll der Digital Equipment Corporation uber das Internet hinweg benutzen. Die privaten Daten werden dabei nicht durch das VPN geschutzt, das heifit sie konnen beim Transport uber das offentliche Netzwerk potentiell durch Dritte manipuliert und abgehort werden. Ein VPN, bei dem auf die Sicherheit der privaten Daten beim Transport uber das offentliche Netzwerk vertraut wird, wird als ein Trusted VPN bezeichnet.

Durch Verwendung eines kryptographisch sicheren Kommunikationskanals (siehe „The Secure Channel“ [8, S. 111 ff.]) fur den VPN-Tunnel konnen die Manipulation und das Abhoren der privaten Daten durch Dritte im offentlichen Transportnetz unterbunden werden. Die privaten Daten werden dabei zur Verhinderung von Manipulation authenti- siert und zur Verhinderung von Abhoren verschlusselt. Ein derart geschutztes VPN wird als ein Secure VPN bezeichnet.

Werden die Endpunkte vor dem Aufbau des VPN-Tunnels zusatzlich gegenseitig authenti- fiziert, lasst sich die Nutzung des VPN durch Dritte und damit der unbefugte Zugriff auf das lokale Netzwerk verhindern. Durch die Authentifizierung der Endpunkte lasst sich ein VPN auch dazu benutzen, um bei Anwendungsprotokollen, die selbst keine Authenti- fizierungsmechanismen bereitstellen, dennoch eine Nutzungsberechtigung sicherzustellen. Werden an die Endpunkte des VPN zusatzlich so genannte virtuelle Adressen fur die Kommunikation innerhalb des virtuellen Netzwerkes vergeben, lasst sich auf einfache Art und Weise ein Dienst auf die Nutzung von den virtuellen Adressen aus und damit auf die authentifizierten Teilnehmer des VPN beschranken.

Wahrend ein VPN-Tunnel in der Regel als eine Punkt-zu-Punkt-Verbindung uber das offentliche Netzwerk realisiert ist, lassen sich durch den VPN-Tunnel auch Punkt-zu- Mehrpunkt- und Mehrpunkt-zu-Mehrpunkt-Verbindungen realisieren. Entsprechend wer­den folgende drei VPN-Varianten unterschieden:

-End-to-End- oder Single-User-to-Single-User-VPN

Nur die beiden tatsachlichen VPN-Endpunkte konnen durch den VPN-Tunnel miteinander kommunizieren.

-End-to-Site- oder Single-User-to-LAN-VPN

Durch den VPN-Tunnel kann ein VPN-Endpunkt mit den Stationen in einem LAN, das am anderen VPN-Endpunkt angeschlossen ist, kommunizieren und umgekehrt. Der erste VPN-Endpunkt, in diesem Fall auch User Device genannt, ist dabei in der Regel als Software auf einem Personal Computer (PC) realisiert. Der zweite VPN-Endpunkt, in diesem Fall auch VPN-Gateway oder Edge Device genannt, ist ublicherweise eine eigene Appliance oder Bestandteil einer Firewall-Losung.

-Site-to-Site- oder LAN-to-LAN-VPN

Der VPN-Tunnel existiert zwischen zwei VPN-Gateways. Uber das VPN findet eine Kopplung der jeweils an die VPN-Gateways angeschlossenen LANs statt. Alle Stationen in einem LAN konnen uber den VPN-Tunnel mit den Stationen im jeweils entfernten LAN kommunizieren.

Eine spezielle Form von VPN-Gateways sind die so genannten VPN-Concentrators beziehungsweise VPN-Konzentratoren. Diese konnen nicht nur einem VPN als Endpunkt dienen, sondern ermoglichen den Aufbau mehrere VPN-Tunnel zu mehreren verschiedenen Benutzern und LANs gleichzeitig.

Im Prinzip sind auch Punkt-zu-Mehrpunkt- und Mehrpunkt-zu-Mehrpunkt-VPN-Tunnel realisierbar. Mit Ausnahme der Internet Protocol Security (IPsec) RFCs (Request for Comments), die das Thema Multicast-VPNs anschneiden, werden solche VPN-Tunnel von den im Folgenden vorgestellten VPN-Protokollen jedoch nicht vorgesehen.

Entsprechend der historischen Entwicklung der VPN-Technologie - im Wesentlichen verlief diese von Trusted hin zu Secure VPNs - und den Anforderungen daran wurden verschiedene VPN-Protokolle spezifiziert. Die bekanntesten sind:

-Point-to-Point Tunneling Protocol (PPTP)

PPTP ist in RFC 2637 [11] spezifiziert. Im Unterschied zu den restlichen hier vorgestellten VPN-Protokollen handelt es sich hierbei um einen RFC zu Informati- onszwecken und nicht um einen Proposed Standard nach IETF (Internet Engineering Task Force). Die PPTP-Spezifikation beschreibt die Erweiterung des Point-to-Point Protocol (PPP) zum VPN-Protokoll durch die Tunnelung der PPP-Pakete per GRE. Beim Versand von Daten durch einen PPTP-Tunnel treten die Netzwerk- und die Transportschicht daher doppelt auf, was sich negativ auf die Performance auswirkt. Fur die Authentisierung der VPN-Endpunkte beim Verbindungsaufbau sieht PPTP die Verwendung der PPP-Mechanismen, in der in RFC 2637 spezifizierten Fassung jedoch weder Authentisierung noch Verschlusselung der Nutzdaten vor.

Von der Microsoft Corporation wurde eine eigene Variante von PPTP, Microsoft- PPTP genannt, entwickelt. Microsoft-PPTP bietet bei der Verwendung der Microsoft-Variante des Challenge/Response Protocol (MS-CHAP, Version 1 spe­zifiziert in RFC 2433 [47], Version 2 in RFC 2759 [48]) zur Authentisierung der Endpunkte die Moglichkeit der Verschlusselung der Nutzdaten per Microsoft Point- to-Point Encryption Protocol (MPPE, spezifiziert in RFC 3078 [34]). MS-CHAP Version 1 (MS-CHAPv1) und MPPE wurden vom Kryptologieexperten Bruce Schneier analysiert und als angreifbar bewiesen (siehe [43]). Das daraufhin verbes- serte MS-CHAP Version 2 (MS-CHAPv2) und das an MS-CHAPv2 angepasste MPPE wurden wiederum von Bruce Schneier analysiert und stellten sich ebenfalls als nicht ausreichend sicher heraus (siehe [44]).

-Layer 2 Tunneling Protocol (L2TP)

L2TP ist in RFC 2661 [46] spezifiziert. Es basiert auf PPTP - als dessen Nachfolger es gedacht ist - und dem Layer 2 Fowarding (L2F)-Protokoll. Analog zu PPTP benutzt das L2T-Protokoll getunnelte PPP-Pakete und sieht eine Authentifizierung der VPN-Endpunkte beim Verbindungsaufbau mit den PPP-Mechanismen, jedoch ebenfalls keine Authentisierung und Verschlusselung der Nutzdaten vor.

-Internet Protocol Security (IPsec)

IPsec ist kein einzelnes Protokoll, sondern eine modular aufgebaute Protokoll- Suite, die im Rahmen des Internet Protocol Version 6 (IPv6) entwickelt wurde. Die IPsec-Protokoll-Suite ist in der aktuellen Version in den RFCs 2401 [24], 2402 [21], 2403 [30], 2404 [31], 2405 [29], 2406 [22], 2407 [38], 2408 [32], 2409 [12], 2410 [10] und 2411 [45] spezifiziert. RFC 2401 erlautert dabei die Architektur von IPsec und die RFCs 2402 bis 2410 beschreiben die einzelne IPsec-Komponenten beziehungsweise Teilprotokolle im Detail. Als Erganzung wird in RFC 2411 noch einmal eine Ubersicht uber die IPsec-Protokoll-Suite und die zugehorigen RFCs gegeben.

Abhangig von den eingesetzten IPsec-Komponenten und der Art deren Verwendung bietet IPsec die Authentisierung der VPN-Endpunkte beim Verbindungsaufbau und beim Datenaustausch sowie Authentisierung und Verschlusselung der Nutzdaten.

IPsec arbeitet im Gegensatz zu den anderen hier vorgestellten VPN-Protokollen direkt auf der Netzwerkschicht des International Standards Organization/Open Systems Interconnection (ISO/OSI)-Modells nach ISO/IEC 7498-1 [16]. Abhangig vom gewahlten Arbeitsmodus - es kommen Transport- und Tunnelmodus in Frage - tritt durch IPsec im Netzwerk-Stack der Endpunkte keine Schicht mehrfach - beziehungsweise im Tunnelmodus nur die Netzwerkschicht - doppelt auf. Ohne die Verwendung eines weiteren Tunnel-Protokolls ist IPsec dadurch andererseits auf das Tunneln des Internet-Protokolls und darauf aufsetzende Protokolle hoherer Schichten begrenzt.

Die Verwendung von IPsec mit dem Internet Protocol Version 4 (IPv4) als Netz­werkschicht ist ebenfalls moglich und in den IPsec-RFCs spezifiziert. Fur eine detailliertere Beschreibung von IPsec siehe 1.2.

-L2TP-over-IPsec

Um LT2P mit den Vorteilen von IPsec, also Authentisierung und Verschlusselung der Nutzdaten zu versehen, wurde in RFC 3193 [35] die Verwendung von LT2P zusammen mit IPsec spezifiziert. LT2P wird dabei uber IPsec getunnelt, was fur das Tunneln von IP uber LT2P weiteren Overhead bedeutet und fur reine IP-Netze daher keine Vorteile gegenuber der direkten Verwendung von IPsec bietet. In erster Linie eignet sich L2TP-over-IPsec daher zum Tunnel von anderen Protokollen aufier IP uber IPsec.

-Secure Sockets Layer (SSL)/Transport Layer Security (TLS)

Version 1.0 des TLS-Protokolls ist in RFC 2246 [5] spezifiziert. Es basiert auf der Version 3.0 des nicht in einem RFC spezifizierten SSL-Protokolls. TLS 1.0 und SSL 3.0 sind im Wesentlichen identisch. TLS ist als ein erweiterbares Protokoll konzipiert. Der aktuelle Satz an Erweiterungen ist in RFC 3546 [2] spezifiziert.

Das TLS-Protokoll stellt Client/Server-Anwendungen auf der Basis der Public-Key- Kryptographie (siehe 2.2) eine gesicherte Kommunikation mit Authentisierung und Verschlusselung ab der Transportschicht zur Verfugung. Es eignet sich daher nur fur End-to-End-VPNs. Am bekanntesten ist das TLS-Protokoll durch die Verwendung im Hypertext Transfer Protocol Secure (HTTPS), wo auch die Ursprunge des SSL-Protokolls liegen. Es wird aber beispielsweise auch fur das File Transfer Protocol (FTP) sowie das Simple Mail Transfer Protocol (SMTP) benutzt.

1.2 IPsec-Protokoll-Suite

„ We perform a cryptographic review of the IPsec protocol, as described in the November 1998 RFCs. Even though the protocol is a disappointment - our primary complaint is with its complexity - it is the best IP security protocol available at the m,om,ent.“ — Niels Ferguson und Bruce Schneier [7]

An dieser Stelle wird ein Uberblick uber die IPsec-Protokoll-Suite gegeben, da das VPN der Universitat Regensburg IPsec als VPN-Protokoll einsetzt und diese Diplomarbeit ein hinreichendes Verstandnis von IPsec voraussetzt.

Die in RFC 2401 [2spezifizierte IPsec-Architektur besteht aus den folgenden Kompo- nenten:

-Security Protocols
-Security Associations
-Key Management
-Algorithms for Authentication and Encryption

Als Security Protocols beziehungsweise Sicherheitsprotokolle werden die in Rahmen von IPsec spezifizierten Verfahren Authentication Header und Encapsulating Security Payload angeboten. Mit diesen kann ein kryptographisch sicherer Kommunikationskanal mit Authentisierung und Verschlusselung der Nutzdaten realisiert werden.

1.2.1 Authentication-Header-Verfahren

Das Authentication Header (AH)-Verfahren ist in RFC 2402 [21] spezifiziert. Es garantiert fur die damit geschutzten Nutzdaten connectionless Integrity (Integritat der Daten) sowie

Data Origin Authentication (Authentizitat der Datenquelle). Das bedeutet: Veranderun- gen der Nutzdaten auf dem Weg durch das Netzwerk werden sicher detektiert und es wird uberpruft, ob der angegebene Absender die tatsachliche Datenquelle ist. Die Bezeichnung der Integritat als „connectionless“ bedeutet, dass sie sich auf jedes einzelne IP-Paket bezieht und unabhangig von deren Reihenfolge beim Eintreffen beim Empfanger ist. Diese beiden Schutzmechanismen zusammen werden kurz als „Authentication“ bezeichnet und derart geschutzte Daten als „authenticated“.

Optional bietet das AH-Verfahren zusatzlich Schutz vor so genannten Replay-Attacken, das heiht eventuell abgefangene Datenpakete, die per AH geschutzt sind, werden beim erneuten Versenden an den Empfanger von diesem nicht mehr akzeptiert.

Das AH-Verfahren kennt zwei Arbeitsmodi, den Transport- und den Tunnelmodus, wobei beide Modi die oben erlauterten Schutzmahnahmen bieten. Im Transportmodus wird der Authentication Header nach dem IP-Header und vor dem Header des Transportprotokolls beziehungsweise vor eventuell vorhandenen Headers weiterer IPsec-Protokolle eingefugt. Im Unterschied dazu wird im Tunnelmodus der Authentication Header vor dem IP- Header des ursprunglichen IP-Pakets - innerer IP-Header genannt - und wiederum vor dem Authentication Header ein zusatzlicher IP-Header - auherer IP-Header genannt - eingefugt.

Die Protokollnummer von AH ist 51. Diese wird in beiden Modi im Protokollfeld des auheren IP-Header eingetragen.

Der Transportmodus ist in erster Linie als eine Optimierung des Tunnelmodus fur End- to-End-VPNs zu sehen. Entsprechend erlaubt IPsec die Verwendung des Transportmodus nur fur End-to-End-VPNs, wahrend fur End-to-Site- sowie Site-to-Site-VPNs der Tun­nelmodus einzusetzen ist. Der Grund fur diese Einschrankung ist offensichtlich, bei End-to-Site- und Site-to-Site-VPNs sind fur das korrekte Routing die ursprunglichen Empfanger- und Absenderadressen zu erhalten. Dies ist durch die Verwendung des ur­sprunglichen IP-Header als innerem IP-Header gegeben, wahrend im auheren IP-Header die Adressen der IPsec-Endpunkte eingetragen werden.

Der folgende Auszug aus RFC 2402 [21] verdeutlicht die Arbeitsweise des AH-Verfahrens im Transportmodus am Beispiel von IPv4 und einem Transmission Control Proto­col (TCP)-Paket:

BEFORE APPLYING AH

Abbildung in dieser Leseprobe nicht enthalten

AFTER APPLYING AH

Abbildung in dieser Leseprobe nicht enthalten

Analog dazu im Tunnelmodus:

AFTER APPLYING AH

Abbildung in dieser Leseprobe nicht enthalten

Bemerkenswert dabei ist, dass sich der Schutz durch AH auch auf den vorangestellten IP-Header aufier dessen beim Routing veranderliche Felder wie dem Time to live (TTL)- Feld bezieht. Entsprechendes gilt fur die IPv6 Extension-Header. Diese umfassende Authentisierung verhindert jedoch die Nutzung von AH mit Network Address Transla­tion (NAT), da NAT je nach Arbeitsrichtung die Absender- oder die Empfangersdresse im vorangestellten IP-Header auf die des NAT-Gateway andert.

Als Authentisierungsalgorithmen sieht RFC 2402 Message Authentication Codes (MACs) auf Basis von symmetrischen Verschlusselungsalgorithmen wie den Data Encryption Standard (DES)-Algorithmus oder auf Basis von Einweg-Hash-Funktionen wie den Message Digest Algorithm 5 (MD5) und den Secure Hash Algorithm 1 (SHA-1) vor. MAC auf Basis von Einweg-Hash-Funktionen werden als Keyed-Hash Message Authentication Code (HMAC) bezeichnet. Eine konforme AH-Implementierung muss die Varianten HMAC-MD5 und HMAC-SHA-1 beherrschen. Die Verwendung von HMAC-MD5 und HMAC-SHA-1 fur AH ist in RFC 2403 [30] beziehungsweise RFC 2404 [31] spezifiziert. Ein NULL-Authentisierung-Algorithmus darf hier nicht zum Einsatz kommen.

1.2.2 Encapsulating-Security-Payload-Verfahren

Das Encapsulating Security Payload (ESP)-Verfahren ist in RFC 2406 [22] spezifiziert. Wie das AH-Verfahren bietet es connectionless Integrity und Data Origin Authentication der Nutzdaten sowie optional Schutz vor Replay-Attacken. Es wird ebenfalls zwischen Transport- und Tunnelmodus mit den gleichen Einschrankungen und Anwendungsgebieten unterschieden. Das Einfugen des ESP-Header erfolgt analog zum AH-Verfahren, als Protokollnummer im vorangestellten IP-Header wird fur ESP 50 eingetragen. Eine konforme ESP-Implementierung muss wiederum HMAC-MD5 und HMAC-SHA-1 als Authentisierungsalgorithmen anbieten. Anders als beim AH-Verfahren darf hier aber ein NULL-Algorithmus zum Einsatz kommen. Dieser muss von einer konformen ESP- Implementierung auch beherrscht werden.

Ein weiterer Unterschied zu AH besteht im Umfang der durch einen ESP-Header au- thentisierten Daten, der im Fall von ESP den vorangestellten IP-Header nicht enthalt. Folglich ist eine Benutzung von ESP uber NAT moglich. In der Praxis beherrschen viele NAT-Implementierungen jedoch IPsec nicht. Als Abhilfe wurde in RFC 3948 [15] die Encapsulation beziehungsweise Kapselung von ESP in User Datagram Protocol (UDP)- Paketen spezifiziert.

Ein zusatzlicher Schutzmechanismus von ESP ist die Confidentiality des Payloads durch Verwendung eines Encryption Algorithm, das heifit die Nutzdaten werden ab dem Header der Transportschicht verschlusselt und somit vor Einsicht durch Dritte geschutzt. Derart gesicherte Daten werden als „encrypted“ bezeichnet.

Beim ESP-Verfahren wird der Payload zwischen dem ESP-Header und dem ESP-Trailer encapsulated beziehungsweise eingeschlossen. Der ESP-Trailer dient in erster Linie dem Padding, das fur bestimmte Verschlusselungsalgorithmen notwendig ist. Das Padding kann auch zur kunstlichen Verlangerung des Payloads verwendet werden, um ein un- befugtes Entschlusseln weiter zu erschweren. Nach dem ESP-Trailer folgen die ESP- Authentisierungsdaten.

Der folgende Auszug aus RFC 2406 [22] verdeutlicht die Arbeitsweise des ESP-Verfahrens im Transportmodus am Beispiel von IPv4 und einem TCP-Paket:

BEFORE APPLYING ESP

Abbildung in dieser Leseprobe nicht enthalten

AFTER APPLYING ESP

Abbildung in dieser Leseprobe nicht enthalten

Analog dazu im Tunnelmodus:

AFTER APPLYING ESP

Abbildung in dieser Leseprobe nicht enthalten

ESP ist fur symmetrische Verschlusselungsalgorithmen - auch Cipher genannt - ausgelegt. Die Spezifikation schrankt Typ und Anwendung des eingesetzten Verschlusselungsalgo- rithmus aber nicht ein. Eine konforme ESP-Implementierung muss den DES-Algorithmus im Cipher Block Chaining (CBC)-Mode und den NULL-Verschlusselungsalgorithmus beherrschen. Die Verwendung von DES-CBC fur ESP ist in RFC 2405 [29] spezifi- ziert. Der NULL-Verschlusselungsalgorithmus und seine Verwendung fur ESP ist in RFC 2410 [10] spezifiziert. Da der DES-Algorithmus nicht als sicher angesehen werden kann (siehe „Sicherheit von DES“ [39, S. 23]), wird heute in der Regel der Triple-DES (3DES)-Algorithmus oder der Advanced Encryption Standard (AES)-Algorithmus als Verschlusselungsalgorithmus fur ESP verwendet. Die Verwendung von 3DES fur ESP ist in RFC 1851 [19] spezifiziert. Dieser RFC bezieht sich jedoch nicht auf die aktuelle IPsec- Spezifikation und ist als „experimental“ gekennzeichnet. Die Verwendung von AES-CBC fur ESP ist in RFC 3602 [9] spezifiziert. Die Verwendung von AES im Counter (CTR) Mode ist in RFC 3686 [1spezifiziert.

Da das ESP-Verfahren die Verwendung von NULL-Authentisierungs- und NULL- Verschlusselungsalgorithmen vorsieht, sind sowohl Authentisierung als auch Verschlus- selung bei ESP optional. Bei der Benutzung von ESP darf jedoch nicht gleichzeitig fur die Authentisierung und die Verschlusselung ein NULL-Algorithmus ausgewahlt werden. Beide konnen jedoch gleichzeitig nicht NULL-Algorithmen sein, das heiht es kann ein kombinierter Schutz aus Authentisierung und Verschlusselung gewahlt werden. Fur eine starkere Authentisierung in Kombination mit Verschlusselung konnen AH und ESP auch zusammen -beziehungsweise im Tunnelmodus verschachtelt - benutzt werden.

1.2.3 Security Associations

Security Associations sind als Teil des Security Architecture RFC 2401 [2spezifiziert und sind das grundlegende Konzept von IPsec. Eine Security Association (SA) ist ein vom jeweiligen Sicherheitsprotokoll (AH oder ESP) abhangiger Satz an Parametern und zur Anwendung des Sicherheitsprotokolls benotigter Daten (Authentisierungs- beziehungs­weise Verschlusselungsalgorithmus, Schlussel et cetera), der eine gesicherte Verbindung zwischen IPsec-Endpunkten beschreibt. Eine IPsec-Verbindung kann als ein VPN-Tunnel betrachtet werden und funktioniert ahnlich einer TCP-Verbindung, das heifit nach dem Aufbau der IPsec-Verbindung konnen bis zu deren Abbau Daten daruber ausgetauscht werden. Eine SA bezieht sich dabei genau auf eine IPsec-Verbindung, eine Kommunikati- onsrichtung und ein Sicherheitsprotokoll, das heifit fur eine bidirektionale Kommunikation zwischen zwei Endpunkten werden pro Sicherheitsprotokoll insgesamt zwei SAs benotigt.

Auf einem IPsec-Endpunkt werden SAs in der Security Association Database (SAD) verwaltet. Eine SA in der SAD wird durch das Tripel aus IP-Adresse des Ziel-IPsec- Endpunktes, zu verwendendem Sicherheitsprotokoll und Security Parameter Index (SPI) eindeutig beschrieben. Der SPI dient dabei zur Unterscheidung von SAs, die Verbin- dungen zum selben IPsec-Endpunkt unter Verwendung desselben Sicherheitsprotokolls beschreiben.

Die Anwendung von SAs erfolgt uber die Security Policy Database (SPD), die ahnlich einer Regeltabelle fur den Paketfilter einer Firewall benutzt wird. Eine Policy in der SPD entspricht dabei einer Regel in der Tabelle. Fur jeglichen, das heifit IPsec- und nicht-IPsec-Datenverkehr uber ein Netzwerk-Interface eines IPsec-Endpunktes, uber das IPsec-Datenverkehr stattfinden kann, ist eingehend und ausgehend die entsprechende Policy in der SPD zu suchen und die in der Policy angegebene Aktion auszufuhren. Die Auswahl einer Policy erfolgt uber Selektoren, die je nach Implementierung und Anforderungen verschiedenartig sein und auch Wildcards enthalten konnen. Als mogliche Aktionen einer Policy kommen „discard“ (Verwerfen des ‘Datagramm), „apply“ (Verschi- cken beziehungsweise Empfangen unter Anwendung von IPsec) und „bypass“ (Verschicken beziehungsweise Empfangen unter Umgehung von IPsec) in Frage. Fur die Anwendung von IPsec verweist eine Policy in der SPD auf eine SA in der SAD.

SAs besitzen eine begrenzte Gultigkeit um ein kontinuierliches Rekeying, das heifit Erneuerung der fur die Authentisierung und Verschlusselung der Nutzdaten eingesetzten Schlussel, zu gewahrleisten. Die Gultigkeit wird entweder uber ein Zeitlimit, ein Datenlimit fur die uber eine SA beschriebenen IPsec-Verbindung verschickten Nutzdaten oder uber beides festgelegt. Beim Erreichen des Limits beziehungsweise eines der Limits ist eine SA durch eine neue zu ersetzen, wobei die Verbindung zwischen IPsec-Endpunkten selbst bestehen bleiben kann.

IPsec sieht fur die Erzeugung von SAs sowohl manuelle als auch automatische Verfahren vor. Unter dem manuellen Verfahren ist das handische Konfigurieren der SAs auf den End- punkten einschliefilich handischem Eintragen der Schlussel fur die Sicherheitsprotokolle zu verstehen. Durch den damit verbundenen Aufwand eignet sich das manuelle Verfahren nur fur kleine VPN-Installationen mit wenigen Endpunkten. Daruber hinaus hat der Anwender selbst fur den gesicherten Austausch der Schlussel zwischen den Endpunkten zu sorgen. Als automatisches Verfahren sieht IPsec die Verwendung des in RFC 2408 [32] spezifizierten Internet Security Association and Key Management Protocol (ISAKMP) vor. ISAKMP ist ein Framework zur Authentifizierung der Endpunkte beim Verbindungs- aufbau, Aushandlung der SAs zwischen den Endpunkten und Management (Erzeugung, Modifizierung und Loschung) der SAs sowie Austausch und Management von Schlusseln fur die SAs. Die Benutzung von ISAKMP mit IPsec ist in RFC 2407 [38] spezifiziert.

1.2.4 Internet Key Exchange

Das Internet Key Exchange (IKE) Protokoll ist in RFC 2409 [12] spezifiziert. Es ist ein so genanntes Hybridprotokoll, da es auf dem ISAKMP-Framework, dem Oakley Key Determination Protocol (spezifiziert in RFC 2412 [33]) und dem Secure Key Exchange Mechanism (SKEME) for Internet basiert. IKE ist ein Protokoll zur Authentifizierung der Endpunkte beim Verbindungsaufbau, Aushandlung der SAs zwischen den Endpunk­ten und Austausch von Schlusseln fur die SAs in einer sicheren Art und Weise. Als Transportprotokoll fur IKE ist in RFC 2409 die Verwendung von UDP auf Port 500 spezifiziert.

Das IKE-Protokoll ist der komplexeste Teile von IPsec und die Grenzen zu ISAKMP sind fliefiend. Dies spiegelt sich auch im Entwurf der Version 2 von IKE (IKEv2, fur die zum Zeitpunkt dieser Diplomarbeit aktuellen Fassung siehe [20]) wider. Mit dem Ubergang dieses Entwurfes in einen RFC wird dieser die RFCs 2407, 2408 sowie 2409 und somit IKEv2 die Kombination aus IKE und ISAKMP ablosen.

Das IKE-Protokoll arbeitet im Wesentlichen in zwei Phasen:

-Phase 1: Aushandlung und Erzeugung einer speziellen ISAKMP-SA einschlieb- lich gegenseitiger Authentifizierung der Endpunkte fur die Authentisierung und Verschlusselung weiterer IKE-Kommunikation zwischen den Endpunkten, und

-Phase 2: Aushandlung und Erzeugung von SAs fur die Sicherheitsprotokolle (AH und ESP) sowie Austausch der dafur benotigten Schlussel.

Die in Phase 1 ausgehandelte ISAKMP-SA ist insofern speziell, da sie im Gegensatz zu den SAs fur die Sicherheitsprotokolle bidirektionale Kommunikation erlaubt. Fur die Erzeu­gung der ISAKMP-SA werden ein Verschlusselungsalgorithmus, ein Hash-Algorithmus, eine Authentifizierungsmethode und die MODP-Gruppe (multiplikative Gruppe mo­dulo Primzahl p) fur Diffie-Hellman-Schlusselaustausche ausgehandelt. Eine konforme IKE-Implementierung muss hierfur DES-CBC, MD5 und SHA, Authentifizierung mit Pre-Shared Key und MODP-Gruppe 1 beherrschen. Laut RFC 2409 sollen des Weiteren 3DES fur die Verschlusselung, der Tiger-Hash-Algorithmus sowie derDigital Signature Standard (DSS), Rivest-Shamir-Adleman (RSA)-Public-Key-Verschlusselung und das RSA-Signaturverfahren fur die Authentifizierung der Endpunkte implementiert werden.

Allgemein sieht RFC 2409 die Authentifizierung anhand von Verschlusselung mit einem Pre-Shared Key, Public-Key-Verschlusselung und digitalen Signaturen vor, wobei die letzten beiden Methoden optional zu implementieren sind. Unter einem Pre-Shared Key ist ein geheimer Schlussel zu verstehen, der fur alle Endpunkte eines VPN identisch und auf diesen im Vorfeld einzutragen ist. Fur die Authentifizierung des jeweils anderen Endpunktes anhand von Pre-Shared Key- oder Public-Key-Verschlusselung, wird dem Gegenuber eine verschlusselte Nonce (entstanden aus Number used once) gesendet. Antwortet das Gegenuber mit der entschlusselten Nonce (prazise: mit dem erwarteten Hash-Wert, in den die entschlusselte Nonce mit eingerechnet wurde), so hat das Gegenuber die Kenntnis des Pre-Shared Key beziehungsweise des Private-Key bewiesen und ist somit authentifiziert. Um den jeweils anderen Endpunkt unter Verwendung einer digitalen Signatur zu authentifizieren, wird dem Gegenuber eine Nonce in Klartext mitgeteilt. Das Gegenuber signiert diese Nonce und schickt das Ergebnis zuruck. Mit erfolgreicher Uberprufung der Signatur ist das Gegenuber authentifiziert. Bei allen drei Methoden hat die Authentifizierung der Endpunkte gegenseitig und symmetrisch, das heibt mit jeweils der gleichen Methode, stattzufinden. Fur detailliertere Informationen zur Funktionsweise dieser Authentifizierungsmethoden siehe 2.2.

Die Aushandlung der Algorithmen, Methoden und Parameter zu Beginn von Phase 1 erfolgt uber Vorschlage, die der Initiator des Verbindungsaufbaus in Form von SA Ne­gotiation Payload unterbreitet und aus denen der Antwortsender einen auswahlt und ebenfalls in Form eines SA Negotiation Payload bestatigt. Danach erfolgt ein Diffie- Hellman-Schlusselaustausch fur die Erzeugung eines Schlussels zur Verschlusselung der Kommunikation uber die ISAKMP-SA und die oben erlauterte gegenseitige Authentifi- zierung der Endpunkte.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.1: Main-Mode-Austausch (Authentifizierung anhand von digitalen Signaturen)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.2: Aggressive-Mode-Austausch (Authentifizierung anhand von digitalen Signaturen)

Fur den Ablauf von Phase 1 sind zwei verschiedene Exchange- beziehungsweise Austausch- varianten spezifiziert. Diese sind der in Abbildung 1.1 - mit Verwendung von digitalen Signaturen fur die Authentifizierung - dargestellte Main-Mode- und der in Abbildung 1.2 - ebenfalls mit Verwendung von digitalen Signaturen fur die Authentifizierung - skizzierte Aggressive-Mode-Austausch. Eine konforme IKE-Implementierung muss den Main-Mode- Austausch beherrschen. Dieser benotigt drei Round-Trips zwischen Initiator und Antwort- sender. Im optional zu implementierenden Aggressive-Mode-Austausch werden durch das Senden von mehr Payload pro verschickter Meldung nur eineinhalb Round-Trips benotigt. Dadurch kann beim Aggressive-Mode-Austausch der Identity Payload aber nur unver- schlusselt ubertragen werden. Im Unterschied dazu wird beim Main-Mode-Austausch der Identity Payload mit dem im Diffie-Hellman-Schlusselaustausch erzeugten Schlussel symmetrisch verschlusselt (der offentliche Teil des Diffie-Hellman-Schlusselaustausches wird in Form von Key Exchange Payload ausgetauscht, in den Abbildungen als „Key“ dargestellt). Fur die Identitaten der Endpunkte werden deren IP-Adressen, Hostnames et cetera oder bei einem Aggressive-Mode-Austausch ein Index auf den zu verwendenden Pre-Shared Key - falls mehrere zur Verfugung stehen - benutzt. Da die IP-Adressen ohnehin unverschlusselt in den IP-Headers zu finden sind und mit dem Index auf einen Pre-Shared Key keine sensible Information preisgegeben wird, ist diese Einschrankung des Aggressive-Mode-Austausches zu Gunsten eines schnelleren Ablaufes von Phase 1 in der Praxis akzeptabel. Optional konnen in beiden Austauschvarianten bei der Au­thentifizierung anhand von Public-Key-Verschlusselung oder mit digitalen Signaturen die zur Authentisierung der Endpunkte eingesetzten Zertifikate in Form von Certificate Payload ausgetauscht werden. Dadurch kann der Austausch von Zertifikaten zwischen den Endpunkten im Vorfeld entfallen, das zur Uberprufung der Zertifikate der Endpunkte benotigte Certificate Authority (CA)-Zertifikat muss jedoch im Vorfeld bereitgestellt werden. Fur nahere Informationen hierzu siehe 2.2.2.

Wurde eine ISAKMP-SA erzeugt, kann Phase 2 beliebig oft ausgefuhrt werden. Fur Phase 2 sind zwei verschiedene Austausche spezifiziert: Quick-Mode- und Informational- Austausch. Der Quick-Mode-Austausch wird uber die ISAKMP-SA authentisiert und verschlusselt. Er muss von einer konformen IKE-Implementierung beherrscht werden und dient der Aushandlung von SAs fur die Sicherheitsprotokolle und der Erzeugung der dafur benotigten Schlussel. Die Aushandlung einer SA fur ein Sicherheitsprotokoll erfolgt uber Vorschlage analog zur Aushandlung der ISAKMP-SA in Phase 1. Um Schlussel fur die Sicherheitsprotokolle bereitzustellen, werden Nonces ausgetauscht, mit denen die Endpunkte die benotigten Schlussel erzeugen konnen (im einfachsten Fall durch Berechnung des Hash-Wertes aus Identifikationsnummer des Sicherheitsprotokolls, SPI und Nonces). Das Resultat des Quick-Mode-Austausches sind zwei SAs fur die bidirektionale Kommunikation uber ein Sicherheitsprotokoll. Optional konnen uber einen einzigen Quick-Mode-Austausch SAs fur mehrere Sicherheitsprotokolle ausgehandelt werden.

Der Informational-Austausch muss von einer konformen IKE-Implementierung beherrscht werden und dient der gegenseitigen Benachrichtigung der Endpunkte. Wenn moglich wird er uber die ISAKMP-SA authentisiert und verschlusselt. Fur den Informational- Austausch sind Notification und Delete Payload spezifiziert. Der Notification Payload ist fur Nachrichten wie Fehlermeldungen vorgesehen, der Delete Payload zur Signalisierung der Loschung einer SA.

In RFC 2409 ist der New-Group-Mode-Austausch als weiterer optional zu implementie- render Austausch spezifiziert. Es handelt sich dabei nicht um einen Phase 2 Austausch, er darf aber nicht vor Phase 1 stattfinden und wird uber die ISAKMP-SA authentisiert und verschlusselt. Der New-Group-Mode-Austausch dient der Aushandlung einer neuen MODP-Gruppe fur weitere optionale Diffie-Hellman-Schlusselaustausche.

IKE kann aus verschiedenen Grunden in der in RFC 2409 spezifizierten Form nicht uber NAT verwendet werden, obwohl diese die Verwendung des UDP als Transportprotokoll vorsieht. Einer der Grunde ist die Vorgabe, Port 500 als Quell- und Zielport zu verwenden, der Quellport eines UDP-Pakets kann sich durch NAT jedoch verandern. Die notigen Mafinahmen, um IKE mit so genanntem NAT-Traversal uber NAT zu verwenden, sind in RFC 3947 [25] spezifiziert. Fur die weiteren Grunde, warum das in RFC 2409 spezifizierte IKE-Protokoll mit NAT nicht funktioniert, sei ebenfalls auf RFC 3947 verwiesen.

Die Verstandigung zwischen Endpunkten, welche IKE-Erweiterungen wie zum Beispiel RFC 3947 zum Einsatz kommen, erfolgt innerhalb des Phase 1 Austausches uber den dafur reservierten Vendor ID Payload. Die Aushandlung der IKE-Erweiterungen erfolgt uber Vorschlage analog und parallel zur Aushandlung der ISAKMP-SA in Phase 1. Durch die parallele Aushandlung der IKE-Erweiterungen zur ISAKMP-SA kann Vendor ID Payload jedoch nicht uber die ISAKMP-SA authentisiert und verschlusselt werden. Da das Vorschlagen und Bestatigen von IKE-Erweiterungen uber Vendor ID Payload optional ist, kann eine IPsec-Implementierung, die eine bestimmte IKE-Erweiterung beherrscht, abwartskompatibel zu IPsec-Implementierungen bleiben, die diese Erweiterung nicht beziehungsweise keine Erweiterung beherrscht, und umgekehrt.

Neben den genannten Problemen mit NAT stellten sich bei der Implementierung von Firewalls mit IPsec-Unterstutzung, VPN-Appliances et cetera fur die Verwendung als VPN-Gateway im industriellen Umfeld weitere Unzulanglichkeiten von IKE heraus. Um diese zu beheben wurden eine Reihe von Erweiterungen fur IKE in Drafts, RFCs und als Teil des eingangs erwahnten Entwurfs von IKEv2 spezifiziert. An dieser Stelle werden drei dieser Erweiterungen kurz beschrieben, da sie von der an der Universitat Regensburg eingesetzten VPN-Losung benutzt werden beziehungsweise da sie fur diese Diplomarbeit relevant sind. Diese sind:

-ISAKMP Configuration Method
-Extended Authentication
-Hybrid Authentication

Die ISAKMP Configuration Method ist auch als IKE Mode Configuration (MODECFG) bekannt und nur in Form eines Entwurfes (fur die letzte Fassung siehe [37]) spezifiziert. Sie ist eine dem Dynamic Host Configuration Protocol (DHCP) nachempfundene Erweiterung und dient primar der Anfrage nach und Vergabe von virtuellen IP-Adressen fur die Verwendung im VPN. Ahnlich dem DHCP lassen sich bei Bedarf auch weitere Parameter mit der ISAKMP Configuration Method aushandeln. Diese Parameter konnen einem Endpunkt uber ein Push/Acknowledge- mitgeteilt oder von einem Endpunkt uber ein Request/Reply-Verfahren angefragt werden. Die dafur notigen Meldungen werden in einem eigenen so genannten Transaction-Austausch als Attribute Payload verschickt. Der Transaction-Austausch ist ahnlich dem New-Group-Mode-Austausch weder ein Phase 1 noch ein Phase 2 Austausch und kann daruber hinaus zu jedem Zeitpunkt stattfinden. Wie im ISAKMP Configuration-Method-Entwurf spezifiziert sollte der Transaction-Austausch jedoch nach Phase 1 ausgefuhrt werden, damit er uber die ISAKMP-SA authentisiert und verschlusselt werden kann. Bei den meisten IPsec-Implementierungen findet der Transaction-Austausch nach Phase 1 und vor dem ersten Phase 2 Austausch statt und wird daher in diesem Fall auch „Phase 1.5“ genannt.

Die letzte Fassung des ISAKMP Configuration-Method-Entwurfs ist seit Februar 2000 ausgelaufen, ohne in einen RFC ubergegangen zu sein. Der Ansatz wurde jedoch in den zum Zeitpunkt dieser Diplomarbeit gultigen IKEv2-Entwurf [20] ubernommen. Abgesehen von Namensanderungen - beispielsweise wird der Attribute Payload im IKEv2-Entwurf Configuration Payload genannt - wurden die Meldungen, deren Verwendung und das Payload-Format dabei nahezu unverandert in den IKEv2-Entwurf aufgenommen. Der wesentliche Unterschied zwischen den beiden Entwurfen ist der Versand des Configuration Payload in einem Phase-2-Informational-Austausch bei IKEv2.

Extended Authentication (XAUTH) ist ebenfalls nur in Form eines Entwurfes (fur die letzte Fassung siehe [36]) spezifiziert. XAUTH erweitert IKE um die Moglichkeit, die Benutzer eines VPN vom VPN-Gateway unter Verwendung einer so genannten Legacy Authentication Method (LAM) zu authentifizieren. Zu den LAMs zahlen zum Beispiel der Remote Access Dial-In User Service (RADIUS), Challenge-Response-Systeme wie CRYPTOCard und Token-basierte Systeme wie RSA SecurID. Die Notwendigkeit der Erweiterung von IKE um die Moglichkeit, Endpunkte uber eine LAM zu authentifizieren, entstand aus der Anforderung, bestehende Remote Access Services (RAS) durch VPNs ersetzen zu konnen, ohne zusatzlich in die von IKE unterstutzten Authentifizierungsme- thoden investieren beziehungsweise darauf umstellen zu mussen.

Das grundlegende Problem liegt dabei in der in RFC 2409 geforderten gegenseitigen symmetrischen Authentifizierung der Endpunkte. In der Praxis konnen uber LAMs aber nur die Endpunkte der RAS-Benutzer von einem VPN-Gateway mit Zugriff auf den entsprechenden LAM-Server authentifiziert werden, jedoch kann keine Authentifizie- rung in umgekehrter Richtung erfolgen. XAUTH umgeht dieses Problem, indem die Authentisierung eines RAS-Benutzers gegenuber einem VPN uber eine LAM in einem Phase-1.5-Transaction-Austausch stattfindet. Der Transport der Authentisierungsdaten - beispielsweise eine Kombination aus Benutzername und Passwort - erfolgt dabei uber ISAKMP Configuration-Method-Meldungen als Attribute Payload. Die entsprechende Verwendung der ISAKMP Configuration-Method-Meldungen werden im XAUTH-Entwurf spezifiziert. Nach der Authentifizierung mit XAUTH konnen wie gewohnt mit Phase-2- Quick-Mode-Austausche die SAs fur die Sicherheitsprotokolle ausgehandelt werden.

Die Authentisierung und Verschlusselung des Phase-1.5-Transaction-Austausches erfolgt uber eine ISAKMP-SA, die analog zu IKE ohne XAUTH unverandert mit gegenseitiger und symmetrischer Authentifizierung unter Verwendung einer der in RFC 2409 vorgesehe- nen Methoden in Phase 1 erzeugt wurde. Hier liegt die Gefahr beim Einsatz von XAUTH. Viele Hersteller betrachten die Authentifizierung in Phase 1 als notwendiges Ubel, um die Authentifizierung mit XAUTH in Phase 1.5 „in Gang zu bringen“. Sie empfehlen daher als Vereinfachung den Einsatz eines einzigen, fur samtliche Endpunkte einer Gruppe von RAS-Benutzern gemeinsam benutzten Pre-Shared Key. Ein auf diese Weise genutzter Pre-Shared Key wird auch als „Group Password" beziehungsweise „Gruppenpasswort“ bezeichnet. Zum Teil beherrschen IPsec-Implementierungen mit XAUTH-Erweiterung aus- schliehlich solche Gruppenpassworter fur die Authentifizierung der Endpunkte in Phase 1. Als Konsequenz daraus ist beim Bekanntwerden des Gruppenpasswortes die Sicherheit aller RAS-Benutzer in der betreffenden Gruppe gefahrdet. Da der Pre-Shared Key fur symmetrische Verschlusselung eingesetzt wird, das heifit sowohl fur die Verschlusselung als auch zur Entschlusselung derselbe Schlussel zum Einsatz kommt, kann ein Angreifer bei Kenntnis des Gruppenpasswortes in einer Man In The Middle (MITM)-Attacke als Relais zwischen den User Devices und dem Edge Device auftreten. Dadurch ist es dem Angreifer moglich, den uber Sicherheitsprotokolle authentisierten und verschlusselten Datenverkehr zu manipulieren und abzuhoren (vergleiche „Man in the Middle“ [8, S. 211 ff.]).

Um eine Kompromittierung der gesamten Benutzergruppe beim Einsatz von XAUTH zu vermeiden, kann XAUTH folglich nur unter Verwendung eines Pre-Shared Key pro RAS-Benutzer, mit Public-Key-Verschlusselung oder digitalen Signaturen fur die Au- thentifizierung in Phase 1 sicher eingesetzt werden. Dies wurde jedoch den Zweck von XAUTH, nicht auf die Authentifizierung der Benutzer uber diese Authentifizierungsme- thoden umstellen zu mussen, ad absurdum fuhren.

Am Rande bemerkt trifft dieser Schwachpunkt von XAUTH ebenfalls auf L2TP-over- IPsec zu, welches die Authentifizierung der RAS-Benutzer uber LAMs durch die PPP- Mechanismen erlaubt. Die Verschlusselung der Benutzerauthentisierung findet uber ESP statt und setzt ahnlich XAUTH daher bereits eine gegenseitig und symmetrisch authentifizierte IPsec-Verbindung voraus.

Hybrid Authentication ist wiederum nur in Form eines Entwurfes (fur die letzte Fas- sung siehe [28]) spezifiziert. Sie dient wie XAUTH der Authentifizierung der Benutzer eines VPN durch den VPN-Gateway uber eine LAM. Es handelt sich dabei um eine Weiterentwicklung von XAUTH, die den erlauterten Schwachpunkt von XAUTH be- hebt. Hierfur wird im Gegensatz zu XAUTH ein anderer Ansatz verfolgt. Wahrend der XAUTH-Entwurf eine reine Erweiterung des IKE-Protokolls - namlich die Authenti- sierung gegenuber einem VPN-Gateway in einem zusatzlichen Phase-1.5-Austausch - spezifiziert, sieht der Hybrid-Authentication-Entwurf die Anderung der Phase 1 Austau- sche vor, um eine asymmetrische Authentifizierungen der Endpunkte zuzulassen. Fur die gegenseitige asymmetrische Authentifizierung der Endpunkte authentisiert sich in einem ersten Schritt, das heifit in Phase 1, der VPN-Gateway gegenuber dem Endpunkt eines RAS-Benutzers mit einem digitalen Zertifikat und der Endpunkt des RAS-Benutzers authentifiziert den VPN-Gateway mit einer digitalen Signatur. Danach wird bereits die ISAKMP-SA erzeugt. Diese ist zu diesem Zeitpunkt im Gegensatz zu einem traditionellen Phase 1 Austausch folglich nur unidirektional authentifiziert, das heifit die Kommu- nikation vom VPN-Gateway zum Endpunkt des RAS-Benutzers kann nicht gesichert werden. Dies genugt jedoch zur Verhinderung von MITM-Angriffen wahrend der gegen- seitigen Authentifizierung der Endpunkte, da durch die vorausgehende Authentifizierung des VPN-Gateway die Kommunikation vom Endpunkt des RAS-Benutzers zum VPN­Gateway und somit die Ubertragung der Authentisierungsdaten des Endpunktes des RAS-Benutzers uber die ISAKMP-SA authentisiert und verschlusselt werden kann. Fur die Authentifizierung des Endpunktes eines RAS-Benutzers uber eine LAM authentisiert sich dieser in einem zweiten Schritt analog zu XAUTH in einem Phase-1.5-Transaction- Austausch gegenuber dem VPN-Gateway mit einer Kombination aus Benutzername und Passwort oder ahnlichem. Damit ist die ISAKMP-SA nachtraglich bidirektional authentifiziert. Nach Phase 1.5 konnen mit Phase-2-Quick-Mode-Austausche die SAs fur die Sicherheitsprotokolle ausgehandelt werden.

Hybrid Authentication geht im Gegensatz zu XAUTH daher nicht zu Lasten der Sicherheit. Zum Einsatz einer Hybrid Authentication-Implementierung ist fur den VPN-Gateway ein digitales Zertifikat fur dessen Authentisierung auszustellen und der zur Uberprufung dieses Zertifikates benotigte Public-Key des Ausstellers den Endpunkten der RAS-Benutzer zur Verfugung zu stellen. Im Vergleich zur Ausgabe von jeweils unterschiedlichen Pre-Shared Keys oder eigenen digitalen Zertifikaten an die RAS-Benutzer - wie es fur den sicheren Einsatz von XAUTH notig ist - ist dieser Aufwand jedoch verhaltnismabig gering.

Sowohl der XAUTH- als auch der Hybrid-Authentication-Entwurf sind seit Mai 2000 be- ziehungsweise Februar 2001 ausgelaufen, ohne in RFCs ubergegangen zu sein. Der Ansatz der asymmetrischen Authentifizierung zusatzlich zur symmetrischen wurde jedoch in den zum Zeitpunkt dieser Diplomarbeit gultigen IKEv2-Entwurf [20] ubernommen. Im Gegen­satz zur Hybrid Authentication erfolgt bei IKEv2 die asymmetrische Authentifizierung vollstandig innerhalb von Phase 1.

1.3 Ausgangssituation: VPN der Universitat Regensburg

Vom Rechenzentrum der Universitat Regensburg wird fur die Universitat Regensburg seit Mitte 2003 ein VPN betrieben, uber das auf das Campus-LAN und das Internet zugegriffen werden kann. Das VPN ist auf Seiten des Rechenzentrums mit einem Cisco VPN 3030 Concentrator realisiert, der als VPN-Protokoll IPsec verwendet. Voraussetzungen fur die Nutzung des VPN sind ein an der Universitat Regensburg gultiger NDS-Account sowie die Installation der Cisco VPN Client in Form von Software auf dem Rechner des Benutzers.

Zur Authentisierung der Benutzer gegenuber dem VPN wird der beim VPN Client ange- gebene NDS-Account verwendet. Dieser wird mit XAUTH uber die RADIUS-Servers der Universitat authentisiert. Das VPN dient daher auch der Authentifizierung der Benutzer und der Verschlusselung des Datenverkehrs im Funknetz der Universitat Regensburg.

Ein weiteres Einsatzgebiet des VPN ist die Nutzung fur RAS uber das Internet, um Zugriff auf Servers und Dienste innerhalb des Campus-LAN zu erhalten, die auf Client-Seite eine IP-Adresse aus dem Pool der Universitat voraussetzen. Wahrend diese Zugriffe - falls die Dienste nicht alternativ auch uber die Web-Proxies der Universitat nutzbar sind - und derzeit das Funknetz die Benutzung des VPN zwingend voraussetzen, kann das VPN bei Bedarf auch innerhalb des Campus-LAN eingesetzt werden. So ist die Nutzung des VPN von den potentiell unsicheren Segmenten des Campus-LAN wie Computer-Investitions- Programm (CIP)-Pools und Wohnheimen aus moglich, um die Kommunikation mit zentralen Servers kryptographisch abzusichern.

1.3.1 Technische Daten und Leistungsmerkmale der Cisco VPN Hard- und Software

Der von der Universitat Regensburg eingesetzte Cisco VPN 3030 Concentrator gehort zur Familie der Cisco VPN 3000 Series Concentrators (fur die Produktseite auf der Homepage des Herstellers siehe [51]). Die Modelle 3020 bis 3080 dieser Familie basieren auf dem gleichen Grundmodell Cisco VPN 3015 Concentrator und unterscheiden sich von diesem durch die jeweils in der Standardkonfiguration ausgelieferte Grofie des Hauptspeichers, Anzahl und Art der Hardware-Crypto-Karten sowie Anzahl der Netzteile.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.3 zeigt einen Cisco VPN 3015 Concentrator, Abbildung 1.4 eine schematische Darstellung der Bestuckungsmoglichkeiten auf dessen Ruckseite.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.3: Cisco VPN 3015 Concentrator, basierend auf [52]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.4: Cisco VPN 3015 Concentrator - Bestuckungsmoglichkeiten [4, S. 2] (ENC1 - 4: Hardware-Crypto-Karten, PS1 - 2: Netzteile)

Die technischen Daten des Modells Cisco VPN 3030 Concentrator sind:

-Rack-mountbares 19-Zoll-Gehause mit zwei Hoheneinheiten,
-Motorola PowerPC (Performance optimization with enhanced Reduced Instruction Set Computer - Performance Computing) CPU (Central Processing Unit),
-128 MB Hauptspeicher (bis auf 512 MB erweiterbar),
-Flash-Speicher fur Bootloader, Betriebssystem, Konfigurations- und sonstige Datei- en (Logfiles, Statistiken et cetera), per FTP, SFTP (Secure File Transfer Protocol) und Web-Interface ansprechbar,
-optional zweites, redundantes Netzteil (im Cisco VPN 3030 der Universitat Regens­burg eingebaut),
-drei 10/100 Mbps (Megabit per Second) Ethernet-Interfaces (Ethernet 1 - Private, Ethernet 2 - Public und Ethernet 3 - External),
-ein SEP (Scalable Encryption Processing)-Modul (beherrscht DES- und 3DES- Verschlusselung in Hardware), je nach Performance-Bedarf optional auf bis zu vier SEP-Module erweiterbar, alternativ mit SEP-E (Enhanced Scalable Encryption Processing)-Modulen bestuckbar (beherrschen zusatzlich AES-Verschlusselung).

Die Leistungsmerkmale des Cisco VPN 3030 Concentrator sind:

-VPN-Protokolle IPsec, PPTP, L2TP und L2TP-over-IPsec sowie TLS (Letzteres nur fur den Zugriff per HTTPS) mit IPv4, Aufbau von End-to-Site-VPNs mit IPsec-, PPTP-, L2TP- und L2TP-over-IPsec-fahigen Clients (Konzentrator fungiert als Edge Device), Aufbau von Site-to-Site-VPNs mit anderen IPsec VPN-Gateways,
-Verschlusselungsalgorithmen DES mit 56-bit, 3DES mit 168-bit, MPPE mit 40-bit und 128-bit RC4 (Ron’s Code 4) sowie AES mit 128-, 192- und 256-bit, je nach Ausstattung mit SEP- und SEP-E-Modulen in Hard- oder Software,
-Authentisierungsalgorithmen MD5, SHA-1, HMAC-MD5 und HMAC-SHA-1,
-Authentifizierungsmethoden DSS- und RSA-Signaturen (auf Basis von X.509- Zertifikaten) sowie XAUTH (unter Verwendung eines Pre-Shared Key fur die Au- thentisierung in Phase 1) fur End-to-Site-VPNs, ab Firmware Version 4.7 zusatzlich CRACK (Challenge/Response for Authenticated Cryptographic Keys) und Hybrid Authentication (unter Verwendung eines X.509-Zertifikates fur die Authentisierung des Konzentrators und einer DSS- oder RSA-Signatur fur die Authentifizierung des Konzentrators) fur End-to-Site-VPNs, DSS- und RSA-Signaturen sowie Pre-Shared Keys fur Site-to-Site-VPNs,
-Kapselung von IKE und ESP in TCP- oder UDP-Paketen fur den Aufbau von VPN-Verbindungen uber NAT,
-Einteilung der End-to-Site-VPN-Benutzer in Gruppen mit verschiedenen Gruppen- passwortern und Rechten (Anzahl der gleichzeitigen IPsec-Verbindungen, maximale Verbindungsdauer et cetera),
-Authentifizierung der End-to-Site-VPN-Benutzer fur CRACK, Hybrid Authentica­tion und XAUTH uber interne Userbase (zusammen maximal 500 Benutzer und Gruppen) oder extern uber LAM (Kerberos/Active Directory, LDAP (Lightweight Directory Access Protocol), NT (New Technology) Domain, RADIUS, RSA Se- curlD),
-Accounting der End-to-Site-VPN-Benutzer uber RADIUS,
-Vergabe von virtuellen IP-Adressen an die End-to-Site-VPN Clients auf Basis von DHCP, LAM, auf dem Konzentrator konfigurierte Pools und der Vorgabe des jeweiligen VPN Client,
-zentrale Verwaltung von uber MODECFG zugewiesene Client-Policies (zu ver- wendende Domain Name System (DNS)- und Windows Internet Naming Ser­vice (WINS)-Server, Default Domain Name, Erlaubnis zur Speicherung des Be- nutzerpasswortes, Erlaubnis zum Zugriff auf Client-seitiges LAN bei bestehender VPN-Verbindung et cetera), Konfiguration der Client-Policies global oder pro Benutzergruppe,
-maximal 1500 IPsec-VPNs gleichzeitig, maximale Verschlusselungsleistung laut Hersteller 50 Mbps (maximale gemessene Datenrate bei UDP-Verkehr uber IPsec 70 Mbps mit 56-bit DES-Verschlusselung und 40 Mbps mit der an der Universitat Re­gensburg in der Standardkonfiguration verwendeten 168-bit 3DES-Verschlusselung),
-Paketfilter, anwendbar auf die Netzwerk-Interfaces und die VPNs,
-1:N NAT der virtuellen IP-Adressen von End-to-Site-VPNs sowie 1:N und N:N NAT der IP-Adressen in Site-to-Site-VPNs,
-Traffic-Shaping per Benutzergruppe oder per Netzwerk-Interface,
-Load-Balancing uber proprietares Protokoll sowie Fail-Over uber Virtual Router Redundancy Protocol (VRRP),
-Management uber HTTP (Hypertext Transfer Protocol Secure) und HTTPS (Web- Interface) sowie Telnet, Secure Shell (SSH) und serielle Konsole (Abbildung des Web-Interface auf Menu-Struktur),
-Monitoring via SNMP (Simple Network Management Protocol), Logging via Syslog, E-Mail, FTP, SNMP Traps und Web-Interface.
Fur die Nutzung des VPN der Universitat Regensburg wird auf der Seite der Benutzer in erster Linie die Cisco VPN Client Software (fur die Produktseite auf der Homepage des Herstellers siehe [53]) verwendet. Der Cisco VPN Client ist fur Apple Mac OS X, Linux/i386 und Linux/x86_64, Microsoft Windows 95, 98, ME, NT, 2000 und XP sowie Sun Solaris/sparc und Solaris/sparc64 verfugbar. Ein Cisco VPN 3000 Series Concentrator beinhaltet eine Lizenz fur die Benutzung des Cisco VPN Client durch eine unbeschrankte Anzahl an Nutzern.

Die Leistungsmerkmale des Cisco VPN Client sind:

-VPN-Protokoll IPsec mit IPv4, Aufbau von End-to-Site-VPNs mit IPsec-fahigen VPN-Gateways (Client fungiert als User Device),
-Verschlusselungsalgorithmen DES mit 56-bit, 3DES mit 168-bit, sowie AES mit 128-, 192- und 256-bit,
-Authentisierungsalgorithmen MD5, SHA-1, HMAC-MD5 und HMAC-SHA-1,
-Authentifizierungsmethoden RSA-Signaturen (auf Basis von X.509-Zertifikaten) sowie XAUTH (unter Verwendung eines Pre-Shared Key fur die Authentisierung in IKE Phase 1), ab Version 4.6 zusatzlich Hybrid Authentication (unter Verwendung einer RSA-Signatur fur die Authentifizierung des Konzentrators),
-Authentisierung der End-to-Site-VPN-Benutzer fur Hybrid Authentication und XAUTH mit Kombinationen aus Benutzername und Passwort (fur interne Userbase des Konzentrators, Kerberos/Active Directory, LDAP, NT Domain, und RADIUS) oder - fur RSA SecurlD - Kombinationen aus Benutzername und Personal Identifi­cation Number (PIN),
-Kapselung von IKE und ESP in TCP- oder UDP-Paketen fur den Aufbau von VPN-Verbindungen uber NAT,
-Zuweisung einer virtuellen IP-Adresse und von Policies (zu verwendende DNS- und WINS-Server, Default Domain Name, Erlaubnis zur Speicherung des Be- nutzerpasswortes, Erlaubnis zum Zugriff auf Client-seitiges LAN bei bestehender VPN-Verbindung et cetera) durch das Edge Device uber MODECFG,
-mehrere VPNs uber Verbindungsprofile konfigurierbar,
-Beantragung von X.509-Zertifikaten uber Simple Certificate Enrollment Proto­col (SCEP),
-Paketfilter (verwendet feste Regeln), kompatibel mit Personal-Firewall-Produkten von BlackIce, Sygate und Zone Labs,
-automatische Initiierung einer VPN-Verbindung beim Etablieren einer WLAN- Verbindung,
-automatische Initiierung einer VPN-Verbindung fur ein Microsoft Network Login unter Microsoft Windows 2000, NT und XP,
-ab Version 4.6 automatische Updates des Client unterMicrosoft Windows 2000 und XP,
-grafische Versionen fur Apple Mac OS X und Microsoft Windows, Kommandozei- lenversionen fur alle unterstutzten Betriebssysteme,
-Installer anpassbar fur die automatische Installation von Verbindungsprofilen und X.509-CA-Zertifikaten.

1.3.2 VPN-Topologie an der Universitat Regensburg

Abbildung 1.5 zeigt die VPN-Topologie an der Universität Regensburg einschließlich der Nutzung des Cisco VPN 3030 Concentrator zum Aufbau von End-to-Site-VPNs durch die Benutzer der drei Gruppen „intern“, „internet“ und „wlan“. Site-to-Site-VPNs werden mit dem Cisco VPN 3030 Concentrator keine betrieben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.5: VPN-Topologie an der Universitat Regensburg

Im Detail werden die drei Ethernet-Interfaces des Cisco VPN 3030 Concentrator wie folgt verwendet:

-Ethernet 1 - Private

dient primar den virtuellen IP-Adressen der VPNs als Default-Router zum Backbone- Segment der Universitat Regensburg und uber dieses zum Campus-LAN und zum Internet, dient ebenfalls als Endpunkt-Interface fur VPNs der Benutzergruppe „intern“.

-Ethernet 2 - Public

ist uber den Gigabit-Wissenschaftsnetz (G-WiN)-Router parallel zum Backbone der Universitat Regensburg am G-WiN und damit am Internet angeschlossen. Benutzer der Gruppe „internet“ benutzen dieses Ethernet-Interface als Endpunkt-Interface fur VPNs.

- Ethernet 3 - External

Das Funknetz der Universitat Regensburg ist uber dieses Ethernet-Interface an- gebunden. Dieses Netz verwendet IP-Adressen aus dem RFC 1918 [40]-Class-B- Netz 172.29.0.0/16. Der VPN-Konzentrator dient hier als DHCP-Relay fur die Vergabe dieser IP-Adressen und als deren Default-Router. Vom Paketfilter des VPN-Konzentrators werden Pakete von 172.29.0.0/16 nur zu wenigen ausgewahlten Servers im Backbone-Segment erlaubt, wie zum Beispiel zu den DNS-Servers und zum Web-Server, von dem der Cisco VPN Client bezogen werden kann. Den Benut- zern der Gruppe „internet“ dient das External-Interface als Endpunkt-Interface fur VPNs. Uber eine VPN-Verbindung konnen diese Benutzer uneingeschrankt auf das Campus-LAN und das Internet zugreifen.

Der Paketfilter des Cisco VPN 3030 Concentrator ist restriktiv konfiguriert und lasst uber die Ethernet-Interfaces mit Ausnahme von und zu den virtuellen IP-Adressen der VPNs nur wenig IP-Verkehr zu. Zugelassen sind neben dem bereits erwahnten Zugriff auf die DNS-Server und den Web-Server mit dem Cisco VPN Client vom Funknetz aus in erster Linie nur VPN-Verbindungen mit dem Konzentrator als Endpunkt, Zugriffe vom Konzentrator aus auf benotigte Server im Backbone-Segment wie RADIUS- und Syslog-Server sowie Zugriffe auf den Konzentrator und Access-Points im Funknetz von bestimmten Management-Rechnern aus. Der IP-Verkehr von und zu den virtuellen IP- Adressen der VPNs wird auf dem Konzentrator nicht eingeschrankt, aber von Campus- und G-WiN-Router analog zum restlichen IP-Verkehr des Campus-LAN gefiltert.

Die Einteilung der Benutzer in die Gruppen „intern“, „internet“ und „wlan“ dient primar der Erstellung drei gleichnamiger Verbindungsprofile fur den Cisco VPN Client, da die Cisco VPN 3000 Series Concentrators auf die Nutzung des aus Netzwerk-Sicht dem jeweiligen User Device nachstgelegenen Ethernet-Interface als Endpunkt-Interface limitiert sind, das heifit auf einem Cisco VPN 3000 Series Concentrator konnen keine IPsec-Verbindungen uber ein Ethernet-Interface zu einem anderen als Endpunkt-Interface fungierenden Ethernet-Interface geroutet werden. Eine IPsec-Verbindung vom Campus-LAN aus zum Public-Interface des Cisco VPN 3030 Concentrator der Universitat Regensburg ist somit nicht moglich. Die Bereitstellung der drei Verbindungsprofile mit den drei entsprechenden Hostnames der Ethernet-Interfaces des Konzentrators vereinfacht fur die Benutzer daher die Auswahl des jeweils zutreffenden Eintrages im Cisco VPN Client.

Daneben werden die verschiedenen Gruppen fur die Erstellung von Statistiken uber das Nutzungsverhalten der VPN-Benutzer per SNMP herangezogen.

1.3.3 Nutzung des VPN aus Benutzersicht

An dieser Stelle wird die Nutzung des VPN der Universitat Regensburg aus Sicht der Benutzer beschrieben. Reprasentativ hierfur wird der manuelle Aufbau einer VPN- Verbindung mit der graphischen Version des Cisco VPN Client unter Microsoft Win­dows XP gezeigt. Unter den anderen unterstutzten Microsoft Windows Versionen und unter Apple Mac OS X ist diese identisch zu bedienen. Fur Sun Solaris und GNU’s Not Unix (GNU)/Linux-basierte Betriebssysteme steht nur die Kommandozeilenversion des Cisco VPN Client zur Verfugung. Diese ist unter allen unterstutzten Betriebssyste- men identisch zu bedienen und die fur den Aufbau einer VPN-Verbindung notwendigen Schritte entsprechen den in der graphischen Version.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.6: Cisco VPN Client - Auswahl der Verbindungsprofile

Nach dem Laden der graphischen Version des Cisco VPN Client prasentiert sich dieser unter Windows XP mit der in Abbildung 1.6 gezeigten Benutzeroberflache. Unter dem Reiter „Connection Entries“ ist fur den Aufbau einer VPN-Verbindung mit der Universitat Regensburg vom Benutzer aus dem in 1.3.2 erlauterten Grund das fur seine Netzwerk- Anbindung zutreffende Verbindungsprofil auszuwahlen. Diese Verbindungsprofile werden in der fur die Universitat Regensburg angepassten Version des Installer des Cisco VPN Client automatisch mitinstalliert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.7: Cisco VPN Client - Abfrage nach Benutzername und Passwort

Nach einem Klick auf „Connect“ wird (Erreichbarkeit des VPN-Konzentrators der Uni­versitat Regensburg vorausgesetzt) mit dem ausgewahlten Verbindungsprofil eine VPN- Verbindung initiiert und es erscheint die in Abbildung 1.7 dargestellte Abfrage nach Be­nutzername und Passwort. Hier muss sich der Benutzer mit seinem NDS-Benutzernamen und -Passwort authentisieren, wobei die Kurzform des NDS-Benutzernamens bestehend aus drei Buchstaben und funf Ziffern ausreicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.8: Cisco VPN Client - Banner-Meldung

Nach erfolgreicher Authentifizierung des Benutzers erscheint ein Fenster mit einer vom gewahlten Verbindungsprofil abhangigen Banner-Meldung. Zu diesem Zeitpunkt ist die VPN-Verbindung bereits vollstandig etabliert. Abbildung 1.8 zeigt die Banner-Meldung einer VPN-Verbindung unter Auswahl des Verbindungsprofils „intern“. Wird in diesem Fenster auf „ContinueInternet“ geklickt, minimiert sich der Cisco VPN Client auf das Sym­bol eines geschlossenen Schlosses in der TaskInternet-Leiste. Ein Klick auf „Disconnect“ baut die VPN-Verbindung wieder ab.

Uber die etablierte VPN-Verbindung kann der Benutzer auf das Campus-LAN der Universitat Regensburg und das Internet zugreifen. Wie in Abbildung 1.9 am Beispiel

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.9: Traceroute uber VPN-Verbindung zur Universitat Regensburg

von Traceroute gezeigt, lauft der gesamte IP-Verkehr des Rechners des Benutzers (mit Ausnahme von und zu 127.0.0.1) uber den VPN-Tunnel und den VPN-Konzentrator.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.10: Cisco VPN Client – VPN-Verbindung aufgebaut

Wird der Cisco VPN Client maximiert, ist bei bestehender VPN-Verbindung der entspre- chende Eintrag in der Auswahl der Verbindungsprofile mit dem Symbol des geschlossenen Schlosses markiert (vergleiche Abbildung 1.10). Mit einem Klick auf „Disconnect“ kann der Benutzer die VPN-Verbindung abbauen.

Alternativ zum Abbau der VPN-Verbindung kann der Benutzer bei bestehender VPN- Verbindung im Menu „Status“ des Cisco VPN Client unter dem Menupunkt „Statistics“

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.11: Cisco VPN Client - Statistik

die in Abbildung 1.11 dargestellte Statistik abrufen. Diese enthalt neben Informatio- nen wie die Menge der uber die VPN-Verbindung ubertragenen Daten und die Ver- bindungsdauer auch die zwischen den beiden VPN-Endpunkten uber IKE fur ESP ausgehandelten Authentisierungs- und Verschlusselungsalgorithmen, die IP-Adresse des VPN-Konzentrators (Address Information Server) sowie die dem Rechner des Benutzers uber MODECFG zugewiesene virtuelle IP-Adresse (Address Information Client).

1.3.4 Nutzung des VPN aus technischer Sicht

Die Nutzung des VPN der Universitat Regensburg aus technischer Sicht wird anhand des Netzwerkanalyse-Listing in Anhang A erlautert. Als Packet Analyzer wurde Ethereal [56] in Version 0.10.12 verwendet. Das Capturing der Pakete erfolgte an einem Ethernet-Hub, der mit dem Public-Interface eines Cisco VPN 3030 Concentrator und einem Switch im Campus-LAN verbunden war. Das Listing zeigt den Aufbau einer IPsec-Verbindung, den Aufbau einer FTP-Verbindung uber diese IPsec-Verbindung und den Abbau der IPsec-Verbindung von einem PC (IP-Adresse 172.27.1.249) aus zum Public-Interface (IP-Adresse 194.94.155.251) des VPN-Konzentrators. Auf dem PC kam der Cisco VPN Client unter Microsoft Windows 98 zum Einsatz.

Im genannten Listing wurden alle Pakete bis auf die Kommunikation zwischen diesen beiden Stationen herausgefiltert, um den Anhang nicht unnotig in die Lange zu ziehen. Gefiltert wurden in erster Linie Routing Information Protocol (RIP)- und Spanning

Tree Protocol (STP)-Meldungen. Die FTP-Verbindung ist ebenfalls gekurzt, da sie uber ESP verschlusselt wurde und weitere ESP-Pakete an dieser Stelle keine zusatzlichen Informationen liefern wurden.

Die Frames 8, 9 und 10 des Listing sind der eineinhalb Round-Trips benotigende Phase- 1-Aggressive-Mode-Austausch zwischen den beiden Stationen:

Abbildung in dieser Leseprobe nicht enthalten

Die zu verwendende Variante des Phase 1 Austausches, das heibt Main Mode oder Aggressive Mode ist beim Cisco VPN Client nicht konfigurierbar, sondern wird von diesem selbststandig gewahlt (im Gegensatz hierzu lasst sich auf Cisco VPN 3000 Series Concentrators die Variante des Phase 1 Austausches fur IPsec-Verbindungen, die von diesen VPN-Konzentratoren initiiert werden, konfigurieren).

In Frame 8, Zeile 32 bis 193, sind die 14 vom Cisco VPN Client vorgeschlagenen Kombina- tionen aus Verschlusselungs- und Hash-Algorithmen, Authentifizierungsmethoden sowie MODP-Gruppen in Form der verschickten Transform Payload Meldungen ersichtlich.

Vom Cisco VPN Client wird der offentliche Teil des Diffie-Hellman-Schlusselaustausches im folgenden Key Exchange Payload verschickt:

Abbildung in dieser Leseprobe nicht enthalten

Danach folgt die Nonce (im Fall der Authentifizierung mit einem Pre-Shared Key ver- schlusselt) fur die Authentifizierung des VPN-Konzentrators:

Abbildung in dieser Leseprobe nicht enthalten

Die Identitat des User Device wird in folgender Identification Payload Meldung mitgeteilt:

Abbildung in dieser Leseprobe nicht enthalten

Diese Identitat ist vom Typ KEY_ID, das heifit es wird ein Verweis auf den zu ver- wendenden Pre-Shared Key eingesetzt (und damit die Verwendung eines Aggressive- Mode-Austausches notig). Vermutlich wird hieruber dem VPN-Konzentrator die gewahlte Benutzergruppe mitgeteilt. Als Pre-Shared Key fur XAUTH verwendet der Cisco VPN Client und die Cisco VPN 3000 Series Concentrators das Gruppenpasswort der gewahlten Benutzergruppe.

In den Zeilen 209 bis 228 sind die vom Cisco VPN Client per Vendor ID Payload vorge- schlagenen IKE-Erweiterungen ersichtlich, die mit Ausnahme der letzten von Ethereal identifiziert werden konnte:

Abbildung in dieser Leseprobe nicht enthalten

In Frame 9 bestatigt der VPN-Konzentrator die vorgeschlagene Kombination aus 3DES-CBC, MD5, XAUTH mit Pre-Shared Key und MODP-Gruppe 2 mit einer Gultig- keit der ISAKMP-SA von 2147483 Sekunden (knapp 25 Tage):

Abbildung in dieser Leseprobe nicht enthalten

Die Auswahl der Kombination aus Verschlusselungs- und Hash-Algorithmen, Authentifi- zierungsmethoden sowie MODP-Gruppen durch den Cisco VPN 3030 Concentrator erfolgt auf Basis der fur die gewahlte Benutzergruppe auf dem VPN-Konzentrator getroffenen Einstellungen.

Danach folgt der offentliche Teil des VPN-Konzentrators im Diffie-Hellman- Schlusselaustausch:

Abbildung in dieser Leseprobe nicht enthalten

wiederum gefolgt von der - im Fall der Authentifizierung mit einem Pre-Shared Key verschlusselten - Nonce fur die Authentifizierung des Cisco VPN Client:

Abbildung in dieser Leseprobe nicht enthalten

Als Identitat des Edge Device wird im Identification Payload dessen IP-Adresse verwendet. Diese wird - wie fur einen Aggressive-Mode-Austausch zu erwarten ist - als Klartext ubertragen:

Abbildung in dieser Leseprobe nicht enthalten

Mit dem Hash-Wert, der unter Einbeziehung der entschlusselten Nonce aus dem Nonce Payload von Zeile 198 berechnet wurde, im folgenden Hash Payload wird der VPN- Konzentrator vom Cisco VPN Client authentifiziert:

Abbildung in dieser Leseprobe nicht enthalten

Des Weiteren werden die vom Cisco VPN Client vorgeschlagenen IKE-Erweiterungen bestatigt und der in RFC 3947 fur NAT-Traversal spezifizierte NAT Discovery (NAT-D) Payload verschickt:

Abbildung in dieser Leseprobe nicht enthalten

Ungewohnlich sind hier die beiden letzten Vendor ID Payloads, in denen vom VPN- Konzentrator Vendor IDs bestatigt werden, die zuvor vom Cisco VPN Client nicht vorge- schlagen wurden und von Ethereal auch nicht dekodiert werden konnten. Die IPsec-RFCs treffen zu einer derartigen Verwendung der Vendor IDs keine Aussage. Es konnte sich daher um eine proprietares Verhalten des Cisco VPN 3030 Concentrator handeln, nachdem durch die in Frame 8 vorgeschlagene Vendor ID 0x12F5F28C457168A9702D9FE274CC0100 ein Cisco VPN Client als User Device erkannt wurde.

Beginnend mit Frame 10, dem letzten Frame des Phase-1-Aggressive-Mode-Austausches, findet die IKE-Kommunikation zwischen den beiden Stationen - wie in Zeile 342 ersicht- lich - - nur noch verschlusselt statt:

Abbildung in dieser Leseprobe nicht enthalten

Der IKE-Payload kann ab dieser Stelle daher nicht mehr dekodiert werden und uber die ubermittelten Meldungen konnen nur noch Vermutungen anhand des Typs der Austausche getroffen werden. Beim verschlusselten Payload von Frame 10 muss es sich beispielsweise um den Hash-Wert handeln, der unter Einbeziehung der entschlusselten Nonce aus dem Nonce Payload von Zeile 276 berechnet wurde und mit dem der Cisco VPN Client vom VPN-Konzentrator authentifiziert wird. Damit ist der Phase-1-Aggressive-Mode- Austausch abgeschlossen.

Die Frames 11, 28, 29, 30, 32 und 34 sind Phase-1.5-Transaction-Austausche zwischen den Devices:

Abbildung in dieser Leseprobe nicht enthalten

Nach Erhalt von Frame 11 fragt der Cisco VPN Client nach Benutzername und Pass- wort und versendet nach deren Eingabe Frame 28. Mit diesen Frames werden daher offensichtlich die Authentisierungsdaten des Benutzers wie fur XAUTH charakteristisch per MODECFG angefragt und ubertragen. Der VPN-Konzentrator authentifiziert die- se Angaben anhand der beiden RADIUS-Servers der Universitat Regensburg, wobei einer dieser Servers als primarer RADIUS-Server eingetragen ist und der zweite nur angefragt wird, falls der erste nicht innerhalb des konfigurierten Zeitintervalls antwortet. Die RADIUS-Servers uberprufen die angegebene Kombination aus Benutzername und Passwort ihrerseits anhand einer Bound-Search auf einem LDAP Directory Server, welcher den NDS-Baum von Fachhochschule und Universitat Regensburg bereitstellt.

In den Frames 29 und 30 wird vermutlich die erfolgreiche Authentifizierung des User Device bestatigt und in den Frames 32 und 34 vom Cisco VPN Client die zu verwendende virtuelle IP-Adresse und die Client-Policies mit dem Request/Acknowledge-Verfahren abgefragt. In der Konfiguration der Universitat Regensburg werden zum Beispiel die Speicherung des Benutzerpasswortes durch den Cisco VPN Client und der Zugriff auf ein eventuell vorhandenes LAN, an das der Rechner des Benutzers angebunden ist, bei bestehender VPN-Verbindung per Client-Policies unterbunden.

Die Frames 35, 37 und 38 sind Phase-2-Quick-Mode-Austausche zur Aushandlung einer SA fur das Sicherheitsprotokoll zwischen den Devices:

Abbildung in dieser Leseprobe nicht enthalten

Auf den Cisco VPN 3000 Series Concentrators und dem Cisco VPN Client lasst sich das zu verwendende Sicherheitsprotokoll allerdings nicht konfigurieren und es wird stets ESP verwendet.

Bei Frame 36 handelt es sich um eine vom VPN-Konzentrator gesendete Meldung eines verschlusselten Informational-Austausches:

Abbildung in dieser Leseprobe nicht enthalten

Die Bedeutung dieser Meldung ist unklar, da die IKE- und ISAKMP-RFCs keinen Informational-Austausch zu diesem Zeitpunkt vorschreiben.

Die Frames 94 bis 97 sind der Anfang einer auf dem PC initiierten FTP-Verbindung zu einem FTP-Server im Campus-LAN. Zwischen PC und VPN-Konzentrator werden die zugehorigen IP-Pakete uber ESP verschlusselt ubertragen und es kann folglich nur der vom jeweiligen Device fur die ESP SA verwendete SPI dekodiert werden:

Abbildung in dieser Leseprobe nicht enthalten

[...]